Re: [Intel-gfx] NVIDIA GPU fallen off the bus after exiting s2idle
Hi, > -Original Message- > From: Intel-gfx On Behalf Of Chris > Chiu > Sent: perjantai 21. toukokuuta 2021 7.02 > To: Rafael J. Wysocki > Cc: Brown, Len ; Karol Herbst ; Linux > PM ; Linux PCI ; > Westerberg, Mika ; Rafael J. Wysocki > ; dri-devel ; Bjorn > Helgaas > ; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] NVIDIA GPU fallen off the bus after exiting s2idle > > On Thu, May 6, 2021 at 5:46 PM Rafael J. Wysocki wrote: > > > > On Tue, May 4, 2021 at 10:08 AM Chris Chiu wrote: > > > > > > Hi, > > > We have some Intel laptops (11th generation CPU) with NVIDIA GPU > > > suffering the same GPU falling off the bus problem while exiting > > > s2idle with external display connected. These laptops connect the > > > external display via the HDMI/DisplayPort on a USB Type-C interfaced > > > dock. If we enter and exit s2idle with the dock connected, the > > > NVIDIA GPU (confirmed on 10de:24b6 and 10de:25b8) and the PCIe port > > > can come back to D0 w/o problem. If we enter the s2idle, disconnect > > > the dock, then exit the s2idle, both external display and the panel > > > will remain with no output. The dmesg as follows shows the "nvidia > :01:00.0: > > > can't change power state from D3cold to D0 (config space > > > inaccessible)" due to the following ACPI error [ 154.446781] [ > > > 154.446783] [ 154.446783] Initialized Local Variables for Method > > > [IPCS]: > > > [ 154.446784] Local0: 9863e365 Integer > > > 09C5 [ 154.446790] [ 154.446791] Initialized Arguments > > > for Method [IPCS]: (7 arguments defined for method invocation) [ > > > 154.446792] Arg0: 25568fbd Integer 00AC [ > > > 154.446795] Arg1: 9ef30e76 Integer [ > > > 154.446798] Arg2: fdf820f0 Integer 0010 [ > > > 154.446801] Arg3: 9fc2a088 Integer 0001 [ > > > 154.446804] Arg4: 3a3418f7 Integer 0001 [ > > > 154.446807] Arg5: 20c4b87c Integer [ > > > 154.446810] Arg6: 8b965a8a Integer [ > > > 154.446813] [ 154.446815] ACPI Error: Aborting method \IPCS due to > > > previous error > > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446824] ACPI > > > Error: Aborting method \MCUI due to previous error > > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446829] ACPI > > > Error: Aborting method \SPCX due to previous error > > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446835] ACPI > > > Error: Aborting method \_SB.PC00.PGSC due to previous error > > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446841] ACPI > > > Error: Aborting method \_SB.PC00.PGON due to previous error > > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446846] ACPI > > > Error: Aborting method \_SB.PC00.PEG1.NPON due to previous error > > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446852] ACPI > > > Error: Aborting method \_SB.PC00.PEG1.PG01._ON due to previous error > > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446860] acpi > > > device:02: Failed to change power state to D0 [ 154.690760] video > > > LNXVIDEO:00: Cannot transition to power state D0 for parent in > > > (unknown) > > > > If I were to guess, I would say that AML tries to access memory that > > is not accessible while suspended, probably PCI config space. > > > > > The IPCS is the last function called from \_SB.PC00.PEG1.PG01._ON > > > which we expect it to prepare everything before bringing back the > > > NVIDIA GPU but it's stuck in the infinite loop as described below. > > > Please refer to > > > https://gist.github.com/mschiu77/fa4f5a97297749d0d66fe60c1d421c44 > > > for the full DSDT.dsl. > > > > The DSDT alone may not be sufficient. > > > > Can you please create a bug entry at bugzilla.kernel.org for this > > issue and attach the full output of acpidump from one of the affected > > machines to it? And please let me know the number of the bug. > > > > Also please attach the output of dmesg including a suspend-resume > > cycle including dock disconnection while suspended and the ACPI > > messages quoted below. > > > > >While (One) > > > { > > > If ((!IBSY || (IERR == One))) > > > { > > > Break > > > } > > > > > > If ((Local0 > TMOV)) > > > { > > > RPKG [Zero] = 0x03 > > > Return (RPKG) /* \IPCS.RPKG */ > > > } > > > > > > Sleep (One) > > > Local0++ > > > } > > > > > > And the upstream PCIe port of NVIDIA seems to become inaccessible > > > due to the messages as follows. > > > [ 292.746508] pcieport :00:01.0: waiting 100 ms for downstream > > > link, after activation [ 292.882296] pci :01:00.0: waiting > > > additional 100 ms to become accessible [ 316.876997] pci > > > :01:00.0: can't change power state from D
Re: [Intel-gfx] [CI 3/5] drm/i915/dmc: Rename macro names containing csr
On Tue, 18 May 2021, Lucas De Marchi wrote: > On Tue, May 18, 2021 at 02:34:42PM -0700, Anusha Srivatsa wrote: >>Rename all occurences of CSR_* with DMC_* >> >>Cc: Jani Nikula >>Signed-off-by: Anusha Srivatsa > > > Reviewed-by: Lucas De Marchi We failed to take GVT into account, and apparently neither CI or Anusha has CONFIG_DRM_I915_GVT=y. They use the register definitions, and this broke the build. Anusha, please enable the config, and fix the fallout. Cc: the patch to GVT folks for ack. Thanks, Jani. > > Lucas De Marchi > >>--- >> drivers/gpu/drm/i915/display/intel_csr.c | 167 +- >> drivers/gpu/drm/i915/display/intel_csr.h | 6 +- >> .../drm/i915/display/intel_display_debugfs.c | 16 +- >> .../drm/i915/display/intel_display_power.c| 14 +- >> drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- >> drivers/gpu/drm/i915/i915_reg.h | 28 +-- >> 6 files changed, 117 insertions(+), 118 deletions(-) >> >>diff --git a/drivers/gpu/drm/i915/display/intel_csr.c >>b/drivers/gpu/drm/i915/display/intel_csr.c >>index 5ed286dc6720..f2124796ce77 100644 >>--- a/drivers/gpu/drm/i915/display/intel_csr.c >>+++ b/drivers/gpu/drm/i915/display/intel_csr.c >>@@ -30,10 +30,9 @@ >> #include "intel_de.h" >> >> /** >>- * DOC: csr support for dmc >>+ * DOC: DMC firmware support >> * >>- * Display Context Save and Restore (CSR) firmware support added from gen9 >>- * onwards to drive newly added DMC (Display microcontroller) in display >>+ * From gen9 onwards we have newly added DMC (Display microcontroller) in >>display >> * engine to save and restore the state of display engine when it enter into >> * low-power state and comes back to normal. >> */ >>@@ -44,55 +43,55 @@ >> __stringify(major) "_" \ >> __stringify(minor) ".bin" >> >>-#define GEN12_CSR_MAX_FW_SIZEICL_CSR_MAX_FW_SIZE >>+#define GEN12_DMC_MAX_FW_SIZEICL_DMC_MAX_FW_SIZE >> >>-#define ADLS_CSR_PATHDMC_PATH(adls, 2, 01) >>-#define ADLS_CSR_VERSION_REQUIREDCSR_VERSION(2, 1) >>-MODULE_FIRMWARE(ADLS_CSR_PATH); >>+#define ADLS_DMC_PATHDMC_PATH(adls, 2, 01) >>+#define ADLS_DMC_VERSION_REQUIREDDMC_VERSION(2, 1) >>+MODULE_FIRMWARE(ADLS_DMC_PATH); >> >>-#define DG1_CSR_PATH DMC_PATH(dg1, 2, 02) >>-#define DG1_CSR_VERSION_REQUIRED CSR_VERSION(2, 2) >>-MODULE_FIRMWARE(DG1_CSR_PATH); >>+#define DG1_DMC_PATH DMC_PATH(dg1, 2, 02) >>+#define DG1_DMC_VERSION_REQUIRED DMC_VERSION(2, 2) >>+MODULE_FIRMWARE(DG1_DMC_PATH); >> >>-#define RKL_CSR_PATH DMC_PATH(rkl, 2, 02) >>-#define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 2) >>-MODULE_FIRMWARE(RKL_CSR_PATH); >>+#define RKL_DMC_PATH DMC_PATH(rkl, 2, 02) >>+#define RKL_DMC_VERSION_REQUIRED DMC_VERSION(2, 2) >>+MODULE_FIRMWARE(RKL_DMC_PATH); >> >>-#define TGL_CSR_PATH DMC_PATH(tgl, 2, 08) >>-#define TGL_CSR_VERSION_REQUIRED CSR_VERSION(2, 8) >>-MODULE_FIRMWARE(TGL_CSR_PATH); >>+#define TGL_DMC_PATH DMC_PATH(tgl, 2, 08) >>+#define TGL_DMC_VERSION_REQUIRED DMC_VERSION(2, 8) >>+MODULE_FIRMWARE(TGL_DMC_PATH); >> >>-#define ICL_CSR_PATH DMC_PATH(icl, 1, 09) >>-#define ICL_CSR_VERSION_REQUIRED CSR_VERSION(1, 9) >>-#define ICL_CSR_MAX_FW_SIZE 0x6000 >>-MODULE_FIRMWARE(ICL_CSR_PATH); >>+#define ICL_DMC_PATH DMC_PATH(icl, 1, 09) >>+#define ICL_DMC_VERSION_REQUIRED DMC_VERSION(1, 9) >>+#define ICL_DMC_MAX_FW_SIZE 0x6000 >>+MODULE_FIRMWARE(ICL_DMC_PATH); >> >>-#define CNL_CSR_PATH DMC_PATH(cnl, 1, 07) >>-#define CNL_CSR_VERSION_REQUIRED CSR_VERSION(1, 7) >>-#define CNL_CSR_MAX_FW_SIZE GLK_CSR_MAX_FW_SIZE >>-MODULE_FIRMWARE(CNL_CSR_PATH); >>+#define CNL_DMC_PATH DMC_PATH(cnl, 1, 07) >>+#define CNL_DMC_VERSION_REQUIRED DMC_VERSION(1, 7) >>+#define CNL_DMC_MAX_FW_SIZE GLK_DMC_MAX_FW_SIZE >>+MODULE_FIRMWARE(CNL_DMC_PATH); >> >>-#define GLK_CSR_PATH DMC_PATH(glk, 1, 04) >>-#define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 4) >>-#define GLK_CSR_MAX_FW_SIZE 0x4000 >>-MODULE_FIRMWARE(GLK_CSR_PATH); >>+#define GLK_DMC_PATH DMC_PATH(glk, 1, 04) >>+#define GLK_DMC_VERSION_REQUIRED DMC_VERSION(1, 4) >>+#define GLK_DMC_MAX_FW_SIZE 0x4000 >>+MODULE_FIRMWARE(GLK_DMC_PATH); >> >>-#define KBL_CSR_PATH DMC_PATH(kbl, 1, 04) >>-#define KBL_CSR_VERSION_REQUIRED CSR_VERSION(1, 4) >>-#define KBL_CSR_MAX_FW_SIZE BXT_CSR_MAX_FW_SIZE >>-MODULE_FIRMWARE(KBL_CSR_PATH); >>+#define KBL_DMC_PATH DMC_PATH(kbl, 1, 04) >>+#define KBL_DMC_VERSION_REQUIRED DMC_VERSION(1, 4) >>+#define KBL_DMC_MAX_FW_SIZE BXT_DMC_MAX_FW_SIZE >>+MODULE_FIRMWARE(KBL_DMC_PATH); >> >>-#define SKL_CSR_PATH DMC_PATH(skl, 1, 27) >>-#define SKL_CSR_VERSION_REQUIRED CSR_VERSION(1, 27) >>
Re: [Intel-gfx] [RFC PATCH 1/5] drm/ttm: Add a generic TTM memcpy move for page-based iomem
Am 20.05.21 um 17:09 schrieb Thomas Hellström: The internal ttm_bo_util memcpy uses ioremap functionality, and while it probably might be possible to use it for copying in- and out of sglist represented io memory, using io_mem_reserve() / io_mem_free() callbacks, that would cause problems with fault(). Instead, implement a method mapping page-by-page using kmap_local() semantics. As an additional benefit we then avoid the occasional global TLB flushes of ioremap() and consuming ioremap space, elimination of a critical point of failure and with a slight change of semantics we could also push the memcpy out async for testing and async driver development purposes. A special linear iomem iterator is introduced internally to mimic the old ioremap behaviour for code-paths that can't immediately be ported over. This adds to the code size and should be considered a temporary solution. Looking at the code we have a lot of checks for iomap tagged pointers. Ideally we should extend the core memremap functions to also accept uncached memory and kmap_local functionality. Then we could strip a lot of code. Cc: Christian König Signed-off-by: Thomas Hellström --- drivers/gpu/drm/ttm/ttm_bo_util.c | 468 -- include/drm/ttm/ttm_bo_driver.h | 94 ++ 2 files changed, 407 insertions(+), 155 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index ae8b61460724..bad9b16e96ba 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -35,11 +35,13 @@ #include #include #include +#include #include #include #include #include #include +#include struct ttm_transfer_obj { struct ttm_buffer_object base; @@ -72,190 +74,366 @@ void ttm_mem_io_free(struct ttm_device *bdev, mem->bus.addr = NULL; } -static int ttm_resource_ioremap(struct ttm_device *bdev, - struct ttm_resource *mem, - void **virtual) +static pgprot_t ttm_prot_from_caching(enum ttm_caching caching, pgprot_t tmp) Could you move this to ttm_module.c, creating a separate ttm_caching.c sounds overkill but it is rather independent from the BO object. { - int ret; - void *addr; + /* Cached mappings need no adjustment */ + if (caching == ttm_cached) + return tmp; - *virtual = NULL; - ret = ttm_mem_io_reserve(bdev, mem); - if (ret || !mem->bus.is_iomem) - return ret; +#if defined(__i386__) || defined(__x86_64__) + if (caching == ttm_write_combined) + tmp = pgprot_writecombine(tmp); + else if (boot_cpu_data.x86 > 3) + tmp = pgprot_noncached(tmp); +#endif +#if defined(__ia64__) || defined(__arm__) || defined(__aarch64__) || \ + defined(__powerpc__) || defined(__mips__) + if (caching == ttm_write_combined) + tmp = pgprot_writecombine(tmp); + else + tmp = pgprot_noncached(tmp); +#endif +#if defined(__sparc__) + tmp = pgprot_noncached(tmp); +#endif + return tmp; +} - if (mem->bus.addr) { - addr = mem->bus.addr; - } else { - size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT; +static void ttm_kmap_iter_tt_kmap_local(struct ttm_kmap_iter *iter, + struct dma_buf_map *dmap, + pgoff_t i) I really like the idea of the iterator, but I think we should move the code for iterating over TT and iterating over resource object to ttm_tt.c and ttm_resource.c respectively. +{ + struct ttm_kmap_iter_tt *iter_tt = + container_of(iter, typeof(*iter_tt), base); - if (mem->bus.caching == ttm_write_combined) - addr = ioremap_wc(mem->bus.offset, bus_size); -#ifdef CONFIG_X86 - else if (mem->bus.caching == ttm_cached) - addr = ioremap_cache(mem->bus.offset, bus_size); -#endif - else - addr = ioremap(mem->bus.offset, bus_size); - if (!addr) { - ttm_mem_io_free(bdev, mem); - return -ENOMEM; - } + dma_buf_map_set_vaddr(dmap, kmap_local_page_prot(iter_tt->tt->pages[i], +iter_tt->prot)); +} + +static void ttm_kmap_iter_iomap_kmap_local(struct ttm_kmap_iter *iter, + struct dma_buf_map *dmap, + pgoff_t i) +{ + struct ttm_kmap_iter_iomap *iter_io = + container_of(iter, typeof(*iter_io), base); + void __iomem *addr; + +retry: + while (i >= iter_io->cache.end) { + iter_io->cache.sg = iter_io->cache.sg ? + sg_next(iter_io->cache.sg) : iter_io->st->sgl; + iter_io->cache.i = iter_io->cache.e
Re: [Intel-gfx] [RFC PATCH 3/5] drm/ttm: Use drm_memcpy_from_wc for TTM bo moves
Am 20.05.21 um 17:09 schrieb Thomas Hellström: Use fast wc memcpy for reading out of wc memory for TTM bo moves. Cc: Dave Airlie Cc: Christian König Cc: Daniel Vetter Signed-off-by: Thomas Hellström Oh, yes I really wanted to have that in TTM for quite some time. But I'm wondering if we shouldn't fix the memremap stuff first. Christian. --- drivers/gpu/drm/ttm/ttm_bo_util.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index bad9b16e96ba..919ee03f7eb3 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -31,6 +31,7 @@ #include #include +#include #include #include #include @@ -185,6 +186,7 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo, struct ttm_resource *old_mem = &bo->mem; struct ttm_resource_manager *old_man = ttm_manager_type(bdev, old_mem->mem_type); struct dma_buf_map old_map, new_map; + bool wc_memcpy; pgoff_t i; /* Single TTM move. NOP */ @@ -208,11 +210,25 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo, return; } + wc_memcpy = ((!old_man->use_tt || bo->ttm->caching != ttm_cached) && +drm_has_memcpy_from_wc()); + + /* +* We use some nasty aliasing for drm_memcpy_from_wc, but assuming +* that we can move to memremapping in the not too distant future, +* reduce the fragility for now with a build assert. +*/ + BUILD_BUG_ON(offsetof(typeof(old_map), vaddr) != +offsetof(typeof(old_map), vaddr_iomem)); + for (i = 0; i < new_mem->num_pages; ++i) { new_iter->ops->kmap_local(new_iter, &new_map, i); old_iter->ops->kmap_local(old_iter, &old_map, i); - if (!old_map.is_iomem && !new_map.is_iomem) { + if (wc_memcpy) { + drm_memcpy_from_wc(new_map.vaddr, old_map.vaddr, + PAGE_SIZE); + } else if (!old_map.is_iomem && !new_map.is_iomem) { memcpy(new_map.vaddr, old_map.vaddr, PAGE_SIZE); } else if (!old_map.is_iomem) { dma_buf_map_memcpy_to(&new_map, old_map.vaddr, ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 4/5] drm/ttm: Document and optimize ttm_bo_pipeline_gutting()
Am 20.05.21 um 17:09 schrieb Thomas Hellström: If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily create a ghost object and push it out to delayed destroy. Fix this by adding a path for idle, and document the function. Also avoid having the bo end up in a bad state vulnerable to user-space triggered kernel BUGs if the call to ttm_tt_create() fails. Finally reuse ttm_bo_pipeline_gutting() in ttm_bo_evict(). Cc: Christian König Signed-off-by: Thomas Hellström --- drivers/gpu/drm/ttm/ttm_bo.c | 20 +- drivers/gpu/drm/ttm/ttm_bo_util.c | 63 --- drivers/gpu/drm/ttm/ttm_tt.c | 5 +++ include/drm/ttm/ttm_tt.h | 10 + 4 files changed, 75 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index ca1b098b6a56..a8fa3375b8aa 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -501,10 +501,15 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bdev->funcs->evict_flags(bo, &placement); if (!placement.num_placement && !placement.num_busy_placement) { - ttm_bo_wait(bo, false, false); + ret = ttm_bo_wait(bo, true, false); + if (ret) + return ret; - ttm_bo_cleanup_memtype_use(bo); - return ttm_tt_create(bo, false); + /* +* Since we've already synced, this frees backing store +* immediately. +*/ + return ttm_bo_pipeline_gutting(bo); Yeah, we tried to avoid pipeline_gutting here because of eviction. But I think when you wait before that should work. } ret = ttm_bo_mem_space(bo, &placement, &evict_mem, ctx); @@ -974,13 +979,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo, /* * Remove the backing store if no placement is given. */ - if (!placement->num_placement && !placement->num_busy_placement) { - ret = ttm_bo_pipeline_gutting(bo); - if (ret) - return ret; - - return ttm_tt_create(bo, false); - } + if (!placement->num_placement && !placement->num_busy_placement) + return ttm_bo_pipeline_gutting(bo); /* * Check whether we need to move buffer. diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index 919ee03f7eb3..1860e2e7563f 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -479,7 +479,8 @@ static void ttm_transfered_destroy(struct ttm_buffer_object *bo) */ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, - struct ttm_buffer_object **new_obj) + struct ttm_buffer_object **new_obj, + bool realloc_tt) { struct ttm_transfer_obj *fbo; int ret; @@ -493,6 +494,17 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, ttm_bo_get(bo); fbo->bo = bo; + if (realloc_tt) { + bo->ttm = NULL; + ret = ttm_tt_create(bo, true); + if (ret) { + bo->ttm = fbo->base.ttm; + kfree(fbo); + ttm_bo_put(bo); + return ret; + } + } + Can't we keep that logic in the caller? I think that would be cleaner. /** * Fix up members that we shouldn't copy directly: * TODO: Explicit member copy would probably be better here. @@ -763,7 +775,7 @@ static int ttm_bo_move_to_ghost(struct ttm_buffer_object *bo, dma_fence_put(bo->moving); bo->moving = dma_fence_get(fence); - ret = ttm_buffer_object_transfer(bo, &ghost_obj); + ret = ttm_buffer_object_transfer(bo, &ghost_obj, false); if (ret) return ret; @@ -836,26 +848,51 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo, } EXPORT_SYMBOL(ttm_bo_move_accel_cleanup); +/** + * ttm_bo_pipeline_gutting - purge the contents of a bo + * @bo: The buffer object + * + * Purge the contents of a bo, async if the bo is not idle. + * After a successful call, the bo is left unpopulated in + * system placement. The function may wait uninterruptible + * for idle on OOM. + * + * Return: 0 if successful, negative error code on failure. + */ 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; int ret; - ret = ttm_buffer_object_transfer(bo, &ghost); - if (ret) - return ret; + /* If already idle, no need for ghost object dance. */ + ret = ttm_bo_wait(bo, false, true); + if (ret == -EBUSY) { + ret = ttm_buffer_object_transfer(bo, &
Re: [Intel-gfx] [RFC PATCH 3/5] drm/ttm: Use drm_memcpy_from_wc for TTM bo moves
On 5/21/21 10:10 AM, Christian König wrote: Am 20.05.21 um 17:09 schrieb Thomas Hellström: Use fast wc memcpy for reading out of wc memory for TTM bo moves. Cc: Dave Airlie Cc: Christian König Cc: Daniel Vetter Signed-off-by: Thomas Hellström Oh, yes I really wanted to have that in TTM for quite some time. We should use it for swap copy from WC as well IMO. A todo-task for somebody. But I'm wondering if we shouldn't fix the memremap stuff first. Using memremap all over is a fairly big change probably with lots of opinions involved all over the place. What I can do for now is to add a dma_buf_map interface to the memcpy itself, to move the aliasing out of TTM to the arch specific code that knows what it's doing? /Thomas Christian. --- drivers/gpu/drm/ttm/ttm_bo_util.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index bad9b16e96ba..919ee03f7eb3 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -31,6 +31,7 @@ #include #include +#include #include #include #include @@ -185,6 +186,7 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo, struct ttm_resource *old_mem = &bo->mem; struct ttm_resource_manager *old_man = ttm_manager_type(bdev, old_mem->mem_type); struct dma_buf_map old_map, new_map; + bool wc_memcpy; pgoff_t i; /* Single TTM move. NOP */ @@ -208,11 +210,25 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo, return; } + wc_memcpy = ((!old_man->use_tt || bo->ttm->caching != ttm_cached) && + drm_has_memcpy_from_wc()); + + /* + * We use some nasty aliasing for drm_memcpy_from_wc, but assuming + * that we can move to memremapping in the not too distant future, + * reduce the fragility for now with a build assert. + */ + BUILD_BUG_ON(offsetof(typeof(old_map), vaddr) != + offsetof(typeof(old_map), vaddr_iomem)); + for (i = 0; i < new_mem->num_pages; ++i) { new_iter->ops->kmap_local(new_iter, &new_map, i); old_iter->ops->kmap_local(old_iter, &old_map, i); - if (!old_map.is_iomem && !new_map.is_iomem) { + if (wc_memcpy) { + drm_memcpy_from_wc(new_map.vaddr, old_map.vaddr, + PAGE_SIZE); + } else if (!old_map.is_iomem && !new_map.is_iomem) { memcpy(new_map.vaddr, old_map.vaddr, PAGE_SIZE); } else if (!old_map.is_iomem) { dma_buf_map_memcpy_to(&new_map, old_map.vaddr, ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 0/9] DG1/LMEM uAPI basics v2
On Wed, May 19, 2021 at 03:53:28PM +0100, Matthew Auld wrote: > Just the really basic stuff, which unlocks adding more interesting testcases > later, like gem_lmem_swapping. > > On the kernel side we landed the uAPI bits[1] behind CONFIG_BROKEN, which is > already enabled in CI builds, so it should be possible to get some more BAT > testing(outside of just the selftests) on DG1 to the point where we can start > to > exercise the LMEM paths with the new bits of uAPI. > > [1] https://patchwork.freedesktop.org/series/89648/ > > v2:(Petri) >- add missing kernel sha for i915_drm.h sync >- squash the various region lib patches together >- just directly use the uapi bits from the start, instead of adding a bunch > of locals, which then later get removed anyway > > Andrzej Turko (5): > lib/i915/gem_create: Add gem_create_ext > lib/i915/intel_memory_region: Add new memory region lib > tests/i915/gem_exec_basic: Use memory region interface > tests/i915/gem_gpgpu_fill: Use memory region interface > tests/i915/gem_media_fill: Use memory region interface > > Dominik Grzegorzek (1): > tests/gem_gpgpu_fill: Convert from simple to standard igt_main > > Kalamarz, Lukasz (1): > tests/i915/gem_exec_basic: Iterate over all memory regions > > Matthew Auld (2): > i915_drm.h sync > tests/i915/gem_create: exercise placements extension > > benchmarks/gem_blt.c| 2 +- > benchmarks/gem_busy.c | 2 +- > benchmarks/gem_create.c | 2 +- > benchmarks/gem_exec_ctx.c | 2 +- > benchmarks/gem_exec_fault.c | 2 +- > benchmarks/gem_exec_nop.c | 2 +- > benchmarks/gem_exec_reloc.c | 2 +- > benchmarks/gem_exec_trace.c | 2 +- > benchmarks/gem_latency.c| 2 +- > benchmarks/gem_prw.c| 2 +- > benchmarks/gem_set_domain.c | 2 +- > benchmarks/gem_syslatency.c | 2 +- > benchmarks/gem_wsim.c | 2 +- > benchmarks/prime_lookup.c | 2 +- > include/drm-uapi/i915_drm.h | 394 +++-- > lib/i915/gem.h | 3 - > lib/i915/gem_create.c | 43 ++- > lib/i915/gem_create.h | 19 + > lib/i915/gem_mman.c | 2 +- > lib/i915/gem_ring.c | 1 + > lib/i915/gem_submission.c | 1 + > lib/i915/intel_memory_region.c | 441 > lib/i915/intel_memory_region.h | 130 +++ > lib/igt_draw.c | 2 +- > lib/igt_dummyload.c | 2 +- > lib/igt_fb.c| 2 +- > lib/intel_batchbuffer.c | 2 +- > lib/intel_bufops.c | 2 +- > lib/ioctl_wrappers.c| 2 +- > lib/ioctl_wrappers.h| 1 + > lib/meson.build | 1 + > tests/amdgpu/amd_prime.c| 1 + > tests/core_hotunplug.c | 1 + > tests/i915/api_intel_allocator.c| 1 + > tests/i915/api_intel_bb.c | 1 + > tests/i915/gem_bad_reloc.c | 1 + > tests/i915/gem_basic.c | 2 +- > tests/i915/gem_blits.c | 1 + > tests/i915/gem_busy.c | 1 + > tests/i915/gem_close.c | 1 + > tests/i915/gem_close_race.c | 1 + > tests/i915/gem_concurrent_all.c | 1 + > tests/i915/gem_create.c | 189 ++ > tests/i915/gem_cs_tlb.c | 1 + > tests/i915/gem_ctx_clone.c | 1 + > tests/i915/gem_ctx_create.c | 1 + > tests/i915/gem_ctx_engines.c| 1 + > tests/i915/gem_ctx_exec.c | 1 + > tests/i915/gem_ctx_isolation.c | 1 + > tests/i915/gem_ctx_param.c | 1 + > tests/i915/gem_ctx_shared.c | 1 + > tests/i915/gem_ctx_sseu.c | 1 + > tests/i915/gem_ctx_switch.c | 1 + > tests/i915/gem_eio.c| 1 + > tests/i915/gem_evict_alignment.c| 1 + > tests/i915/gem_evict_everything.c | 1 + > tests/i915/gem_exec_alignment.c | 1 + > tests/i915/gem_exec_async.c | 1 + > tests/i915/gem_exec_await.c | 1 + > tests/i915/gem_exec_balancer.c | 1 + > tests/i915/gem_exec_basic.c | 53 ++- > tests/i915/gem_exec_big.c | 1 + > tests/i915/gem_exec_capture.c | 1 + > tests/i915/gem_exec_create.c| 1 + > tests/i915/gem_exec_endless.c | 1 + > tests/i915/gem_exec_fair.c | 1 + > tests/i915/gem_exec_fence.c | 1 + > tests/i915/gem_exec_flush.c | 1 + > tests/i915/gem_exec_gttfill.c | 1 + > tests/i915/gem
Re: [Intel-gfx] [RFC PATCH 4/5] drm/ttm: Document and optimize ttm_bo_pipeline_gutting()
On 5/21/21 10:21 AM, Christian König wrote: Am 20.05.21 um 17:09 schrieb Thomas Hellström: If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily create a ghost object and push it out to delayed destroy. Fix this by adding a path for idle, and document the function. Also avoid having the bo end up in a bad state vulnerable to user-space triggered kernel BUGs if the call to ttm_tt_create() fails. Finally reuse ttm_bo_pipeline_gutting() in ttm_bo_evict(). Cc: Christian König Signed-off-by: Thomas Hellström --- drivers/gpu/drm/ttm/ttm_bo.c | 20 +- drivers/gpu/drm/ttm/ttm_bo_util.c | 63 --- drivers/gpu/drm/ttm/ttm_tt.c | 5 +++ include/drm/ttm/ttm_tt.h | 10 + 4 files changed, 75 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index ca1b098b6a56..a8fa3375b8aa 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -501,10 +501,15 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bdev->funcs->evict_flags(bo, &placement); if (!placement.num_placement && !placement.num_busy_placement) { - ttm_bo_wait(bo, false, false); + ret = ttm_bo_wait(bo, true, false); + if (ret) + return ret; - ttm_bo_cleanup_memtype_use(bo); - return ttm_tt_create(bo, false); + /* + * Since we've already synced, this frees backing store + * immediately. + */ + return ttm_bo_pipeline_gutting(bo); Yeah, we tried to avoid pipeline_gutting here because of eviction. But I think when you wait before that should work. } ret = ttm_bo_mem_space(bo, &placement, &evict_mem, ctx); @@ -974,13 +979,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo, /* * Remove the backing store if no placement is given. */ - if (!placement->num_placement && !placement->num_busy_placement) { - ret = ttm_bo_pipeline_gutting(bo); - if (ret) - return ret; - - return ttm_tt_create(bo, false); - } + if (!placement->num_placement && !placement->num_busy_placement) + return ttm_bo_pipeline_gutting(bo); /* * Check whether we need to move buffer. diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index 919ee03f7eb3..1860e2e7563f 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -479,7 +479,8 @@ static void ttm_transfered_destroy(struct ttm_buffer_object *bo) */ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, - struct ttm_buffer_object **new_obj) + struct ttm_buffer_object **new_obj, + bool realloc_tt) { struct ttm_transfer_obj *fbo; int ret; @@ -493,6 +494,17 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, ttm_bo_get(bo); fbo->bo = bo; + if (realloc_tt) { + bo->ttm = NULL; + ret = ttm_tt_create(bo, true); + if (ret) { + bo->ttm = fbo->base.ttm; + kfree(fbo); + ttm_bo_put(bo); + return ret; + } + } + Can't we keep that logic in the caller? I think that would be cleaner. Indeed, let me see if we can do that without breaking anything. /** * Fix up members that we shouldn't copy directly: * TODO: Explicit member copy would probably be better here. @@ -763,7 +775,7 @@ static int ttm_bo_move_to_ghost(struct ttm_buffer_object *bo, dma_fence_put(bo->moving); bo->moving = dma_fence_get(fence); - ret = ttm_buffer_object_transfer(bo, &ghost_obj); + ret = ttm_buffer_object_transfer(bo, &ghost_obj, false); if (ret) return ret; @@ -836,26 +848,51 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo, } EXPORT_SYMBOL(ttm_bo_move_accel_cleanup); +/** + * ttm_bo_pipeline_gutting - purge the contents of a bo + * @bo: The buffer object + * + * Purge the contents of a bo, async if the bo is not idle. + * After a successful call, the bo is left unpopulated in + * system placement. The function may wait uninterruptible + * for idle on OOM. + * + * Return: 0 if successful, negative error code on failure. + */ 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; int ret; - ret = ttm_buffer_object_transfer(bo, &ghost); - if (ret) - return ret; + /* If already idle, no need for ghost object dance. */ + ret = ttm_bo_wait(bo, false, true); + if (ret == -EBUSY) { + ret = ttm_buffer_object_transfer(bo, &ghost, true); + if (ret) + return ret; When this is a shortcout to avoid work we should rather use the inverse notation. In other words something like that: if (r
[Intel-gfx] [PATCH 02/11] drm/panfrost: Remove sched_lock
Scheduler takes care of its own locking, dont worry. For everything else there's reservation locking on each bo. So seems to be entirely redundnant and just a bit in the way. Signed-off-by: Daniel Vetter Cc: Rob Herring Cc: Tomeu Vizoso Cc: Steven Price Cc: Alyssa Rosenzweig --- drivers/gpu/drm/panfrost/panfrost_device.c | 1 - drivers/gpu/drm/panfrost/panfrost_device.h | 2 -- drivers/gpu/drm/panfrost/panfrost_job.c| 13 ++--- 3 files changed, 2 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c b/drivers/gpu/drm/panfrost/panfrost_device.c index 125ed973feaa..23070c01c63f 100644 --- a/drivers/gpu/drm/panfrost/panfrost_device.c +++ b/drivers/gpu/drm/panfrost/panfrost_device.c @@ -199,7 +199,6 @@ int panfrost_device_init(struct panfrost_device *pfdev) int err; struct resource *res; - mutex_init(&pfdev->sched_lock); INIT_LIST_HEAD(&pfdev->scheduled_jobs); INIT_LIST_HEAD(&pfdev->as_lru_list); diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h b/drivers/gpu/drm/panfrost/panfrost_device.h index 597cf1459b0a..7519903bb031 100644 --- a/drivers/gpu/drm/panfrost/panfrost_device.h +++ b/drivers/gpu/drm/panfrost/panfrost_device.h @@ -105,8 +105,6 @@ struct panfrost_device { struct panfrost_perfcnt *perfcnt; - struct mutex sched_lock; - struct { struct work_struct work; atomic_t pending; diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c index 6003cfeb1322..f5d39ee14ab5 100644 --- a/drivers/gpu/drm/panfrost/panfrost_job.c +++ b/drivers/gpu/drm/panfrost/panfrost_job.c @@ -218,26 +218,19 @@ static void panfrost_attach_object_fences(struct drm_gem_object **bos, int panfrost_job_push(struct panfrost_job *job) { - struct panfrost_device *pfdev = job->pfdev; int slot = panfrost_job_get_slot(job); struct drm_sched_entity *entity = &job->file_priv->sched_entity[slot]; struct ww_acquire_ctx acquire_ctx; int ret = 0; - mutex_lock(&pfdev->sched_lock); - ret = drm_gem_lock_reservations(job->bos, job->bo_count, &acquire_ctx); - if (ret) { - mutex_unlock(&pfdev->sched_lock); + if (ret) return ret; - } ret = drm_sched_job_init(&job->base, entity, NULL); - if (ret) { - mutex_unlock(&pfdev->sched_lock); + if (ret) goto unlock; - } job->render_done_fence = dma_fence_get(&job->base.s_fence->finished); @@ -248,8 +241,6 @@ int panfrost_job_push(struct panfrost_job *job) drm_sched_entity_push_job(&job->base, entity); - mutex_unlock(&pfdev->sched_lock); - panfrost_attach_object_fences(job->bos, job->bo_count, job->render_done_fence); -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
Docs for struct dma_resv are fairly clear: "A reservation object can have attached one exclusive fence (normally associated with write operations) or N shared fences (read operations)." https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html#reservation-objects Furthermore a review across all of upstream. First of render drivers and how they set implicit fences: - nouveau follows this contract, see in validate_fini_no_ticket() nouveau_bo_fence(nvbo, fence, !!b->write_domains); and that last boolean controls whether the exclusive or shared fence slot is used. - radeon follows this contract by setting p->relocs[i].tv.num_shared = !r->write_domain; in radeon_cs_parser_relocs(), which ensures that the call to ttm_eu_fence_buffer_objects() in radeon_cs_parser_fini() will do the right thing. - vmwgfx seems to follow this contract with the shotgun approach of always setting ttm_val_buf->num_shared = 0, which means ttm_eu_fence_buffer_objects() will only use the exclusive slot. - etnaviv follows this contract, as can be trivially seen by looking at submit_attach_object_fences() - i915 is a bit a convoluted maze with multiple paths leading to i915_vma_move_to_active(). Which sets the exclusive flag if EXEC_OBJECT_WRITE is set. This can either come as a buffer flag for softpin mode, or through the write_domain when using relocations. It follows this contract. - lima follows this contract, see lima_gem_submit() which sets the exclusive fence when the LIMA_SUBMIT_BO_WRITE flag is set for that bo - msm follows this contract, see msm_gpu_submit() which sets the exclusive flag when the MSM_SUBMIT_BO_WRITE is set for that buffer - panfrost follows this contract with the shotgun approach of just always setting the exclusive fence, see panfrost_attach_object_fences(). Benefits of a single engine I guess - v3d follows this contract with the same shotgun approach in v3d_attach_fences_and_unlock_reservation(), but it has at least an XXX comment that maybe this should be improved - v4c uses the same shotgun approach of always setting an exclusive fence, see vc4_update_bo_seqnos() - vgem also follows this contract, see vgem_fence_attach_ioctl() and the VGEM_FENCE_WRITE. This is used in some igts to validate prime sharing with i915.ko without the need of a 2nd gpu - vritio follows this contract again with the shotgun approach of always setting an exclusive fence, see virtio_gpu_array_add_fence() This covers the setting of the exclusive fences when writing. Synchronizing against the exclusive fence is a lot more tricky, and I only spot checked a few: - i915 does it, with the optional EXEC_OBJECT_ASYNC to skip all implicit dependencies (which is used by vulkan) - etnaviv does this. Implicit dependencies are collected in submit_fence_sync(), again with an opt-out flag ETNA_SUBMIT_NO_IMPLICIT. These are then picked up in etnaviv_sched_dependency which is the drm_sched_backend_ops->dependency callback. - v4c seems to not do much here, maybe gets away with it by not having a scheduler and only a single engine. Since all newer broadcom chips than the OG vc4 use v3d for rendering, which follows this contract, the impact of this issue is fairly small. - v3d does this using the drm_gem_fence_array_add_implicit() helper, which then it's drm_sched_backend_ops->dependency callback v3d_job_dependency() picks up. - panfrost is nice here and tracks the implicit fences in panfrost_job->implicit_fences, which again the drm_sched_backend_ops->dependency callback panfrost_job_dependency() picks up. It is mildly questionable though since it only picks up exclusive fences in panfrost_acquire_object_fences(), but not buggy in practice because it also always sets the exclusive fence. It should pick up both sets of fences, just in case there's ever going to be a 2nd gpu in a SoC with a mali gpu. Or maybe a mali SoC with a pcie port and a real gpu, which might actually happen eventually. A bug, but easy to fix. Should probably use the drm_gem_fence_array_add_implicit() helper. - lima is nice an easy, uses drm_gem_fence_array_add_implicit() and the same schema as v3d. - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT, but because it doesn't use the drm/scheduler it handles fences from the wrong context with a synchronous dma_fence_wait. See submit_fence_sync() leading to msm_gem_sync_object(). Investing into a scheduler might be a good idea. - all the remaining drivers are ttm based, where I hope they do appropriately obey implicit fences already. I didn't do the full audit there because a) not follow the contract would confuse ttm quite well and b) reading non-standard scheduler and submit code which isn't based on drm/scheduler is a pain. Onwards to the display side. - Any driver using the drm_gem_plane_helper_prepare_fb() helper will correctly. Overwhelm
[Intel-gfx] [PATCH 03/11] drm/panfrost: Use xarray and helpers for depedency tracking
More consistency and prep work for the next patch. Aside: I wonder whether we shouldn't just move this entire xarray business into the scheduler so that not everyone has to reinvent the same wheels. Cc'ing some scheduler people for this too. Cc: "Christian König" Cc: Luben Tuikov Cc: Alex Deucher Cc: Lee Jones Cc: Steven Price Cc: Rob Herring Cc: Tomeu Vizoso Cc: Alyssa Rosenzweig Cc: Sumit Semwal Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/panfrost/panfrost_drv.c | 41 - drivers/gpu/drm/panfrost/panfrost_job.c | 61 ++--- drivers/gpu/drm/panfrost/panfrost_job.h | 8 ++-- 3 files changed, 46 insertions(+), 64 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c index ca07098a6141..7977b4752b5c 100644 --- a/drivers/gpu/drm/panfrost/panfrost_drv.c +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c @@ -137,12 +137,6 @@ panfrost_lookup_bos(struct drm_device *dev, if (!job->bo_count) return 0; - job->implicit_fences = kvmalloc_array(job->bo_count, - sizeof(struct dma_fence *), - GFP_KERNEL | __GFP_ZERO); - if (!job->implicit_fences) - return -ENOMEM; - ret = drm_gem_objects_lookup(file_priv, (void __user *)(uintptr_t)args->bo_handles, job->bo_count, &job->bos); @@ -173,7 +167,7 @@ panfrost_lookup_bos(struct drm_device *dev, } /** - * panfrost_copy_in_sync() - Sets up job->in_fences[] with the sync objects + * panfrost_copy_in_sync() - Sets up job->deps with the sync objects * referenced by the job. * @dev: DRM device * @file_priv: DRM file for this fd @@ -193,22 +187,14 @@ panfrost_copy_in_sync(struct drm_device *dev, { u32 *handles; int ret = 0; - int i; + int i, in_fence_count; - job->in_fence_count = args->in_sync_count; + in_fence_count = args->in_sync_count; - if (!job->in_fence_count) + if (!in_fence_count) return 0; - job->in_fences = kvmalloc_array(job->in_fence_count, - sizeof(struct dma_fence *), - GFP_KERNEL | __GFP_ZERO); - if (!job->in_fences) { - DRM_DEBUG("Failed to allocate job in fences\n"); - return -ENOMEM; - } - - handles = kvmalloc_array(job->in_fence_count, sizeof(u32), GFP_KERNEL); + handles = kvmalloc_array(in_fence_count, sizeof(u32), GFP_KERNEL); if (!handles) { ret = -ENOMEM; DRM_DEBUG("Failed to allocate incoming syncobj handles\n"); @@ -217,16 +203,23 @@ panfrost_copy_in_sync(struct drm_device *dev, if (copy_from_user(handles, (void __user *)(uintptr_t)args->in_syncs, - job->in_fence_count * sizeof(u32))) { + in_fence_count * sizeof(u32))) { ret = -EFAULT; DRM_DEBUG("Failed to copy in syncobj handles\n"); goto fail; } - for (i = 0; i < job->in_fence_count; i++) { + for (i = 0; i < in_fence_count; i++) { + struct dma_fence *fence; + ret = drm_syncobj_find_fence(file_priv, handles[i], 0, 0, -&job->in_fences[i]); - if (ret == -EINVAL) +&fence); + if (ret) + goto fail; + + ret = drm_gem_fence_array_add(&job->deps, fence); + + if (ret) goto fail; } @@ -264,6 +257,8 @@ static int panfrost_ioctl_submit(struct drm_device *dev, void *data, kref_init(&job->refcount); + xa_init_flags(&job->deps, XA_FLAGS_ALLOC); + job->pfdev = pfdev; job->jc = args->jc; job->requirements = args->requirements; diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c index f5d39ee14ab5..707d912ff64a 100644 --- a/drivers/gpu/drm/panfrost/panfrost_job.c +++ b/drivers/gpu/drm/panfrost/panfrost_job.c @@ -196,14 +196,21 @@ static void panfrost_job_hw_submit(struct panfrost_job *job, int js) job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START); } -static void panfrost_acquire_object_fences(struct drm_gem_object **bos, - int bo_count, - struct dma_fence **implicit_fences) +static int panfrost_acquire_object_fences(struct drm_gem_object **bos, + int bo_count, + struct xarray *deps) { - int i; + int i, ret; - for (i = 0; i < bo_count; i++) -
[Intel-gfx] [PATCH 07/11] drm/armada: Remove prepare/cleanup_fb hooks
All they do is refcount the fb, which the atomic helpers already do. This is was necessary with the legacy helpers and I guess just carry over in the conversion. drm_plane_state always has a full reference for its ->fb pointer during its entire lifetime, see __drm_atomic_helper_plane_destroy_state() Signed-off-by: Daniel Vetter Cc: Russell King --- drivers/gpu/drm/armada/armada_overlay.c | 2 -- drivers/gpu/drm/armada/armada_plane.c | 29 - drivers/gpu/drm/armada/armada_plane.h | 2 -- 3 files changed, 33 deletions(-) diff --git a/drivers/gpu/drm/armada/armada_overlay.c b/drivers/gpu/drm/armada/armada_overlay.c index d3e3e5fdc390..424250535fed 100644 --- a/drivers/gpu/drm/armada/armada_overlay.c +++ b/drivers/gpu/drm/armada/armada_overlay.c @@ -247,8 +247,6 @@ static void armada_drm_overlay_plane_atomic_disable(struct drm_plane *plane, } static const struct drm_plane_helper_funcs armada_overlay_plane_helper_funcs = { - .prepare_fb = armada_drm_plane_prepare_fb, - .cleanup_fb = armada_drm_plane_cleanup_fb, .atomic_check = armada_drm_plane_atomic_check, .atomic_update = armada_drm_overlay_plane_atomic_update, .atomic_disable = armada_drm_overlay_plane_atomic_disable, diff --git a/drivers/gpu/drm/armada/armada_plane.c b/drivers/gpu/drm/armada/armada_plane.c index 40f5c34fb4d8..1c56a2883b91 100644 --- a/drivers/gpu/drm/armada/armada_plane.c +++ b/drivers/gpu/drm/armada/armada_plane.c @@ -78,33 +78,6 @@ void armada_drm_plane_calc(struct drm_plane_state *state, u32 addrs[2][3], } } -int armada_drm_plane_prepare_fb(struct drm_plane *plane, - struct drm_plane_state *state) -{ - DRM_DEBUG_KMS("[PLANE:%d:%s] [FB:%d]\n", - plane->base.id, plane->name, - state->fb ? state->fb->base.id : 0); - - /* -* Take a reference on the new framebuffer - we want to -* hold on to it while the hardware is displaying it. -*/ - if (state->fb) - drm_framebuffer_get(state->fb); - return 0; -} - -void armada_drm_plane_cleanup_fb(struct drm_plane *plane, - struct drm_plane_state *old_state) -{ - DRM_DEBUG_KMS("[PLANE:%d:%s] [FB:%d]\n", - plane->base.id, plane->name, - old_state->fb ? old_state->fb->base.id : 0); - - if (old_state->fb) - drm_framebuffer_put(old_state->fb); -} - int armada_drm_plane_atomic_check(struct drm_plane *plane, struct drm_atomic_state *state) { @@ -282,8 +255,6 @@ static void armada_drm_primary_plane_atomic_disable(struct drm_plane *plane, } static const struct drm_plane_helper_funcs armada_primary_plane_helper_funcs = { - .prepare_fb = armada_drm_plane_prepare_fb, - .cleanup_fb = armada_drm_plane_cleanup_fb, .atomic_check = armada_drm_plane_atomic_check, .atomic_update = armada_drm_primary_plane_atomic_update, .atomic_disable = armada_drm_primary_plane_atomic_disable, diff --git a/drivers/gpu/drm/armada/armada_plane.h b/drivers/gpu/drm/armada/armada_plane.h index 51dab8d8da22..368415c609a6 100644 --- a/drivers/gpu/drm/armada/armada_plane.h +++ b/drivers/gpu/drm/armada/armada_plane.h @@ -21,8 +21,6 @@ struct armada_plane_state { void armada_drm_plane_calc(struct drm_plane_state *state, u32 addrs[2][3], u16 pitches[3], bool interlaced); -int armada_drm_plane_prepare_fb(struct drm_plane *plane, - struct drm_plane_state *state); void armada_drm_plane_cleanup_fb(struct drm_plane *plane, struct drm_plane_state *old_state); int armada_drm_plane_atomic_check(struct drm_plane *plane, -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default
No need to set it explicitly. Signed-off-by: Daniel Vetter Cc: Laurentiu Palcu Cc: Lucas Stach Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: Philipp Zabel Cc: Paul Cercueil Cc: Chun-Kuang Hu Cc: Matthias Brugger Cc: Neil Armstrong Cc: Kevin Hilman Cc: Jerome Brunet Cc: Martin Blumenstingl Cc: Marek Vasut Cc: Stefan Agner Cc: Sandy Huang Cc: "Heiko Stübner" Cc: Yannick Fertre Cc: Philippe Cornu Cc: Benjamin Gaignard Cc: Maxime Coquelin Cc: Alexandre Torgue Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Jernej Skrabec Cc: Jyri Sarha Cc: Tomi Valkeinen Cc: linux-arm-ker...@lists.infradead.org Cc: linux-m...@vger.kernel.org Cc: linux-media...@lists.infradead.org Cc: linux-amlo...@lists.infradead.org Cc: linux-rockc...@lists.infradead.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-su...@lists.linux.dev --- drivers/gpu/drm/imx/dcss/dcss-plane.c | 1 - drivers/gpu/drm/imx/ipuv3-plane.c | 1 - drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 - drivers/gpu/drm/ingenic/ingenic-ipu.c | 1 - drivers/gpu/drm/mediatek/mtk_drm_plane.c| 1 - drivers/gpu/drm/meson/meson_overlay.c | 1 - drivers/gpu/drm/meson/meson_plane.c | 1 - drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 -- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 - drivers/gpu/drm/stm/ltdc.c | 1 - drivers/gpu/drm/sun4i/sun4i_layer.c | 1 - drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 1 - drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 1 - drivers/gpu/drm/tidss/tidss_plane.c | 1 - 14 files changed, 15 deletions(-) diff --git a/drivers/gpu/drm/imx/dcss/dcss-plane.c b/drivers/gpu/drm/imx/dcss/dcss-plane.c index 044d3bdf313c..ac45d54acd4e 100644 --- a/drivers/gpu/drm/imx/dcss/dcss-plane.c +++ b/drivers/gpu/drm/imx/dcss/dcss-plane.c @@ -361,7 +361,6 @@ static void dcss_plane_atomic_disable(struct drm_plane *plane, } static const struct drm_plane_helper_funcs dcss_plane_helper_funcs = { - .prepare_fb = drm_gem_plane_helper_prepare_fb, .atomic_check = dcss_plane_atomic_check, .atomic_update = dcss_plane_atomic_update, .atomic_disable = dcss_plane_atomic_disable, diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c index 8710f55d2579..ef114b6aa691 100644 --- a/drivers/gpu/drm/imx/ipuv3-plane.c +++ b/drivers/gpu/drm/imx/ipuv3-plane.c @@ -772,7 +772,6 @@ static void ipu_plane_atomic_update(struct drm_plane *plane, } static const struct drm_plane_helper_funcs ipu_plane_helper_funcs = { - .prepare_fb = drm_gem_plane_helper_prepare_fb, .atomic_check = ipu_plane_atomic_check, .atomic_disable = ipu_plane_atomic_disable, .atomic_update = ipu_plane_atomic_update, diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c index 389cad59e090..62db7349bf6a 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c @@ -786,7 +786,6 @@ static const struct drm_plane_helper_funcs ingenic_drm_plane_helper_funcs = { .atomic_update = ingenic_drm_plane_atomic_update, .atomic_check = ingenic_drm_plane_atomic_check, .atomic_disable = ingenic_drm_plane_atomic_disable, - .prepare_fb = drm_gem_plane_helper_prepare_fb, }; static const struct drm_crtc_helper_funcs ingenic_drm_crtc_helper_funcs = { diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c b/drivers/gpu/drm/ingenic/ingenic-ipu.c index 3b1091e7c0cd..caf038f3e231 100644 --- a/drivers/gpu/drm/ingenic/ingenic-ipu.c +++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c @@ -615,7 +615,6 @@ static const struct drm_plane_helper_funcs ingenic_ipu_plane_helper_funcs = { .atomic_update = ingenic_ipu_plane_atomic_update, .atomic_check = ingenic_ipu_plane_atomic_check, .atomic_disable = ingenic_ipu_plane_atomic_disable, - .prepare_fb = drm_gem_plane_helper_prepare_fb, }; static int diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c index b5582dcf564c..1667a7e7de38 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c @@ -227,7 +227,6 @@ static void mtk_plane_atomic_update(struct drm_plane *plane, } static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = { - .prepare_fb = drm_gem_plane_helper_prepare_fb, .atomic_check = mtk_plane_atomic_check, .atomic_update = mtk_plane_atomic_update, .atomic_disable = mtk_plane_atomic_disable, diff --git a/drivers/gpu/drm/meson/meson_overlay.c b/drivers/gpu/drm/meson/meson_overlay.c index ed063152aecd..dfef8afcc245 100644 --- a/drivers/gpu/drm/meson/meson_overlay.c +++ b/drivers/gpu/drm/meson/meson_overlay.c @@ -747,7 +747,6 @@ static const struct drm_plane_helper_funcs meson_overlay_helper_f
[Intel-gfx] [PATCH 05/11] drm/atomic-helper: make drm_gem_plane_helper_prepare_fb the default
There's a bunch of atomic drivers who don't do this quite correctly, luckily most of them aren't in wide use or people would have noticed the tearing. By making this the default we avoid the constant audit pain and can additionally remove a ton of lines from vfuncs for a bit more clarity in smaller drivers. While at it complain if there's a cleanup_fb hook but no prepare_fb hook, because that makes no sense. I haven't found any driver which violates this, but better safe than sorry. Subsequent patches will reap the benefits. Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter --- drivers/gpu/drm/drm_atomic_helper.c | 10 ++ drivers/gpu/drm/drm_gem_atomic_helper.c | 3 +++ include/drm/drm_modeset_helper_vtables.h | 7 +-- 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 531f2374b072..9f6c5f21c4d6 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include #include @@ -2408,6 +2409,15 @@ int drm_atomic_helper_prepare_planes(struct drm_device *dev, ret = funcs->prepare_fb(plane, new_plane_state); if (ret) goto fail; + } else { + WARN_ON_ONCE(funcs->cleanup_fb); + + if (!drm_core_check_feature(dev, DRIVER_GEM)) + continue; + + ret = drm_gem_plane_helper_prepare_fb(plane, new_plane_state); + if (ret) + goto fail; } } diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c b/drivers/gpu/drm/drm_gem_atomic_helper.c index a005c5a0ba46..2d825c81e9fd 100644 --- a/drivers/gpu/drm/drm_gem_atomic_helper.c +++ b/drivers/gpu/drm/drm_gem_atomic_helper.c @@ -135,6 +135,9 @@ * GEM based framebuffer drivers which have their buffers always pinned in * memory. * + * This function is the default implementation for GEM drivers of + * &drm_plane_helper_funcs.prepare_fb if no callback is provided. + * * See drm_atomic_set_fence_for_plane() for a discussion of implicit and * explicit fencing in atomic modeset updates. */ diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h index f3a4b47b3986..4e727261dca5 100644 --- a/include/drm/drm_modeset_helper_vtables.h +++ b/include/drm/drm_modeset_helper_vtables.h @@ -1178,8 +1178,11 @@ struct drm_plane_helper_funcs { * equivalent functionality should be implemented through private * members in the plane structure. * -* Drivers which always have their buffers pinned should use -* drm_gem_plane_helper_prepare_fb() for this hook. +* For GEM drivers who neither have a @prepare_fb not @cleanup_fb hook +* set drm_gem_plane_helper_prepare_fb() is called automatically to +* implement this. Other drivers which need additional plane processing +* can call drm_gem_plane_helper_prepare_fb() from their @prepare_fb +* hook. * * The helpers will call @cleanup_fb with matching arguments for every * successful call to this hook. -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
Goes through all the drivers and deletes the default hook since it's the default now. Signed-off-by: Daniel Vetter Cc: Joel Stanley Cc: Andrew Jeffery Cc: "Noralf Trønnes" Cc: Linus Walleij Cc: Emma Anholt Cc: David Lechner Cc: Kamlesh Gurudasani Cc: Oleksandr Andrushchenko Cc: Daniel Vetter Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: Sam Ravnborg Cc: Alex Deucher Cc: Andy Shevchenko Cc: linux-asp...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: xen-de...@lists.xenproject.org --- drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 1 - drivers/gpu/drm/gud/gud_drv.c| 1 - drivers/gpu/drm/mcde/mcde_display.c | 1 - drivers/gpu/drm/pl111/pl111_display.c| 1 - drivers/gpu/drm/tiny/hx8357d.c | 1 - drivers/gpu/drm/tiny/ili9225.c | 1 - drivers/gpu/drm/tiny/ili9341.c | 1 - drivers/gpu/drm/tiny/ili9486.c | 1 - drivers/gpu/drm/tiny/mi0283qt.c | 1 - drivers/gpu/drm/tiny/repaper.c | 1 - drivers/gpu/drm/tiny/st7586.c| 1 - drivers/gpu/drm/tiny/st7735r.c | 1 - drivers/gpu/drm/tve200/tve200_display.c | 1 - drivers/gpu/drm/xen/xen_drm_front_kms.c | 1 - 14 files changed, 14 deletions(-) diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c index 098f96d4d50d..827e62c1daba 100644 --- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c @@ -220,7 +220,6 @@ static const struct drm_simple_display_pipe_funcs aspeed_gfx_funcs = { .enable = aspeed_gfx_pipe_enable, .disable= aspeed_gfx_pipe_disable, .update = aspeed_gfx_pipe_update, - .prepare_fb = drm_gem_simple_display_pipe_prepare_fb, .enable_vblank = aspeed_gfx_enable_vblank, .disable_vblank = aspeed_gfx_disable_vblank, }; diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c index e8b672dc9832..1925df9c0fb7 100644 --- a/drivers/gpu/drm/gud/gud_drv.c +++ b/drivers/gpu/drm/gud/gud_drv.c @@ -364,7 +364,6 @@ static void gud_debugfs_init(struct drm_minor *minor) static const struct drm_simple_display_pipe_funcs gud_pipe_funcs = { .check = gud_pipe_check, .update = gud_pipe_update, - .prepare_fb = drm_gem_simple_display_pipe_prepare_fb, }; static const struct drm_mode_config_funcs gud_mode_config_funcs = { diff --git a/drivers/gpu/drm/mcde/mcde_display.c b/drivers/gpu/drm/mcde/mcde_display.c index 4ddc55d58f38..ce12a36e2db4 100644 --- a/drivers/gpu/drm/mcde/mcde_display.c +++ b/drivers/gpu/drm/mcde/mcde_display.c @@ -1479,7 +1479,6 @@ static struct drm_simple_display_pipe_funcs mcde_display_funcs = { .update = mcde_display_update, .enable_vblank = mcde_display_enable_vblank, .disable_vblank = mcde_display_disable_vblank, - .prepare_fb = drm_gem_simple_display_pipe_prepare_fb, }; int mcde_display_init(struct drm_device *drm) diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c index 6fd7f13f1aca..b5a8859739a2 100644 --- a/drivers/gpu/drm/pl111/pl111_display.c +++ b/drivers/gpu/drm/pl111/pl111_display.c @@ -440,7 +440,6 @@ static struct drm_simple_display_pipe_funcs pl111_display_funcs = { .enable = pl111_display_enable, .disable = pl111_display_disable, .update = pl111_display_update, - .prepare_fb = drm_gem_simple_display_pipe_prepare_fb, }; static int pl111_clk_div_choose_div(struct clk_hw *hw, unsigned long rate, diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c index da5df93450de..9b33c05732aa 100644 --- a/drivers/gpu/drm/tiny/hx8357d.c +++ b/drivers/gpu/drm/tiny/hx8357d.c @@ -184,7 +184,6 @@ static const struct drm_simple_display_pipe_funcs hx8357d_pipe_funcs = { .enable = yx240qv29_enable, .disable = mipi_dbi_pipe_disable, .update = mipi_dbi_pipe_update, - .prepare_fb = drm_gem_simple_display_pipe_prepare_fb, }; static const struct drm_display_mode yx350hv15_mode = { diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c index 69265d8a3beb..976d3209f164 100644 --- a/drivers/gpu/drm/tiny/ili9225.c +++ b/drivers/gpu/drm/tiny/ili9225.c @@ -328,7 +328,6 @@ static const struct drm_simple_display_pipe_funcs ili9225_pipe_funcs = { .enable = ili9225_pipe_enable, .disable= ili9225_pipe_disable, .update = ili9225_pipe_update, - .prepare_fb = drm_gem_simple_display_pipe_prepare_fb, }; static const struct drm_display_mode ili9225_mode = { diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c index ad9ce7b4f76f..37e0c33399c8 100644 --- a/drivers/gpu/drm/tiny/ili9341.c +++ b/drivers/gpu/drm/tiny/ili9341.c @@ -140,7 +140,6 @@ static const struct drm_simple_display_pipe_funcs ili9341_pipe_funcs = { .enable = yx240qv29_enable, .disable = mipi_dbi_pipe_disa
[Intel-gfx] [PATCH 08/11] drm/vram-helpers: Create DRM_GEM_VRAM_PLANE_HELPER_FUNCS
Like we have for the shadow helpers too, and roll it out to drivers. Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Thomas Zimmermann Cc: Hans de Goede Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Daniel Vetter Cc: Tian Tao Cc: Laurent Pinchart --- drivers/gpu/drm/ast/ast_mode.c | 3 +-- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 3 +-- drivers/gpu/drm/vboxvideo/vbox_mode.c | 3 +-- include/drm/drm_gem_vram_helper.h | 12 4 files changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 36d9575aa27b..20557d2c2fae 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -612,8 +612,7 @@ ast_primary_plane_helper_atomic_disable(struct drm_plane *plane, } static const struct drm_plane_helper_funcs ast_primary_plane_helper_funcs = { - .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, - .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb, + DRM_GEM_VRAM_PLANE_HELPER_FUNCS, .atomic_check = ast_primary_plane_helper_atomic_check, .atomic_update = ast_primary_plane_helper_atomic_update, .atomic_disable = ast_primary_plane_helper_atomic_disable, diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c index 29b8332b2bca..ccf80e369b4b 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c @@ -158,8 +158,7 @@ static const struct drm_plane_funcs hibmc_plane_funcs = { }; static const struct drm_plane_helper_funcs hibmc_plane_helper_funcs = { - .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, - .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb, + DRM_GEM_VRAM_PLANE_HELPER_FUNCS, .atomic_check = hibmc_plane_atomic_check, .atomic_update = hibmc_plane_atomic_update, }; diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c b/drivers/gpu/drm/vboxvideo/vbox_mode.c index 964381d55fc1..972c83b720aa 100644 --- a/drivers/gpu/drm/vboxvideo/vbox_mode.c +++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c @@ -488,8 +488,7 @@ static const struct drm_plane_helper_funcs vbox_primary_helper_funcs = { .atomic_check = vbox_primary_atomic_check, .atomic_update = vbox_primary_atomic_update, .atomic_disable = vbox_primary_atomic_disable, - .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, - .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb, + DRM_GEM_VRAM_PLANE_HELPER_FUNCS, }; static const struct drm_plane_funcs vbox_primary_plane_funcs = { diff --git a/include/drm/drm_gem_vram_helper.h b/include/drm/drm_gem_vram_helper.h index 27ed7e9243b9..f48d181c824b 100644 --- a/include/drm/drm_gem_vram_helper.h +++ b/include/drm/drm_gem_vram_helper.h @@ -124,6 +124,18 @@ void drm_gem_vram_plane_helper_cleanup_fb(struct drm_plane *plane, struct drm_plane_state *old_state); +/** + * DRM_GEM_VRAM_PLANE_HELPER_FUNCS - + * Initializes struct drm_plane_helper_funcs for VRAM handling + * + * Drivers may use GEM BOs as VRAM helpers for the framebuffer memory. This + * macro initializes struct drm_plane_helper_funcs to use the respective helper + * functions. + */ +#define DRM_GEM_VRAM_PLANE_HELPER_FUNCS \ + .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, \ + .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb + /* * Helpers for struct drm_simple_display_pipe_funcs */ -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/11] drm/panfrost: Fix implicit sync
Currently this has no practial relevance I think because there's not many who can pull off a setup with panfrost and another gpu in the same system. But the rules are that if you're setting an exclusive fence, indicating a gpu write access in the implicit fencing system, then you need to wait for all fences, not just the previous exclusive fence. panfrost against itself has no problem, because it always sets the exclusive fence (but that's probably something that will need to be fixed for vulkan and/or multi-engine gpus, or you'll suffer badly). Also no problem with that against display. With the prep work done to switch over to the dependency helpers this is now a oneliner. Signed-off-by: Daniel Vetter Cc: Rob Herring Cc: Tomeu Vizoso Cc: Steven Price Cc: Alyssa Rosenzweig Cc: Sumit Semwal Cc: "Christian König" Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org --- drivers/gpu/drm/panfrost/panfrost_job.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c index 707d912ff64a..619d6104040c 100644 --- a/drivers/gpu/drm/panfrost/panfrost_job.c +++ b/drivers/gpu/drm/panfrost/panfrost_job.c @@ -203,9 +203,8 @@ static int panfrost_acquire_object_fences(struct drm_gem_object **bos, int i, ret; for (i = 0; i < bo_count; i++) { - struct dma_fence *fence = dma_resv_get_excl_rcu(bos[i]->resv); - - ret = drm_gem_fence_array_add(deps, fence); + /* panfrost always uses write mode in its current uapi */ + ret = drm_gem_fence_array_add_implicit(deps, bos[i], true); if (ret) return ret; } -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/11] drm/omap: Follow implicit fencing in prepare_fb
I guess no one ever tried running omap together with lima or panfrost, not even sure that's possible. Anyway for consistency, fix this. Signed-off-by: Daniel Vetter Cc: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_plane.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c b/drivers/gpu/drm/omapdrm/omap_plane.c index 801da917507d..512af976b7e9 100644 --- a/drivers/gpu/drm/omapdrm/omap_plane.c +++ b/drivers/gpu/drm/omapdrm/omap_plane.c @@ -6,6 +6,7 @@ #include #include +#include #include #include "omap_dmm_tiler.h" @@ -29,6 +30,8 @@ static int omap_plane_prepare_fb(struct drm_plane *plane, if (!new_state->fb) return 0; + drm_gem_plane_helper_prepare_fb(plane, new_state); + return omap_framebuffer_pin(new_state->fb); } -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/11] drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as default
It's tedious to review this all the time, and my audit showed that arcpgu actually forgot to set this. Make this the default and stop worrying. Again I sprinkled WARN_ON_ONCE on top to make sure we don't have strange combinations of hooks: cleanup_fb without prepare_fb doesn't make sense, and since simpler drivers are all new they better be GEM based drivers. Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter --- drivers/gpu/drm/drm_simple_kms_helper.c | 12 ++-- include/drm/drm_simple_kms_helper.h | 7 +-- 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c b/drivers/gpu/drm/drm_simple_kms_helper.c index 0b095a313c44..1a97571d97d9 100644 --- a/drivers/gpu/drm/drm_simple_kms_helper.c +++ b/drivers/gpu/drm/drm_simple_kms_helper.c @@ -9,6 +9,8 @@ #include #include #include +#include +#include #include #include #include @@ -225,8 +227,14 @@ static int drm_simple_kms_plane_prepare_fb(struct drm_plane *plane, struct drm_simple_display_pipe *pipe; pipe = container_of(plane, struct drm_simple_display_pipe, plane); - if (!pipe->funcs || !pipe->funcs->prepare_fb) - return 0; + if (!pipe->funcs || !pipe->funcs->prepare_fb) { + if (WARN_ON_ONCE(drm_core_check_feature(plane->dev, DRIVER_GEM))) + return 0; + + WARN_ON_ONCE(pipe->funcs && pipe->funcs->cleanup_fb); + + return drm_gem_simple_display_pipe_prepare_fb(pipe, state); + } return pipe->funcs->prepare_fb(pipe, state); } diff --git a/include/drm/drm_simple_kms_helper.h b/include/drm/drm_simple_kms_helper.h index ef9944e9c5fc..363a9a8c3587 100644 --- a/include/drm/drm_simple_kms_helper.h +++ b/include/drm/drm_simple_kms_helper.h @@ -116,8 +116,11 @@ struct drm_simple_display_pipe_funcs { * the documentation for the &drm_plane_helper_funcs.prepare_fb hook for * more details. * -* Drivers which always have their buffers pinned should use -* drm_gem_simple_display_pipe_prepare_fb() for this hook. +* For GEM drivers who neither have a @prepare_fb not @cleanup_fb hook +* set drm_gem_simple_display_pipe_prepare_fb() is called automatically +* to implement this. Other drivers which need additional plane +* processing can call drm_gem_simple_display_pipe_prepare_fb() from +* their @prepare_fb hook. */ int (*prepare_fb)(struct drm_simple_display_pipe *pipe, struct drm_plane_state *plane_state); -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/amdgpu: Comply with implicit fencing rules
== Series Details == Series: series starting with [01/11] drm/amdgpu: Comply with implicit fencing rules URL : https://patchwork.freedesktop.org/series/90401/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6771ddb74407 drm/amdgpu: Comply with implicit fencing rules -:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #15: https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html#reservation-objects -:140: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("")' - ie: 'commit 049aca4363d8 ("drm/amdgpu: fix using shared fence for exported BOs v2")' #140: commit 049aca4363d8af87cab8d53de5401602db3b -:155: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("")' - ie: 'commit 9b495a588799 ("dma-buf: add poll support, v3")' #155: commit 9b495a5887994a6d74d5c261d012083a92b94738 -:183: WARNING:REPEATED_WORD: Possible repeated word: 'to' #183: writes, and a per-bo flag to to skip implicit fencing in the CS -:200: WARNING:TYPO_SPELLING: 'wont' may be misspelled - perhaps 'won't'? #200: wont notice the perf impact. I think we can ignore LTS distros who -:250: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 2 errors, 4 warnings, 0 checks, 10 lines checked 624f38550c70 drm/panfrost: Remove sched_lock -:83: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 51 lines checked 2edd25e5fe08 drm/panfrost: Use xarray and helpers for depedency tracking -:242: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 192 lines checked 953b17b9a69e drm/panfrost: Fix implicit sync -:49: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 11 lines checked 611ea094f310 drm/atomic-helper: make drm_gem_plane_helper_prepare_fb the default -:87: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 44 lines checked b88bbf562ada drm/: drm_gem_plane_helper_prepare_fb is now the default -:223: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 104 lines checked c6de563ba9b7 drm/armada: Remove prepare/cleanup_fb hooks -:88: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 57 lines checked 808bc32c760a drm/vram-helpers: Create DRM_GEM_VRAM_PLANE_HELPER_FUNCS -:83: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 45 lines checked bdd282fc50b5 drm/omap: Follow implicit fencing in prepare_fb -:32: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 15 lines checked f13bd70bbd81 drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as default -:71: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 37 lines checked 8e1fe156d455 drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default -:199: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 98 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/11] drm/amdgpu: Comply with implicit fencing rules
== Series Details == Series: series starting with [01/11] drm/amdgpu: Comply with implicit fencing rules URL : https://patchwork.freedesktop.org/series/90401/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1
Re: [Intel-gfx] [PATCH 02/11] drm/panfrost: Remove sched_lock
Am Freitag, dem 21.05.2021 um 11:09 +0200 schrieb Daniel Vetter: > Scheduler takes care of its own locking, dont worry. For everything else > there's reservation locking on each bo. > > So seems to be entirely redundnant and just a bit in the way. I haven't read all the surrounding code, but this looks wrong from a glance. You must hold a lock across drm_sched_job_init -> drm_sched_entity_push_job as the scheduler fences are initialized in the job init, so if there's no exclusive section across those two function calls you might end up with jobs being queued with their fence seqnos not monotonically increasing, which breaks all kinds of other stuff. I don't see a reason to hold the lock across the reservation calls, though. Regards, Lucas > > Signed-off-by: Daniel Vetter > Cc: Rob Herring > Cc: Tomeu Vizoso > Cc: Steven Price > Cc: Alyssa Rosenzweig > --- > drivers/gpu/drm/panfrost/panfrost_device.c | 1 - > drivers/gpu/drm/panfrost/panfrost_device.h | 2 -- > drivers/gpu/drm/panfrost/panfrost_job.c| 13 ++--- > 3 files changed, 2 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c > b/drivers/gpu/drm/panfrost/panfrost_device.c > index 125ed973feaa..23070c01c63f 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_device.c > +++ b/drivers/gpu/drm/panfrost/panfrost_device.c > @@ -199,7 +199,6 @@ int panfrost_device_init(struct panfrost_device *pfdev) > int err; > struct resource *res; > > - mutex_init(&pfdev->sched_lock); > INIT_LIST_HEAD(&pfdev->scheduled_jobs); > INIT_LIST_HEAD(&pfdev->as_lru_list); > > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h > b/drivers/gpu/drm/panfrost/panfrost_device.h > index 597cf1459b0a..7519903bb031 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_device.h > +++ b/drivers/gpu/drm/panfrost/panfrost_device.h > @@ -105,8 +105,6 @@ struct panfrost_device { > > struct panfrost_perfcnt *perfcnt; > > - struct mutex sched_lock; > - > struct { > struct work_struct work; > atomic_t pending; > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c > b/drivers/gpu/drm/panfrost/panfrost_job.c > index 6003cfeb1322..f5d39ee14ab5 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_job.c > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c > @@ -218,26 +218,19 @@ static void panfrost_attach_object_fences(struct > drm_gem_object **bos, > > int panfrost_job_push(struct panfrost_job *job) > { > - struct panfrost_device *pfdev = job->pfdev; > int slot = panfrost_job_get_slot(job); > struct drm_sched_entity *entity = &job->file_priv->sched_entity[slot]; > struct ww_acquire_ctx acquire_ctx; > int ret = 0; > > - mutex_lock(&pfdev->sched_lock); > - > ret = drm_gem_lock_reservations(job->bos, job->bo_count, > &acquire_ctx); > - if (ret) { > - mutex_unlock(&pfdev->sched_lock); > + if (ret) > return ret; > - } > > ret = drm_sched_job_init(&job->base, entity, NULL); > - if (ret) { > - mutex_unlock(&pfdev->sched_lock); > + if (ret) > goto unlock; > - } > > job->render_done_fence = dma_fence_get(&job->base.s_fence->finished); > > @@ -248,8 +241,6 @@ int panfrost_job_push(struct panfrost_job *job) > > drm_sched_entity_push_job(&job->base, entity); > > - mutex_unlock(&pfdev->sched_lock); > - > panfrost_attach_object_fences(job->bos, job->bo_count, > job->render_done_fence); > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default
Am Freitag, dem 21.05.2021 um 11:09 +0200 schrieb Daniel Vetter: > No need to set it explicitly. > > Signed-off-by: Daniel Vetter > Cc: Laurentiu Palcu > Cc: Lucas Stach For dcss and imx-drm: Acked-by: Lucas Stach > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: Philipp Zabel > Cc: Paul Cercueil > Cc: Chun-Kuang Hu > Cc: Matthias Brugger > Cc: Neil Armstrong > Cc: Kevin Hilman > Cc: Jerome Brunet > Cc: Martin Blumenstingl > Cc: Marek Vasut > Cc: Stefan Agner > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Benjamin Gaignard > Cc: Maxime Coquelin > Cc: Alexandre Torgue > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Jernej Skrabec > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-m...@vger.kernel.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-su...@lists.linux.dev > --- > drivers/gpu/drm/imx/dcss/dcss-plane.c | 1 - > drivers/gpu/drm/imx/ipuv3-plane.c | 1 - > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 - > drivers/gpu/drm/ingenic/ingenic-ipu.c | 1 - > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 1 - > drivers/gpu/drm/meson/meson_overlay.c | 1 - > drivers/gpu/drm/meson/meson_plane.c | 1 - > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 -- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 - > drivers/gpu/drm/stm/ltdc.c | 1 - > drivers/gpu/drm/sun4i/sun4i_layer.c | 1 - > drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 1 - > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 1 - > drivers/gpu/drm/tidss/tidss_plane.c | 1 - > 14 files changed, 15 deletions(-) > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-plane.c > b/drivers/gpu/drm/imx/dcss/dcss-plane.c > index 044d3bdf313c..ac45d54acd4e 100644 > --- a/drivers/gpu/drm/imx/dcss/dcss-plane.c > +++ b/drivers/gpu/drm/imx/dcss/dcss-plane.c > @@ -361,7 +361,6 @@ static void dcss_plane_atomic_disable(struct drm_plane > *plane, > } > > static const struct drm_plane_helper_funcs dcss_plane_helper_funcs = { > - .prepare_fb = drm_gem_plane_helper_prepare_fb, > .atomic_check = dcss_plane_atomic_check, > .atomic_update = dcss_plane_atomic_update, > .atomic_disable = dcss_plane_atomic_disable, > diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c > b/drivers/gpu/drm/imx/ipuv3-plane.c > index 8710f55d2579..ef114b6aa691 100644 > --- a/drivers/gpu/drm/imx/ipuv3-plane.c > +++ b/drivers/gpu/drm/imx/ipuv3-plane.c > @@ -772,7 +772,6 @@ static void ipu_plane_atomic_update(struct drm_plane > *plane, > } > > static const struct drm_plane_helper_funcs ipu_plane_helper_funcs = { > - .prepare_fb = drm_gem_plane_helper_prepare_fb, > .atomic_check = ipu_plane_atomic_check, > .atomic_disable = ipu_plane_atomic_disable, > .atomic_update = ipu_plane_atomic_update, > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c > b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c > index 389cad59e090..62db7349bf6a 100644 > --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c > +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c > @@ -786,7 +786,6 @@ static const struct drm_plane_helper_funcs > ingenic_drm_plane_helper_funcs = { > .atomic_update = ingenic_drm_plane_atomic_update, > .atomic_check = ingenic_drm_plane_atomic_check, > .atomic_disable = ingenic_drm_plane_atomic_disable, > - .prepare_fb = drm_gem_plane_helper_prepare_fb, > }; > > static const struct drm_crtc_helper_funcs ingenic_drm_crtc_helper_funcs = { > diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c > b/drivers/gpu/drm/ingenic/ingenic-ipu.c > index 3b1091e7c0cd..caf038f3e231 100644 > --- a/drivers/gpu/drm/ingenic/ingenic-ipu.c > +++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c > @@ -615,7 +615,6 @@ static const struct drm_plane_helper_funcs > ingenic_ipu_plane_helper_funcs = { > .atomic_update = ingenic_ipu_plane_atomic_update, > .atomic_check = ingenic_ipu_plane_atomic_check, > .atomic_disable = ingenic_ipu_plane_atomic_disable, > - .prepare_fb = drm_gem_plane_helper_prepare_fb, > }; > > static int > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c > b/drivers/gpu/drm/mediatek/mtk_drm_plane.c > index b5582dcf564c..1667a7e7de38 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c > @@ -227,7 +227,6 @@ static void mtk_plane_atomic_update(struct drm_plane > *plane, > } > > static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = { > - .prepare_fb = drm_gem_plane_helper_prepare_fb, > .atomic_check = mtk_plane_atomic_check, > .atomic_update = mtk_plane_atomic_update, > .atomic_disable = mtk_pl
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] drm/amdgpu: Comply with implicit fencing rules
== Series Details == Series: series starting with [01/11] drm/amdgpu: Comply with implicit fencing rules URL : https://patchwork.freedesktop.org/series/90401/ State : success == Summary == CI Bug Log - changes from CI_DRM_10119 -> Patchwork_20167 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20167/index.html Known issues Here are the changes found in Patchwork_20167 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2] ([i915#155]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20167/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][3] -> [INCOMPLETE][4] ([i915#2782]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20167/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20167/fi-bdw-5557u/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20167/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html Warnings * igt@i915_selftest@live@execlists: - fi-bsw-nick:[DMESG-FAIL][7] ([i915#3462]) -> [INCOMPLETE][8] ([i915#2782] / [i915#2940] / [i915#3462]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20167/fi-bsw-nick/igt@i915_selftest@l...@execlists.html - fi-bsw-kefka: [DMESG-FAIL][9] ([i915#3462]) -> [INCOMPLETE][10] ([i915#2782] / [i915#2940] / [i915#3462]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20167/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-cml-u2: [FAIL][11] ([i915#3363] / [i915#3462]) -> [FAIL][12] ([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-cml-u2/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20167/fi-cml-u2/igt@run...@aborted.html - fi-cfl-guc: [FAIL][13] ([i915#3363]) -> [FAIL][14] ([i915#2426] / [i915#3363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-cfl-guc/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20167/fi-cfl-guc/igt@run...@aborted.html - fi-kbl-7567u: [FAIL][15] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][16] ([i915#1436] / [i915#3363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-kbl-7567u/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20167/fi-kbl-7567u/igt@run...@aborted.html - fi-skl-6700k2: [FAIL][17] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][18] ([i915#1436] / [i915#3363]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-skl-6700k2/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20167/fi-skl-6700k2/igt@run...@aborted.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155 [i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082 [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363 [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462 Participating hosts (42 -> 38) -- Missing(4): fi-glk-dsi fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_10119 -> Patchwork_20167 CI-20190529: 20190529 CI_DRM_10119: 1aa3a4edb0aa53e7a302c540f9b947cb55dbadc5 @ git://anongit.freedesktop.o
Re: [Intel-gfx] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote: > > Docs for struct dma_resv are fairly clear: > > "A reservation object can have attached one exclusive fence (normally > associated with write operations) or N shared fences (read > operations)." > > https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html#reservation-objects > > Furthermore a review across all of upstream. > > First of render drivers and how they set implicit fences: > > - nouveau follows this contract, see in validate_fini_no_ticket() > > nouveau_bo_fence(nvbo, fence, !!b->write_domains); > > and that last boolean controls whether the exclusive or shared fence > slot is used. > > - radeon follows this contract by setting > > p->relocs[i].tv.num_shared = !r->write_domain; > > in radeon_cs_parser_relocs(), which ensures that the call to > ttm_eu_fence_buffer_objects() in radeon_cs_parser_fini() will do the > right thing. > > - vmwgfx seems to follow this contract with the shotgun approach of > always setting ttm_val_buf->num_shared = 0, which means > ttm_eu_fence_buffer_objects() will only use the exclusive slot. > > - etnaviv follows this contract, as can be trivially seen by looking > at submit_attach_object_fences() > > - i915 is a bit a convoluted maze with multiple paths leading to > i915_vma_move_to_active(). Which sets the exclusive flag if > EXEC_OBJECT_WRITE is set. This can either come as a buffer flag for > softpin mode, or through the write_domain when using relocations. It > follows this contract. > > - lima follows this contract, see lima_gem_submit() which sets the > exclusive fence when the LIMA_SUBMIT_BO_WRITE flag is set for that > bo > > - msm follows this contract, see msm_gpu_submit() which sets the > exclusive flag when the MSM_SUBMIT_BO_WRITE is set for that buffer > > - panfrost follows this contract with the shotgun approach of just > always setting the exclusive fence, see > panfrost_attach_object_fences(). Benefits of a single engine I guess > > - v3d follows this contract with the same shotgun approach in > v3d_attach_fences_and_unlock_reservation(), but it has at least an > XXX comment that maybe this should be improved > > - v4c uses the same shotgun approach of always setting an exclusive > fence, see vc4_update_bo_seqnos() > > - vgem also follows this contract, see vgem_fence_attach_ioctl() and > the VGEM_FENCE_WRITE. This is used in some igts to validate prime > sharing with i915.ko without the need of a 2nd gpu > > - vritio follows this contract again with the shotgun approach of > always setting an exclusive fence, see virtio_gpu_array_add_fence() > > This covers the setting of the exclusive fences when writing. > > Synchronizing against the exclusive fence is a lot more tricky, and I > only spot checked a few: > > - i915 does it, with the optional EXEC_OBJECT_ASYNC to skip all > implicit dependencies (which is used by vulkan) > > - etnaviv does this. Implicit dependencies are collected in > submit_fence_sync(), again with an opt-out flag > ETNA_SUBMIT_NO_IMPLICIT. These are then picked up in > etnaviv_sched_dependency which is the > drm_sched_backend_ops->dependency callback. > > - v4c seems to not do much here, maybe gets away with it by not having > a scheduler and only a single engine. Since all newer broadcom chips than > the OG vc4 use v3d for rendering, which follows this contract, the > impact of this issue is fairly small. > > - v3d does this using the drm_gem_fence_array_add_implicit() helper, > which then it's drm_sched_backend_ops->dependency callback > v3d_job_dependency() picks up. > > - panfrost is nice here and tracks the implicit fences in > panfrost_job->implicit_fences, which again the > drm_sched_backend_ops->dependency callback panfrost_job_dependency() > picks up. It is mildly questionable though since it only picks up > exclusive fences in panfrost_acquire_object_fences(), but not buggy > in practice because it also always sets the exclusive fence. It > should pick up both sets of fences, just in case there's ever going > to be a 2nd gpu in a SoC with a mali gpu. Or maybe a mali SoC with a > pcie port and a real gpu, which might actually happen eventually. A > bug, but easy to fix. Should probably use the > drm_gem_fence_array_add_implicit() helper. > > - lima is nice an easy, uses drm_gem_fence_array_add_implicit() and > the same schema as v3d. > > - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT, > but because it doesn't use the drm/scheduler it handles fences from > the wrong context with a synchronous dma_fence_wait. See > submit_fence_sync() leading to msm_gem_sync_object(). Investing into > a scheduler might be a good idea. > > - all the remaining drivers are ttm based, where I hope they do > appropriately obey implicit fences already. I didn't do the full > audit there because a) not follow the contract woul
Re: [Intel-gfx] [PATCH 1/3] drm/i915/dmc: s/DRM_ERROR/drm_err
On Thu, 20 May 2021, Anusha Srivatsa wrote: > Use new format of debug messages across intel_csr. > > While at it, change some function definitions which now > need dev_priv for drm_err and drm_info etc. > > v2: use container_of() (Jani) > > Cc: Jani Nikula > Suggested-by: Lucas De Marchi > Signed-off-by: Anusha Srivatsa > Reviewed-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/display/intel_dmc.c | 42 ++-- > 1 file changed, 24 insertions(+), 18 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c > b/drivers/gpu/drm/i915/display/intel_dmc.c > index 560574dd929a..71ef6022d4af 100644 > --- a/drivers/gpu/drm/i915/display/intel_dmc.c > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c > @@ -400,6 +400,8 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc, > u32 mmio_count, mmio_count_max; > u8 *payload; > > + struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc); Please keep the variable declarations together; typically you'd have i915 first. Same for all cases below. > + > BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT || >ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT); > > @@ -439,28 +441,28 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc, > header_len_bytes = dmc_header->header_len; > dmc_header_size = sizeof(*v1); > } else { > - DRM_ERROR("Unknown DMC fw header version: %u\n", > - dmc_header->header_ver); > + drm_err(&i915->drm, "Unknown DMC fw header version: %u\n", > + dmc_header->header_ver); > return 0; > } > > if (header_len_bytes != dmc_header_size) { > - DRM_ERROR("DMC firmware has wrong dmc header length " > + drm_err(&i915->drm, "DMC firmware has wrong dmc header length " > "(%u bytes)\n", header_len_bytes); Please fix indentation on subsequent lines everywhere. Otherwise, LGTM. BR, Jani. > return 0; > } > > /* Cache the dmc header info. */ > if (mmio_count > mmio_count_max) { > - DRM_ERROR("DMC firmware has wrong mmio count %u\n", mmio_count); > + drm_err(&i915->drm, "DMC firmware has wrong mmio count %u\n", > mmio_count); > return 0; > } > > for (i = 0; i < mmio_count; i++) { > if (mmioaddr[i] < DMC_MMIO_START_RANGE || > mmioaddr[i] > DMC_MMIO_END_RANGE) { > - DRM_ERROR("DMC firmware has wrong mmio address 0x%x\n", > - mmioaddr[i]); > + drm_err(&i915->drm, "DMC firmware has wrong mmio > address 0x%x\n", > + mmioaddr[i]); > return 0; > } > dmc->mmioaddr[i] = _MMIO(mmioaddr[i]); > @@ -476,14 +478,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc, > goto error_truncated; > > if (payload_size > dmc->max_fw_size) { > - DRM_ERROR("DMC FW too big (%u bytes)\n", payload_size); > + drm_err(&i915->drm, "DMC FW too big (%u bytes)\n", > payload_size); > return 0; > } > dmc->dmc_fw_size = dmc_header->fw_size; > > dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL); > if (!dmc->dmc_payload) { > - DRM_ERROR("Memory allocation failed for dmc payload\n"); > + drm_err(&i915->drm, "Memory allocation failed for dmc > payload\n"); > return 0; > } > > @@ -493,7 +495,7 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc, > return header_len_bytes + payload_size; > > error_truncated: > - DRM_ERROR("Truncated DMC firmware, refusing.\n"); > + drm_err(&i915->drm, "Truncated DMC firmware, refusing.\n"); > return 0; > } > > @@ -507,6 +509,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc, > u32 num_entries, max_entries, dmc_offset; > const struct intel_fw_info *fw_info; > > + struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc); > + > if (rem_size < package_size) > goto error_truncated; > > @@ -515,8 +519,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc, > } else if (package_header->header_ver == 2) { > max_entries = PACKAGE_V2_MAX_FW_INFO_ENTRIES; > } else { > - DRM_ERROR("DMC firmware has unknown header version %u\n", > - package_header->header_ver); > + drm_err(&i915->drm, "DMC firmware has unknown header version > %u\n", > + package_header->header_ver); > return 0; > } > > @@ -529,8 +533,8 @@ parse_dmc_fw_package(struct intel_dmc *dmc, > goto error_truncated; > > if (package_header->header_len * 4 != package_size) { > - DRM_ERROR("DMC firmware has wrong package header leng
Re: [Intel-gfx] [PATCH 2/3] drm/i915/dmc: Add intel_dmc_has_payload() helper
On Thu, 20 May 2021, Anusha Srivatsa wrote: > We check for dmc_payload being there at various points in the driver. > Replace it with the helper. Seems like a good idea. Some comments inline. BR, Jani. > > v2: rebased. > v3: Move intel_dmc to intel_dmc.h in another patch (Lucas) > > Cc: Lucas De Marchi > Signed-off-by: Anusha Srivatsa > Reviewed-by: Lucas De Marchi > --- > .../gpu/drm/i915/display/intel_display_debugfs.c | 4 ++-- > .../gpu/drm/i915/display/intel_display_power.c | 16 > drivers/gpu/drm/i915/display/intel_dmc.c | 13 + > drivers/gpu/drm/i915/display/intel_dmc.h | 5 + > drivers/gpu/drm/i915/i915_gpu_error.c| 2 +- > 5 files changed, 25 insertions(+), 15 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c > index 94e5cbd86e77..88bb05d5c483 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c > @@ -542,10 +542,10 @@ static int i915_dmc_info(struct seq_file *m, void > *unused) > > wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm); > > - seq_printf(m, "fw loaded: %s\n", yesno(dmc->dmc_payload)); > + seq_printf(m, "fw loaded: %s\n", > yesno(intel_dmc_has_payload(dev_priv))); > seq_printf(m, "path: %s\n", dmc->fw_path); > > - if (!dmc->dmc_payload) > + if (!intel_dmc_has_payload(dev_priv)) > goto out; > > seq_printf(m, "version: %d.%d\n", DMC_VERSION_MAJOR(dmc->version), > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c > b/drivers/gpu/drm/i915/display/intel_display_power.c > index 991ceea06a07..b546672c9b00 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_power.c > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c > @@ -1220,7 +1220,7 @@ static void gen9_dc_off_power_well_enable(struct > drm_i915_private *dev_priv, > static void gen9_dc_off_power_well_disable(struct drm_i915_private *dev_priv, > struct i915_power_well *power_well) > { > - if (!dev_priv->dmc.dmc_payload) > + if (!intel_dmc_has_payload(dev_priv)) > return; > > switch (dev_priv->dmc.target_dc_state) { > @@ -5579,7 +5579,7 @@ static void skl_display_core_init(struct > drm_i915_private *dev_priv, > > gen9_dbuf_enable(dev_priv); > > - if (resume && dev_priv->dmc.dmc_payload) > + if (resume && intel_dmc_has_payload(dev_priv)) > intel_dmc_load_program(dev_priv); > } > > @@ -5646,7 +5646,7 @@ static void bxt_display_core_init(struct > drm_i915_private *dev_priv, bool resume > > gen9_dbuf_enable(dev_priv); > > - if (resume && dev_priv->dmc.dmc_payload) > + if (resume && intel_dmc_has_payload(dev_priv)) > intel_dmc_load_program(dev_priv); > } > > @@ -5712,7 +5712,7 @@ static void cnl_display_core_init(struct > drm_i915_private *dev_priv, bool resume > /* 6. Enable DBUF */ > gen9_dbuf_enable(dev_priv); > > - if (resume && dev_priv->dmc.dmc_payload) > + if (resume && intel_dmc_has_payload(dev_priv)) > intel_dmc_load_program(dev_priv); > } > > @@ -5869,7 +5869,7 @@ static void icl_display_core_init(struct > drm_i915_private *dev_priv, > if (DISPLAY_VER(dev_priv) >= 12) > tgl_bw_buddy_init(dev_priv); > > - if (resume && dev_priv->dmc.dmc_payload) > + if (resume && intel_dmc_has_payload(dev_priv)) > intel_dmc_load_program(dev_priv); > > /* Wa_14011508470 */ > @@ -6230,7 +6230,7 @@ void intel_power_domains_suspend(struct > drm_i915_private *i915, >*/ > if (!(i915->dmc.allowed_dc_mask & DC_STATE_EN_DC9) && > suspend_mode == I915_DRM_SUSPEND_IDLE && > - i915->dmc.dmc_payload) { > + intel_dmc_has_payload(i915)) { > intel_display_power_flush_work(i915); > intel_power_domains_verify_state(i915); > return; > @@ -6420,7 +6420,7 @@ void intel_display_power_resume(struct drm_i915_private > *i915) > if (DISPLAY_VER(i915) >= 11) { > bxt_disable_dc9(i915); > icl_display_core_init(i915, true); > - if (i915->dmc.dmc_payload) { > + if (intel_dmc_has_payload(i915)) { > if (i915->dmc.allowed_dc_mask & > DC_STATE_EN_UPTO_DC6) > skl_enable_dc6(i915); > @@ -6431,7 +6431,7 @@ void intel_display_power_resume(struct drm_i915_private > *i915) > } else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) { > bxt_disable_dc9(i915); > bxt_display_core_init(i915, true); > - if (i915->dmc.dmc_payload && > + if (intel_dmc_has_payload(i915) && > (i915->dmc.allowed_dc_mask & DC_STATE_EN_UPTO_DC5)) > gen9_enabl
Re: [Intel-gfx] [PATCH v4 18/23] drm/i915/display: Introduce new intel_psr_pause/resume function
On Tue, 2021-05-18 at 14:06 +0300, Ville Syrjälä wrote: > On Tue, May 18, 2021 at 09:33:09AM +, Mun, Gwan-gyeong wrote: > > Hi Ville, > > initially, intel_psr_pause() called intel_psr_disable_locked() > > instead > > of intel_psr_exit(). > > In intel_psr_resume(), _intel_psr_enable_locked() was called instead > > of > > intel_psr_activate(). > > Can you share what problem the initial code caused when calling > > intel_psr_pause() / intel_psr_resume()? > > It was doing illegal stuff with crtc->state/etc. That was oopsing. > The other problem was that IIRC it was going to do DPCD accesses > while the cdclk code was already holding the aux mutexes. I moved it > out from under the lock, but I think we might actually want it inside > the lock since we'll need that to prevent PSR during all AUX transfers > anyway. Putting it back inside the lock should also make it less racy > I guess. > > > > > In addition, intel_psr_exit() /intel_psr_activate() function disable > > / > > enable only the PSR source. > > So, if disable/enable for PSR Sink Device is not called together, > > there > > will be a problem that the PSR state machine of sink and source is > > different. > > What do you think? > > If possible I wouldn't want it touch the sink at all. It should > basically be no different to eg. enabling the vblank interrupt. > Hi Ville and Stan, Thanks, Ville, for explaining. intel_psr_pause() and intel_psr_resume() are an api added to use when reactivating (disable and enable) the psr functionality without intel_crtc_state and drm_connector_state, as described in the commit log. And in order to deactivate and activate psr normally, we must deactivate the psr functionality of the sink as well, and at this time, sink psr deactivate using dpcd. And in the part explaining disabling psr in cdclk setting in bspec, the following procedure is explained for disabling psr. 1. Temporarily disable PSR1, PSR2, and GTC. 2. Wait for disabling status from those functions. 3. Wait for any pending Aux transactions to complete, and do not start any new Aux transaction. ... So, in my opinion, when the cdclk setting is called from intel_atomic_commit_tail() with functions such as intel_set_cdclk_pre_plane_update() / intel_set_cdclk_post_plane_update(), if psr deactivation/activation is necessary, it seems that intel_set_cdclk_pre_plane_update() / intel_set_cdclk_post_plane_update() should be called with intel_psr_enable() / intel_psr_disable() functions together. What do you think? Br, G.G. > > > > On Mon, 2021-05-17 at 09:58 -0700, Souza, Jose wrote: > > > On Fri, 2021-05-14 at 20:10 -0700, Matt Roper wrote: > > > > From: Gwan-gyeong Mun > > > > > > > > This introduces the following function that can enable and > > > > disable > > > > psr > > > > without intel_crtc_state/drm_connector_state when intel_psr is > > > > already > > > > enabled with current intel_crtc_state and drm_connector_state > > > > information. > > > > > > > > - intel_psr_pause(): Pause current PSR. it deactivates current > > > > psr > > > > state. > > > > - intel_psr_resume(): Resume paused PSR without intel_crtc_state > > > > and > > > > drm_connector_state. It activates paused > > > > psr > > > > state. > > > > > > > > Cc: José Roberto de Souza > > > > Cc: Stanislav Lisovskiy > > > > Cc: Ville Syrjälä > > > > Signed-off-by: Gwan-gyeong Mun > > > > Signed-off-by: Matt Roper > > > > --- > > > > .../drm/i915/display/intel_display_types.h | 1 + > > > > drivers/gpu/drm/i915/display/intel_psr.c | 93 > > > > - > > > > -- > > > > drivers/gpu/drm/i915/display/intel_psr.h | 2 + > > > > 3 files changed, 82 insertions(+), 14 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h > > > > b/drivers/gpu/drm/i915/display/intel_display_types.h > > > > index b8d1f702d808..ee7cbdd7db87 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h > > > > @@ -1482,6 +1482,7 @@ struct intel_psr { > > > > bool sink_support; > > > > bool source_support; > > > > bool enabled; > > > > + bool paused; > > > > enum pipe pipe; > > > > enum transcoder transcoder; > > > > bool active; > > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c > > > > b/drivers/gpu/drm/i915/display/intel_psr.c > > > > index 4a63d10876ce..d4df3f5e7918 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c > > > > @@ -1060,34 +1060,23 @@ static bool > > > > psr_interrupt_error_check(struct > > > > intel_dp *intel_dp) > > > > return true; > > > > } > > > > > > > > -static void intel_psr_enable_locked(struct intel_dp *intel_dp, > > > > - const struct intel_crtc_state > > > > *crtc_state, > > > > - const struct > > > > drm_connect
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/plane: add intel_plane_helper_add() helper (rev2)
== Series Details == Series: drm/i915/plane: add intel_plane_helper_add() helper (rev2) URL : https://patchwork.freedesktop.org/series/90287/ State : success == Summary == CI Bug Log - changes from CI_DRM_10119 -> Patchwork_20168 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20168/index.html Known issues Here are the changes found in Patchwork_20168 that come from known issues: ### IGT changes ### Issues hit * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][1] ([i915#2283]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20168/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@i915_selftest@live@execlists: - fi-bdw-5557u: NOTRUN -> [DMESG-FAIL][2] ([i915#3462]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20168/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20168/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_psr@cursor_plane_move: - fi-bdw-5557u: NOTRUN -> [SKIP][4] ([fdo#109271]) +9 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20168/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html Warnings * igt@i915_selftest@live@execlists: - fi-bsw-nick:[DMESG-FAIL][5] ([i915#3462]) -> [INCOMPLETE][6] ([i915#2782] / [i915#2940] / [i915#3462]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20168/fi-bsw-nick/igt@i915_selftest@l...@execlists.html - fi-bsw-kefka: [DMESG-FAIL][7] ([i915#3462]) -> [INCOMPLETE][8] ([i915#2782] / [i915#2940] / [i915#3462]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20168/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-cfl-8700k: [FAIL][9] ([i915#3363]) -> [FAIL][10] ([i915#2426] / [i915#3363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-cfl-8700k/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20168/fi-cfl-8700k/igt@run...@aborted.html - fi-glk-dsi: [FAIL][11] ([i915#3363] / [k.org#202321]) -> [FAIL][12] ([i915#2426] / [i915#3363] / [k.org#202321]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-glk-dsi/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20168/fi-glk-dsi/igt@run...@aborted.html - fi-bdw-5557u: [FAIL][13] ([i915#1602] / [i915#2029]) -> [FAIL][14] ([i915#3462]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-bdw-5557u/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20168/fi-bdw-5557u/igt@run...@aborted.html - fi-skl-6700k2: [FAIL][15] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][16] ([i915#1436] / [i915#3363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-skl-6700k2/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20168/fi-skl-6700k2/igt@run...@aborted.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029 [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283 [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966 [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363 [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462 [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321 Participating hosts (42 -> 39) -- Missing(3): fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_10119 -> Patchwork_20168 CI-20190529: 20190529 CI_DRM_10119: 1aa3a4edb0aa53e7a302c540f9b947cb55dbadc5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6090: 8eeb9c130e75d4063d0dc2ed69c8
Re: [Intel-gfx] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
Am 21.05.21 um 11:09 schrieb Daniel Vetter: Docs for struct dma_resv are fairly clear: "A reservation object can have attached one exclusive fence (normally associated with write operations) or N shared fences (read operations)." https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdri.freedesktop.org%2Fdocs%2Fdrm%2Fdriver-api%2Fdma-buf.html%23reservation-objects&data=04%7C01%7Cchristian.koenig%40amd.com%7C2cdb7d8e82de40fd452e08d91c383a13%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637571850083203679%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Y5zO4aMKMuQwTCKVk6DrjTIbbRBLrcklrZgNCzNGXGs%3D&reserved=0 Furthermore a review across all of upstream. First of render drivers and how they set implicit fences: - nouveau follows this contract, see in validate_fini_no_ticket() nouveau_bo_fence(nvbo, fence, !!b->write_domains); and that last boolean controls whether the exclusive or shared fence slot is used. - radeon follows this contract by setting p->relocs[i].tv.num_shared = !r->write_domain; in radeon_cs_parser_relocs(), which ensures that the call to ttm_eu_fence_buffer_objects() in radeon_cs_parser_fini() will do the right thing. - vmwgfx seems to follow this contract with the shotgun approach of always setting ttm_val_buf->num_shared = 0, which means ttm_eu_fence_buffer_objects() will only use the exclusive slot. - etnaviv follows this contract, as can be trivially seen by looking at submit_attach_object_fences() - i915 is a bit a convoluted maze with multiple paths leading to i915_vma_move_to_active(). Which sets the exclusive flag if EXEC_OBJECT_WRITE is set. This can either come as a buffer flag for softpin mode, or through the write_domain when using relocations. It follows this contract. - lima follows this contract, see lima_gem_submit() which sets the exclusive fence when the LIMA_SUBMIT_BO_WRITE flag is set for that bo - msm follows this contract, see msm_gpu_submit() which sets the exclusive flag when the MSM_SUBMIT_BO_WRITE is set for that buffer - panfrost follows this contract with the shotgun approach of just always setting the exclusive fence, see panfrost_attach_object_fences(). Benefits of a single engine I guess - v3d follows this contract with the same shotgun approach in v3d_attach_fences_and_unlock_reservation(), but it has at least an XXX comment that maybe this should be improved - v4c uses the same shotgun approach of always setting an exclusive fence, see vc4_update_bo_seqnos() - vgem also follows this contract, see vgem_fence_attach_ioctl() and the VGEM_FENCE_WRITE. This is used in some igts to validate prime sharing with i915.ko without the need of a 2nd gpu - vritio follows this contract again with the shotgun approach of always setting an exclusive fence, see virtio_gpu_array_add_fence() This covers the setting of the exclusive fences when writing. Synchronizing against the exclusive fence is a lot more tricky, and I only spot checked a few: - i915 does it, with the optional EXEC_OBJECT_ASYNC to skip all implicit dependencies (which is used by vulkan) - etnaviv does this. Implicit dependencies are collected in submit_fence_sync(), again with an opt-out flag ETNA_SUBMIT_NO_IMPLICIT. These are then picked up in etnaviv_sched_dependency which is the drm_sched_backend_ops->dependency callback. - v4c seems to not do much here, maybe gets away with it by not having a scheduler and only a single engine. Since all newer broadcom chips than the OG vc4 use v3d for rendering, which follows this contract, the impact of this issue is fairly small. - v3d does this using the drm_gem_fence_array_add_implicit() helper, which then it's drm_sched_backend_ops->dependency callback v3d_job_dependency() picks up. - panfrost is nice here and tracks the implicit fences in panfrost_job->implicit_fences, which again the drm_sched_backend_ops->dependency callback panfrost_job_dependency() picks up. It is mildly questionable though since it only picks up exclusive fences in panfrost_acquire_object_fences(), but not buggy in practice because it also always sets the exclusive fence. It should pick up both sets of fences, just in case there's ever going to be a 2nd gpu in a SoC with a mali gpu. Or maybe a mali SoC with a pcie port and a real gpu, which might actually happen eventually. A bug, but easy to fix. Should probably use the drm_gem_fence_array_add_implicit() helper. - lima is nice an easy, uses drm_gem_fence_array_add_implicit() and the same schema as v3d. - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT, but because it doesn't use the drm/scheduler it handles fences from the wrong context with a synchronous dma_fence_wait. See submit_fence_sync() leading to msm_gem_sync_object(). Investing into a sch
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/kms_big_fb: Wait for vblank before collecting CRC
Hi Vidya, on which machines this would help? I see there's many vblanks already being waited. There's igt_display_commit2 which probably will block and even if it didn't there's igt_pipe_crc_collect_crc(..) where crc calculation is started after flip and then get one crc before disabling crc counting again. /Juha-Pekka On 21.5.2021 7.08, Vidya Srinivas wrote: Without wait for vblank, CRC mismatch is seen between big and small CRC on few systems Change-Id: I3bec931aa901130997e693ac1cacf389e2a8100f Signed-off-by: Vidya Srinivas --- tests/kms_big_fb.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c index b2027b6b9d1b..7d78ff829d41 100644 --- a/tests/kms_big_fb.c +++ b/tests/kms_big_fb.c @@ -254,6 +254,7 @@ static void unset_lut(data_t *data) static bool test_plane(data_t *data) { igt_plane_t *plane = data->plane; + igt_display_t *display = &data->display; struct igt_fb *small_fb = &data->small_fb; struct igt_fb *big_fb = &data->big_fb; int w = data->big_fb_width - small_fb->width; @@ -337,16 +338,17 @@ static bool test_plane(data_t *data) igt_display_commit2(&data->display, data->display.is_atomic ? COMMIT_ATOMIC : COMMIT_UNIVERSAL); - + igt_wait_for_vblank(data->drm_fd, display->pipes[data->pipe].crtc_offset); igt_pipe_crc_collect_crc(data->pipe_crc, &small_crc); igt_plane_set_fb(plane, big_fb); igt_fb_set_position(big_fb, plane, x, y); igt_fb_set_size(big_fb, plane, small_fb->width, small_fb->height); + igt_plane_set_size(plane, data->width, data->height); igt_display_commit2(&data->display, data->display.is_atomic ? COMMIT_ATOMIC : COMMIT_UNIVERSAL); - + igt_wait_for_vblank(data->drm_fd, display->pipes[data->pipe].crtc_offset); igt_pipe_crc_collect_crc(data->pipe_crc, &big_crc); igt_plane_set_fb(plane, NULL); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v3)
On Tue, May 11, 2021 at 10:05:26AM +0300, Heikki Krogerus wrote: > On Wed, May 05, 2021 at 06:24:07PM +0200, Hans de Goede wrote: > > Hi All, > > > > Here is v3 of my patchset making DP over Type-C work on devices where the > > Type-C controller does not drive the HPD pin on the GPU, but instead > > we need to forward HPD events from the Type-C controller to the DRM driver. > > These look good to me. I can also test these next week if needed. I'll > give my Tested-by tag after that if these haven't been taken by > anybody by that. It's almost weird to see console output from the Type-C connector on my good old GPD printed to an actual display :-) At least in my tests, the DP alt mode driver now calls drm_connector_oob_hotplug_event() only when it should. This is pretty cool! FWIW: Tested-by: Heikki Krogerus thanks, -- heikki ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo
[AMD Official Use Only] i would like to add a unit marker for the stats that we monitor in the fd, as we discussed currently we are displaying the usage percentage, because we wanted to to provide single query percentages, but this may evolve with time. May I suggest to add two new fields drm-stat-interval: <64 bit> ns drm-stat-timestamp: <64 bit> ns If interval is set, engine utilization is calculated by doing = 100*/ if interval is not set, two reads are needed : = 100* / Regards, David From: Tvrtko Ursulin Sent: Thursday, May 20, 2021 8:12 AM To: Intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org ; Tvrtko Ursulin ; Nieto, David M ; Koenig, Christian ; Daniel Vetter Subject: [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo From: Tvrtko Ursulin Similar to AMD commit 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the infrastructure added in previous patches, we add basic client info and GPU engine utilisation for i915. Example of the output: pos:0 flags: 012 mnt_id: 21 drm-driver: i915 drm-pdev: :00:02.0 drm-client-id: 7 drm-engine-render: 9288864723 ns drm-engine-copy:2035071108 ns drm-engine-video: 0 ns drm-engine-video-enhance: 0 ns DRM related fields are appropriately prefixed for easy parsing and separation from generic fdinfo fields. Idea is for some fields to become either fully or partially standardised in order to enable writting of generic top-like tools. Initial proposal for fully standardised common fields: drm-driver: drm-pdev: Optional fully standardised: drm-client-id: Optional partially standardised: engine-: ns memory-: KiB Once agreed the format would need to go to some README or kerneldoc in DRM core. Signed-off-by: Tvrtko Ursulin Cc: David M Nieto Cc: Christian König Cc: Daniel Vetter --- drivers/gpu/drm/i915/i915_drm_client.c | 68 ++ drivers/gpu/drm/i915/i915_drm_client.h | 4 ++ drivers/gpu/drm/i915/i915_drv.c| 3 ++ 3 files changed, 75 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drm_client.c b/drivers/gpu/drm/i915/i915_drm_client.c index 1e5db7753276..5e9cfba1116b 100644 --- a/drivers/gpu/drm/i915/i915_drm_client.c +++ b/drivers/gpu/drm/i915/i915_drm_client.c @@ -9,6 +9,11 @@ #include +#include + +#include "gem/i915_gem_context.h" +#include "gt/intel_engine_user.h" + #include "i915_drm_client.h" #include "i915_drv.h" #include "i915_gem.h" @@ -168,3 +173,66 @@ void i915_drm_clients_fini(struct i915_drm_clients *clients) xa_destroy(&clients->xarray); } + +#ifdef CONFIG_PROC_FS +static const char * const uabi_class_names[] = { + [I915_ENGINE_CLASS_RENDER] = "render", + [I915_ENGINE_CLASS_COPY] = "copy", + [I915_ENGINE_CLASS_VIDEO] = "video", + [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "video-enhance", +}; + +static u64 busy_add(struct i915_gem_context *ctx, unsigned int class) +{ + struct i915_gem_engines_iter it; + struct intel_context *ce; + u64 total = 0; + + for_each_gem_engine(ce, rcu_dereference(ctx->engines), it) { + if (ce->engine->uabi_class != class) + continue; + + total += intel_context_get_total_runtime_ns(ce); + } + + return total; +} + +static void +show_client_class(struct seq_file *m, + struct i915_drm_client *client, + unsigned int class) +{ + const struct list_head *list = &client->ctx_list; + u64 total = atomic64_read(&client->past_runtime[class]); + struct i915_gem_context *ctx; + + rcu_read_lock(); + list_for_each_entry_rcu(ctx, list, client_link) + total += busy_add(ctx, class); + rcu_read_unlock(); + + return seq_printf(m, "drm-engine-%s:\t%llu ns\n", + uabi_class_names[class], total); +} + +void i915_drm_client_fdinfo(struct seq_file *m, struct file *f) +{ + struct drm_file *file = f->private_data; + struct drm_i915_file_private *file_priv = file->driver_priv; + struct drm_i915_private *i915 = file_priv->dev_priv; + struct i915_drm_client *client = file_priv->client; + struct pci_dev *pdev = to_pci_dev(i915->drm.dev); + unsigned int i; + + seq_printf(m, "drm-driver:\ti915\n"); + seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n", + pci_domain_nr(pdev->bus), pdev->bus->number, + PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn)); + + seq_printf(m, "drm-client-id:\t%u\n", client->id); + + for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++) + show_client_class(m, client, i); +} +#endif diff --git a/drivers/gpu/drm/i915/i915_drm_client.h b/drivers/gpu/drm/i915/i915_drm_client.h index b2b69d6985e4..9885002433a0 100644 --- a/drivers/gpu/drm/i915/i915_drm_client.h +++ b/drivers/gpu/drm/i915/i915_drm_client.h @@ -98,6
Re: [Intel-gfx] [Mesa-dev] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
Am 20.05.21 um 23:38 schrieb Jason Ekstrand: On Thu, May 20, 2021 at 10:46 AM Matthew Brost wrote: On Thu, May 20, 2021 at 01:11:59PM +0200, Christian König wrote: Am 19.05.21 um 18:51 schrieb Matthew Brost: On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote: Oh, yeah we call that gang submit on the AMD side. Had already some internal discussions how to implement this, but so far couldn't figure out how to cleanly introduce that into the DRM scheduler. Can you briefly describe in a few words how that is supposed to work on the Intel side? On Intel, we actually have two cases which don't fit the current drm/scheduler model well: balanced and bonded. In the balanced model, we want to submit a batch which can go to any one of some set of engines and we don't care which. It's up to the kernel to pick an engine. Imagine you had 64 identical HW compute queues, for instance. This could be done by making all the identical engines share a single drm_gpu_scheduler and round-robin around the HW queues or something. I don't know that we strictly need drm/scheduler to be aware of it but it might be nice if it grew support for this mode so we could maintain a 1:1 relationship between HW queues and drm_gpu_schedulers. That said, I'm not sure how this would play with GuC queues so maybe it doesn't help? Oh, we do have support for load balancing like that. When you call drm_sched_entity_init() you can give a list of drm_gpu_scheduler object to use round robing for scheduling. New jobs are then scheduler to the drm_gpu_scheduler instance which is idle or rather the least busy one. The bonded model is like your ganged, I think. We want to submit N batches to run in parallel. And they actually have to be executing on the GPU simultaneously and not just sort-of at similar times. We need this for video. There are also potential use-cases in Vulkan or even GL that might be able to use this. One difference with the balanced mode is that bonds don't, strictly speaking, need to be on the same type of engine. Imagine, for instance, a 3D batch with a parallel compute batch doing vertex pre-processing. I'm pretty sure the bonded case is something that the mobile drivers (panfrost, etc.) would like as well for doing Vulkan on tilers where you often have to have two command buffers running in parallel. They're currently doing it by submitting a giant pile of batches where they split the batch and add sync primitives every time some GL call requires them to sync between fragment and vertex pipes. Yeah, we have exactly the same problem as well. But so far every model we discussed has some drawbacks and it is rather hard for the scheduler to guarantee that stuff runs at the same time. So if you got any ideas how to cleanly implement that then they would be rather welcomed. Regards, Christian. So, to sum up, I think there's likely some good collaboration to be had here for everyone. :-) --Jason Sure, I've done a quick PoC internally and have been able to hook this into the DRM scheduler. Basically each BB still maps to a single job as each job is somewhat unique (e.g. each job has its own ring, lrc, seqno, etc...). However all the jobs configured to run in parallel map to a single sched_entity which maintains the order each job was generated from the execbuf IOCTL (1 - N). When the backend receives jobs 1 to N - 1 it basically just updates some internal state. When the backend sees job N (last job) it actually does the submit for jobs 1 - N which with GuC submission is a simple command moving the LRC tail of the N jobs. Daniel has suggested that we create a single job for the NN BBs but that would be huge rework to the internals of the i915 and likely won't happen by the time this code first lands. Also worth noting one way a job isn't really a treated individually is the excl slot with dma-resv. In that case we create a composite fence of all jobs (dma_fence_array). Yeah, that's something we have discussed as well. How do you prevent the scheduler from over committing to a single ring buffer in this scenario? Each job has its own ring, the execbuf IOCTL throttles itself for each job if there isn't space in the ring. This is exactly the same as non-parallel submits. I think this is what you were asking? If not, maybe try explaining the question a bit more. Matt Christian. Matt Thanks, Christian. Am 19.05.21 um 01:58 schrieb Matthew Brost: Add entry fpr i915 new parallel submission uAPI plan. v2: (Daniel Vetter): - Expand logical order explaination - Add dummy header - Only allow N BBs in execbuf IOCTL - Configure parallel submission per slot not per gem context Cc: Tvrtko Ursulin Cc: Tony Ye CC: Carl Zhang Cc: Daniel Vetter Cc: Jason Ekstrand Signed-off-by: Matthew Brost --- Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++ Documentation/gpu/rfc/i915_scheduler.rst | 53 ++- 2 files changed,
Re: [Intel-gfx] [PATCH 08/11] drm/vram-helpers: Create DRM_GEM_VRAM_PLANE_HELPER_FUNCS
在 2021/5/21 17:09, Daniel Vetter 写道: Like we have for the shadow helpers too, and roll it out to drivers. Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Thomas Zimmermann Cc: Hans de Goede Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Daniel Vetter Cc: Tian Tao Cc: Laurent Pinchart --- drivers/gpu/drm/ast/ast_mode.c | 3 +-- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 3 +-- drivers/gpu/drm/vboxvideo/vbox_mode.c | 3 +-- include/drm/drm_gem_vram_helper.h | 12 4 files changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 36d9575aa27b..20557d2c2fae 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -612,8 +612,7 @@ ast_primary_plane_helper_atomic_disable(struct drm_plane *plane, } static const struct drm_plane_helper_funcs ast_primary_plane_helper_funcs = { - .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, - .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb, + DRM_GEM_VRAM_PLANE_HELPER_FUNCS, .atomic_check = ast_primary_plane_helper_atomic_check, .atomic_update = ast_primary_plane_helper_atomic_update, .atomic_disable = ast_primary_plane_helper_atomic_disable, diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c index 29b8332b2bca..ccf80e369b4b 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c @@ -158,8 +158,7 @@ static const struct drm_plane_funcs hibmc_plane_funcs = { }; static const struct drm_plane_helper_funcs hibmc_plane_helper_funcs = { - .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, - .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb, + DRM_GEM_VRAM_PLANE_HELPER_FUNCS, .atomic_check = hibmc_plane_atomic_check, .atomic_update = hibmc_plane_atomic_update, }; Reviewed-by: Tian Tao diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c b/drivers/gpu/drm/vboxvideo/vbox_mode.c index 964381d55fc1..972c83b720aa 100644 --- a/drivers/gpu/drm/vboxvideo/vbox_mode.c +++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c @@ -488,8 +488,7 @@ static const struct drm_plane_helper_funcs vbox_primary_helper_funcs = { .atomic_check = vbox_primary_atomic_check, .atomic_update = vbox_primary_atomic_update, .atomic_disable = vbox_primary_atomic_disable, - .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, - .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb, + DRM_GEM_VRAM_PLANE_HELPER_FUNCS, }; static const struct drm_plane_funcs vbox_primary_plane_funcs = { diff --git a/include/drm/drm_gem_vram_helper.h b/include/drm/drm_gem_vram_helper.h index 27ed7e9243b9..f48d181c824b 100644 --- a/include/drm/drm_gem_vram_helper.h +++ b/include/drm/drm_gem_vram_helper.h @@ -124,6 +124,18 @@ void drm_gem_vram_plane_helper_cleanup_fb(struct drm_plane *plane, struct drm_plane_state *old_state); +/** + * DRM_GEM_VRAM_PLANE_HELPER_FUNCS - + * Initializes struct drm_plane_helper_funcs for VRAM handling + * + * Drivers may use GEM BOs as VRAM helpers for the framebuffer memory. This + * macro initializes struct drm_plane_helper_funcs to use the respective helper + * functions. + */ +#define DRM_GEM_VRAM_PLANE_HELPER_FUNCS \ + .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, \ + .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb + /* * Helpers for struct drm_simple_display_pipe_funcs */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Nouveau] [PATCH 0/7] Per client engine busyness
> Well if it becomes a problem fixing the debugfs "clients" file and > making it sysfs shouldn't be much of a problem later on. Why not to try using something in terms of perf / opensnoop or bpf to do the work. Should be optimal enough. ie. http://www.brendangregg.com/blog/2014-07-25/opensnoop-for-linux.html https://man7.org/linux/man-pages/man2/bpf.2.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On 19/05/2021 00:58, Matthew Brost wrote: Add entry fpr i915 new parallel submission uAPI plan. v2: (Daniel Vetter): - Expand logical order explaination - Add dummy header - Only allow N BBs in execbuf IOCTL - Configure parallel submission per slot not per gem context Cc: Tvrtko Ursulin Cc: Tony Ye CC: Carl Zhang Cc: Daniel Vetter Cc: Jason Ekstrand Signed-off-by: Matthew Brost --- Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++ Documentation/gpu/rfc/i915_scheduler.rst | 53 ++- 2 files changed, 196 insertions(+), 1 deletion(-) create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h b/Documentation/gpu/rfc/i915_parallel_execbuf.h new file mode 100644 index ..8c64b983ccad --- /dev/null +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h @@ -0,0 +1,144 @@ +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see i915_context_engines_parallel_submit */ + +/* + * i915_context_engines_parallel_submit: + * + * Setup a slot to allow multiple BBs to be submitted in a single execbuf IOCTL. + * Those BBs will then be scheduled to run on the GPU in parallel. Multiple + * hardware contexts are created internally in the i915 run these BBs. Once a + * slot is configured for N BBs only N BBs can be submitted in each execbuf + * IOCTL and this is implict behavior (e.g. the user doesn't tell the execbuf + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are based on + * the slots configuration). 1) Expand the term slot here with "slot in the context engine map" least once for clarity. 2) About where execbuf will implicitly be finding batches - suggest to also cover first/last flag here. I know you have it in the readme but I think it is good if uapi header is as self-contained as possible. + * + * Their are two currently defined ways to control the placement of the + * hardware contexts on physical engines: default behavior (no flags) and + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in the + * future as new hardware / use cases arise. Details of how to use this + * interface below above the flags. + * + * Returns -EINVAL if hardware context placement configuration invalid or if the + * placement configuration isn't supported on the platform / submission + * interface. + * Returns -ENODEV if extension isn't supported on the platform / submission + * inteface. + */ +struct i915_context_engines_parallel_submit { + struct i915_user_extension base; + + __u16 engine_index; /* slot for parallel engine */ + __u16 width;/* number of contexts per parallel engine */ + __u16 num_siblings; /* number of siblings per context */ + __u16 mbz16; +/* + * Default placement behvavior (currently unsupported): + * + * Rather than restricting parallel submission to a single class with a + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a mode that What do you mean with logically contiguous here? It sounds ambiguous versus logical vs "normal" engine instance numbers. + * enables parallel submission across multiple engine classes. In this case each + * context's logical engine mask indicates where that context can placed. It is + * implied in this mode that all contexts have mutual exclusive placement (e.g. + * if one context is running CS0 no other contexts can run on CS0). I think talk about logical context and its mask is too implementation detail at the uapi level. Instead I would suggest more userspace programmer centric description. + * + * Example 1 pseudo code: + * CSX[Y] = engine class X, logical instance Y + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE + * set_engines(INVALID) + * set_parallel(engine_index=0, width=2, num_siblings=2, + * engines=CS0[0],CS0[1],CS1[0],CS1[1]) + * + * Results in the following valid placements: + * CS0[0], CS1[0] + * CS0[0], CS1[1] + * CS0[1], CS1[0] + * CS0[1], CS1[1] + * + * This can also be though of as 2 virtual engines: + * VE[0] = CS0[0], CS0[1] + * VE[1] = CS1[0], CS1[1] Ah okay so essentially similar to what I was proposing a year ago. But then it is no longer "set_parallel" really. It is one slot in the engine map, right, with the idea to super class intel_context in the implementation? So really a wide virtual engine, as opposed to single one. In which case I think it makes sense to stay close to the existing naming of the load_balance extension for consistency. Load_balance_wide? Load_balance_parallel? Multi? I also have to say the notation "CS0[0]" - I who know this problem space am finding it hard to penetrate what that actually means. (Also uppercase IMO makes it hard to read, but maybe it is just me.) Looking a bit lower below, extension seems to be taking a 2d array of class:instance pairs, right? If so then reading these docs in order, or even just look
Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On 20/05/2021 20:41, Daniel Vetter wrote: On Thu, May 20, 2021 at 11:57:44AM +0100, Tvrtko Ursulin wrote: On 20/05/2021 10:54, Daniel Vetter wrote: On Wed, May 19, 2021 at 7:19 PM Matthew Brost wrote: On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote: On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote: Add entry fpr i915 new parallel submission uAPI plan. v2: (Daniel Vetter): - Expand logical order explaination - Add dummy header - Only allow N BBs in execbuf IOCTL - Configure parallel submission per slot not per gem context Cc: Tvrtko Ursulin Cc: Tony Ye CC: Carl Zhang Cc: Daniel Vetter Cc: Jason Ekstrand Signed-off-by: Matthew Brost --- Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++ Documentation/gpu/rfc/i915_scheduler.rst | 53 ++- 2 files changed, 196 insertions(+), 1 deletion(-) create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h b/Documentation/gpu/rfc/i915_parallel_execbuf.h new file mode 100644 index ..8c64b983ccad --- /dev/null +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h @@ -0,0 +1,144 @@ +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see i915_context_engines_parallel_submit */ + +/* + * i915_context_engines_parallel_submit: + * + * Setup a slot to allow multiple BBs to be submitted in a single execbuf IOCTL. + * Those BBs will then be scheduled to run on the GPU in parallel. Multiple + * hardware contexts are created internally in the i915 run these BBs. Once a + * slot is configured for N BBs only N BBs can be submitted in each execbuf + * IOCTL and this is implict behavior (e.g. the user doesn't tell the execbuf + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are based on + * the slots configuration). + * + * Their are two currently defined ways to control the placement of the + * hardware contexts on physical engines: default behavior (no flags) and + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in the + * future as new hardware / use cases arise. Details of how to use this + * interface below above the flags. + * + * Returns -EINVAL if hardware context placement configuration invalid or if the + * placement configuration isn't supported on the platform / submission + * interface. + * Returns -ENODEV if extension isn't supported on the platform / submission + * inteface. + */ +struct i915_context_engines_parallel_submit { + struct i915_user_extension base; + + __u16 engine_index; /* slot for parallel engine */ + __u16 width;/* number of contexts per parallel engine */ + __u16 num_siblings; /* number of siblings per context */ + __u16 mbz16; Ok the big picture looks reasonable now, the flags still confuse me. Yea, it is a bit confusing. +/* + * Default placement behvavior (currently unsupported): + * + * Rather than restricting parallel submission to a single class with a + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a mode that + * enables parallel submission across multiple engine classes. In this case each + * context's logical engine mask indicates where that context can placed. It is + * implied in this mode that all contexts have mutual exclusive placement (e.g. + * if one context is running CS0 no other contexts can run on CS0). + * + * Example 1 pseudo code: + * CSX[Y] = engine class X, logical instance Y + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE + * set_engines(INVALID) + * set_parallel(engine_index=0, width=2, num_siblings=2, + * engines=CS0[0],CS0[1],CS1[0],CS1[1]) + * + * Results in the following valid placements: + * CS0[0], CS1[0] + * CS0[0], CS1[1] + * CS0[1], CS1[0] + * CS0[1], CS1[1] + * + * This can also be though of as 2 virtual engines: + * VE[0] = CS0[0], CS0[1] + * VE[1] = CS1[0], CS1[1] + * + * Example 2 pseudo code: + * CS[X] = generic engine of same class, logical instance X + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE + * set_engines(INVALID) + * set_parallel(engine_index=0, width=2, num_siblings=3, + * engines=CS[0],CS[1],CS[2],CS[0],CS[1],CS[2]) + * + * Results in the following valid placements: + * CS[0], CS[1] + * CS[0], CS[2] + * CS[1], CS[0] + * CS[1], CS[2] + * CS[2], CS[0] + * CS[2], CS[1] + * + * + * This can also be though of as 2 virtual engines: + * VE[0] = CS[0], CS[1], CS[2] + * VE[1] = CS[0], CS[1], CS[2] + + * This enables a use case where all engines are created equally, we don't care + * where they are scheduled, we just want a certain number of resources, for + * those resources to be scheduled in parallel, and possibly across multiple + * engine classes. + */ So I don't really get what this does compared to setting the flag below. Is this just about running the batchbuffers the wrong way round, i.e. if you have (simplest case) width=2, num_sibglings=1, engines=
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops (rev2)
== Series Details == Series: drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops (rev2) URL : https://patchwork.freedesktop.org/series/89503/ State : success == Summary == CI Bug Log - changes from CI_DRM_10109_full -> Patchwork_20156_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20156_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-skl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-skl1/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@clone: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-snb7/igt@gem_ctx_persiste...@clone.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][3] ([i915#3354]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#2846]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-glk2/igt@gem_exec_f...@basic-deadline.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-glk8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-tglb7/igt@gem_exec_fair@basic-p...@bcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-tglb5/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-glk4/igt@gem_exec_fair@basic-p...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-glk6/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_params@rsvd2-dirt: - shard-tglb: NOTRUN -> [SKIP][10] ([fdo#109283]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-tglb8/igt@gem_exec_par...@rsvd2-dirt.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][11] ([i915#2389]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-snb5/igt@gem_exec_reloc@basic-wide-act...@rcs0.html - shard-kbl: NOTRUN -> [FAIL][12] ([i915#2389]) +4 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-kbl3/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2389]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_whisper@basic-contexts-all: - shard-glk: [PASS][14] -> [DMESG-WARN][15] ([i915#118] / [i915#95]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-glk5/igt@gem_exec_whis...@basic-contexts-all.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-glk7/igt@gem_exec_whis...@basic-contexts-all.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-kbl: NOTRUN -> [INCOMPLETE][16] ([i915#3468]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-kbl3/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([i915#2910] / [i915#3468]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-iclb3/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-iclb2/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([i915#198] / [i915#2910] / [i915#3468]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-skl7/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-skl8/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([i915#3468]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10109/shard-tglb5/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20156/shard-tglb3/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_mmap_gtt@fault-concurrent-x: - shard-apl: NOTRUN -> [INCOMPLETE][23] ([i915#3468]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patc
Re: [Intel-gfx] [PATCH 04/11] drm/panfrost: Fix implicit sync
Hi, On Fri, 21 May 2021 at 10:10, Daniel Vetter wrote: > Currently this has no practial relevance I think because there's not > many who can pull off a setup with panfrost and another gpu in the > same system. But the rules are that if you're setting an exclusive > fence, indicating a gpu write access in the implicit fencing system, > then you need to wait for all fences, not just the previous exclusive > fence. > > panfrost against itself has no problem, because it always sets the > exclusive fence (but that's probably something that will need to be > fixed for vulkan and/or multi-engine gpus, or you'll suffer badly). > Also no problem with that against display. Yeah, the 'second-generation Valhall' GPUs coming later this year / early next year are starting to get pretty weird. Firmware-mediated job scheduling out of multiple queues, userspace having direct access to the queues and can do inter-queue synchronisation (at least I think so), etc. For bonus points, synchronisation is based on $addr = $val to signal and $addr == $val to wait, with a separate fence primitive as well. Obviously Arm should be part of this conversation here, but I guess we'll have to wait for a while yet to see how everything's shaken out with this new gen, and hope that whatever's been designed upstream in the meantime is actually vaguely compatible ... Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo
On 20/05/2021 18:47, Daniel Vetter wrote: On Thu, May 20, 2021 at 6:31 PM Christian König wrote: Yeah, having the timestamp is a good idea as well. drm-driver: i915 I think we should rather add something like printing file_operations->owner->name to the common fdinfo code. This way we would have something common for all drivers in the system. I'm just not sure if that also works if they are compiled into the kernel. Yeah common code could print driver name, busid and all that stuff. I think the common code should also provide some helpers for the key: value pair formatting (and maybe check for all lower-case and stuff like that) because if we don't then this is going to be a complete mess that's not parseable. I see we could have a few options here, non exhaustive list (especially omitting some sub-options): 1) DRM core implements fdinfo, which emits the common parts, calling into the driver to do the rest. 2) DRM adds helpers for driver to emit common parts of fdinfo. 3) DRM core establishes a "spec" defining the common fields, the optional ones, and formats. I was trending towards 3) because it is most lightweight and feeling is there isn't that much value in extracting a tiny bit of commonality in code. Proof in the pudding is how short the fdinfo vfunc is in this patch. And value should be real semantic stuff, not "here's a string". So accumulated time as a struct ktime as the example. Ideally yes, but I have a feeling the ways how amdgpu and i915 track things are so different so first lets learn more about that. Am 20.05.21 um 18:26 schrieb Nieto, David M: [AMD Official Use Only] i would like to add a unit marker for the stats that we monitor in the fd, as we discussed currently we are displaying the usage percentage, because we wanted to to provide single query percentages, but this may evolve with time. May I suggest to add two new fields drm-stat-interval: <64 bit> ns drm-stat-timestamp: <64 bit> ns If interval is set, engine utilization is calculated by doing = 100*/ if interval is not set, two reads are needed : = 100* / I would like to understand how admgpu tracks GPU time since I am not getting these fields yet. 1) You suggest to have a timestamp because of different clock domains? 2) With the interval option - you actually have a restarting counter? Do you keep that in the driver or get it from hw itself? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/11] drm/panfrost: Fix implicit sync
Am 21.05.21 um 14:22 schrieb Daniel Stone: Hi, On Fri, 21 May 2021 at 10:10, Daniel Vetter wrote: Currently this has no practial relevance I think because there's not many who can pull off a setup with panfrost and another gpu in the same system. But the rules are that if you're setting an exclusive fence, indicating a gpu write access in the implicit fencing system, then you need to wait for all fences, not just the previous exclusive fence. panfrost against itself has no problem, because it always sets the exclusive fence (but that's probably something that will need to be fixed for vulkan and/or multi-engine gpus, or you'll suffer badly). Also no problem with that against display. Yeah, the 'second-generation Valhall' GPUs coming later this year / early next year are starting to get pretty weird. Firmware-mediated job scheduling out of multiple queues, userspace having direct access to the queues and can do inter-queue synchronisation (at least I think so), etc. For bonus points, synchronisation is based on $addr = $val to signal and $addr == $val to wait, with a separate fence primitive as well. Well that sounds familiar :) Obviously Arm should be part of this conversation here, but I guess we'll have to wait for a while yet to see how everything's shaken out with this new gen, and hope that whatever's been designed upstream in the meantime is actually vaguely compatible ... Yeah, going to keep you in CC when we start to code and review user fences. Cheers, Christian. Cheers, Daniel ___ Linaro-mm-sig mailing list linaro-mm-...@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-mm-sig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/7] drm/i915: Expose client engine utilisation via fdinfo
Am 21.05.21 um 14:26 schrieb Tvrtko Ursulin: On 20/05/2021 18:47, Daniel Vetter wrote: On Thu, May 20, 2021 at 6:31 PM Christian König wrote: Yeah, having the timestamp is a good idea as well. drm-driver: i915 I think we should rather add something like printing file_operations->owner->name to the common fdinfo code. This way we would have something common for all drivers in the system. I'm just not sure if that also works if they are compiled into the kernel. Yeah common code could print driver name, busid and all that stuff. I think the common code should also provide some helpers for the key: value pair formatting (and maybe check for all lower-case and stuff like that) because if we don't then this is going to be a complete mess that's not parseable. I see we could have a few options here, non exhaustive list (especially omitting some sub-options): 1) DRM core implements fdinfo, which emits the common parts, calling into the driver to do the rest. 2) DRM adds helpers for driver to emit common parts of fdinfo. 3) DRM core establishes a "spec" defining the common fields, the optional ones, and formats. I was trending towards 3) because it is most lightweight and feeling is there isn't that much value in extracting a tiny bit of commonality in code. Proof in the pudding is how short the fdinfo vfunc is in this patch. I would say that we should add printing the module name to the common fdinfo function for the whole kernel. And for the DRM specific stuff either 2 or 3 is the way to go I think. Number 1 sounds to much like mid-layering to me. Regards, Christian. And value should be real semantic stuff, not "here's a string". So accumulated time as a struct ktime as the example. Ideally yes, but I have a feeling the ways how amdgpu and i915 track things are so different so first lets learn more about that. Am 20.05.21 um 18:26 schrieb Nieto, David M: [AMD Official Use Only] i would like to add a unit marker for the stats that we monitor in the fd, as we discussed currently we are displaying the usage percentage, because we wanted to to provide single query percentages, but this may evolve with time. May I suggest to add two new fields drm-stat-interval: <64 bit> ns drm-stat-timestamp: <64 bit> ns If interval is set, engine utilization is calculated by doing render> = 100*/ if interval is not set, two reads are needed : = 100* / - drm-stat-timestamp0> I would like to understand how admgpu tracks GPU time since I am not getting these fields yet. 1) You suggest to have a timestamp because of different clock domains? 2) With the interval option - you actually have a restarting counter? Do you keep that in the driver or get it from hw itself? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default
Hi Daniel, Le ven., mai 21 2021 at 11:09:54 +0200, Daniel Vetter a écrit : No need to set it explicitly. Signed-off-by: Daniel Vetter Cc: Laurentiu Palcu Cc: Lucas Stach Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: Philipp Zabel Cc: Paul Cercueil Cc: Chun-Kuang Hu Cc: Matthias Brugger Cc: Neil Armstrong Cc: Kevin Hilman Cc: Jerome Brunet Cc: Martin Blumenstingl Cc: Marek Vasut Cc: Stefan Agner Cc: Sandy Huang Cc: "Heiko Stübner" Cc: Yannick Fertre Cc: Philippe Cornu Cc: Benjamin Gaignard Cc: Maxime Coquelin Cc: Alexandre Torgue Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Jernej Skrabec Cc: Jyri Sarha Cc: Tomi Valkeinen Cc: linux-arm-ker...@lists.infradead.org Cc: linux-m...@vger.kernel.org Cc: linux-media...@lists.infradead.org Cc: linux-amlo...@lists.infradead.org Cc: linux-rockc...@lists.infradead.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-su...@lists.linux.dev --- drivers/gpu/drm/imx/dcss/dcss-plane.c | 1 - drivers/gpu/drm/imx/ipuv3-plane.c | 1 - drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 - drivers/gpu/drm/ingenic/ingenic-ipu.c | 1 - For drivers/gpu/drm/ingenic/*: Acked-by: Paul Cercueil Cheers, -Paul drivers/gpu/drm/mediatek/mtk_drm_plane.c| 1 - drivers/gpu/drm/meson/meson_overlay.c | 1 - drivers/gpu/drm/meson/meson_plane.c | 1 - drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 -- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 - drivers/gpu/drm/stm/ltdc.c | 1 - drivers/gpu/drm/sun4i/sun4i_layer.c | 1 - drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 1 - drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 1 - drivers/gpu/drm/tidss/tidss_plane.c | 1 - 14 files changed, 15 deletions(-) diff --git a/drivers/gpu/drm/imx/dcss/dcss-plane.c b/drivers/gpu/drm/imx/dcss/dcss-plane.c index 044d3bdf313c..ac45d54acd4e 100644 --- a/drivers/gpu/drm/imx/dcss/dcss-plane.c +++ b/drivers/gpu/drm/imx/dcss/dcss-plane.c @@ -361,7 +361,6 @@ static void dcss_plane_atomic_disable(struct drm_plane *plane, } static const struct drm_plane_helper_funcs dcss_plane_helper_funcs = { - .prepare_fb = drm_gem_plane_helper_prepare_fb, .atomic_check = dcss_plane_atomic_check, .atomic_update = dcss_plane_atomic_update, .atomic_disable = dcss_plane_atomic_disable, diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c index 8710f55d2579..ef114b6aa691 100644 --- a/drivers/gpu/drm/imx/ipuv3-plane.c +++ b/drivers/gpu/drm/imx/ipuv3-plane.c @@ -772,7 +772,6 @@ static void ipu_plane_atomic_update(struct drm_plane *plane, } static const struct drm_plane_helper_funcs ipu_plane_helper_funcs = { - .prepare_fb = drm_gem_plane_helper_prepare_fb, .atomic_check = ipu_plane_atomic_check, .atomic_disable = ipu_plane_atomic_disable, .atomic_update = ipu_plane_atomic_update, diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c index 389cad59e090..62db7349bf6a 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c @@ -786,7 +786,6 @@ static const struct drm_plane_helper_funcs ingenic_drm_plane_helper_funcs = { .atomic_update = ingenic_drm_plane_atomic_update, .atomic_check = ingenic_drm_plane_atomic_check, .atomic_disable = ingenic_drm_plane_atomic_disable, - .prepare_fb = drm_gem_plane_helper_prepare_fb, }; static const struct drm_crtc_helper_funcs ingenic_drm_crtc_helper_funcs = { diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c b/drivers/gpu/drm/ingenic/ingenic-ipu.c index 3b1091e7c0cd..caf038f3e231 100644 --- a/drivers/gpu/drm/ingenic/ingenic-ipu.c +++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c @@ -615,7 +615,6 @@ static const struct drm_plane_helper_funcs ingenic_ipu_plane_helper_funcs = { .atomic_update = ingenic_ipu_plane_atomic_update, .atomic_check = ingenic_ipu_plane_atomic_check, .atomic_disable = ingenic_ipu_plane_atomic_disable, - .prepare_fb = drm_gem_plane_helper_prepare_fb, }; static int diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c index b5582dcf564c..1667a7e7de38 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c @@ -227,7 +227,6 @@ static void mtk_plane_atomic_update(struct drm_plane *plane, } static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = { - .prepare_fb = drm_gem_plane_helper_prepare_fb, .atomic_check = mtk_plane_atomic_check, .atomic_update = mtk_plane_atomic_update, .atomic_disable = mtk_plane_atomic_disable, diff --git a/drivers/gpu/drm/meson/meson_overlay.c b/drivers/gpu/drm/meson/meson_overlay.c index ed063152aecd..dfef8afcc245 100644 --- a/dr
Re: [Intel-gfx] [PATCH 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default
Am Freitag, 21. Mai 2021, 11:09:54 CEST schrieb Daniel Vetter: > No need to set it explicitly. > > Signed-off-by: Daniel Vetter > Cc: Laurentiu Palcu > Cc: Lucas Stach > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: Philipp Zabel > Cc: Paul Cercueil > Cc: Chun-Kuang Hu > Cc: Matthias Brugger > Cc: Neil Armstrong > Cc: Kevin Hilman > Cc: Jerome Brunet > Cc: Martin Blumenstingl > Cc: Marek Vasut > Cc: Stefan Agner > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Benjamin Gaignard > Cc: Maxime Coquelin > Cc: Alexandre Torgue > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Jernej Skrabec > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-m...@vger.kernel.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-su...@lists.linux.dev > --- > drivers/gpu/drm/imx/dcss/dcss-plane.c | 1 - > drivers/gpu/drm/imx/ipuv3-plane.c | 1 - > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 - > drivers/gpu/drm/ingenic/ingenic-ipu.c | 1 - > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 1 - > drivers/gpu/drm/meson/meson_overlay.c | 1 - > drivers/gpu/drm/meson/meson_plane.c | 1 - > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 -- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 - For Rockchip Acked-by: Heiko Stuebner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/11] drm/panfrost: Fix implicit sync
On Fri, 21 May 2021 at 13:28, Christian König wrote: > Am 21.05.21 um 14:22 schrieb Daniel Stone: > > Yeah, the 'second-generation Valhall' GPUs coming later this year / > > early next year are starting to get pretty weird. Firmware-mediated > > job scheduling out of multiple queues, userspace having direct access > > to the queues and can do inter-queue synchronisation (at least I think > > so), etc. For bonus points, synchronisation is based on $addr = $val > > to signal and $addr == $val to wait, with a separate fence primitive > > as well. > > Well that sounds familiar :) I laughed when I first saw it, because it was better than crying I guess. If you're curious, the interface definitions are in the csf/ directory in the 'Bifrost kernel driver' r30p0 download you can get from the Arm developer site. Unfortunately the exact semantics aren't completely clear. > > Obviously Arm should be part of this conversation here, but I guess > > we'll have to wait for a while yet to see how everything's shaken out > > with this new gen, and hope that whatever's been designed upstream in > > the meantime is actually vaguely compatible ... > > Yeah, going to keep you in CC when we start to code and review user fences. Awesome, thanks Christian. Appreciate it. :) Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/11] drm/panfrost: Fix implicit sync
Am 21.05.21 um 14:54 schrieb Daniel Stone: On Fri, 21 May 2021 at 13:28, Christian König wrote: Am 21.05.21 um 14:22 schrieb Daniel Stone: Yeah, the 'second-generation Valhall' GPUs coming later this year / early next year are starting to get pretty weird. Firmware-mediated job scheduling out of multiple queues, userspace having direct access to the queues and can do inter-queue synchronisation (at least I think so), etc. For bonus points, synchronisation is based on $addr = $val to signal and $addr == $val to wait, with a separate fence primitive as well. Well that sounds familiar :) I laughed when I first saw it, because it was better than crying I guess. In Germany we say "Ich freue mich drauf wie auf Zahnschmerzen". If you're curious, the interface definitions are in the csf/ directory in the 'Bifrost kernel driver' r30p0 download you can get from the Arm developer site. Unfortunately the exact semantics aren't completely clear. Well it is actually relatively simple. Take a look at the timeline semaphores from Vulkan, everybody is basically implementing the same semantics now. When you queued up a bunch of commands on your hardware, the first one will write value 1 to a 64bit memory location, the second one will write value 2, the third value 3 and so on. After writing the value the hardware raises and interrupt signal to everybody interested. In other words pretty standard memory fence behavior. When you now have a second queue which depends on work of the first one you look at the memory location and do a compare. If you depend on the third submission you just wait for the value to be >3 and are done. Regards, Christian. Obviously Arm should be part of this conversation here, but I guess we'll have to wait for a while yet to see how everything's shaken out with this new gen, and hope that whatever's been designed upstream in the meantime is actually vaguely compatible ... Yeah, going to keep you in CC when we start to code and review user fences. Awesome, thanks Christian. Appreciate it. :) Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/11] drm/panfrost: Fix implicit sync
On Fri, 21 May 2021 at 14:09, Christian König wrote: > Am 21.05.21 um 14:54 schrieb Daniel Stone: > > If you're curious, the interface definitions are in the csf/ directory > > in the 'Bifrost kernel driver' r30p0 download you can get from the Arm > > developer site. Unfortunately the exact semantics aren't completely > > clear. > > Well it is actually relatively simple. Take a look at the timeline > semaphores from Vulkan, everybody is basically implementing the same > semantics now. > > When you queued up a bunch of commands on your hardware, the first one > will write value 1 to a 64bit memory location, the second one will write > value 2, the third value 3 and so on. After writing the value the > hardware raises and interrupt signal to everybody interested. > > In other words pretty standard memory fence behavior. > > When you now have a second queue which depends on work of the first one > you look at the memory location and do a compare. If you depend on the > third submission you just wait for the value to be >3 and are done. Right, it is clearly defined to the timeline semaphore semantics, I just meant that it's not clear how it works at a lower level wrt the synchronisation and signaling. The simplest possible interpretation is that wait_addrval blocks infinitely before kick-cmdbuf, but that seems painful with only 32 queues. And the same for fences, which are a binary signal. I guess we'll find out. My tooth hurts. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Implement PSF GV point support
PSF GV points are an additional factor that can limit the bandwidth available to display, separate from the traditional QGV points. Whereas traditional QGV points represent possible memory clock frequencies, PSF GV points reflect possible frequencies of the memory fabric. Switching between PSF GV points has the advantage of incurring almost no memory access block time and thus does not need to be accounted for in watermark calculations. This patch adds support for those on top of regular QGV points. Those are supposed to be used simultaneously, i.e we are always at some QGV and some PSF GV point, based on the current video mode requirements. Bspec: 64631, 53998 v2: Seems that initial assumption made during ml conversation was wrong, PCode rejects any masks containing points beyond the ones returned, so even though BSpec says we have around 8 points theoretically, we can mask/unmask only those which are returned, trying to manipulate those beyond causes a failure from PCode. So switched back to generating mask from 1 - num_qgv_points, where num_qgv_points is the actual amount of points, advertised by PCode. Signed-off-by: Stanislav Lisovskiy Cc: Matt Roper --- drivers/gpu/drm/i915/display/intel_bw.c | 113 +++- drivers/gpu/drm/i915/i915_drv.h | 7 ++ drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_dram.c | 1 + 4 files changed, 121 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c index 3a1ba52266a7..fd23a4818c19 100644 --- a/drivers/gpu/drm/i915/display/intel_bw.c +++ b/drivers/gpu/drm/i915/display/intel_bw.c @@ -17,9 +17,15 @@ struct intel_qgv_point { u16 dclk, t_rp, t_rdpre, t_rc, t_ras, t_rcd; }; +struct intel_psf_gv_point { + u8 clk; /* clock in multiples of 16. MHz */ +}; + struct intel_qgv_info { struct intel_qgv_point points[I915_NUM_QGV_POINTS]; + struct intel_psf_gv_point psf_points[I915_NUM_PSF_GV_POINTS]; u8 num_points; + u8 num_psf_points; u8 t_bl; }; @@ -49,6 +55,28 @@ static int icl_pcode_read_qgv_point_info(struct drm_i915_private *dev_priv, return 0; } +static int adls_pcode_read_psf_gv_point_info(struct drm_i915_private *dev_priv, + struct intel_psf_gv_point *points) +{ + u32 val = 0, val2 = 0; + int ret; + int i; + + ret = sandybridge_pcode_read(dev_priv, +ICL_PCODE_MEM_SUBSYSYSTEM_INFO | +ADL_PCODE_MEM_SS_READ_PSF_GV_INFO, +&val, &val2); + if (ret) + return ret; + + for (i = 0; i < I915_NUM_PSF_GV_POINTS; i++) { + points[i].clk = val & 0xff; + val >>= 8; + } + + return 0; +} + int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv, u32 points_mask) { @@ -62,7 +90,7 @@ int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv, 1); if (ret < 0) { - drm_err(&dev_priv->drm, "Failed to disable qgv points (%d)\n", ret); + drm_err(&dev_priv->drm, "Failed to disable qgv points (%d) points: %x\n", ret, points_mask); return ret; } @@ -76,6 +104,7 @@ static int icl_get_qgv_points(struct drm_i915_private *dev_priv, int i, ret; qi->num_points = dram_info->num_qgv_points; + qi->num_psf_points = dram_info->num_psf_gv_points; if (DISPLAY_VER(dev_priv) == 12) switch (dram_info->type) { @@ -109,6 +138,19 @@ static int icl_get_qgv_points(struct drm_i915_private *dev_priv, sp->t_rcd, sp->t_rc); } + if (qi->num_psf_points > 0) { + ret = adls_pcode_read_psf_gv_point_info(dev_priv, qi->psf_points); + if (ret) { + drm_err(&dev_priv->drm, "Failed to read PSF point data; PSF points will not be considered in bandwidth calculations.\n"); + qi->num_psf_points = 0; + } + + for (i = 0; i < qi->num_psf_points; i++) + drm_dbg_kms(&dev_priv->drm, + "PSF GV %d: CLK=%d \n", + i, qi->psf_points[i].clk); + } + return 0; } @@ -118,6 +160,16 @@ static int icl_calc_bw(int dclk, int num, int den) return DIV_ROUND_CLOSEST(num * dclk * 100, den * 6); } +static int adl_calc_psf_bw(int clk) +{ + /* +* clk is multiples of 16.666MHz (100/6) +* According to BSpec PSF GV bandwidth is +* calculated as BW = 64 * clk * 16.666Mhz +*/ + return DIV_ROUND_CLOSEST(64 * clk * 100, 6); +} + static int icl_sagv_max_dclk(const struct intel_qgv_info *qi) {
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Implement PSF GV point support (rev2)
== Series Details == Series: drm/i915: Implement PSF GV point support (rev2) URL : https://patchwork.freedesktop.org/series/90361/ State : warning == Summary == $ dim checkpatch origin/drm-tip dbf9d296fc57 drm/i915: Implement PSF GV point support -:59: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #59: FILE: drivers/gpu/drm/i915/display/intel_bw.c:59: +static int adls_pcode_read_psf_gv_point_info(struct drm_i915_private *dev_priv, + struct intel_psf_gv_point *points) -:88: WARNING:LONG_LINE: line length of 108 exceeds 100 columns #88: FILE: drivers/gpu/drm/i915/display/intel_bw.c:93: + drm_err(&dev_priv->drm, "Failed to disable qgv points (%d) points: %x\n", ret, points_mask); -:113: WARNING:QUOTED_WHITESPACE_BEFORE_NEWLINE: unnecessary whitespace before a quoted newline #113: FILE: drivers/gpu/drm/i915/display/intel_bw.c:150: + "PSF GV %d: CLK=%d \n", total: 0 errors, 2 warnings, 1 checks, 247 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
On 5/21/21 4:09 AM, Daniel Vetter wrote: Goes through all the drivers and deletes the default hook since it's the default now. Acked-by: David Lechner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement PSF GV point support (rev2)
== Series Details == Series: drm/i915: Implement PSF GV point support (rev2) URL : https://patchwork.freedesktop.org/series/90361/ State : success == Summary == CI Bug Log - changes from CI_DRM_10119 -> Patchwork_20169 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/index.html Known issues Here are the changes found in Patchwork_20169 that come from known issues: ### IGT changes ### Issues hit * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][1] ([i915#2283]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@i915_selftest@live@execlists: - fi-bdw-5557u: NOTRUN -> [DMESG-FAIL][2] ([i915#3462]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_psr@cursor_plane_move: - fi-bdw-5557u: NOTRUN -> [SKIP][4] ([fdo#109271]) +9 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html Warnings * igt@i915_selftest@live@execlists: - fi-cfl-8109u: [INCOMPLETE][5] ([i915#3462]) -> [DMESG-FAIL][6] ([i915#3462]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html - fi-bsw-nick:[DMESG-FAIL][7] ([i915#3462]) -> [INCOMPLETE][8] ([i915#2782] / [i915#2940] / [i915#3462]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bsw-nick/igt@i915_selftest@l...@execlists.html - fi-icl-u2: [DMESG-FAIL][9] ([i915#3462]) -> [INCOMPLETE][10] ([i915#2782] / [i915#3462]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-icl-u2/igt@i915_selftest@l...@execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-icl-u2/igt@i915_selftest@l...@execlists.html - fi-bsw-kefka: [DMESG-FAIL][11] ([i915#3462]) -> [INCOMPLETE][12] ([i915#2782] / [i915#2940] / [i915#3462]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-cfl-8109u: [FAIL][13] ([i915#3363]) -> [FAIL][14] ([i915#2426] / [i915#3363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-cfl-8109u/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-cfl-8109u/igt@run...@aborted.html - fi-icl-u2: [FAIL][15] ([i915#2426] / [i915#2782] / [i915#3363]) -> [FAIL][16] ([i915#2782] / [i915#3363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-icl-u2/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-icl-u2/igt@run...@aborted.html - fi-glk-dsi: [FAIL][17] ([i915#3363] / [k.org#202321]) -> [FAIL][18] ([i915#2426] / [i915#3363] / [k.org#202321]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-glk-dsi/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-glk-dsi/igt@run...@aborted.html - fi-bdw-5557u: [FAIL][19] ([i915#1602] / [i915#2029]) -> [FAIL][20] ([i915#3462]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-bdw-5557u/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-bdw-5557u/igt@run...@aborted.html - fi-kbl-7567u: [FAIL][21] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][22] ([i915#1436] / [i915#3363]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-kbl-7567u/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-kbl-7567u/igt@run...@aborted.html - fi-skl-6700k2: [FAIL][23] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][24] ([i915#1436] / [i915#3363]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10119/fi-skl-6700k2/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20169/fi-skl-6700k2/igt@run...@aborted.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:
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/kms_big_fb: Wait for vblank before collecting CRC
Hello Juha-Pekka We are seeing the CRC failures on Jasperlake systems. Sometimes the test passes and sometimes it fails throwing CRC error. Regards Vidya -Original Message- From: Juha-Pekka Heikkila Sent: Friday, May 21, 2021 5:00 PM To: Srinivas, Vidya ; intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; igt-...@lists.freedesktop.org Cc: Lin, Charlton Subject: Re: [igt-dev] [PATCH i-g-t] tests/kms_big_fb: Wait for vblank before collecting CRC Hi Vidya, on which machines this would help? I see there's many vblanks already being waited. There's igt_display_commit2 which probably will block and even if it didn't there's igt_pipe_crc_collect_crc(..) where crc calculation is started after flip and then get one crc before disabling crc counting again. /Juha-Pekka On 21.5.2021 7.08, Vidya Srinivas wrote: > Without wait for vblank, CRC mismatch is seen between big and small > CRC on few systems > > Change-Id: I3bec931aa901130997e693ac1cacf389e2a8100f > Signed-off-by: Vidya Srinivas > --- > tests/kms_big_fb.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c index > b2027b6b9d1b..7d78ff829d41 100644 > --- a/tests/kms_big_fb.c > +++ b/tests/kms_big_fb.c > @@ -254,6 +254,7 @@ static void unset_lut(data_t *data) > static bool test_plane(data_t *data) > { > igt_plane_t *plane = data->plane; > + igt_display_t *display = &data->display; > struct igt_fb *small_fb = &data->small_fb; > struct igt_fb *big_fb = &data->big_fb; > int w = data->big_fb_width - small_fb->width; @@ -337,16 +338,17 @@ > static bool test_plane(data_t *data) > igt_display_commit2(&data->display, data->display.is_atomic ? > COMMIT_ATOMIC : COMMIT_UNIVERSAL); > > - > + igt_wait_for_vblank(data->drm_fd, > +display->pipes[data->pipe].crtc_offset); > igt_pipe_crc_collect_crc(data->pipe_crc, &small_crc); > > igt_plane_set_fb(plane, big_fb); > igt_fb_set_position(big_fb, plane, x, y); > igt_fb_set_size(big_fb, plane, small_fb->width, > small_fb->height); > + > igt_plane_set_size(plane, data->width, data->height); > igt_display_commit2(&data->display, data->display.is_atomic ? > COMMIT_ATOMIC : COMMIT_UNIVERSAL); > - > + igt_wait_for_vblank(data->drm_fd, > +display->pipes[data->pipe].crtc_offset); > igt_pipe_crc_collect_crc(data->pipe_crc, &big_crc); > > igt_plane_set_fb(plane, NULL); > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4
On Thu, May 13, 2021 at 11:23:41PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4 > URL : https://patchwork.freedesktop.org/series/90102/ > State : failure Pushed to drm-intel-next, thanks for the report, testing and review. The failures are unrelated see below. > == Summary == > > CI Bug Log - changes from CI_DRM_10074_full -> Patchwork_20115_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20115_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20115_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_20115_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_draw_crc@draw-method-xrgb-blt-untiled: > - shard-skl: NOTRUN -> [FAIL][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-skl8/igt@kms_draw_...@draw-method-xrgb-blt-untiled.html > > * igt@kms_flip_tiling@flip-changes-tiling@hdmi-a-1-pipe-c: > - shard-glk: [PASS][2] -> [FAIL][3] +1 similar issue >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-glk8/igt@kms_flip_tiling@flip-changes-til...@hdmi-a-1-pipe-c.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-glk6/igt@kms_flip_tiling@flip-changes-til...@hdmi-a-1-pipe-c.html > > * igt@kms_plane_cursor@pipe-b-primary-size-256: > - shard-snb: NOTRUN -> [FAIL][4] >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-snb5/igt@kms_plane_cur...@pipe-b-primary-size-256.html On all the above platforms the LTTPR detection is disabled, so the change is unrelevant on them. All the logs have the x86/PAT: gem_mmap_offset:1163 map pfn RAM range req write-combining for [mem 0x11d278000-0x11d278fff], got write-back message, so the failures could be related to that. > Suppressed > > The following results come from untrusted machines, tests, or statuses. > They do not affect the overall result. > > * {igt@kms_plane@plane-position-hole@pipe-a-planes}: > - shard-glk: [FAIL][5] ([i915#3457]) -> [FAIL][6] >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-glk9/igt@kms_plane@plane-position-h...@pipe-a-planes.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-glk8/igt@kms_plane@plane-position-h...@pipe-a-planes.html > > > > ### Piglit changes ### > > Possible regressions > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t > (NEW): > - {pig-icl-1065g7}: NOTRUN -> [CRASH][7] >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/pig-icl-1065g7/spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t.html > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if > (NEW): > - {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][8] +7 similar issues >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/pig-icl-1065g7/spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if.html > > > New tests > - > > New tests have been introduced between CI_DRM_10074_full and > Patchwork_20115_full: > > ### New Piglit tests (9) ### > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@cs-min-i64vec2-i64vec2: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@cs-op-mult-i64vec3-i64vec3: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t: > - Statuses : 1 crash(s) > - Exec time: [0.76] s > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@gs-max-i64vec3-i64vec3: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@gs-op-mult-i64vec4-i64vec4: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-mod-u64vec2-uint64_t: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@vs-op-add-uint64_t-u64vec2: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s >
Re: [Intel-gfx] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote: > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote: > > > > Docs for struct dma_resv are fairly clear: > > > > "A reservation object can have attached one exclusive fence (normally > > associated with write operations) or N shared fences (read > > operations)." > > > > https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html#reservation-objects > > > > Furthermore a review across all of upstream. > > > > First of render drivers and how they set implicit fences: > > > > - nouveau follows this contract, see in validate_fini_no_ticket() > > > > nouveau_bo_fence(nvbo, fence, !!b->write_domains); > > > > and that last boolean controls whether the exclusive or shared fence > > slot is used. > > > > - radeon follows this contract by setting > > > > p->relocs[i].tv.num_shared = !r->write_domain; > > > > in radeon_cs_parser_relocs(), which ensures that the call to > > ttm_eu_fence_buffer_objects() in radeon_cs_parser_fini() will do the > > right thing. > > > > - vmwgfx seems to follow this contract with the shotgun approach of > > always setting ttm_val_buf->num_shared = 0, which means > > ttm_eu_fence_buffer_objects() will only use the exclusive slot. > > > > - etnaviv follows this contract, as can be trivially seen by looking > > at submit_attach_object_fences() > > > > - i915 is a bit a convoluted maze with multiple paths leading to > > i915_vma_move_to_active(). Which sets the exclusive flag if > > EXEC_OBJECT_WRITE is set. This can either come as a buffer flag for > > softpin mode, or through the write_domain when using relocations. It > > follows this contract. > > > > - lima follows this contract, see lima_gem_submit() which sets the > > exclusive fence when the LIMA_SUBMIT_BO_WRITE flag is set for that > > bo > > > > - msm follows this contract, see msm_gpu_submit() which sets the > > exclusive flag when the MSM_SUBMIT_BO_WRITE is set for that buffer > > > > - panfrost follows this contract with the shotgun approach of just > > always setting the exclusive fence, see > > panfrost_attach_object_fences(). Benefits of a single engine I guess > > > > - v3d follows this contract with the same shotgun approach in > > v3d_attach_fences_and_unlock_reservation(), but it has at least an > > XXX comment that maybe this should be improved > > > > - v4c uses the same shotgun approach of always setting an exclusive > > fence, see vc4_update_bo_seqnos() > > > > - vgem also follows this contract, see vgem_fence_attach_ioctl() and > > the VGEM_FENCE_WRITE. This is used in some igts to validate prime > > sharing with i915.ko without the need of a 2nd gpu > > > > - vritio follows this contract again with the shotgun approach of > > always setting an exclusive fence, see virtio_gpu_array_add_fence() > > > > This covers the setting of the exclusive fences when writing. > > > > Synchronizing against the exclusive fence is a lot more tricky, and I > > only spot checked a few: > > > > - i915 does it, with the optional EXEC_OBJECT_ASYNC to skip all > > implicit dependencies (which is used by vulkan) > > > > - etnaviv does this. Implicit dependencies are collected in > > submit_fence_sync(), again with an opt-out flag > > ETNA_SUBMIT_NO_IMPLICIT. These are then picked up in > > etnaviv_sched_dependency which is the > > drm_sched_backend_ops->dependency callback. > > > > - v4c seems to not do much here, maybe gets away with it by not having > > a scheduler and only a single engine. Since all newer broadcom chips than > > the OG vc4 use v3d for rendering, which follows this contract, the > > impact of this issue is fairly small. > > > > - v3d does this using the drm_gem_fence_array_add_implicit() helper, > > which then it's drm_sched_backend_ops->dependency callback > > v3d_job_dependency() picks up. > > > > - panfrost is nice here and tracks the implicit fences in > > panfrost_job->implicit_fences, which again the > > drm_sched_backend_ops->dependency callback panfrost_job_dependency() > > picks up. It is mildly questionable though since it only picks up > > exclusive fences in panfrost_acquire_object_fences(), but not buggy > > in practice because it also always sets the exclusive fence. It > > should pick up both sets of fences, just in case there's ever going > > to be a 2nd gpu in a SoC with a mali gpu. Or maybe a mali SoC with a > > pcie port and a real gpu, which might actually happen eventually. A > > bug, but easy to fix. Should probably use the > > drm_gem_fence_array_add_implicit() helper. > > > > - lima is nice an easy, uses drm_gem_fence_array_add_implicit() and > > the same schema as v3d. > > > > - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT, > > but because it doesn't use the drm/scheduler it handles fences from > > the wrong context with a synchronous dma_fence_wait. See > > submit_fence_s
Re: [Intel-gfx] [PATCH 02/11] drm/panfrost: Remove sched_lock
On Fri, May 21, 2021 at 11:32:48AM +0200, Lucas Stach wrote: > Am Freitag, dem 21.05.2021 um 11:09 +0200 schrieb Daniel Vetter: > > Scheduler takes care of its own locking, dont worry. For everything else > > there's reservation locking on each bo. > > > > So seems to be entirely redundnant and just a bit in the way. > > I haven't read all the surrounding code, but this looks wrong from a > glance. You must hold a lock across drm_sched_job_init -> > drm_sched_entity_push_job as the scheduler fences are initialized in > the job init, so if there's no exclusive section across those two > function calls you might end up with jobs being queued with their fence > seqnos not monotonically increasing, which breaks all kinds of other > stuff. Uh indeed. That's a bit a loaded gun since generally _init() shouldn't have any such side effects. > I don't see a reason to hold the lock across the reservation calls, > though. Ok I'll adjust the patch. -Daniel > > Regards, > Lucas > > > > > Signed-off-by: Daniel Vetter > > Cc: Rob Herring > > Cc: Tomeu Vizoso > > Cc: Steven Price > > Cc: Alyssa Rosenzweig > > --- > > drivers/gpu/drm/panfrost/panfrost_device.c | 1 - > > drivers/gpu/drm/panfrost/panfrost_device.h | 2 -- > > drivers/gpu/drm/panfrost/panfrost_job.c| 13 ++--- > > 3 files changed, 2 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c > > b/drivers/gpu/drm/panfrost/panfrost_device.c > > index 125ed973feaa..23070c01c63f 100644 > > --- a/drivers/gpu/drm/panfrost/panfrost_device.c > > +++ b/drivers/gpu/drm/panfrost/panfrost_device.c > > @@ -199,7 +199,6 @@ int panfrost_device_init(struct panfrost_device *pfdev) > > int err; > > struct resource *res; > > > > - mutex_init(&pfdev->sched_lock); > > INIT_LIST_HEAD(&pfdev->scheduled_jobs); > > INIT_LIST_HEAD(&pfdev->as_lru_list); > > > > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h > > b/drivers/gpu/drm/panfrost/panfrost_device.h > > index 597cf1459b0a..7519903bb031 100644 > > --- a/drivers/gpu/drm/panfrost/panfrost_device.h > > +++ b/drivers/gpu/drm/panfrost/panfrost_device.h > > @@ -105,8 +105,6 @@ struct panfrost_device { > > > > struct panfrost_perfcnt *perfcnt; > > > > - struct mutex sched_lock; > > - > > struct { > > struct work_struct work; > > atomic_t pending; > > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c > > b/drivers/gpu/drm/panfrost/panfrost_job.c > > index 6003cfeb1322..f5d39ee14ab5 100644 > > --- a/drivers/gpu/drm/panfrost/panfrost_job.c > > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c > > @@ -218,26 +218,19 @@ static void panfrost_attach_object_fences(struct > > drm_gem_object **bos, > > > > int panfrost_job_push(struct panfrost_job *job) > > { > > - struct panfrost_device *pfdev = job->pfdev; > > int slot = panfrost_job_get_slot(job); > > struct drm_sched_entity *entity = &job->file_priv->sched_entity[slot]; > > struct ww_acquire_ctx acquire_ctx; > > int ret = 0; > > > > - mutex_lock(&pfdev->sched_lock); > > - > > ret = drm_gem_lock_reservations(job->bos, job->bo_count, > > &acquire_ctx); > > - if (ret) { > > - mutex_unlock(&pfdev->sched_lock); > > + if (ret) > > return ret; > > - } > > > > ret = drm_sched_job_init(&job->base, entity, NULL); > > - if (ret) { > > - mutex_unlock(&pfdev->sched_lock); > > + if (ret) > > goto unlock; > > - } > > > > job->render_done_fence = dma_fence_get(&job->base.s_fence->finished); > > > > @@ -248,8 +241,6 @@ int panfrost_job_push(struct panfrost_job *job) > > > > drm_sched_entity_push_job(&job->base, entity); > > > > - mutex_unlock(&pfdev->sched_lock); > > - > > panfrost_attach_object_fences(job->bos, job->bo_count, > > job->render_done_fence); > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use DRIVER_NAME for tracing unattached requests
== Series Details == Series: drm/i915: Use DRIVER_NAME for tracing unattached requests URL : https://patchwork.freedesktop.org/series/90351/ State : success == Summary == CI Bug Log - changes from CI_DRM_10110_full -> Patchwork_20157_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20157_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([i915#198]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/shard-skl2/igt@gem_ctx_isolation@preservation...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-skl1/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_param@set-priority-not-supported: - shard-tglb: NOTRUN -> [SKIP][3] ([fdo#109314]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-tglb7/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][5] ([i915#3354]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][6] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-kbl1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-glk3/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/shard-kbl4/igt@gem_exec_fair@basic-none-...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-kbl3/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglb: NOTRUN -> [FAIL][13] ([i915#2842]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-tglb7/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-tglb: NOTRUN -> [SKIP][14] ([fdo#109313]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-tglb7/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][15] ([i915#2389]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-apl7/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][16] ([i915#2389]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_mmap_gtt@big-copy-xy: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#307]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10110/shard-skl7/igt@gem_mmap_...@big-copy-xy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-skl7/igt@gem_mmap_...@big-copy-xy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-apl: NOTRUN -> [INCOMPLETE][19] ([i915#3468]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-apl7/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd: - shard-glk: NOTRUN -> [INCOMPLETE][20] ([i915#2055] / [i915#3468]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-glk6/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-snb: NOTRUN -> [INCOMPLETE][21] ([i915#2055] / [i915#3468]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20157/shard-snb2/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html - shard-kbl: NOTRUN -> [INCOMPLETE][22] ([i9
Re: [Intel-gfx] [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 2:10 AM Daniel Vetter wrote: > > - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT, > but because it doesn't use the drm/scheduler it handles fences from > the wrong context with a synchronous dma_fence_wait. See > submit_fence_sync() leading to msm_gem_sync_object(). Investing into > a scheduler might be a good idea. Yeah, drm/scheduler is (along with a lot of other things) on the TODO list. But this isn't quite as bad as it sounds because userspace uses a u_queue thread to call the submit ioctl rather than blocking the driver. (It also offloads some other work from the driver thread, like submit merging to reduce # of ioctls. Coincidentally that arrangement was a step towards preparing userspace for some hypothetical non-ioctl uapi ;-)) OTOH it would be good to move blocking until the system can free enough pages to repin bo's out of the ioctl path to better handle some memory pressure corner cases without having to be interruptable over a lot more of the submit path.. Running chrome+android on devices without a lot of memory is fun.. BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 07:58:57AM -0700, Rob Clark wrote: > On Fri, May 21, 2021 at 2:10 AM Daniel Vetter wrote: > > > > - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT, > > but because it doesn't use the drm/scheduler it handles fences from > > the wrong context with a synchronous dma_fence_wait. See > > submit_fence_sync() leading to msm_gem_sync_object(). Investing into > > a scheduler might be a good idea. > > Yeah, drm/scheduler is (along with a lot of other things) on the TODO > list. But this isn't quite as bad as it sounds because userspace uses > a u_queue thread to call the submit ioctl rather than blocking the > driver. (It also offloads some other work from the driver thread, > like submit merging to reduce # of ioctls. Coincidentally that > arrangement was a step towards preparing userspace for some > hypothetical non-ioctl uapi ;-)) You're also holding a pile of locks, which I expect latest with multi-engine buffer sharing will be pain. If you push this to the scheduler then the locks aren't held. Or maybe I've misread the flow, it's become all a bit a blurr after all these drivers :-) > OTOH it would be good to move blocking until the system can free > enough pages to repin bo's out of the ioctl path to better handle some > memory pressure corner cases without having to be interruptable over a > lot more of the submit path.. Running chrome+android on devices > without a lot of memory is fun.. Uh that one needs the userspace thread. Or entirely different semantics of your ioctl, because you're not allowed to allocate memory once any dma_fence is visible. So offloading the entire pinning to a submit thread is no-go. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote: > > On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote: > > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter > > wrote: > > > --- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > > index 88a24a0b5691..cc8426e1e8a8 100644 > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > > @@ -617,8 +617,8 @@ static int amdgpu_cs_parser_bos(struct > > > amdgpu_cs_parser *p, > > > amdgpu_bo_list_for_each_entry(e, p->bo_list) { > > > struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo); > > > > > > - /* Make sure we use the exclusive slot for shared BOs */ > > > - if (bo->prime_shared_count) > > > + /* Make sure we use the exclusive slot for all > > > potentially shared BOs */ > > > + if (!(bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)) > > > e->tv.num_shared = 0; > > > > I think it also makes sense to skip this with > > AMDGPU_GEM_CREATE_EXPLICIT_SYNC? It can be shared but I don't think > > anyone expects implicit sync to happen with those. > > Ah yes, I missed this entirely. So the "no implicit flag" is already > there, and the _only_ thing that's missing really is a way to fish out the > implicit fences, and set them. > > https://lore.kernel.org/dri-devel/20210520190007.534046-1-ja...@jlekstrand.net/ > > So I think all that's really needed in radv is not setting > RADEON_FLAG_IMPLICIT_SYNC for winsys buffers when Jason's dma-buf ioctl > are present (means you need to do some import/export and keep the fd > around for winsys buffers, but shouldn't be too bad), and then control the > implicit fences entirely explicitly like vk expects. That is the part I'm less sure about. This is a BO wide flag so we are also disabling implicit sync in the compositor. If the compositor does only do read stuff that is ok, as the inserted exclusive fence will work for that. But as I learned recently the app provided buffer may end up being written to by the X server which open a whole can of potential problems if implicit sync gets disabled between Xserver operations on the app provided buffer. Hence setting that on the WSI buffer is a whole new can of potential problems and hence I've said a submission based flag would be preferred. I can certainly try it out though. > > Are you bored enough to type this up for radv? I'll give Jason's kernel > stuff another review meanwhile. > -Daniel > > > > e->bo_va = amdgpu_vm_bo_find(vm, bo); > > > } > > > -- > > > 2.31.0 > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote: > On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote: > > > > On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote: > > > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter > > > wrote: > > > > --- > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > > > index 88a24a0b5691..cc8426e1e8a8 100644 > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > > > @@ -617,8 +617,8 @@ static int amdgpu_cs_parser_bos(struct > > > > amdgpu_cs_parser *p, > > > > amdgpu_bo_list_for_each_entry(e, p->bo_list) { > > > > struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo); > > > > > > > > - /* Make sure we use the exclusive slot for shared BOs */ > > > > - if (bo->prime_shared_count) > > > > + /* Make sure we use the exclusive slot for all > > > > potentially shared BOs */ > > > > + if (!(bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)) > > > > e->tv.num_shared = 0; > > > > > > I think it also makes sense to skip this with > > > AMDGPU_GEM_CREATE_EXPLICIT_SYNC? It can be shared but I don't think > > > anyone expects implicit sync to happen with those. > > > > Ah yes, I missed this entirely. So the "no implicit flag" is already > > there, and the _only_ thing that's missing really is a way to fish out the > > implicit fences, and set them. > > > > https://lore.kernel.org/dri-devel/20210520190007.534046-1-ja...@jlekstrand.net/ > > > > So I think all that's really needed in radv is not setting > > RADEON_FLAG_IMPLICIT_SYNC for winsys buffers when Jason's dma-buf ioctl > > are present (means you need to do some import/export and keep the fd > > around for winsys buffers, but shouldn't be too bad), and then control the > > implicit fences entirely explicitly like vk expects. > > That is the part I'm less sure about. This is a BO wide flag so we are > also disabling implicit sync in the compositor. If the compositor does > only do read stuff that is ok, as the inserted exclusive fence will > work for that. But as I learned recently the app provided buffer may > end up being written to by the X server which open a whole can of > potential problems if implicit sync gets disabled between Xserver > operations on the app provided buffer. Hence setting that on the WSI > buffer is a whole new can of potential problems and hence I've said a > submission based flag would be preferred. > > I can certainly try it out though. Hm yeah that's the wrong flag. We need a flag on the drm_file which the explicit userspace sets. And which is valid only for itself. There's a nice flags field when creating a ctx, but it's not validated and there's already a comment that we have to filter out garbage priority, so that's not use. I'll whip up something entirely untested just as a draft. -Daniel > > > > > Are you bored enough to type this up for radv? I'll give Jason's kernel > > stuff another review meanwhile. > > -Daniel > > > > > > e->bo_va = amdgpu_vm_bo_find(vm, bo); > > > > } > > > > -- > > > > 2.31.0 > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/display: Nuke has_infoframe
On Fri, 2021-05-14 at 16:22 -0700, José Roberto de Souza wrote: > This was only reduntant information has_hdmi_sink can do the same job. > set_infoframes() hooks will call intel_write_infoframe() for the > supported infoframes types and it will only be enabled if given type > is set in crtc_state->infoframes.enable. > > While at it also fixing the style of dig_port->set_infoframes() calls. > > Cc: Ville Syrjälä > Signed-off-by: José Roberto de Souza > --- > drivers/gpu/drm/i915/display/g4x_hdmi.c | 22 ++- > drivers/gpu/drm/i915/display/intel_ddi.c | 17 +- > drivers/gpu/drm/i915/display/intel_display.c | 6 ++--- > .../drm/i915/display/intel_display_types.h | 3 --- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-- > drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +-- > 6 files changed, 22 insertions(+), 43 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c > b/drivers/gpu/drm/i915/display/g4x_hdmi.c > index be352e9f0afc..f35db96e6239 100644 > --- a/drivers/gpu/drm/i915/display/g4x_hdmi.c > +++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c > @@ -105,9 +105,6 @@ static void intel_hdmi_get_config(struct > intel_encoder *encoder, > pipe_config->infoframes.enable |= > intel_hdmi_infoframes_enabled(encoder, pipe_config); > > - if (pipe_config->infoframes.enable) > - pipe_config->has_infoframe = true; > - "pipe_config->infoframes.enable" is set with information about the infoframes currently active in the hardware through "pipe_config- >infoframes.enable |= intel_hdmi_infoframes_enabled(encoder, pipe_config);". Therefore, when calling set_infoframes() semantically, the has_infoframe information set by "if (pipe_config->infoframes.enable) pipe_config->has_infoframe = true;" is more clear. > if (tmp & HDMI_AUDIO_ENABLE) > pipe_config->has_audio = true; > > @@ -343,9 +340,7 @@ static void intel_disable_hdmi(struct > intel_atomic_state *state, > intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, > true); > } > > - dig_port->set_infoframes(encoder, > - false, > - old_crtc_state, old_conn_state); > + dig_port->set_infoframes(encoder, false, old_crtc_state, > old_conn_state); > > intel_dp_dual_mode_set_tmds_output(intel_hdmi, false); > } > @@ -390,9 +385,8 @@ static void intel_hdmi_pre_enable(struct > intel_atomic_state *state, > > intel_hdmi_prepare(encoder, pipe_config); > > - dig_port->set_infoframes(encoder, > - pipe_config->has_infoframe, > - pipe_config, conn_state); > + dig_port->set_infoframes(encoder, pipe_config->has_hdmi_sink, > + pipe_config, conn_state); > } > > static void vlv_hdmi_pre_enable(struct intel_atomic_state *state, > @@ -410,9 +404,8 @@ static void vlv_hdmi_pre_enable(struct > intel_atomic_state *state, > 0x2b245f5f, 0x2000, > 0x5578b83a, 0x2b247878); > > - dig_port->set_infoframes(encoder, > - pipe_config->has_infoframe, > - pipe_config, conn_state); > + dig_port->set_infoframes(encoder, pipe_config->has_hdmi_sink, > + pipe_config, conn_state); > > g4x_enable_hdmi(state, encoder, pipe_config, conn_state); > > @@ -487,9 +480,8 @@ static void chv_hdmi_pre_enable(struct > intel_atomic_state *state, > /* Use 800mV-0dB */ > chv_set_phy_signal_level(encoder, pipe_config, 128, 102, > false); > > - dig_port->set_infoframes(encoder, > - pipe_config->has_infoframe, > - pipe_config, conn_state); > + dig_port->set_infoframes(encoder, pipe_config->has_hdmi_sink, > + pipe_config, conn_state); > > g4x_enable_hdmi(state, encoder, pipe_config, conn_state); > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index b7a2fce684c9..5bc5528f3091 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -2722,9 +2722,8 @@ static void intel_ddi_pre_enable_hdmi(struct > intel_atomic_state *state, > > intel_ddi_enable_pipe_clock(encoder, crtc_state); > > - dig_port->set_infoframes(encoder, > - crtc_state->has_infoframe, > - crtc_state, conn_state); > + dig_port->set_infoframes(encoder, crtc_state->has_hdmi_sink, > crtc_state, > + conn_state); > } > > static void intel_ddi_pre_enable(struct intel_atomic_state *state, > @@ -2765,9 +2764,8 @@ static void intel_ddi_pre_enable(struc
[Intel-gfx] [PATCH v3 00/12] drm/i915: Move LMEM (VRAM) management over to TTM
This is an initial patch series to move discrete memory management over to TTM. It will be followed up shortly with adding more functionality. The buddy allocator is temporarily removed along with its selftests and It is replaced with the TTM range manager and some selftests are adjusted to account for introduced fragmentation. Work is ongoing to reintroduce the buddy allocator as a TTM resource manager. A new memcpy ttm move is introduced that uses kmap_local() functionality rather than vmap(). Among other things stated in the patch commit message it helps us deal with page-pased LMEM memory. It is generic enough to replace the ttm memcpy move with some additional work if so desired. On x86 it also enables prefetching reads from write-combined memory. Finally the old i915 gem object LMEM backend is replaced with a i915 gem object TTM backend and some additional i915 gem object ops are introduced to support the added functionality. Currently it is used only to support management and eviction of the LMEM region, but work is underway to extend the support to system memory. In this way we use TTM the way it was originally intended, having the GPU binding taken care of by driver code. Intention is to follow up with - System memory support - Pipelined accelerated moves / migration - Re-added buddy allocator in the TTM framework v2: - Add patches to move pagefaulting over to TTM - Break out TTM changes to separate patches - Address various review comments as detailed in the affected patches v3: - Drop TTM pagefaulting patches for now due changing approach due to a NAK. - Address feedback on TTM patches - Move the new TTM memcpy functionality into TTM. - Move fast WC memcpy to drm - Various fixes all over the place as shown in patch commit messages. Cc: Christian König Thomas Hellström (12): drm/i915: Untangle the vma pages_mutex drm/i915: Don't free shared locks while shared drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages drm/i915/ttm Initialize the ttm device and memory managers drm/i915/ttm: Embed a ttm buffer object in the i915 gem object drm/ttm: Add a generic TTM memcpy move for page-based iomem drm, drm/i915: Move the memcpy_from_wc functionality to core drm drm/ttm: Use drm_memcpy_from_wc_dbm for TTM bo moves drm/ttm: Document and optimize ttm_bo_pipeline_gutting() drm/ttm, drm/amdgpu: Allow the driver some control over swapping drm/i915/ttm: Introduce a TTM i915 gem object backend drm/i915/lmem: Verify checks for lmem residency drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 + drivers/gpu/drm/drm_drv.c | 2 + .../drm/{i915/i915_memcpy.c => drm_memcpy.c} | 63 +- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 4 +- drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_create.c| 9 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 71 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 5 - drivers/gpu/drm/i915/gem/i915_gem_object.c| 154 +++- drivers/gpu/drm/i915/gem/i915_gem_object.h| 13 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 49 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_region.c| 126 +-- drivers/gpu/drm/i915/gem/i915_gem_region.h| 4 - drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 10 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 9 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 531 drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 50 ++ drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 19 +- drivers/gpu/drm/i915/gt/intel_gt.c| 2 - drivers/gpu/drm/i915/gt/intel_gtt.c | 45 +- drivers/gpu/drm/i915/gt/intel_gtt.h | 28 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 30 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 7 +- drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 11 +- drivers/gpu/drm/i915/i915_buddy.c | 435 -- drivers/gpu/drm/i915/i915_buddy.h | 131 --- drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +- drivers/gpu/drm/i915/i915_drv.c | 15 +- drivers/gpu/drm/i915/i915_drv.h | 7 +- drivers/gpu/drm/i915/i915_gem.c | 6 +- drivers/gpu/drm/i915/i915_globals.c | 1 - drivers/gpu/drm/i915/i915_globals.h | 1 - drivers/gpu/drm/i915/i915_gpu_error.c | 8 +- drivers/gpu/drm/i915/i915_memcpy.h| 34 - drivers/gpu/drm/i915/i915_scatt
[Intel-gfx] [PATCH v3 01/12] drm/i915: Untangle the vma pages_mutex
Any sleeping dma_resv lock taken while the vma pages_mutex is held will cause a lockdep splat. Move the i915_gem_object_pin_pages() call out of the pages_mutex critical section. Signed-off-by: Thomas Hellström Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_vma.c | 29 + 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index a6cd0fa62847..f2b5912fc542 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -800,32 +800,37 @@ static bool try_qad_pin(struct i915_vma *vma, unsigned int flags) static int vma_get_pages(struct i915_vma *vma) { int err = 0; + bool pinned_pages = false; if (atomic_add_unless(&vma->pages_count, 1, 0)) return 0; + if (vma->obj) { + err = i915_gem_object_pin_pages(vma->obj); + if (err) + return err; + pinned_pages = true; + } + /* Allocations ahoy! */ - if (mutex_lock_interruptible(&vma->pages_mutex)) - return -EINTR; + if (mutex_lock_interruptible(&vma->pages_mutex)) { + err = -EINTR; + goto unpin; + } if (!atomic_read(&vma->pages_count)) { - if (vma->obj) { - err = i915_gem_object_pin_pages(vma->obj); - if (err) - goto unlock; - } - err = vma->ops->set_pages(vma); - if (err) { - if (vma->obj) - i915_gem_object_unpin_pages(vma->obj); + if (err) goto unlock; - } + pinned_pages = false; } atomic_inc(&vma->pages_count); unlock: mutex_unlock(&vma->pages_mutex); +unpin: + if (pinned_pages) + __i915_gem_object_unpin_pages(vma->obj); return err; } -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 02/12] drm/i915: Don't free shared locks while shared
We are currently sharing the VM reservation locks across a number of gem objects with page-table memory. Since TTM will individiualize the reservation locks when freeing objects, including accessing the shared locks, make sure that the shared locks are not freed until that is done. For PPGTT we add an additional refcount, for GGTT we take additional measures to make sure objects sharing the GGTT reservation lock are freed at GGTT takedown Signed-off-by: Thomas Hellström Reviewed-by: Maarten Lankhorst --- v2: Try harder to make sure objects sharing the GGTT reservation lock are freed at GGTT takedown. v3: Use a pointer to the vm to indicate that an object shares a reservation object from that vm, rather than a pointer to the reservation object itself. --- drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 ++ .../gpu/drm/i915/gem/i915_gem_object_types.h | 4 ++ drivers/gpu/drm/i915/gt/intel_ggtt.c | 19 ++-- drivers/gpu/drm/i915/gt/intel_gtt.c | 45 +++ drivers/gpu/drm/i915/gt/intel_gtt.h | 28 +++- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 5 +++ 7 files changed, 93 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index 28144410df86..2be6109d0093 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -252,6 +252,9 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915, if (obj->mm.n_placements > 1) kfree(obj->mm.placements); + if (obj->shares_resv_from) + i915_vm_resv_put(obj->shares_resv_from); + /* But keep the pointer alive for RCU-protected lookups */ call_rcu(&obj->rcu, __i915_gem_free_object_rcu); cond_resched(); diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h index 0727d0c76aa0..0415f99b6b95 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h @@ -149,6 +149,10 @@ struct drm_i915_gem_object { * when i915_gem_ww_ctx_backoff() or i915_gem_ww_ctx_fini() are called. */ struct list_head obj_link; + /** +* @shared_resv_from: The object shares the resv from this vm. +*/ + struct i915_address_space *shares_resv_from; union { struct rcu_head rcu; diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c index 35069ca5d7de..10c23a749a95 100644 --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c @@ -746,7 +746,6 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt) mutex_unlock(&ggtt->vm.mutex); i915_address_space_fini(&ggtt->vm); - dma_resv_fini(&ggtt->vm.resv); arch_phys_wc_del(ggtt->mtrr); @@ -768,6 +767,19 @@ void i915_ggtt_driver_release(struct drm_i915_private *i915) ggtt_cleanup_hw(ggtt); } +/** + * i915_ggtt_driver_late_release - Cleanup of GGTT that needs to be done after + * all free objects have been drained. + * @i915: i915 device + */ +void i915_ggtt_driver_late_release(struct drm_i915_private *i915) +{ + struct i915_ggtt *ggtt = &i915->ggtt; + + GEM_WARN_ON(kref_read(&ggtt->vm.resv_ref) != 1); + dma_resv_fini(&ggtt->vm._resv); +} + static unsigned int gen6_get_total_gtt_size(u16 snb_gmch_ctl) { snb_gmch_ctl >>= SNB_GMCH_GGMS_SHIFT; @@ -829,6 +841,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size) return -ENOMEM; } + kref_init(&ggtt->vm.resv_ref); ret = setup_scratch_page(&ggtt->vm); if (ret) { drm_err(&i915->drm, "Scratch setup failed\n"); @@ -1135,7 +1148,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct intel_gt *gt) ggtt->vm.gt = gt; ggtt->vm.i915 = i915; ggtt->vm.dma = i915->drm.dev; - dma_resv_init(&ggtt->vm.resv); + dma_resv_init(&ggtt->vm._resv); if (INTEL_GEN(i915) <= 5) ret = i915_gmch_probe(ggtt); @@ -1144,7 +1157,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct intel_gt *gt) else ret = gen8_gmch_probe(ggtt); if (ret) { - dma_resv_fini(&ggtt->vm.resv); + dma_resv_fini(&ggtt->vm._resv); return ret; } diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c b/drivers/gpu/drm/i915/gt/intel_gtt.c index 9b98f9d9faa3..94849567143d 100644 --- a/drivers/gpu/drm/i915/gt/intel_gtt.c +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c @@ -22,8 +22,11 @@ struct drm_i915_gem_object *alloc_pt_lmem(struct i915_address_space *vm, int sz) * object underneath, with the idea that one object_lock() will lock * t
[Intel-gfx] [PATCH v3 03/12] drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages
All users of this function actually want the dma segment sizes, but that's not what's calculated. Fix that and rename the function to i915_sg_dma_sizes to reflect what's calculated. Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_phys.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +- drivers/gpu/drm/i915/i915_scatterlist.h | 16 4 files changed, 15 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c index ccede73c6465..616c3a2f1baf 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c @@ -209,7 +209,7 @@ static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj) if (IS_ERR(pages)) return PTR_ERR(pages); - sg_page_sizes = i915_sg_page_sizes(pages->sgl); + sg_page_sizes = i915_sg_dma_sizes(pages->sgl); __i915_gem_object_set_pages(obj, pages, sg_page_sizes); diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c b/drivers/gpu/drm/i915/gem/i915_gem_phys.c index 81dc2bf59bc3..36f373dc493c 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c @@ -208,7 +208,7 @@ static int i915_gem_object_shmem_to_phys(struct drm_i915_gem_object *obj) err_xfer: if (!IS_ERR_OR_NULL(pages)) { - unsigned int sg_page_sizes = i915_sg_page_sizes(pages->sgl); + unsigned int sg_page_sizes = i915_sg_dma_sizes(pages->sgl); __i915_gem_object_set_pages(obj, pages, sg_page_sizes); } diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c index a657b99ec760..602f0ed983ec 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c @@ -173,7 +173,7 @@ static int i915_gem_userptr_get_pages(struct drm_i915_gem_object *obj) goto err; } - sg_page_sizes = i915_sg_page_sizes(st->sgl); + sg_page_sizes = i915_sg_dma_sizes(st->sgl); __i915_gem_object_set_pages(obj, st, sg_page_sizes); diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h b/drivers/gpu/drm/i915/i915_scatterlist.h index 9cb26a224034..b96baad66a3a 100644 --- a/drivers/gpu/drm/i915/i915_scatterlist.h +++ b/drivers/gpu/drm/i915/i915_scatterlist.h @@ -101,15 +101,23 @@ static inline struct scatterlist *__sg_next(struct scatterlist *sg) (((__iter).curr += PAGE_SIZE) >= (__iter).max) ? \ (__iter) = __sgt_iter(__sg_next((__iter).sgp), false), 0 : 0) -static inline unsigned int i915_sg_page_sizes(struct scatterlist *sg) +/** + * i915_sg_dma_sizes - Record the dma segment sizes of a scatterlist + * @sg: The scatterlist + * + * Return: An unsigned int with segment sizes logically or'ed together. + * A caller can use this information to determine what hardware page table + * entry sizes can be used to map the memory represented by the scatterlist. + */ +static inline unsigned int i915_sg_dma_sizes(struct scatterlist *sg) { unsigned int page_sizes; page_sizes = 0; - while (sg) { + while (sg && sg_dma_len(sg)) { GEM_BUG_ON(sg->offset); - GEM_BUG_ON(!IS_ALIGNED(sg->length, PAGE_SIZE)); - page_sizes |= sg->length; + GEM_BUG_ON(!IS_ALIGNED(sg_dma_len(sg), PAGE_SIZE)); + page_sizes |= sg_dma_len(sg); sg = __sg_next(sg); } -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 05/12] drm/i915/ttm: Embed a ttm buffer object in the i915 gem object
Embed a struct ttm_buffer_object into the i915 gem object, making sure we alias the gem object part. It's a bit unfortunate that the struct ttm_buffer_ojbect embeds a gem object since we otherwise could make the TTM part private to the TTM backend, and use the usual i915 gem object for the other backends. To make this a bit more storage efficient for the other backends, we'd have to use a pointer for the gem object which would require a lot of changes in the driver. We postpone that for later. Signed-off-by: Thomas Hellström Acked-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 7 +++ drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 12 +++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index 2be6109d0093..5706d471692d 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -62,6 +62,13 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj, const struct drm_i915_gem_object_ops *ops, struct lock_class_key *key, unsigned flags) { + /* +* A gem object is embedded both in a struct ttm_buffer_object :/ and +* in a drm_i915_gem_object. Make sure they are aliased. +*/ + BUILD_BUG_ON(offsetof(typeof(*obj), base) != +offsetof(typeof(*obj), __do_not_access.base)); + spin_lock_init(&obj->vma.lock); INIT_LIST_HEAD(&obj->vma.list); diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h index f5b46d11e6e6..d047ea126029 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h @@ -10,6 +10,7 @@ #include #include +#include #include #include "i915_active.h" @@ -99,7 +100,16 @@ struct i915_gem_object_page_iter { }; struct drm_i915_gem_object { - struct drm_gem_object base; + /* +* We might have reason to revisit the below since it wastes +* a lot of space for non-ttm gem objects. +* In any case, always use the accessors for the ttm_buffer_object +* when accessing it. +*/ + union { + struct drm_gem_object base; + struct ttm_buffer_object __do_not_access; + }; const struct drm_i915_gem_object_ops *ops; -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 07/12] drm, drm/i915: Move the memcpy_from_wc functionality to core drm
Memcpy from wc will be used as well by TTM memcpy. Move it to core drm, and make the interface do the right thing even on !X86. Cc: Christian König Cc: Daniel Vetter Cc: Dave Airlie Signed-off-by: Thomas Hellström --- drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_drv.c | 2 + .../drm/{i915/i915_memcpy.c => drm_memcpy.c} | 63 ++- drivers/gpu/drm/i915/Makefile | 1 - .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +- drivers/gpu/drm/i915/gem/i915_gem_object.c| 5 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 7 ++- drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 11 ++-- drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +- drivers/gpu/drm/i915/i915_drv.c | 2 - drivers/gpu/drm/i915/i915_gpu_error.c | 8 +-- drivers/gpu/drm/i915/i915_memcpy.h| 34 -- .../drm/i915/selftests/intel_memory_region.c | 7 ++- include/drm/drm_memcpy.h | 47 ++ 14 files changed, 121 insertions(+), 76 deletions(-) rename drivers/gpu/drm/{i915/i915_memcpy.c => drm_memcpy.c} (70%) delete mode 100644 drivers/gpu/drm/i915/i915_memcpy.h create mode 100644 include/drm/drm_memcpy.h diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index a91cc7684904..f3ab8586c3d7 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -18,7 +18,7 @@ drm-y :=drm_aperture.o drm_auth.o drm_cache.o \ drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \ - drm_managed.o drm_vblank_work.o + drm_managed.o drm_vblank_work.o drm_memcpy.o \ drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o drm_dma.o \ drm_legacy_misc.o drm_lock.o drm_memory.o drm_scatter.o \ diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 3d8d68a98b95..351cc2900cf1 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -40,6 +40,7 @@ #include #include #include +#include #include #include @@ -1041,6 +1042,7 @@ static int __init drm_core_init(void) drm_connector_ida_init(); idr_init(&drm_minors_idr); + drm_memcpy_init_early(); ret = drm_sysfs_init(); if (ret < 0) { diff --git a/drivers/gpu/drm/i915/i915_memcpy.c b/drivers/gpu/drm/drm_memcpy.c similarity index 70% rename from drivers/gpu/drm/i915/i915_memcpy.c rename to drivers/gpu/drm/drm_memcpy.c index 1b021a4902de..740377749caa 100644 --- a/drivers/gpu/drm/i915/i915_memcpy.c +++ b/drivers/gpu/drm/drm_memcpy.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: MIT /* * Copyright © 2016 Intel Corporation * @@ -22,16 +23,12 @@ * */ +#ifdef CONFIG_X86 +#include #include #include -#include "i915_memcpy.h" - -#if IS_ENABLED(CONFIG_DRM_I915_DEBUG) -#define CI_BUG_ON(expr) BUG_ON(expr) -#else -#define CI_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr) -#endif +#include "drm/drm_memcpy.h" static DEFINE_STATIC_KEY_FALSE(has_movntdqa); @@ -94,23 +91,24 @@ static void __memcpy_ntdqu(void *dst, const void *src, unsigned long len) } /** - * i915_memcpy_from_wc: perform an accelerated *aligned* read from WC + * drm_memcpy_from_wc: perform an accelerated *aligned* read from WC * @dst: destination pointer * @src: source pointer * @len: how many bytes to copy * - * i915_memcpy_from_wc copies @len bytes from @src to @dst using + * drm_memcpy_from_wc copies @len bytes from @src to @dst using * non-temporal instructions where available. Note that all arguments * (@src, @dst) must be aligned to 16 bytes and @len must be a multiple * of 16. * * To test whether accelerated reads from WC are supported, use - * i915_memcpy_from_wc(NULL, NULL, 0); + * drm_memcpy_from_wc(NULL, NULL, 0); + * This interface is intended for memremapped memory without the __iomem tag. * * Returns true if the copy was successful, false if the preconditions * are not met. */ -bool i915_memcpy_from_wc(void *dst, const void *src, unsigned long len) +bool drm_memcpy_from_wc(void *dst, const void *src, unsigned long len) { if (unlikely(((unsigned long)dst | (unsigned long)src | len) & 15)) return false; @@ -123,24 +121,53 @@ bool i915_memcpy_from_wc(void *dst, const void *src, unsigned long len) return false; } +EXPORT_SYMBOL(drm_memcpy_from_wc); /** - * i915_unaligned_memcpy_from_wc: perform a mostly accelerated read from WC + * drm_memcpy_from_wc_dbm: perform an accelerated *aligned* read from WC with + * struct dma_buf_map arguments. + * @dst: destination map + * @src: source map + * @len: how many bytes to copy + * + * This is identical to drm_memcpy_from_wc, except it's intended for + * potentially ioremapped memory rather than memremapped memory. + * + * Return
[Intel-gfx] [PATCH v3 06/12] drm/ttm: Add a generic TTM memcpy move for page-based iomem
The internal ttm_bo_util memcpy uses ioremap functionality, and while it probably might be possible to use it for copying in- and out of sglist represented io memory, using io_mem_reserve() / io_mem_free() callbacks, that would cause problems with fault(). Instead, implement a method mapping page-by-page using kmap_local() semantics. As an additional benefit we then avoid the occasional global TLB flushes of ioremap() and consuming ioremap space, elimination of a critical point of failure and with a slight change of semantics we could also push the memcpy out async for testing and async driver development purposes. A special linear iomem iterator is introduced internally to mimic the old ioremap behaviour for code-paths that can't immediately be ported over. This adds to the code size and should be considered a temporary solution. Looking at the code we have a lot of checks for iomap tagged pointers. Ideally we should extend the core memremap functions to also accept uncached memory and kmap_local functionality. Then we could strip a lot of code. Cc: Christian König Signed-off-by: Thomas Hellström --- v3: - Split up in various TTM files and addressed review comments by Christian König. Tested and fixed legacy iomap memcpy path on i915. --- drivers/gpu/drm/ttm/ttm_bo_util.c | 278 ++--- drivers/gpu/drm/ttm/ttm_module.c | 35 drivers/gpu/drm/ttm/ttm_resource.c | 166 + drivers/gpu/drm/ttm/ttm_tt.c | 42 + include/drm/ttm/ttm_bo_driver.h| 28 +++ include/drm/ttm/ttm_caching.h | 2 + include/drm/ttm/ttm_kmap_iter.h| 61 +++ include/drm/ttm/ttm_resource.h | 61 +++ include/drm/ttm/ttm_tt.h | 16 ++ 9 files changed, 508 insertions(+), 181 deletions(-) create mode 100644 include/drm/ttm/ttm_kmap_iter.h diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index ae8b61460724..912cbe8e60a2 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -72,190 +72,126 @@ void ttm_mem_io_free(struct ttm_device *bdev, mem->bus.addr = NULL; } -static int ttm_resource_ioremap(struct ttm_device *bdev, - struct ttm_resource *mem, - void **virtual) +/** + * ttm_move_memcpy - Helper to perform a memcpy ttm move operation. + * @bo: The struct ttm_buffer_object. + * @new_mem: The struct ttm_resource we're moving to (copy destination). + * @new_iter: A struct ttm_kmap_iter representing the destination resource. + * @src_iter: A struct ttm_kmap_iter representing the source resource. + * + * This function is intended to be able to move out async under a + * dma-fence if desired. + */ +void ttm_move_memcpy(struct ttm_buffer_object *bo, +struct ttm_resource *dst_mem, +struct ttm_kmap_iter *dst_iter, +struct ttm_kmap_iter *src_iter) { - int ret; - void *addr; - - *virtual = NULL; - ret = ttm_mem_io_reserve(bdev, mem); - if (ret || !mem->bus.is_iomem) - return ret; + const struct ttm_kmap_iter_ops *dst_ops = dst_iter->ops; + const struct ttm_kmap_iter_ops *src_ops = src_iter->ops; + struct ttm_tt *ttm = bo->ttm; + struct dma_buf_map src_map, dst_map; + pgoff_t i; - if (mem->bus.addr) { - addr = mem->bus.addr; - } else { - size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT; + /* Single TTM move. NOP */ + if (dst_ops->maps_tt && src_ops->maps_tt) + return; - if (mem->bus.caching == ttm_write_combined) - addr = ioremap_wc(mem->bus.offset, bus_size); -#ifdef CONFIG_X86 - else if (mem->bus.caching == ttm_cached) - addr = ioremap_cache(mem->bus.offset, bus_size); -#endif - else - addr = ioremap(mem->bus.offset, bus_size); - if (!addr) { - ttm_mem_io_free(bdev, mem); - return -ENOMEM; + /* Don't move nonexistent data. Clear destination instead. */ + if (src_ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm))) { + if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC)) + return; + + for (i = 0; i < dst_mem->num_pages; ++i) { + dst_ops->map_local(dst_iter, &dst_map, i); + if (dst_map.is_iomem) + memset_io(dst_map.vaddr_iomem, 0, PAGE_SIZE); + else + memset(dst_map.vaddr, 0, PAGE_SIZE); + if (dst_ops->unmap_local) + dst_ops->unmap_local(dst_iter, &dst_map); } + return; } - *virtual = addr; - return 0; -} - -static void ttm_resource_iounmap(struct ttm_devic
[Intel-gfx] [PATCH v3 04/12] drm/i915/ttm Initialize the ttm device and memory managers
Temporarily remove the buddy allocator and related selftests and hook up the TTM range manager for i915 regions. Also modify the mock region selftests somewhat to account for a fragmenting manager. Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld #v2 --- v2: - Fix an error unwind in lmem_get_pages() (Reported by Matthew Auld) - Break out and modify usage of i915_sg_dma_sizes() (Reported by Mattew Auld) - Break out TTM changes to a separate patch (Reported by Christian König) v3: - Fix the same error unwind in mock_region_get_pages() (Reported by Matthew Auld) - Don't rely on new TTM functionality, but create a mock TTM device, (Reported by Christian König) --- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 2 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 59 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 3 +- drivers/gpu/drm/i915/gem/i915_gem_region.c| 120 --- drivers/gpu/drm/i915/gem/i915_gem_region.h| 4 - drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 10 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 9 +- drivers/gpu/drm/i915/gt/intel_gt.c| 2 - drivers/gpu/drm/i915/gt/intel_region_lmem.c | 27 +- drivers/gpu/drm/i915/i915_buddy.c | 435 -- drivers/gpu/drm/i915/i915_buddy.h | 131 --- drivers/gpu/drm/i915/i915_drv.c | 8 + drivers/gpu/drm/i915/i915_drv.h | 7 +- drivers/gpu/drm/i915/i915_gem.c | 1 + drivers/gpu/drm/i915/i915_globals.c | 1 - drivers/gpu/drm/i915/i915_globals.h | 1 - drivers/gpu/drm/i915/i915_scatterlist.c | 70 ++ drivers/gpu/drm/i915/i915_scatterlist.h | 4 + drivers/gpu/drm/i915/intel_memory_region.c| 180 ++-- drivers/gpu/drm/i915/intel_memory_region.h| 44 +- drivers/gpu/drm/i915/intel_region_ttm.c | 334 drivers/gpu/drm/i915/intel_region_ttm.h | 38 + drivers/gpu/drm/i915/selftests/i915_buddy.c | 789 -- .../drm/i915/selftests/i915_mock_selftests.h | 1 - .../drm/i915/selftests/intel_memory_region.c | 133 +-- drivers/gpu/drm/i915/selftests/mock_region.c | 52 +- 29 files changed, 722 insertions(+), 1754 deletions(-) delete mode 100644 drivers/gpu/drm/i915/i915_buddy.c delete mode 100644 drivers/gpu/drm/i915/i915_buddy.h create mode 100644 drivers/gpu/drm/i915/intel_region_ttm.c create mode 100644 drivers/gpu/drm/i915/intel_region_ttm.h delete mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 1e1cb245fca7..b63d374dff23 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -26,6 +26,7 @@ config DRM_I915 select SND_HDA_I915 if SND_HDA_CORE select CEC_CORE if CEC_NOTIFIER select VMAP_PFN + select DRM_TTM help Choose this option if you have a system that has "Intel Graphics Media Accelerator" or "HD Graphics" integrated graphics, diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index d0d936d9137b..cb8823570996 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -50,6 +50,7 @@ i915-y += i915_drv.o \ intel_memory_region.o \ intel_pch.o \ intel_pm.o \ + intel_region_ttm.o \ intel_runtime_pm.o \ intel_sideband.o \ intel_step.o \ @@ -160,7 +161,6 @@ gem-y += \ i915-y += \ $(gem-y) \ i915_active.o \ - i915_buddy.o \ i915_cmd_parser.o \ i915_gem_evict.o \ i915_gem_gtt.o \ diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c index f44bdd08f7cb..3b4aa28a076d 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c @@ -4,16 +4,71 @@ */ #include "intel_memory_region.h" +#include "intel_region_ttm.h" #include "gem/i915_gem_region.h" #include "gem/i915_gem_lmem.h" #include "i915_drv.h" +static void lmem_put_pages(struct drm_i915_gem_object *obj, + struct sg_table *pages) +{ + intel_region_ttm_node_free(obj->mm.region, obj->mm.st_mm_node); + obj->mm.dirty = false; + sg_free_table(pages); + kfree(pages); +} + +static int lmem_get_pages(struct drm_i915_gem_object *obj) +{ + unsigned int flags; + struct sg_table *pages; + + flags = I915_ALLOC_MIN_PAGE_SIZE; + if (obj->flags & I915_BO_ALLOC_CONTIGUOUS) + flags |= I915_ALLOC_CONTIGUOUS; + + obj->mm.st_mm_node = intel_region_ttm_node_alloc(obj->mm.region, +obj->base.size, +flags); + if (IS_ERR(obj
[Intel-gfx] [PATCH v3 09/12] drm/ttm: Document and optimize ttm_bo_pipeline_gutting()
If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily create a ghost object and push it out to delayed destroy. Fix this by adding a path for idle, and document the function. Also avoid having the bo end up in a bad state vulnerable to user-space triggered kernel BUGs if the call to ttm_tt_create() fails. Finally reuse ttm_bo_pipeline_gutting() in ttm_bo_evict(). Cc: Christian König Signed-off-by: Thomas Hellström --- drivers/gpu/drm/ttm/ttm_bo.c | 20 ++-- drivers/gpu/drm/ttm/ttm_bo_util.c | 52 --- drivers/gpu/drm/ttm/ttm_tt.c | 5 +++ include/drm/ttm/ttm_tt.h | 10 ++ 4 files changed, 73 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index ca1b098b6a56..a8fa3375b8aa 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -501,10 +501,15 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bdev->funcs->evict_flags(bo, &placement); if (!placement.num_placement && !placement.num_busy_placement) { - ttm_bo_wait(bo, false, false); + ret = ttm_bo_wait(bo, true, false); + if (ret) + return ret; - ttm_bo_cleanup_memtype_use(bo); - return ttm_tt_create(bo, false); + /* +* Since we've already synced, this frees backing store +* immediately. +*/ + return ttm_bo_pipeline_gutting(bo); } ret = ttm_bo_mem_space(bo, &placement, &evict_mem, ctx); @@ -974,13 +979,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo, /* * Remove the backing store if no placement is given. */ - if (!placement->num_placement && !placement->num_busy_placement) { - ret = ttm_bo_pipeline_gutting(bo); - if (ret) - return ret; - - return ttm_tt_create(bo, false); - } + if (!placement->num_placement && !placement->num_busy_placement) + return ttm_bo_pipeline_gutting(bo); /* * Check whether we need to move buffer. diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index 4a7d3d672f9a..7fa9b3a852eb 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -585,26 +585,70 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo, } EXPORT_SYMBOL(ttm_bo_move_accel_cleanup); +/** + * ttm_bo_pipeline_gutting - purge the contents of a bo + * @bo: The buffer object + * + * Purge the contents of a bo, async if the bo is not idle. + * After a successful call, the bo is left unpopulated in + * system placement. The function may wait uninterruptible + * for idle on OOM. + * + * Return: 0 if successful, negative error code on failure. + */ 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_tt *ttm; int ret; - ret = ttm_buffer_object_transfer(bo, &ghost); + /* If already idle, no need for ghost object dance. */ + ret = ttm_bo_wait(bo, false, true); + if (ret != -EBUSY) { + if (!bo->ttm) { + ret = ttm_tt_create(bo, true); + if (ret) + 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, &bo->mem); + ttm_resource_alloc(bo, &sys_mem, &bo->mem); + + return 0; + } + + /* +* We need an unpopulated ttm_tt after giving our current one, +* if any, to the ghost object. And we can't afford to fail +* creating one *after* the operation. +*/ + + ttm = bo->ttm; + bo->ttm = NULL; + ret = ttm_tt_create(bo, true); + swap(bo->ttm, ttm); if (ret) return ret; + ret = ttm_buffer_object_transfer(bo, &ghost); + if (ret) { + ttm_tt_destroy(bo->bdev, ttm); + return ret; + } + ret = dma_resv_copy_fences(&ghost->base._resv, bo->base.resv); /* Last resort, wait for the BO to be idle when we are OOM */ if (ret) ttm_bo_wait(bo, false, false); - ttm_resource_alloc(bo, &sys_mem, &bo->mem); - bo->ttm = NULL; - dma_resv_unlock(&ghost->base._resv); ttm_bo_put(ghost); + bo->ttm = ttm; + ttm_resource_alloc(bo, &sys_mem, &bo->mem); return 0; } diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 0e41227116b1..913b330a234b 100644 --- a/drivers/gp
[Intel-gfx] [PATCH v3 11/12] drm/i915/ttm: Introduce a TTM i915 gem object backend
Most logical place to introduce TTM buffer objects is as an i915 gem object backend. We need to add some ops to account for added functionality like delayed delete and LRU list manipulation. Initially we support only LMEM and SYSTEM memory, but SYSTEM (which in this case means evicted LMEM objects) is not visible to i915 GEM yet. The plan is to move the i915 gem system region over to the TTM system memory type in upcoming patches. We set up GPU bindings directly both from LMEM and from the system region, as there is no need to use the legacy TTM_TT memory type. We reserve that for future porting of GGTT bindings to TTM. Remove the old lmem backend. Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld --- v2: - Break out needed TTM functionality to a separate patch (Reported by Christian König). - Fix an unhandled error (Reported by Matthew Auld and Maarten Lankhorst) - Remove a stray leftover sg_table allocation (Reported by Matthew Auld) - Use ttm_tt_unpopulate() rather than ttm_tt_destroy() in the purge path as some TTM functionality relies on having a ttm_tt present for !is_iomem. v3: - Use ttm_bo_type_device for userspace visible objects so that TTM can allocate an address space offset for mmap'ing. - Fix up the destruction path (Reported by Matthew Auld) - Use ttm_bo_validate() for purging (Reported by Christian König) - Create ttm_tts write-combined as they are currently for eviction only and we want to maintain consistent write-combined caching for bos that are not in system only. (Suggested by Daniel Vetter) - Make struct ttm_placements static. - Add the ttm device funcs/ops to i915_gem_ttm.h for the region code. - Rename new->dst and old->src. Check for swapin in the move callback. --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_create.c| 9 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 84 --- drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 5 - drivers/gpu/drm/i915/gem/i915_gem_object.c| 125 +++-- drivers/gpu/drm/i915/gem/i915_gem_object.h| 9 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +- drivers/gpu/drm/i915/gem/i915_gem_region.c| 6 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 531 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 50 ++ drivers/gpu/drm/i915/gt/intel_region_lmem.c | 3 +- drivers/gpu/drm/i915/i915_gem.c | 5 +- drivers/gpu/drm/i915/intel_memory_region.c| 1 - drivers/gpu/drm/i915/intel_memory_region.h| 1 - drivers/gpu/drm/i915/intel_region_ttm.c | 6 +- drivers/gpu/drm/i915/intel_region_ttm.h | 8 +- 16 files changed, 717 insertions(+), 154 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.h diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 998606b7f49f..2022e763f8f7 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -154,6 +154,7 @@ gem-y += \ gem/i915_gem_stolen.o \ gem/i915_gem_throttle.o \ gem/i915_gem_tiling.o \ + gem/i915_gem_ttm.o \ gem/i915_gem_userptr.o \ gem/i915_gem_wait.o \ gem/i915_gemfs.o diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c b/drivers/gpu/drm/i915/gem/i915_gem_create.c index 548ddf39d853..93bf63bbaff1 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c @@ -85,13 +85,10 @@ i915_gem_setup(struct drm_i915_gem_object *obj, u64 size) return -E2BIG; /* -* For now resort to CPU based clearing for device local-memory, in the -* near future this will use the blitter engine for accelerated, GPU -* based clearing. +* I915_BO_ALLOC_USER will make sure the object is cleared before +* any user access. */ - flags = 0; - if (mr->type == INTEL_MEMORY_LOCAL) - flags = I915_BO_ALLOC_CPU_CLEAR; + flags = I915_BO_ALLOC_USER; ret = mr->ops->init_object(mr, obj, size, flags); if (ret) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c index 3b4aa28a076d..2b8cd15de1d9 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c @@ -4,74 +4,10 @@ */ #include "intel_memory_region.h" -#include "intel_region_ttm.h" #include "gem/i915_gem_region.h" #include "gem/i915_gem_lmem.h" #include "i915_drv.h" -static void lmem_put_pages(struct drm_i915_gem_object *obj, - struct sg_table *pages) -{ - intel_region_ttm_node_free(obj->mm.region, obj->mm.st_mm_node); - obj->mm.dirty = false; - sg_free_table(pages); - kfree(pages); -} - -static int lmem_get_pages(struct drm_i915_gem_object *obj) -{ - unsigned int flags; - struct sg_table *pages; - - flags = I915_ALLOC_MIN_PAGE_SI
[Intel-gfx] [PATCH v3 08/12] drm/ttm: Use drm_memcpy_from_wc_dbm for TTM bo moves
Use fast wc memcpy for reading out of wc memory for TTM bo moves. Cc: Dave Airlie Cc: Christian König Cc: Daniel Vetter Signed-off-by: Thomas Hellström --- drivers/gpu/drm/ttm/ttm_bo_util.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index 912cbe8e60a2..4a7d3d672f9a 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -31,6 +31,7 @@ #include #include +#include #include #include #include @@ -91,6 +92,7 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo, const struct ttm_kmap_iter_ops *src_ops = src_iter->ops; struct ttm_tt *ttm = bo->ttm; struct dma_buf_map src_map, dst_map; + bool wc_memcpy; pgoff_t i; /* Single TTM move. NOP */ @@ -114,11 +116,16 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo, return; } + wc_memcpy = ((!src_ops->maps_tt || ttm->caching != ttm_cached) && +drm_has_memcpy_from_wc()); + for (i = 0; i < dst_mem->num_pages; ++i) { dst_ops->map_local(dst_iter, &dst_map, i); src_ops->map_local(src_iter, &src_map, i); - if (!src_map.is_iomem && !dst_map.is_iomem) { + if (wc_memcpy) { + drm_memcpy_from_wc_dbm(&dst_map, &src_map, PAGE_SIZE); + } else if (!src_map.is_iomem && !dst_map.is_iomem) { memcpy(dst_map.vaddr, src_map.vaddr, PAGE_SIZE); } else if (!src_map.is_iomem) { dma_buf_map_memcpy_to(&dst_map, src_map.vaddr, -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 10/12] drm/ttm, drm/amdgpu: Allow the driver some control over swapping
We are calling the eviction_valuable driver callback at eviction time to determine whether we actually can evict a buffer object. The upcoming i915 TTM backend needs the same functionality for swapout, and that might actually be beneficial to other drivers as well. Add an eviction_valuable call also in the swapout path. Try to keep the current behaviour for all drivers by returning true if the buffer object is already in the TTM_PL_SYSTEM placement. We change behaviour for the case where a buffer object is in a TT backed placement when swapped out, in which case the drivers normal eviction_valuable path is run. Finally make sure we don't try to swapout a bo that was recently purged and therefore unpopulated. Reviewed-by: Maarten Lankhorst Cc: Christian König Signed-off-by: Thomas Hellström --- v3: - Don't export ttm_tt_unpopulate - Fix confusion reading the locked pointer instead of the value pointed to in ttm_bo_evict_swapout_allowable (Reported by Maarten Lankhorst) --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +++ drivers/gpu/drm/ttm/ttm_bo.c| 43 - drivers/gpu/drm/ttm/ttm_tt.c| 3 ++ 3 files changed, 34 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 8c7ec09eb1a4..d5a9d7a88315 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -1399,6 +1399,10 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo, struct dma_fence *f; int i; + /* Swapout? */ + if (bo->mem.mem_type == TTM_PL_SYSTEM) + return true; + if (bo->type == ttm_bo_type_kernel && !amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo))) return false; diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index a8fa3375b8aa..f45486837b44 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -536,6 +536,10 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo, const struct ttm_place *place) { + dma_resv_assert_held(bo->base.resv); + if (bo->mem.mem_type == TTM_PL_SYSTEM) + return true; + /* Don't evict this BO if it's outside of the * requested placement range */ @@ -558,7 +562,9 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable); * b. Otherwise, trylock it. */ static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo, - struct ttm_operation_ctx *ctx, bool *locked, bool *busy) + struct ttm_operation_ctx *ctx, + const struct ttm_place *place, + bool *locked, bool *busy) { bool ret = false; @@ -576,6 +582,14 @@ static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo, *busy = !ret; } + if (ret && place && !bo->bdev->funcs->eviction_valuable(bo, place)) { + ret = false; + if (*locked) { + dma_resv_unlock(bo->base.resv); + *locked = false; + } + } + return ret; } @@ -630,20 +644,14 @@ int ttm_mem_evict_first(struct ttm_device *bdev, list_for_each_entry(bo, &man->lru[i], lru) { bool busy; - if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked, - &busy)) { + if (!ttm_bo_evict_swapout_allowable(bo, ctx, place, + &locked, &busy)) { if (busy && !busy_bo && ticket != dma_resv_locking_ctx(bo->base.resv)) busy_bo = bo; continue; } - if (place && !bdev->funcs->eviction_valuable(bo, - place)) { - if (locked) - dma_resv_unlock(bo->base.resv); - continue; - } if (!ttm_bo_get_unless_zero(bo)) { if (locked) dma_resv_unlock(bo->base.resv); @@ -1138,10 +1146,18 @@ EXPORT_SYMBOL(ttm_bo_wait); int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx, gfp_t gfp_flags) { + struct ttm_place place = {}; bool locked; int ret; - if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked, NULL)) + /* +* While the bo may already reside in SYSTEM p
[Intel-gfx] [PATCH v3 12/12] drm/i915/lmem: Verify checks for lmem residency
Since objects can be migrated or evicted when not pinned or locked, update the checks for lmem residency or future residency so that the value returned is not immediately stale. Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld --- v2: Simplify i915_gem_object_migratable() (Reported by Mattew Auld) --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 42 +++- drivers/gpu/drm/i915/gem/i915_gem_object.c | 18 + drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 ++ 4 files changed, 64 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index de1f13d203b5..b95def2d5af3 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -11615,7 +11615,7 @@ intel_user_framebuffer_create(struct drm_device *dev, /* object is backed with LMEM for discrete */ i915 = to_i915(obj->base.dev); - if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj)) { + if (HAS_LMEM(i915) && !i915_gem_object_validates_to_lmem(obj)) { /* object is "remote", not in local memory */ i915_gem_object_put(obj); return ERR_PTR(-EREMOTE); diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c index 2b8cd15de1d9..d539dffa1554 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c @@ -23,10 +23,50 @@ i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj, return io_mapping_map_wc(&obj->mm.region->iomap, offset, size); } +/** + * i915_gem_object_validates_to_lmem - Whether the object is resident in + * lmem when pages are present. + * @obj: The object to check. + * + * Migratable objects residency may change from under us if the object is + * not pinned or locked. This function is intended to be used to check whether + * the object can only reside in lmem when pages are present. + * + * Return: Whether the object is always resident in lmem when pages are + * present. + */ +bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj) +{ + struct intel_memory_region *mr = READ_ONCE(obj->mm.region); + + return !i915_gem_object_migratable(obj) && + mr && (mr->type == INTEL_MEMORY_LOCAL || + mr->type == INTEL_MEMORY_STOLEN_LOCAL); +} + +/** + * i915_gem_object_is_lmem - Whether the object is resident in + * lmem + * @obj: The object to check. + * + * Even if an object is allowed to migrate and change memory region, + * this function checks whether it will always be present in lmem when + * valid *or* if that's not the case, whether it's currently resident in lmem. + * For migratable and evictable objects, the latter only makes sense when + * the object is locked. + * + * Return: Whether the object migratable but resident in lmem, or not + * migratable and will be present in lmem when valid. + */ bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj) { - struct intel_memory_region *mr = obj->mm.region; + struct intel_memory_region *mr = READ_ONCE(obj->mm.region); +#ifdef CONFIG_LOCKDEP + if (i915_gem_object_migratable(obj) && + i915_gem_object_evictable(obj)) + assert_object_held(obj); +#endif return mr && (mr->type == INTEL_MEMORY_LOCAL || mr->type == INTEL_MEMORY_STOLEN_LOCAL); } diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index df2b4e6b9bcc..c8bb6fb1dba3 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -458,6 +458,24 @@ bool i915_gem_object_evictable(struct drm_i915_gem_object *obj) return pin_count == 0; } +/** + * i915_gem_object_migratable - Whether the object is migratable out of the + * current region. + * @obj: Pointer to the object. + * + * Return: Whether the object is allowed to be resident in other + * regions than the current while pages are present. + */ +bool i915_gem_object_migratable(struct drm_i915_gem_object *obj) +{ + struct intel_memory_region *mr = READ_ONCE(obj->mm.region); + + if (!mr) + return false; + + return obj->mm.n_placements > 1; +} + void i915_gem_init__objects(struct drm_i915_private *i915) { INIT_WORK(&i915->mm.free_work, __i915_gem_free_work); diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h index ae5930e307d5..a3ad8cf4eefd 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h @@ -596,6 +596,10 @@ void __i915_gem_free_object(struct drm_i915_gem_object *obj); bool i915_gem_object_evictable(struct drm_i915_gem_object *obj); +bool i915_gem_object_migratable(struct drm_i915_gem_object *obj); + +bool i915_gem_objec
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Move LMEM (VRAM) management over to TTM (rev3)
== Series Details == Series: drm/i915: Move LMEM (VRAM) management over to TTM (rev3) URL : https://patchwork.freedesktop.org/series/90022/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1bf39c8cd594 drm/i915: Untangle the vma pages_mutex 650181499469 drm/i915: Don't free shared locks while shared e0cd60e6a0d3 drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages 4f895c63cc41 drm/i915/ttm Initialize the ttm device and memory managers -:480: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #480: deleted file mode 100644 total: 0 errors, 1 warnings, 0 checks, 1578 lines checked fbd2191fd254 drm/i915/ttm: Embed a ttm buffer object in the i915 gem object 67e58a6747b0 drm/ttm: Add a generic TTM memcpy move for page-based iomem -:383: CHECK:ARCH_DEFINES: architecture specific defines should be avoided #383: FILE: drivers/gpu/drm/ttm/ttm_module.c:56: +#if defined(__i386__) || defined(__x86_64__) -:699: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #699: new file mode 100644 total: 0 errors, 1 warnings, 1 checks, 812 lines checked fa7a4164f770 drm, drm/i915: Move the memcpy_from_wc functionality to core drm -:54: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #54: rename from drivers/gpu/drm/i915/i915_memcpy.c total: 0 errors, 1 warnings, 0 checks, 410 lines checked 533ef0911275 drm/ttm: Use drm_memcpy_from_wc_dbm for TTM bo moves 655c519cecf1 drm/ttm: Document and optimize ttm_bo_pipeline_gutting() 2f38e8009d75 drm/ttm, drm/amdgpu: Allow the driver some control over swapping 356c346230f1 drm/i915/ttm: Introduce a TTM i915 gem object backend -:449: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #449: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 1024 lines checked 7ced8a9675bb drm/i915/lmem: Verify checks for lmem residency ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Move LMEM (VRAM) management over to TTM (rev3)
== Series Details == Series: drm/i915: Move LMEM (VRAM) management over to TTM (rev3) URL : https://patchwork.freedesktop.org/series/90022/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/dr
Re: [Intel-gfx] [Mesa-dev] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On Fri, May 21, 2021 at 10:35:37AM +0200, Christian König wrote: > Am 20.05.21 um 23:38 schrieb Jason Ekstrand: > > On Thu, May 20, 2021 at 10:46 AM Matthew Brost > > wrote: > > > On Thu, May 20, 2021 at 01:11:59PM +0200, Christian König wrote: > > > > Am 19.05.21 um 18:51 schrieb Matthew Brost: > > > > > On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote: > > > > > > Oh, yeah we call that gang submit on the AMD side. > > > > > > > > > > > > Had already some internal discussions how to implement this, but so > > > > > > far > > > > > > couldn't figure out how to cleanly introduce that into the DRM > > > > > > scheduler. > > > > > > > > > > > > Can you briefly describe in a few words how that is supposed to > > > > > > work on the > > > > > > Intel side? > > On Intel, we actually have two cases which don't fit the current > > drm/scheduler model well: balanced and bonded. > > > > In the balanced model, we want to submit a batch which can go to any > > one of some set of engines and we don't care which. It's up to the > > kernel to pick an engine. Imagine you had 64 identical HW compute > > queues, for instance. This could be done by making all the identical > > engines share a single drm_gpu_scheduler and round-robin around the HW > > queues or something. I don't know that we strictly need drm/scheduler > > to be aware of it but it might be nice if it grew support for this > > mode so we could maintain a 1:1 relationship between HW queues and > > drm_gpu_schedulers. That said, I'm not sure how this would play with > > GuC queues so maybe it doesn't help? > > Oh, we do have support for load balancing like that. > > When you call drm_sched_entity_init() you can give a list of > drm_gpu_scheduler object to use round robing for scheduling. > > New jobs are then scheduler to the drm_gpu_scheduler instance which is idle > or rather the least busy one. > > > The bonded model is like your ganged, I think. We want to submit N > > batches to run in parallel. And they actually have to be executing on > > the GPU simultaneously and not just sort-of at similar times. We need > > this for video. There are also potential use-cases in Vulkan or even > > GL that might be able to use this. One difference with the balanced > > mode is that bonds don't, strictly speaking, need to be on the same > > type of engine. Imagine, for instance, a 3D batch with a parallel > > compute batch doing vertex pre-processing. > > > > I'm pretty sure the bonded case is something that the mobile drivers > > (panfrost, etc.) would like as well for doing Vulkan on tilers where > > you often have to have two command buffers running in parallel. > > They're currently doing it by submitting a giant pile of batches where > > they split the batch and add sync primitives every time some GL call > > requires them to sync between fragment and vertex pipes. > > Yeah, we have exactly the same problem as well. > > But so far every model we discussed has some drawbacks and it is rather hard > for the scheduler to guarantee that stuff runs at the same time. > > So if you got any ideas how to cleanly implement that then they would be > rather welcomed. > Everything Jason said about our submission modes is correct for execlists, we have balanced + bonded models which is tightly coupled with that backend. Fortunately with GuC submission most of this complexity goes away as the GuC handles this for us. e.g. For balanced when we register a context we just give it a mask of which physical engines a context is allowed to run on. For parallel we register N contexts in a single command with the placement information + submit to all the contexts with a command which moves the tails in LRCs for us. We really don't need to bake any of this into the DRM scheduler for GuC submission. Execlists is different story but I think our plan is to do the minimum possible to plum that into the DRM scheduler (e.g. leave the balanced / bonded code in the backend). Could we update the DRM scheduler to understand balanced (seems like already does to some extent) and bonded? Yes we could but IMO the ROI on that is low for Intel. The DRM scheduler is quite clean at the moment compared to our near incomprehensible execlist backend. Execlists are basically a legacy interface so pushing features which are only required for that backend to the DRM scheduler doesn't make sense to me. That being said, if this is something AMD needs in the DRM scheduler of course we can support you. Matt > Regards, > Christian. > > > > > So, to sum up, I think there's likely some good collaboration to be > > had here for everyone. :-) > > > > --Jason > > > > > > > Sure, I've done a quick PoC internally and have been able to hook this > > > > > into the DRM scheduler. > > > > > > > > > > Basically each BB still maps to a single job as each job is somewhat > > > > > unique (e.g. each job has its own ring, lrc, seqno, etc...). However > > > > > all > > > > > the j
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4
== Series Details == Series: drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4 URL : https://patchwork.freedesktop.org/series/90102/ State : success == Summary == CI Bug Log - changes from CI_DRM_10074_full -> Patchwork_20115_full Summary --- **SUCCESS** No regressions found. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20115_full: ### Piglit changes ### Possible regressions * spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t (NEW): - {pig-icl-1065g7}: NOTRUN -> [CRASH][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/pig-icl-1065g7/spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t.html * spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if (NEW): - {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][2] +7 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/pig-icl-1065g7/spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if.html New tests - New tests have been introduced between CI_DRM_10074_full and Patchwork_20115_full: ### New Piglit tests (9) ### * spec@arb_gpu_shader_int64@execution@built-in-functions@cs-min-i64vec2-i64vec2: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_int64@execution@built-in-functions@cs-op-mult-i64vec3-i64vec3: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t: - Statuses : 1 crash(s) - Exec time: [0.76] s * spec@arb_gpu_shader_int64@execution@built-in-functions@gs-max-i64vec3-i64vec3: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_int64@execution@built-in-functions@gs-op-mult-i64vec4-i64vec4: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-mod-u64vec2-uint64_t: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_int64@execution@built-in-functions@vs-op-add-uint64_t-u64vec2: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_int64@execution@built-in-functions@vs-op-bitxor-uint64_t-uint64_t: - Statuses : 1 incomplete(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_20115_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@blit-noreloc-purge-cache-random: - shard-apl: NOTRUN -> [DMESG-FAIL][3] ([i915#3457]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-apl7/igt@api_intel...@blit-noreloc-purge-cache-random.html * igt@api_intel_bb@intel-bb-blit-none: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#3471]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-glk5/igt@api_intel...@intel-bb-blit-none.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-glk4/igt@api_intel...@intel-bb-blit-none.html * igt@api_intel_bb@offset-control: - shard-skl: NOTRUN -> [DMESG-WARN][6] ([i915#3457]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-skl8/igt@api_intel...@offset-control.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +5 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_eio@unwedge-stress: - shard-skl: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#3063] / [i915#3457]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-skl7/igt@gem_...@unwedge-stress.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-skl9/igt@gem_...@unwedge-stress.html - shard-snb: NOTRUN -> [FAIL][10] ([i915#3354] / [i915#3457]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-snb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-apl: [PASS][11] -> [FAIL][12] ([i915#3457]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-apl3/igt@gem_exec_fair@basic-none-r...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-apl2/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@bcs0: - shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3457]) [13]: https://intel-gfx-ci.01.org/tree/dr
Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On Thu, May 20, 2021 at 09:44:59PM +0200, Daniel Vetter wrote: > On Thu, May 20, 2021 at 08:10:59AM -0700, Matthew Brost wrote: > > On Thu, May 20, 2021 at 11:54:25AM +0200, Daniel Vetter wrote: > > > On Wed, May 19, 2021 at 7:19 PM Matthew Brost > > > wrote: > > > > > > > > On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote: > > > > > On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote: > > > > > > Add entry fpr i915 new parallel submission uAPI plan. > > > > > > > > > > > > v2: > > > > > > (Daniel Vetter): > > > > > > - Expand logical order explaination > > > > > > - Add dummy header > > > > > > - Only allow N BBs in execbuf IOCTL > > > > > > - Configure parallel submission per slot not per gem context > > > > > > > > > > > > Cc: Tvrtko Ursulin > > > > > > Cc: Tony Ye > > > > > > CC: Carl Zhang > > > > > > Cc: Daniel Vetter > > > > > > Cc: Jason Ekstrand > > > > > > Signed-off-by: Matthew Brost > > > > > > --- > > > > > > Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 > > > > > > ++ > > > > > > Documentation/gpu/rfc/i915_scheduler.rst | 53 ++- > > > > > > 2 files changed, 196 insertions(+), 1 deletion(-) > > > > > > create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h > > > > > > > > > > > > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h > > > > > > b/Documentation/gpu/rfc/i915_parallel_execbuf.h > > > > > > new file mode 100644 > > > > > > index ..8c64b983ccad > > > > > > --- /dev/null > > > > > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h > > > > > > @@ -0,0 +1,144 @@ > > > > > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see > > > > > > i915_context_engines_parallel_submit */ > > > > > > + > > > > > > +/* > > > > > > + * i915_context_engines_parallel_submit: > > > > > > + * > > > > > > + * Setup a slot to allow multiple BBs to be submitted in a single > > > > > > execbuf IOCTL. > > > > > > + * Those BBs will then be scheduled to run on the GPU in parallel. > > > > > > Multiple > > > > > > + * hardware contexts are created internally in the i915 run these > > > > > > BBs. Once a > > > > > > + * slot is configured for N BBs only N BBs can be submitted in > > > > > > each execbuf > > > > > > + * IOCTL and this is implict behavior (e.g. the user doesn't tell > > > > > > the execbuf > > > > > > + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs > > > > > > there are based on > > > > > > + * the slots configuration). > > > > > > + * > > > > > > + * Their are two currently defined ways to control the placement > > > > > > of the > > > > > > + * hardware contexts on physical engines: default behavior (no > > > > > > flags) and > > > > > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added > > > > > > the in the > > > > > > + * future as new hardware / use cases arise. Details of how to use > > > > > > this > > > > > > + * interface below above the flags. > > > > > > + * > > > > > > + * Returns -EINVAL if hardware context placement configuration > > > > > > invalid or if the > > > > > > + * placement configuration isn't supported on the platform / > > > > > > submission > > > > > > + * interface. > > > > > > + * Returns -ENODEV if extension isn't supported on the platform / > > > > > > submission > > > > > > + * inteface. > > > > > > + */ > > > > > > +struct i915_context_engines_parallel_submit { > > > > > > + struct i915_user_extension base; > > > > > > + > > > > > > + __u16 engine_index; /* slot for parallel engine */ > > > > > > + __u16 width;/* number of contexts per parallel > > > > > > engine */ > > > > > > + __u16 num_siblings; /* number of siblings per context */ > > > > > > + __u16 mbz16; > > > > > > > > > > Ok the big picture looks reasonable now, the flags still confuse me. > > > > > > > > > > > > > Yea, it is a bit confusing. > > > > > > > > > > +/* > > > > > > + * Default placement behvavior (currently unsupported): > > > > > > + * > > > > > > + * Rather than restricting parallel submission to a single class > > > > > > with a > > > > > > + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), > > > > > > add a mode that > > > > > > + * enables parallel submission across multiple engine classes. In > > > > > > this case each > > > > > > + * context's logical engine mask indicates where that context can > > > > > > placed. It is > > > > > > + * implied in this mode that all contexts have mutual exclusive > > > > > > placement (e.g. > > > > > > + * if one context is running CS0 no other contexts can run on CS0). > > > > > > + * > > > > > > + * Example 1 pseudo code: > > > > > > + * CSX[Y] = engine class X, logical instance Y > > > > > > + * INVALID = I915_ENGINE_CLASS_INVALID, > > > > > > I915_ENGINE_CLASS_INVALID_NONE > > > > > > + * set_engines(INVALID) > > > > > > + * set_parallel(engine_index=0, width=2, num_siblings=2, > > > > > > + * engines=CS0[0],CS0[1],CS1[0],CS1[1])
Re: [Intel-gfx] [CI 3/5] drm/i915/dmc: Rename macro names containing csr
> -Original Message- > From: Jani Nikula > Sent: Friday, May 21, 2021 12:45 AM > To: De Marchi, Lucas ; Srivatsa, Anusha > > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [CI 3/5] drm/i915/dmc: Rename macro names > containing csr > > On Tue, 18 May 2021, Lucas De Marchi wrote: > > On Tue, May 18, 2021 at 02:34:42PM -0700, Anusha Srivatsa wrote: > >>Rename all occurences of CSR_* with DMC_* > >> > >>Cc: Jani Nikula > >>Signed-off-by: Anusha Srivatsa > > > > > > Reviewed-by: Lucas De Marchi > > We failed to take GVT into account, and apparently neither CI or Anusha has > CONFIG_DRM_I915_GVT=y. They use the register definitions, and this broke > the build. > > Anusha, please enable the config, and fix the fallout. Cc: the patch to GVT > folks for ack. On it. Anusha > > > Thanks, > Jani. > > > > > > > Lucas De Marchi > > > >>--- > >> drivers/gpu/drm/i915/display/intel_csr.c | 167 +- > >> drivers/gpu/drm/i915/display/intel_csr.h | 6 +- > >> .../drm/i915/display/intel_display_debugfs.c | 16 +- > >> .../drm/i915/display/intel_display_power.c| 14 +- > >> drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- > >> drivers/gpu/drm/i915/i915_reg.h | 28 +-- > >> 6 files changed, 117 insertions(+), 118 deletions(-) > >> > >>diff --git a/drivers/gpu/drm/i915/display/intel_csr.c > >>b/drivers/gpu/drm/i915/display/intel_csr.c > >>index 5ed286dc6720..f2124796ce77 100644 > >>--- a/drivers/gpu/drm/i915/display/intel_csr.c > >>+++ b/drivers/gpu/drm/i915/display/intel_csr.c > >>@@ -30,10 +30,9 @@ > >> #include "intel_de.h" > >> > >> /** > >>- * DOC: csr support for dmc > >>+ * DOC: DMC firmware support > >> * > >>- * Display Context Save and Restore (CSR) firmware support added from > >>gen9 > >>- * onwards to drive newly added DMC (Display microcontroller) in > >>display > >>+ * From gen9 onwards we have newly added DMC (Display > >>+ microcontroller) in display > >> * engine to save and restore the state of display engine when it > >>enter into > >> * low-power state and comes back to normal. > >> */ > >>@@ -44,55 +43,55 @@ > >>__stringify(major) "_" \ > >>__stringify(minor) ".bin" > >> > >>-#define GEN12_CSR_MAX_FW_SIZE ICL_CSR_MAX_FW_SIZE > >>+#define GEN12_DMC_MAX_FW_SIZE > ICL_DMC_MAX_FW_SIZE > >> > >>-#define ADLS_CSR_PATH DMC_PATH(adls, 2, 01) > >>-#define ADLS_CSR_VERSION_REQUIRED CSR_VERSION(2, 1) > >>-MODULE_FIRMWARE(ADLS_CSR_PATH); > >>+#define ADLS_DMC_PATH DMC_PATH(adls, 2, 01) > >>+#define ADLS_DMC_VERSION_REQUIRED DMC_VERSION(2, 1) > >>+MODULE_FIRMWARE(ADLS_DMC_PATH); > >> > >>-#define DG1_CSR_PATH DMC_PATH(dg1, 2, 02) > >>-#define DG1_CSR_VERSION_REQUIRED CSR_VERSION(2, 2) > >>-MODULE_FIRMWARE(DG1_CSR_PATH); > >>+#define DG1_DMC_PATH DMC_PATH(dg1, 2, 02) > >>+#define DG1_DMC_VERSION_REQUIRED DMC_VERSION(2, 2) > >>+MODULE_FIRMWARE(DG1_DMC_PATH); > >> > >>-#define RKL_CSR_PATH DMC_PATH(rkl, 2, 02) > >>-#define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 2) > >>-MODULE_FIRMWARE(RKL_CSR_PATH); > >>+#define RKL_DMC_PATH DMC_PATH(rkl, 2, 02) > >>+#define RKL_DMC_VERSION_REQUIRED DMC_VERSION(2, 2) > >>+MODULE_FIRMWARE(RKL_DMC_PATH); > >> > >>-#define TGL_CSR_PATH DMC_PATH(tgl, 2, 08) > >>-#define TGL_CSR_VERSION_REQUIRED CSR_VERSION(2, 8) > >>-MODULE_FIRMWARE(TGL_CSR_PATH); > >>+#define TGL_DMC_PATH DMC_PATH(tgl, 2, 08) > >>+#define TGL_DMC_VERSION_REQUIRED DMC_VERSION(2, 8) > >>+MODULE_FIRMWARE(TGL_DMC_PATH); > >> > >>-#define ICL_CSR_PATH DMC_PATH(icl, 1, 09) > >>-#define ICL_CSR_VERSION_REQUIRED CSR_VERSION(1, 9) > >>-#define ICL_CSR_MAX_FW_SIZE0x6000 > >>-MODULE_FIRMWARE(ICL_CSR_PATH); > >>+#define ICL_DMC_PATH DMC_PATH(icl, 1, 09) > >>+#define ICL_DMC_VERSION_REQUIRED DMC_VERSION(1, 9) > >>+#define ICL_DMC_MAX_FW_SIZE0x6000 > >>+MODULE_FIRMWARE(ICL_DMC_PATH); > >> > >>-#define CNL_CSR_PATH DMC_PATH(cnl, 1, 07) > >>-#define CNL_CSR_VERSION_REQUIRED CSR_VERSION(1, 7) > >>-#define CNL_CSR_MAX_FW_SIZEGLK_CSR_MAX_FW_SIZE > >>-MODULE_FIRMWARE(CNL_CSR_PATH); > >>+#define CNL_DMC_PATH DMC_PATH(cnl, 1, 07) > >>+#define CNL_DMC_VERSION_REQUIRED DMC_VERSION(1, 7) > >>+#define CNL_DMC_MAX_FW_SIZEGLK_DMC_MAX_FW_SIZE > >>+MODULE_FIRMWARE(CNL_DMC_PATH); > >> > >>-#define GLK_CSR_PATH DMC_PATH(glk, 1, 04) > >>-#define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 4) > >>-#define GLK_CSR_MAX_FW_SIZE0x4000 > >>-MODULE_FIRMWARE(GLK_CSR_PATH); > >>+#define GLK_DMC_PATH DMC_PATH(glk, 1, 04) > >>+#define GLK_DMC_VERSION_REQUIRED DMC_VERSION(1, 4) > >>+#define GLK_DMC_MAX_FW_SIZE0x4000 > >>+MO
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4
Re-reported. -Original Message- From: Deak, Imre Sent: Friday, May 21, 2021 7:33 AM To: intel-gfx@lists.freedesktop.org; Casey Harkins ; Almahallawy, Khaled ; Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4 On Thu, May 13, 2021 at 11:23:41PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4 > URL : https://patchwork.freedesktop.org/series/90102/ > State : failure Pushed to drm-intel-next, thanks for the report, testing and review. The failures are unrelated see below. > == Summary == > > CI Bug Log - changes from CI_DRM_10074_full -> Patchwork_20115_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20115_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20115_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_20115_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_draw_crc@draw-method-xrgb-blt-untiled: > - shard-skl: NOTRUN -> [FAIL][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-skl8/ig > t@kms_draw_...@draw-method-xrgb-blt-untiled.html > > * igt@kms_flip_tiling@flip-changes-tiling@hdmi-a-1-pipe-c: > - shard-glk: [PASS][2] -> [FAIL][3] +1 similar issue >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-glk8/igt@kms_flip_tiling@flip-changes-til...@hdmi-a-1-pipe-c.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-glk6/ig > t@kms_flip_tiling@flip-changes-til...@hdmi-a-1-pipe-c.html > > * igt@kms_plane_cursor@pipe-b-primary-size-256: > - shard-snb: NOTRUN -> [FAIL][4] >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-snb5/ig > t@kms_plane_cur...@pipe-b-primary-size-256.html On all the above platforms the LTTPR detection is disabled, so the change is unrelevant on them. All the logs have the x86/PAT: gem_mmap_offset:1163 map pfn RAM range req write-combining for [mem 0x11d278000-0x11d278fff], got write-back message, so the failures could be related to that. > Suppressed > > The following results come from untrusted machines, tests, or statuses. > They do not affect the overall result. > > * {igt@kms_plane@plane-position-hole@pipe-a-planes}: > - shard-glk: [FAIL][5] ([i915#3457]) -> [FAIL][6] >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10074/shard-glk9/igt@kms_plane@plane-position-h...@pipe-a-planes.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/shard-glk8/ig > t@kms_plane@plane-position-h...@pipe-a-planes.html > > > > ### Piglit changes ### > > Possible regressions > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t > (NEW): > - {pig-icl-1065g7}: NOTRUN -> [CRASH][7] >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/pig-icl-1065g > 7/spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint > 64_t-uint64_t.html > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if > (NEW): > - {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][8] +7 similar issues >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20115/pig-icl-1065g > 7/spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uin > t64_t-uint64_t-using-if.html > > > New tests > - > > New tests have been introduced between CI_DRM_10074_full and > Patchwork_20115_full: > > ### New Piglit tests (9) ### > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@cs-min-i64vec2-i64vec2: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@cs-op-mult-i64vec3-i64vec3: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-ne-uint64_t-uint64_t: > - Statuses : 1 crash(s) > - Exec time: [0.76] s > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@gs-max-i64vec3-i64vec3: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@gs-op-mult-i64vec4-i64vec4: > - Statuses : 1 incomplete(s) > - Exec time: [0.0] s > > * > spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-gt-uint64_t-uint64_t-using-if: > - Statuses : 1 incomplete(s) > - Exec t
Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On Thu, May 20, 2021 at 09:41:20PM +0200, Daniel Vetter wrote: > On Thu, May 20, 2021 at 11:57:44AM +0100, Tvrtko Ursulin wrote: > > > > On 20/05/2021 10:54, Daniel Vetter wrote: > > > On Wed, May 19, 2021 at 7:19 PM Matthew Brost > > > wrote: > > > > > > > > On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote: > > > > > On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote: > > > > > > Add entry fpr i915 new parallel submission uAPI plan. > > > > > > > > > > > > v2: > > > > > > (Daniel Vetter): > > > > > >- Expand logical order explaination > > > > > >- Add dummy header > > > > > >- Only allow N BBs in execbuf IOCTL > > > > > >- Configure parallel submission per slot not per gem context > > > > > > > > > > > > Cc: Tvrtko Ursulin > > > > > > Cc: Tony Ye > > > > > > CC: Carl Zhang > > > > > > Cc: Daniel Vetter > > > > > > Cc: Jason Ekstrand > > > > > > Signed-off-by: Matthew Brost > > > > > > --- > > > > > > Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 > > > > > > ++ > > > > > > Documentation/gpu/rfc/i915_scheduler.rst | 53 ++- > > > > > > 2 files changed, 196 insertions(+), 1 deletion(-) > > > > > > create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h > > > > > > > > > > > > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h > > > > > > b/Documentation/gpu/rfc/i915_parallel_execbuf.h > > > > > > new file mode 100644 > > > > > > index ..8c64b983ccad > > > > > > --- /dev/null > > > > > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h > > > > > > @@ -0,0 +1,144 @@ > > > > > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see > > > > > > i915_context_engines_parallel_submit */ > > > > > > + > > > > > > +/* > > > > > > + * i915_context_engines_parallel_submit: > > > > > > + * > > > > > > + * Setup a slot to allow multiple BBs to be submitted in a single > > > > > > execbuf IOCTL. > > > > > > + * Those BBs will then be scheduled to run on the GPU in parallel. > > > > > > Multiple > > > > > > + * hardware contexts are created internally in the i915 run these > > > > > > BBs. Once a > > > > > > + * slot is configured for N BBs only N BBs can be submitted in > > > > > > each execbuf > > > > > > + * IOCTL and this is implict behavior (e.g. the user doesn't tell > > > > > > the execbuf > > > > > > + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs > > > > > > there are based on > > > > > > + * the slots configuration). > > > > > > + * > > > > > > + * Their are two currently defined ways to control the placement > > > > > > of the > > > > > > + * hardware contexts on physical engines: default behavior (no > > > > > > flags) and > > > > > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added > > > > > > the in the > > > > > > + * future as new hardware / use cases arise. Details of how to use > > > > > > this > > > > > > + * interface below above the flags. > > > > > > + * > > > > > > + * Returns -EINVAL if hardware context placement configuration > > > > > > invalid or if the > > > > > > + * placement configuration isn't supported on the platform / > > > > > > submission > > > > > > + * interface. > > > > > > + * Returns -ENODEV if extension isn't supported on the platform / > > > > > > submission > > > > > > + * inteface. > > > > > > + */ > > > > > > +struct i915_context_engines_parallel_submit { > > > > > > + struct i915_user_extension base; > > > > > > + > > > > > > + __u16 engine_index; /* slot for parallel engine */ > > > > > > + __u16 width;/* number of contexts per parallel > > > > > > engine */ > > > > > > + __u16 num_siblings; /* number of siblings per context */ > > > > > > + __u16 mbz16; > > > > > > > > > > Ok the big picture looks reasonable now, the flags still confuse me. > > > > > > > > > > > > > Yea, it is a bit confusing. > > > > > > > > > > +/* > > > > > > + * Default placement behvavior (currently unsupported): > > > > > > + * > > > > > > + * Rather than restricting parallel submission to a single class > > > > > > with a > > > > > > + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), > > > > > > add a mode that > > > > > > + * enables parallel submission across multiple engine classes. In > > > > > > this case each > > > > > > + * context's logical engine mask indicates where that context can > > > > > > placed. It is > > > > > > + * implied in this mode that all contexts have mutual exclusive > > > > > > placement (e.g. > > > > > > + * if one context is running CS0 no other contexts can run on CS0). > > > > > > + * > > > > > > + * Example 1 pseudo code: > > > > > > + * CSX[Y] = engine class X, logical instance Y > > > > > > + * INVALID = I915_ENGINE_CLASS_INVALID, > > > > > > I915_ENGINE_CLASS_INVALID_NONE > > > > > > + * set_engines(INVALID) > > > > > > + * set_parallel(engine_index=0, width=2, num_siblings=2, > > > > > > + * engines=CS0[0],CS0[1],CS1[0],CS1[1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move LMEM (VRAM) management over to TTM (rev3)
== Series Details == Series: drm/i915: Move LMEM (VRAM) management over to TTM (rev3) URL : https://patchwork.freedesktop.org/series/90022/ State : success == Summary == CI Bug Log - changes from CI_DRM_10120 -> Patchwork_20170 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/index.html Known issues Here are the changes found in Patchwork_20170 that come from known issues: ### IGT changes ### Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [FAIL][1] ([i915#1372]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u2: [FAIL][3] ([i915#49]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html Warnings * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [INCOMPLETE][5] ([i915#2782] / [i915#2940] / [i915#3462]) -> [DMESG-FAIL][6] ([i915#3462]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-skl-6600u: [FAIL][7] ([i915#1436] / [i915#3363]) -> [FAIL][8] ([i915#1436] / [i915#2426] / [i915#3363]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-skl-6600u/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-skl-6600u/igt@run...@aborted.html - fi-bdw-5557u: [FAIL][9] ([i915#3462]) -> [FAIL][10] ([i915#1602] / [i915#2029]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-bdw-5557u/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-bdw-5557u/igt@run...@aborted.html - fi-kbl-soraka: [FAIL][11] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][12] ([i915#1436] / [i915#3363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-soraka/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-kbl-soraka/igt@run...@aborted.html - fi-cml-u2: [FAIL][13] ([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462]) -> [FAIL][14] ([i915#3363] / [i915#3462]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cml-u2/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20170/fi-cml-u2/igt@run...@aborted.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029 [i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966 [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012 [i915#3276]: https://gitlab.freedesktop.org/drm/intel/issues/3276 [i915#3277]: https://gitlab.freedesktop.org/drm/intel/issues/3277 [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282 [i915#3283]: https://gitlab.freedesktop.org/drm/intel/issues/3283 [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291 [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363 [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462 [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (41 -> 39) -- Additional (1): fi-rkl-11500t Missing(3): fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux
Re: [Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On Fri, May 21, 2021 at 01:00:54PM +0100, Tvrtko Ursulin wrote: > > On 19/05/2021 00:58, Matthew Brost wrote: > > Add entry fpr i915 new parallel submission uAPI plan. > > > > v2: > > (Daniel Vetter): > >- Expand logical order explaination > >- Add dummy header > >- Only allow N BBs in execbuf IOCTL > >- Configure parallel submission per slot not per gem context > > > > Cc: Tvrtko Ursulin > > Cc: Tony Ye > > CC: Carl Zhang > > Cc: Daniel Vetter > > Cc: Jason Ekstrand > > Signed-off-by: Matthew Brost > > --- > > Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++ > > Documentation/gpu/rfc/i915_scheduler.rst | 53 ++- > > 2 files changed, 196 insertions(+), 1 deletion(-) > > create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h > > > > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h > > b/Documentation/gpu/rfc/i915_parallel_execbuf.h > > new file mode 100644 > > index ..8c64b983ccad > > --- /dev/null > > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h > > @@ -0,0 +1,144 @@ > > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see > > i915_context_engines_parallel_submit */ > > + > > +/* > > + * i915_context_engines_parallel_submit: > > + * > > + * Setup a slot to allow multiple BBs to be submitted in a single execbuf > > IOCTL. > > + * Those BBs will then be scheduled to run on the GPU in parallel. Multiple > > + * hardware contexts are created internally in the i915 run these BBs. > > Once a > > + * slot is configured for N BBs only N BBs can be submitted in each execbuf > > + * IOCTL and this is implict behavior (e.g. the user doesn't tell the > > execbuf > > + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are > > based on > > + * the slots configuration). > > 1) > Expand the term slot here with "slot in the context engine map" least once > for clarity. > Sure. > 2) > About where execbuf will implicitly be finding batches - suggest to also > cover first/last flag here. I know you have it in the readme but I think it > is good if uapi header is as self-contained as possible. > Yep, good idea. > > + * > > + * Their are two currently defined ways to control the placement of the > > + * hardware contexts on physical engines: default behavior (no flags) and > > + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in the > > + * future as new hardware / use cases arise. Details of how to use this > > + * interface below above the flags. > > + * > > + * Returns -EINVAL if hardware context placement configuration invalid or > > if the > > + * placement configuration isn't supported on the platform / submission > > + * interface. > > + * Returns -ENODEV if extension isn't supported on the platform / > > submission > > + * inteface. > > + */ > > +struct i915_context_engines_parallel_submit { > > + struct i915_user_extension base; > > + > > + __u16 engine_index; /* slot for parallel engine */ > > + __u16 width;/* number of contexts per parallel engine */ > > + __u16 num_siblings; /* number of siblings per context */ > > + __u16 mbz16; > > +/* > > + * Default placement behvavior (currently unsupported): > > + * > > + * Rather than restricting parallel submission to a single class with a > > + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a > > mode that > > What do you mean with logically contiguous here? It sounds ambiguous versus > logical vs "normal" engine instance numbers. > This is a little backwards. I think when I wrote this originally the implicit placement comments were first. I can reword this. > > + * enables parallel submission across multiple engine classes. In this > > case each > > + * context's logical engine mask indicates where that context can placed. > > It is > > + * implied in this mode that all contexts have mutual exclusive placement > > (e.g. > > + * if one context is running CS0 no other contexts can run on CS0). > > I think talk about logical context and its mask is too implementation detail > at the uapi level. Instead I would suggest more userspace programmer centric > description. Ok, can you give me suggestion? Writing DOC isn't really my strength. > > > + * > > + * Example 1 pseudo code: > > + * CSX[Y] = engine class X, logical instance Y > > + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE > > + * set_engines(INVALID) > > + * set_parallel(engine_index=0, width=2, num_siblings=2, > > + * engines=CS0[0],CS0[1],CS1[0],CS1[1]) > > + * > > + * Results in the following valid placements: > > + * CS0[0], CS1[0] > > + * CS0[0], CS1[1] > > + * CS0[1], CS1[0] > > + * CS0[1], CS1[1] > > + * > > + * This can also be though of as 2 virtual engines: > > + * VE[0] = CS0[0], CS0[1] > > + * VE[1] = CS1[0], CS1[1] > > Ah okay so essentially similar to what I was proposing a year ago. But then > it is no longer "set_parallel" really. It is one slot in th
Re: [Intel-gfx] [PATCH] drm/i915/display: fix typo when returning table
Reviewed-by: Anusha Srivatsa > -Original Message- > From: De Marchi, Lucas > Sent: Thursday, May 20, 2021 5:52 PM > To: intel-gfx@lists.freedesktop.org > Cc: Srivatsa, Anusha > Subject: [PATCH] drm/i915/display: fix typo when returning table > > Fix table returned when port_clock > 27: > > drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c:752:47: error: > variable 'adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3' is not needed and will not > be emitted [-Werror,-Wunneeded-internal-declaration] > static const struct tgl_dkl_phy_ddi_buf_trans > adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3[] = { > > Initial version of the patch had it in a single table, but on second version > the > table got split, but we continued to reference just one of them. > > Fixes: ca962882268a ("drm/i915/adl_p: Define and use ADL-P specific DP > translation tables") > Reported-by: kernel test robot > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c > b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c > index ce5d5d13b7c1..8bfd00f49f2a 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c > @@ -1383,7 +1383,7 @@ adlp_get_dkl_buf_trans_dp(struct intel_encoder > *encoder, { > if (crtc_state->port_clock > 27) { > *n_entries = > ARRAY_SIZE(adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3); > - return adlp_dkl_phy_dp_ddi_trans_hbr; > + return adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3; > } > > *n_entries = ARRAY_SIZE(adlp_dkl_phy_dp_ddi_trans_hbr); > -- > 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gvt: Add missing macro name changes
Propogate changes to macros name containing CSR_* to DMC_* from display side. Fixes: 0633cdcbaa77 ("drm/i915/dmc: Rename macro names containing csr") Cc: intel-gvt-...@lists.freedesktop.org Cc: Jani Nikula Cc: Lucas De Marchi Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/gvt/handlers.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/handlers.c b/drivers/gpu/drm/i915/gvt/handlers.c index dda320749c65..33496397a74f 100644 --- a/drivers/gpu/drm/i915/gvt/handlers.c +++ b/drivers/gpu/drm/i915/gvt/handlers.c @@ -3342,9 +3342,9 @@ static int init_skl_mmio_info(struct intel_gvt *gvt) MMIO_D(_MMIO(_PLANE_SURF_3_A), D_SKL_PLUS); MMIO_D(_MMIO(_PLANE_SURF_3_B), D_SKL_PLUS); - MMIO_D(CSR_SSP_BASE, D_SKL_PLUS); - MMIO_D(CSR_HTP_SKL, D_SKL_PLUS); - MMIO_D(CSR_LAST_WRITE, D_SKL_PLUS); + MMIO_D(DMC_SSP_BASE, D_SKL_PLUS); + MMIO_D(DMC_HTP_SKL, D_SKL_PLUS); + MMIO_D(DMC_LAST_WRITE, D_SKL_PLUS); MMIO_DFH(BDW_SCRATCH1, D_SKL_PLUS, F_CMD_ACCESS, NULL, NULL); @@ -3655,7 +3655,7 @@ void intel_gvt_clean_mmio_info(struct intel_gvt *gvt) * otherwise, need to update cmd_reg_handler in cmd_parser.c */ static struct gvt_mmio_block mmio_blocks[] = { - {D_SKL_PLUS, _MMIO(CSR_MMIO_START_RANGE), 0x3000, NULL, NULL}, + {D_SKL_PLUS, _MMIO(DMC_MMIO_START_RANGE), 0x3000, NULL, NULL}, {D_ALL, _MMIO(MCHBAR_MIRROR_BASE_SNB), 0x4, NULL, NULL}, {D_ALL, _MMIO(VGT_PVINFO_PAGE), VGT_PVINFO_SIZE, pvinfo_mmio_read, pvinfo_mmio_write}, -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gvt: Add missing macro name changes
== Series Details == Series: drm/i915/gvt: Add missing macro name changes URL : https://patchwork.freedesktop.org/series/90427/ State : warning == Summary == $ dim checkpatch origin/drm-tip 355406594b6b drm/i915/gvt: Add missing macro name changes -:6: WARNING:TYPO_SPELLING: 'Propogate' may be misspelled - perhaps 'Propagate'? #6: Propogate changes to macros name containing CSR_* ^ total: 0 errors, 1 warnings, 0 checks, 20 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gvt: Add missing macro name changes
Propagate changes to macros name containing CSR_* to DMC_* from display side. Cc: intel-gvt-...@lists.freedesktop.org Cc: Jani Nikula Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/gvt/handlers.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/handlers.c b/drivers/gpu/drm/i915/gvt/handlers.c index dda320749c65..33496397a74f 100644 --- a/drivers/gpu/drm/i915/gvt/handlers.c +++ b/drivers/gpu/drm/i915/gvt/handlers.c @@ -3342,9 +3342,9 @@ static int init_skl_mmio_info(struct intel_gvt *gvt) MMIO_D(_MMIO(_PLANE_SURF_3_A), D_SKL_PLUS); MMIO_D(_MMIO(_PLANE_SURF_3_B), D_SKL_PLUS); - MMIO_D(CSR_SSP_BASE, D_SKL_PLUS); - MMIO_D(CSR_HTP_SKL, D_SKL_PLUS); - MMIO_D(CSR_LAST_WRITE, D_SKL_PLUS); + MMIO_D(DMC_SSP_BASE, D_SKL_PLUS); + MMIO_D(DMC_HTP_SKL, D_SKL_PLUS); + MMIO_D(DMC_LAST_WRITE, D_SKL_PLUS); MMIO_DFH(BDW_SCRATCH1, D_SKL_PLUS, F_CMD_ACCESS, NULL, NULL); @@ -3655,7 +3655,7 @@ void intel_gvt_clean_mmio_info(struct intel_gvt *gvt) * otherwise, need to update cmd_reg_handler in cmd_parser.c */ static struct gvt_mmio_block mmio_blocks[] = { - {D_SKL_PLUS, _MMIO(CSR_MMIO_START_RANGE), 0x3000, NULL, NULL}, + {D_SKL_PLUS, _MMIO(DMC_MMIO_START_RANGE), 0x3000, NULL, NULL}, {D_ALL, _MMIO(MCHBAR_MIRROR_BASE_SNB), 0x4, NULL, NULL}, {D_ALL, _MMIO(VGT_PVINFO_PAGE), VGT_PVINFO_SIZE, pvinfo_mmio_read, pvinfo_mmio_write}, -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/gt: Move CS interrupt handler to the backend
From: Chris Wilson The different submission backends each have their own preferred behaviour and interrupt setup. Let each handle their own interrupts. This becomes more useful later as we to extract the use of auxiliary state in the interrupt handler that is backend specific. Signed-off-by: Matthew Brost Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Reviewed-by: Matthew Brost --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 7 ++ drivers/gpu/drm/i915/gt/intel_engine_types.h | 14 +--- .../drm/i915/gt/intel_execlists_submission.c | 41 ++ drivers/gpu/drm/i915/gt/intel_gt_irq.c| 82 ++- drivers/gpu/drm/i915/gt/intel_gt_irq.h| 23 ++ .../gpu/drm/i915/gt/intel_ring_submission.c | 8 ++ drivers/gpu/drm/i915/gt/intel_rps.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 ++- drivers/gpu/drm/i915/i915_irq.c | 10 ++- 9 files changed, 124 insertions(+), 74 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index e54a2a4df87c..3f9a811eb02b 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -255,6 +255,11 @@ static void intel_engine_sanitize_mmio(struct intel_engine_cs *engine) intel_engine_set_hwsp_writemask(engine, ~0u); } +static void nop_irq_handler(struct intel_engine_cs *engine, u16 iir) +{ + GEM_DEBUG_WARN_ON(iir); +} + static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id) { const struct engine_info *info = &intel_engines[id]; @@ -292,6 +297,8 @@ static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id) engine->hw_id = info->hw_id; engine->guc_id = MAKE_GUC_ID(info->class, info->instance); + engine->irq_handler = nop_irq_handler; + engine->class = info->class; engine->instance = info->instance; __sprint_engine_name(engine); diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h b/drivers/gpu/drm/i915/gt/intel_engine_types.h index 883bafc44902..9ef349cd5cea 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h @@ -402,6 +402,7 @@ struct intel_engine_cs { u32 irq_enable_mask; /* bitmask to enable ring interrupt */ void(*irq_enable)(struct intel_engine_cs *engine); void(*irq_disable)(struct intel_engine_cs *engine); + void(*irq_handler)(struct intel_engine_cs *engine, u16 iir); void(*sanitize)(struct intel_engine_cs *engine); int (*resume)(struct intel_engine_cs *engine); @@ -481,10 +482,9 @@ struct intel_engine_cs { #define I915_ENGINE_HAS_PREEMPTION BIT(2) #define I915_ENGINE_HAS_SEMAPHORES BIT(3) #define I915_ENGINE_HAS_TIMESLICES BIT(4) -#define I915_ENGINE_NEEDS_BREADCRUMB_TASKLET BIT(5) -#define I915_ENGINE_IS_VIRTUAL BIT(6) -#define I915_ENGINE_HAS_RELATIVE_MMIO BIT(7) -#define I915_ENGINE_REQUIRES_CMD_PARSER BIT(8) +#define I915_ENGINE_IS_VIRTUAL BIT(5) +#define I915_ENGINE_HAS_RELATIVE_MMIO BIT(6) +#define I915_ENGINE_REQUIRES_CMD_PARSER BIT(7) unsigned int flags; /* @@ -593,12 +593,6 @@ intel_engine_has_timeslices(const struct intel_engine_cs *engine) return engine->flags & I915_ENGINE_HAS_TIMESLICES; } -static inline bool -intel_engine_needs_breadcrumb_tasklet(const struct intel_engine_cs *engine) -{ - return engine->flags & I915_ENGINE_NEEDS_BREADCRUMB_TASKLET; -} - static inline bool intel_engine_is_virtual(const struct intel_engine_cs *engine) { diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index 9d2da5ccaef6..8db200422950 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -118,6 +118,7 @@ #include "intel_engine_stats.h" #include "intel_execlists_submission.h" #include "intel_gt.h" +#include "intel_gt_irq.h" #include "intel_gt_pm.h" #include "intel_gt_requests.h" #include "intel_lrc.h" @@ -2384,6 +2385,45 @@ static void execlists_submission_tasklet(struct tasklet_struct *t) rcu_read_unlock(); } +static void execlists_irq_handler(struct intel_engine_cs *engine, u16 iir) +{ + bool tasklet = false; + + if (unlikely(iir & GT_CS_MASTER_ERROR_INTERRUPT)) { + u32 eir; + + /* Upper 16b are the enabling mask, rsvd for internal errors */ + eir = ENGINE_READ(engine, RING_EIR) & GENMASK(15, 0); + ENGINE_TRACE(engine, "CS error: %x\n", eir); + + /* Disable the error interrupt until after the reset */ + if (likely(eir)) { + ENGINE_WRITE(engine, RING_EMR, ~0u); + ENGINE_WRITE(engine, RING_EIR, eir); + WRITE_ONCE(engine->exe
[Intel-gfx] [PATCH 1/3] drm/i915/gt: Move engine setup out of set_default_submission
From: Chris Wilson Now that we no longer switch back and forth between guc and execlists, we no longer need to restore the backend's vfunc and can leave them set after initialisation. The only catch is that we lose the submission on wedging and still need to reset the submit_request vfunc on unwedging. Signed-off-by: Matthew Brost Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Reviewed-by: Matthew Brost --- .../drm/i915/gt/intel_execlists_submission.c | 46 - .../gpu/drm/i915/gt/intel_ring_submission.c | 4 -- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 50 --- 3 files changed, 44 insertions(+), 56 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index de124870af44..1108c193ab65 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -3076,29 +3076,6 @@ static void execlists_set_default_submission(struct intel_engine_cs *engine) engine->submit_request = execlists_submit_request; engine->schedule = i915_schedule; engine->execlists.tasklet.callback = execlists_submission_tasklet; - - engine->reset.prepare = execlists_reset_prepare; - engine->reset.rewind = execlists_reset_rewind; - engine->reset.cancel = execlists_reset_cancel; - engine->reset.finish = execlists_reset_finish; - - engine->park = execlists_park; - engine->unpark = NULL; - - engine->flags |= I915_ENGINE_SUPPORTS_STATS; - if (!intel_vgpu_active(engine->i915)) { - engine->flags |= I915_ENGINE_HAS_SEMAPHORES; - if (can_preempt(engine)) { - engine->flags |= I915_ENGINE_HAS_PREEMPTION; - if (IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION)) - engine->flags |= I915_ENGINE_HAS_TIMESLICES; - } - } - - if (intel_engine_has_preemption(engine)) - engine->emit_bb_start = gen8_emit_bb_start; - else - engine->emit_bb_start = gen8_emit_bb_start_noarb; } static void execlists_shutdown(struct intel_engine_cs *engine) @@ -3129,6 +3106,14 @@ logical_ring_default_vfuncs(struct intel_engine_cs *engine) engine->cops = &execlists_context_ops; engine->request_alloc = execlists_request_alloc; + engine->reset.prepare = execlists_reset_prepare; + engine->reset.rewind = execlists_reset_rewind; + engine->reset.cancel = execlists_reset_cancel; + engine->reset.finish = execlists_reset_finish; + + engine->park = execlists_park; + engine->unpark = NULL; + engine->emit_flush = gen8_emit_flush_xcs; engine->emit_init_breadcrumb = gen8_emit_init_breadcrumb; engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb_xcs; @@ -3149,6 +3134,21 @@ logical_ring_default_vfuncs(struct intel_engine_cs *engine) * until a more refined solution exists. */ } + + engine->flags |= I915_ENGINE_SUPPORTS_STATS; + if (!intel_vgpu_active(engine->i915)) { + engine->flags |= I915_ENGINE_HAS_SEMAPHORES; + if (can_preempt(engine)) { + engine->flags |= I915_ENGINE_HAS_PREEMPTION; + if (IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION)) + engine->flags |= I915_ENGINE_HAS_TIMESLICES; + } + } + + if (intel_engine_has_preemption(engine)) + engine->emit_bb_start = gen8_emit_bb_start; + else + engine->emit_bb_start = gen8_emit_bb_start_noarb; } static void logical_ring_default_irqs(struct intel_engine_cs *engine) diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c b/drivers/gpu/drm/i915/gt/intel_ring_submission.c index 9585546556ee..5f4f7f1df48f 100644 --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c @@ -989,14 +989,10 @@ static void gen6_bsd_submit_request(struct i915_request *request) static void i9xx_set_default_submission(struct intel_engine_cs *engine) { engine->submit_request = i9xx_submit_request; - - engine->park = NULL; - engine->unpark = NULL; } static void gen6_bsd_set_default_submission(struct intel_engine_cs *engine) { - i9xx_set_default_submission(engine); engine->submit_request = gen6_bsd_submit_request; } 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 92688a9b6717..f72faa0b8339 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -608,35 +608,6 @@ static int guc_resume(struct intel_engine_cs *engine) static void guc_set_default_submission(struct intel_engine_cs *engine) { engine->submit_request = guc_submit_re
[Intel-gfx] [PATCH 0/3] Clean a few backend interfaces in the i915
As discussed in [1] start merging some support patches as a precursor to GuC submission the i915. This is step #1 mentioned in [1]. [1] https://patchwork.freedesktop.org/series/89844/ Signed-off-by: Matthew Brost Chris Wilson (3): drm/i915/gt: Move engine setup out of set_default_submission drm/i915/gt: Move submission_method into intel_gt drm/i915/gt: Move CS interrupt handler to the backend drivers/gpu/drm/i915/gt/intel_engine.h| 8 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 19 +++- drivers/gpu/drm/i915/gt/intel_engine_types.h | 14 +-- .../drm/i915/gt/intel_execlists_submission.c | 95 +-- .../drm/i915/gt/intel_execlists_submission.h | 3 - drivers/gpu/drm/i915/gt/intel_gt_irq.c| 82 +--- drivers/gpu/drm/i915/gt/intel_gt_irq.h| 23 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 ++ drivers/gpu/drm/i915/gt/intel_reset.c | 7 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 12 ++- drivers/gpu/drm/i915/gt/intel_rps.c | 2 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 +- .../drm/i915/gt/selftest_ring_submission.c| 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 64 ++--- .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 1 - drivers/gpu/drm/i915/i915_irq.c | 10 +- drivers/gpu/drm/i915/i915_perf.c | 10 +- 17 files changed, 199 insertions(+), 162 deletions(-) -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/gt: Move submission_method into intel_gt
From: Chris Wilson Since we setup the submission method for the engines once, it is easy to assign an enum and use that instead of probing into the backends. Signed-off-by: Matthew Brost Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Reviewed-by: Matthew Brost --- drivers/gpu/drm/i915/gt/intel_engine.h | 8 +++- drivers/gpu/drm/i915/gt/intel_engine_cs.c| 12 drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 8 drivers/gpu/drm/i915/gt/intel_execlists_submission.h | 3 --- drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 +++ drivers/gpu/drm/i915/gt/intel_reset.c| 7 +++ drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 +- drivers/gpu/drm/i915/gt/selftest_ring_submission.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 5 - drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h| 1 - drivers/gpu/drm/i915/i915_perf.c | 10 +- 11 files changed, 32 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h b/drivers/gpu/drm/i915/gt/intel_engine.h index 47ee8578e511..8d9184920c51 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine.h +++ b/drivers/gpu/drm/i915/gt/intel_engine.h @@ -13,8 +13,9 @@ #include "i915_reg.h" #include "i915_request.h" #include "i915_selftest.h" -#include "gt/intel_timeline.h" #include "intel_engine_types.h" +#include "intel_gt_types.h" +#include "intel_timeline.h" #include "intel_workarounds.h" struct drm_printer; @@ -262,6 +263,11 @@ void intel_engine_init_active(struct intel_engine_cs *engine, #define ENGINE_MOCK1 #define ENGINE_VIRTUAL 2 +static inline bool intel_engine_uses_guc(const struct intel_engine_cs *engine) +{ + return engine->gt->submission_method >= INTEL_SUBMISSION_GUC; +} + static inline bool intel_engine_has_preempt_reset(const struct intel_engine_cs *engine) { diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index eba2da9679a5..e54a2a4df87c 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -909,12 +909,16 @@ int intel_engines_init(struct intel_gt *gt) enum intel_engine_id id; int err; - if (intel_uc_uses_guc_submission(>->uc)) + if (intel_uc_uses_guc_submission(>->uc)) { + gt->submission_method = INTEL_SUBMISSION_GUC; setup = intel_guc_submission_setup; - else if (HAS_EXECLISTS(gt->i915)) + } else if (HAS_EXECLISTS(gt->i915)) { + gt->submission_method = INTEL_SUBMISSION_ELSP; setup = intel_execlists_submission_setup; - else + } else { + gt->submission_method = INTEL_SUBMISSION_RING; setup = intel_ring_submission_setup; + } for_each_engine(engine, gt, id) { err = engine_setup_common(engine); @@ -1479,7 +1483,7 @@ static void intel_engine_print_registers(struct intel_engine_cs *engine, drm_printf(m, "\tIPEHR: 0x%08x\n", ENGINE_READ(engine, IPEHR)); } - if (intel_engine_in_guc_submission_mode(engine)) { + if (intel_engine_uses_guc(engine)) { /* nothing to print yet */ } else if (HAS_EXECLISTS(dev_priv)) { struct i915_request * const *port, *rq; diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index 1108c193ab65..9d2da5ccaef6 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -1768,7 +1768,6 @@ process_csb(struct intel_engine_cs *engine, struct i915_request **inactive) */ GEM_BUG_ON(!tasklet_is_locked(&execlists->tasklet) && !reset_in_progress(execlists)); - GEM_BUG_ON(!intel_engine_in_execlists_submission_mode(engine)); /* * Note that csb_write, csb_status may be either in HWSP or mmio. @@ -3884,13 +3883,6 @@ void intel_execlists_show_requests(struct intel_engine_cs *engine, spin_unlock_irqrestore(&engine->active.lock, flags); } -bool -intel_engine_in_execlists_submission_mode(const struct intel_engine_cs *engine) -{ - return engine->set_default_submission == - execlists_set_default_submission; -} - #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST) #include "selftest_execlists.c" #endif diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h index fd61dae820e9..4ca9b475e252 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h @@ -43,7 +43,4 @@ int intel_virtual_engine_attach_bond(struct intel_engine_cs *engine, const struct intel_engine_cs *master, const struct intel_e
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Add missing macro name changes
== Series Details == Series: drm/i915/gvt: Add missing macro name changes URL : https://patchwork.freedesktop.org/series/90427/ State : success == Summary == CI Bug Log - changes from CI_DRM_10120 -> Patchwork_20171 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/index.html Known issues Here are the changes found in Patchwork_20171 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@hangcheck: - fi-icl-y: [PASS][1] -> [INCOMPLETE][2] ([i915#2782]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-y/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-icl-y/igt@i915_selftest@l...@hangcheck.html Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [FAIL][3] ([i915#1372]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u2: [FAIL][5] ([i915#49]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html Warnings * igt@i915_selftest@live@execlists: - fi-cfl-8109u: [INCOMPLETE][7] ([i915#3462]) -> [DMESG-FAIL][8] ([i915#3462]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html - fi-icl-u2: [INCOMPLETE][9] ([i915#2782] / [i915#3462]) -> [DMESG-FAIL][10] ([i915#3462]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@i915_selftest@l...@execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-icl-u2/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-cfl-8700k: [FAIL][11] ([i915#3363]) -> [FAIL][12] ([i915#2426] / [i915#3363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-8700k/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-cfl-8700k/igt@run...@aborted.html - fi-cfl-8109u: [FAIL][13] ([i915#3363]) -> [FAIL][14] ([i915#2426] / [i915#3363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-8109u/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-cfl-8109u/igt@run...@aborted.html - fi-icl-u2: [FAIL][15] ([i915#2782] / [i915#3363]) -> [FAIL][16] ([i915#2426] / [i915#2782] / [i915#3363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-icl-u2/igt@run...@aborted.html - fi-glk-dsi: [FAIL][17] ([i915#2426] / [i915#3363] / [k.org#202321]) -> [FAIL][18] ([i915#3363] / [k.org#202321]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-glk-dsi/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-glk-dsi/igt@run...@aborted.html - fi-bdw-5557u: [FAIL][19] ([i915#3462]) -> [FAIL][20] ([i915#1602] / [i915#2029]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-bdw-5557u/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-bdw-5557u/igt@run...@aborted.html - fi-kbl-guc: [FAIL][21] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][22] ([i915#1436] / [i915#3363]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-guc/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-kbl-guc/igt@run...@aborted.html - fi-cfl-guc: [FAIL][23] ([i915#3363]) -> [FAIL][24] ([i915#2426] / [i915#3363]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-guc/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-cfl-guc/igt@run...@aborted.html - fi-skl-6700k2: [FAIL][25] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][26] ([i915#1436] / [i915#3363]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-skl-6700k2/igt@run...@aborted.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20171/fi-skl-6700k2/igt@run...@aborted.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.fre
Re: [Intel-gfx] [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
Am 21.05.21 um 17:16 schrieb Daniel Vetter: On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote: On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote: On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote: On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote: --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 88a24a0b5691..cc8426e1e8a8 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -617,8 +617,8 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p, amdgpu_bo_list_for_each_entry(e, p->bo_list) { struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo); - /* Make sure we use the exclusive slot for shared BOs */ - if (bo->prime_shared_count) + /* Make sure we use the exclusive slot for all potentially shared BOs */ + if (!(bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)) e->tv.num_shared = 0; I think it also makes sense to skip this with AMDGPU_GEM_CREATE_EXPLICIT_SYNC? It can be shared but I don't think anyone expects implicit sync to happen with those. Ah yes, I missed this entirely. So the "no implicit flag" is already there, and the _only_ thing that's missing really is a way to fish out the implicit fences, and set them. https://lore.kernel.org/dri-devel/20210520190007.534046-1-ja...@jlekstrand.net/ So I think all that's really needed in radv is not setting RADEON_FLAG_IMPLICIT_SYNC for winsys buffers when Jason's dma-buf ioctl are present (means you need to do some import/export and keep the fd around for winsys buffers, but shouldn't be too bad), and then control the implicit fences entirely explicitly like vk expects. That is the part I'm less sure about. This is a BO wide flag so we are also disabling implicit sync in the compositor. If the compositor does only do read stuff that is ok, as the inserted exclusive fence will work for that. But as I learned recently the app provided buffer may end up being written to by the X server which open a whole can of potential problems if implicit sync gets disabled between Xserver operations on the app provided buffer. Hence setting that on the WSI buffer is a whole new can of potential problems and hence I've said a submission based flag would be preferred. I can certainly try it out though. Hm yeah that's the wrong flag. We need a flag on the drm_file which the explicit userspace sets. And which is valid only for itself. There's a nice flags field when creating a ctx, but it's not validated and there's already a comment that we have to filter out garbage priority, so that's not use. I'll whip up something entirely untested just as a draft. We could provide an IOCTL for the BO to change the flag. But could we first figure out the semantics we want to use here? Cause I'm pretty sure we don't actually need those changes at all and as said before I'm certainly NAKing things which break existing use cases. Regards, Christian. -Daniel Are you bored enough to type this up for radv? I'll give Jason's kernel stuff another review meanwhile. -Daniel e->bo_va = amdgpu_vm_bo_find(vm, bo); } -- 2.31.0 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default
Dne petek, 21. maj 2021 ob 11:09:54 CEST je Daniel Vetter napisal(a): > No need to set it explicitly. > > Signed-off-by: Daniel Vetter > Cc: Laurentiu Palcu > Cc: Lucas Stach > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: Philipp Zabel > Cc: Paul Cercueil > Cc: Chun-Kuang Hu > Cc: Matthias Brugger > Cc: Neil Armstrong > Cc: Kevin Hilman > Cc: Jerome Brunet > Cc: Martin Blumenstingl > Cc: Marek Vasut > Cc: Stefan Agner > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Benjamin Gaignard > Cc: Maxime Coquelin > Cc: Alexandre Torgue > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Jernej Skrabec > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-m...@vger.kernel.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-su...@lists.linux.dev For sun4i: Acked-by: Jernej Skrabec Best regards, Jernej ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
Den 21.05.2021 11.09, skrev Daniel Vetter: > Goes through all the drivers and deletes the default hook since it's > the default now. > > Signed-off-by: Daniel Vetter Acked-by: Noralf Trønnes ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 8:08 PM Christian König wrote: > > Am 21.05.21 um 17:16 schrieb Daniel Vetter: > > On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote: > >> On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote: > >>> On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote: > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter > wrote: > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > index 88a24a0b5691..cc8426e1e8a8 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > @@ -617,8 +617,8 @@ static int amdgpu_cs_parser_bos(struct > > amdgpu_cs_parser *p, > > amdgpu_bo_list_for_each_entry(e, p->bo_list) { > > struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo); > > > > - /* Make sure we use the exclusive slot for shared BOs */ > > - if (bo->prime_shared_count) > > + /* Make sure we use the exclusive slot for all > > potentially shared BOs */ > > + if (!(bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)) > > e->tv.num_shared = 0; > I think it also makes sense to skip this with > AMDGPU_GEM_CREATE_EXPLICIT_SYNC? It can be shared but I don't think > anyone expects implicit sync to happen with those. > >>> Ah yes, I missed this entirely. So the "no implicit flag" is already > >>> there, and the _only_ thing that's missing really is a way to fish out the > >>> implicit fences, and set them. > >>> > >>> https://lore.kernel.org/dri-devel/20210520190007.534046-1-ja...@jlekstrand.net/ > >>> > >>> So I think all that's really needed in radv is not setting > >>> RADEON_FLAG_IMPLICIT_SYNC for winsys buffers when Jason's dma-buf ioctl > >>> are present (means you need to do some import/export and keep the fd > >>> around for winsys buffers, but shouldn't be too bad), and then control the > >>> implicit fences entirely explicitly like vk expects. > >> That is the part I'm less sure about. This is a BO wide flag so we are > >> also disabling implicit sync in the compositor. If the compositor does > >> only do read stuff that is ok, as the inserted exclusive fence will > >> work for that. But as I learned recently the app provided buffer may > >> end up being written to by the X server which open a whole can of > >> potential problems if implicit sync gets disabled between Xserver > >> operations on the app provided buffer. Hence setting that on the WSI > >> buffer is a whole new can of potential problems and hence I've said a > >> submission based flag would be preferred. > >> > >> I can certainly try it out though. > > Hm yeah that's the wrong flag. We need a flag on the drm_file which the > > explicit userspace sets. And which is valid only for itself. > > > > There's a nice flags field when creating a ctx, but it's not validated and > > there's already a comment that we have to filter out garbage priority, so > > that's not use. I'll whip up something entirely untested just as a draft. > > We could provide an IOCTL for the BO to change the flag. That's not the semantics we need. > But could we first figure out the semantics we want to use here? > > Cause I'm pretty sure we don't actually need those changes at all and as > said before I'm certainly NAKing things which break existing use cases. Please read how other drivers do this and at least _try_ to understand it. I'm really loosing my patience here with you NAKing patches you're not even understanding (or did you actually read and fully understand the entire story I typed up here, and your NAK is on the entire thing?). There's not much useful conversation to be had with that approach. And with drivers I mean kernel + userspace here. That's the other frustration part: You're trying to fix this purely in the kernel. This is exactly one of these issues why we require open source userspace, so that we can fix the issues correctly across the entire stack. And meanwhile you're steadfastily refusing to even look at that the userspace side of the picture. Also I thought through your tlb issue, why are you even putting these tlb flush fences into the shard dma_resv slots? If you store them somewhere else in the amdgpu private part, the oversync issues goes away - in your ttm bo move callback, you can just make your bo copy job depend on them too (you have to anyway) - even for p2p there's not an issue here, because you have the ->move_notify callback, and can then lift the tlb flush fences from your private place to the shared slots so the exporter can see them. The kernel move fences otoh are a bit more nasty to wring through the p2p dma-buf interface. That one probably needs something new. -Daniel > > Regard
Re: [Intel-gfx] [PATCH] drm/i915/gvt: remove local storage of debugfs file
On Wed, May 19, 2021 at 04:21:23PM +0800, Zhenyu Wang wrote: > On 2021.05.19 10:31:18 +0200, Greg Kroah-Hartman wrote: > > On Wed, May 19, 2021 at 04:03:13PM +0800, Zhenyu Wang wrote: > > > On 2021.05.18 18:28:53 +0200, Greg Kroah-Hartman wrote: > > > > On Tue, May 18, 2021 at 06:17:05PM +0200, Greg Kroah-Hartman wrote: > > > > > There is no need to keep the dentry around for the debugfs kvmgt cache > > > > > file, as we can just look it up when we want to remove it later on. > > > > > Simplify the structure by removing the dentry and relying on debugfs > > > > > to find the dentry to remove when we want to. > > > > > > > > > > By doing this change, we remove the last in-kernel user that was > > > > > storing > > > > > the result of debugfs_create_long(), so that api can be cleaned up. > > > > > > > > > > Cc: Zhenyu Wang > > > > > Cc: Zhi Wang > > > > > Cc: Jani Nikula > > > > > Cc: Joonas Lahtinen > > > > > Cc: Rodrigo Vivi > > > > > Cc: David Airlie > > > > > Cc: Daniel Vetter > > > > > Cc: intel-gvt-...@lists.freedesktop.org > > > > > Cc: intel-gfx@lists.freedesktop.org > > > > > Cc: dri-de...@lists.freedesktop.org > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > --- > > > > > drivers/gpu/drm/i915/gvt/kvmgt.c | 11 +-- > > > > > 1 file changed, 5 insertions(+), 6 deletions(-) > > > > > > > > Note, I can take this through my debugfs tree if wanted, that way I can > > > > clean up the debugfs_create_long() api at the same time. Otherwise it's > > > > fine, I can wait until next -rc1 for that to happen. > > > > > > > > > > It's fine with me to go through debugfs tree. Just double check that > > > recent > > > kvmgt change would not cause conflict with this as well. > > > > How can I check that? I'll be glad to take this through my tree, we can > > handle the merge issues later for 5.14-rc1 :) > > > > Current kvmgt change in merge queue is just > https://patchwork.freedesktop.org/patch/433536/?series=89995&rev=2 > It applies fine with debugfs change. Thanks, I'll go take this through my tree now. greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Add missing macro name changes (rev2)
== Series Details == Series: drm/i915/gvt: Add missing macro name changes (rev2) URL : https://patchwork.freedesktop.org/series/90427/ State : success == Summary == CI Bug Log - changes from CI_DRM_10120 -> Patchwork_20172 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/index.html Known issues Here are the changes found in Patchwork_20172 that come from known issues: ### IGT changes ### Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [FAIL][1] ([i915#1372]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u2: [FAIL][3] ([i915#49]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html Warnings * igt@i915_selftest@live@execlists: - fi-bsw-nick:[INCOMPLETE][5] ([i915#2782] / [i915#2940] / [i915#3462]) -> [DMESG-FAIL][6] ([i915#3462]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-cfl-8700k: [FAIL][7] ([i915#3363]) -> [FAIL][8] ([i915#2426] / [i915#3363]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cfl-8700k/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-cfl-8700k/igt@run...@aborted.html - fi-kbl-7500u: [FAIL][9] ([i915#1436] / [i915#3363]) -> [FAIL][10] ([i915#1436] / [i915#2426] / [i915#3363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7500u/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-kbl-7500u/igt@run...@aborted.html - fi-cml-u2: [FAIL][11] ([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462]) -> [FAIL][12] ([i915#3363] / [i915#3462]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-cml-u2/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-cml-u2/igt@run...@aborted.html - fi-kbl-7567u: [FAIL][13] ([i915#1436] / [i915#3363]) -> [FAIL][14] ([i915#1436] / [i915#2426] / [i915#3363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10120/fi-kbl-7567u/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20172/fi-kbl-7567u/igt@run...@aborted.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012 [i915#3276]: https://gitlab.freedesktop.org/drm/intel/issues/3276 [i915#3277]: https://gitlab.freedesktop.org/drm/intel/issues/3277 [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282 [i915#3283]: https://gitlab.freedesktop.org/drm/intel/issues/3283 [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291 [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363 [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462 [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (41 -> 38) -- Additional (1): fi-rkl-11500t Missing(4): fi-kbl-soraka fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_10120 -> Patchwork_20172 CI-20190529: 20190529 CI_DRM_10120: 9221d50d353487d2e10226318d89027037255621 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6091: a7016bde81f6e6ee9f2ded3c091c56766a6adc46 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-