dri-devel October 2021

dri-devel@lists.freedesktop.org

347 participants
825 discussions

[PATCH v4 0/5] CMDQ refinement of Mediatek DRM driver
by jason-jh.lin 26 Oct '21

26 Oct '21

These refinements include using standard mailbox callback interface, timeout detection, and a fixed cmdq_handle. Change in v4: 1. Add cmdq_vblank_cnt initial value to 3. 2. Move mtk_drm_cmdq_pkt_create to the same define scope with mtk_drm_cmdq_pkt_destroy. Change in v3: 1. Revert "drm/mediatek: clear pending flag when cmdq packet is done" and add it after the CMDQ refinement pathes. 2. Change the remove of struct cmdq_client to remove the pointer of struct cmdq_client. 3. Fix pkt buf alloc once but free many times. Changes in v2: 1. Define mtk_drm_cmdq_pkt_create() and mtk_drm_cmdq_pkt_destroy() when CONFIG_MTK_CMDQ is reachable. Chun-Kuang Hu (4): drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb drm/mediatek: Remove the pointer of struct cmdq_client drm/mediatek: Detect CMDQ execution timeout drm/mediatek: Add cmdq_handle in mtk_crtc Yongqiang Niu (1): drm/mediatek: clear pending flag when cmdq packet is done. drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 174 ++++++++++++++++++++---- 1 file changed, 150 insertions(+), 24 deletions(-) -- 2.18.0

2 10

[PATCH v2 00/17] drm/i915/dg2: Enabling 64k page size and flat ccs
by Ramalingam C 26 Oct '21

26 Oct '21

This series introduces the enabling patches for new memory compression feature Flat CCS and 64k page support for i915 local memory, along with documentation on the uAPI impact. Included the details of the feature and the implications on the uAPI below. Which is also added into Documentation/gpu/rfc/i915_dg2.rst DG2 64K page size support: ========================= On discrete platforms, starting from DG2, we have to contend with GTT page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE objects. Specifically the hardware only supports 64K or larger GTT page sizes for such memory. The kernel will already ensure that all I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page sizes underneath. Note that the returned size here will always reflect any required rounding up done by the kernel, i.e 4K will now become 64K on devices such as DG2. Special DG2 GTT address alignment requirement: ============================================= The GTT alignment will also need be at least 64K for such objects. Note that due to how the hardware implements 64K GTT page support, we have some further complications: 1) The entire PDE(which covers a 2M virtual address range), must contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same PDE is forbidden by the hardware. 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM objects. To handle the above the kernel implements a memory coloring scheme to prevent userspace from mixing I915_MEMORY_CLASS_DEVICE and I915_MEMORY_CLASS_SYSTEM objects in the same PDE. If the kernel is ever unable to evict the required pages for the given PDE(different color) when inserting the object into the GTT then it will simply fail the request. Since userspace needs to manage the GTT address space themselves, special care is needed to ensure this doesn’t happen. The simplest scheme is to simply align and round up all I915_MEMORY_CLASS_DEVICE objects to 2M, which avoids any issues here. At the very least this is likely needed for objects that can be placed in both I915_MEMORY_CLASS_DEVICE and I915_MEMORY_CLASS_SYSTEM, to avoid potential issues when the kernel needs to migrate the object behind the scenes, since that might also involve evicting other objects. To summarise the GTT rules, on platforms like DG2: 1) All objects that can be placed in I915_MEMORY_CLASS_DEVICE must have 64K alignment. The kernel will reject this otherwise. 2) All I915_MEMORY_CLASS_DEVICE objects must never be placed in the same PDE with other I915_MEMORY_CLASS_SYSTEM objects. The kernel will reject this otherwise. 3) Objects that can be placed in both I915_MEMORY_CLASS_DEVICE and I915_MEMORY_CLASS_SYSTEM should probably be aligned and padded out to 2M. Flat CCS support for lmem ========================= On Xe-HP and later devices, we use dedicated compression control state (CCS) stored in local memory for each surface, to support the 3D and media compression formats. The memory required for the CCS of the entire local memory is 1/256 of the local memory size. So before the kernel boot, the required memory is reserved for the CCS data and a secure register will be programmed with the CCS base address. Flat CCS data needs to be cleared when a lmem object is allocated. And CCS data can be copied in and out of CCS region through XY_CTRL_SURF_COPY_BLT. CPU can’t access the CCS data directly. When we exaust the lmem, if the object’s placements support smem, then we can directly decompress the compressed lmem object into smem and start using it from smem itself. But when we need to swapout the compressed lmem object into a smem region though objects’ placement doesn’t support smem, then we copy the lmem content as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT). When the object is referred, lmem content will be swaped in along with restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding location. Flat-CCS Modifiers for different compression formats ==================================================== I915_FORMAT_MOD_F_TILED_DG2_RC_CCS - used to indicate the buffers of Flat CCS render compression formats. Though the general layout is same as I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS, new hashing/compression algorithm is used. Render compression uses 128 byte compression blocks I915_FORMAT_MOD_F_TILED_DG2_MC_CCS -used to indicate the buffers of Flat CCS media compression formats. Though the general layout is same as I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS, new hashing/compression algorithm is used. Media compression uses 256 byte compression blocks. I915_FORMAT_MOD_F_TILED_DG2_RC_CCS_CC - used to indicate the buffers of Flat CCS clear color render compression formats. Unified compression format for clear color render compression. The genral layout is a tiled layout using 4Kb tiles i.e Tile4 layout. v2: Fixed some formatting issues and platform naming issues Added some more documentation on Flat-CCS Abdiel Janulgue (1): drm/i915/lmem: Enable lmem for platforms with Flat CCS Ayaz A Siddiqui (1): drm/i915/gt: Clear compress metadata for Xe_HP platforms Bommu Krishnaiah (1): drm/i915: Add vm min alignment support CQ Tang (1): drm/i915/xehpsdv: Add has_flat_ccs to device info Matt Roper (1): uapi/drm/dg2: Format modifier for DG2 unified compression and clear color Matthew Auld (8): drm/i915/xehpsdv: set min page-size to 64K drm/i915/xehpsdv: enforce min GTT alignment drm/i915: enforce min page size for scratch drm/i915/gtt/xehpsdv: move scratch page to system memory drm/i915/xehpsdv: support 64K GTT pages drm/i915/selftests: account for min_alignment in GTT selftests drm/i915/xehpsdv: implement memory coloring drm/i915/uapi: document behaviour for DG2 64K support Ramalingam C (2): drm/i915/Flat-CCS: Document on Flat-CCS memory compression Doc/gpu/rfc/i915: i915 DG2 uAPI Stanislav Lisovskiy (1): drm/i915/dg2: Tile 4 plane format support Stuart Summers (1): drm/i915: Add has_64k_pages flag Documentation/gpu/rfc/i915_dg2.rst | 32 ++++ Documentation/gpu/rfc/index.rst | 3 + drivers/gpu/drm/i915/display/intel_display.c | 4 + .../drm/i915/display/intel_display_types.h | 10 +- drivers/gpu/drm/i915/display/intel_fb.c | 14 ++ drivers/gpu/drm/i915/display/intel_fbc.c | 1 + .../drm/i915/display/intel_plane_initial.c | 1 + .../drm/i915/display/skl_universal_plane.c | 81 +++++++-- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 6 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 61 +++++++ .../i915/gem/selftests/i915_gem_client_blt.c | 23 ++- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 1 + drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 145 ++++++++++++++- drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 14 ++ drivers/gpu/drm/i915/gt/intel_gt.c | 19 ++ drivers/gpu/drm/i915/gt/intel_gt.h | 1 + drivers/gpu/drm/i915/gt/intel_gtt.c | 23 ++- drivers/gpu/drm/i915/gt/intel_gtt.h | 20 +++ drivers/gpu/drm/i915/gt/intel_migrate.c | 167 +++++++++++++++++- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 + drivers/gpu/drm/i915/gt/intel_region_lmem.c | 27 ++- drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gem_evict.c | 17 ++ drivers/gpu/drm/i915/i915_pci.c | 4 + drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/i915_vma.c | 55 ++++-- drivers/gpu/drm/i915/intel_device_info.h | 3 + drivers/gpu/drm/i915/intel_pm.c | 1 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ++++++---- drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 + include/uapi/drm/drm_fourcc.h | 38 ++++ include/uapi/drm/i915_drm.h | 67 ++++++- 33 files changed, 861 insertions(+), 87 deletions(-) create mode 100644 Documentation/gpu/rfc/i915_dg2.rst -- 2.20.1

7 27

[PATCH] dma-buf: st: fix error handling in test_get_fences()
by Arnd Bergmann 26 Oct '21

26 Oct '21

From: Arnd Bergmann <arnd(a)arndb.de> The new driver incorrectly unwinds after errors, as clang points out: drivers/dma-buf/st-dma-resv.c:295:7: error: variable 'i' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] if (r) { ^ drivers/dma-buf/st-dma-resv.c:336:9: note: uninitialized use occurs here while (i--) ^ drivers/dma-buf/st-dma-resv.c:295:3: note: remove the 'if' if its condition is always false if (r) { ^~~~~~~~ drivers/dma-buf/st-dma-resv.c:288:6: error: variable 'i' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] if (r) { ^ drivers/dma-buf/st-dma-resv.c:336:9: note: uninitialized use occurs here while (i--) ^ drivers/dma-buf/st-dma-resv.c:288:2: note: remove the 'if' if its condition is always false if (r) { ^~~~~~~~ drivers/dma-buf/st-dma-resv.c:280:10: note: initialize the variable 'i' to silence this warning int r, i; ^ = 0 Skip cleaning up the bits that have not been allocated at this point. Fixes: 1d51775cd3f5 ("dma-buf: add dma_resv selftest v4") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- I'm not familiar with these interfaces, so I'm just guessing where we should jump after an error, please double-check and fix if necessary. --- drivers/dma-buf/st-dma-resv.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/st-dma-resv.c b/drivers/dma-buf/st-dma-resv.c index 6f3ba756da3e..bc32b3eedcb6 100644 --- a/drivers/dma-buf/st-dma-resv.c +++ b/drivers/dma-buf/st-dma-resv.c @@ -287,7 +287,7 @@ static int test_get_fences(void *arg, bool shared) r = dma_resv_lock(&resv, NULL); if (r) { pr_err("Resv locking failed\n"); - goto err_free; + goto err_resv; } if (shared) { @@ -295,7 +295,7 @@ static int test_get_fences(void *arg, bool shared) if (r) { pr_err("Resv shared slot allocation failed\n"); dma_resv_unlock(&resv); - goto err_free; + goto err_resv; } dma_resv_add_shared_fence(&resv, f); @@ -336,6 +336,7 @@ static int test_get_fences(void *arg, bool shared) while (i--) dma_fence_put(fences[i]); kfree(fences); +err_resv: dma_resv_fini(&resv); dma_fence_put(f); return r; -- 2.29.2

3 2

[PATCH 1/9] drm/i915: mark dmabuf objects as ALLOC_USER
by Matthew Auld 26 Oct '21

26 Oct '21

These are userspace objects, so mark them as such. In a later patch it's useful to determine how paranoid we need to be when managing cache flushes. In theory no functional changes. Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c index afa34111de02..5be505ebbb7b 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c @@ -301,7 +301,8 @@ struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev, } drm_gem_private_object_init(dev, &obj->base, dma_buf->size); - i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops, &lock_class, 0); + i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops, &lock_class, + I915_BO_ALLOC_USER); obj->base.import_attach = attach; obj->base.resv = dma_buf->resv; -- 2.26.3

3 18

[PULL] drm-misc-fixes
by Maarten Lankhorst 26 Oct '21

26 Oct '21

Hi Dave and Dan, Last pull request for me for v5.15 I hope. Out for vacation until the third week of november, Maxime offered to do the remainder of v5.15. ~Maarten drm-misc-fixes-2021-10-26: drm-misc-fixes for v5.15-rc8: - Fix fence leak in ttm_transfered_destroy. - Add quirk for Aya Neo 2021 - Reset property count for each drm damage selftest so full run will work correctly. The following changes since commit 74056092ff415e7e20ce2544689b32ee811c4f0b: drm/kmb: Enable ADV bridge after modeset (2021-10-21 11:08:09 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-10-26 for you to fetch changes up to ee71fb6c4d99c51f2d82a32c503c872b7e40e7f7: drm/i915/selftests: Properly reset mock object propers for each test (2021-10-22 11:09:45 +0200) ---------------------------------------------------------------- drm-misc-fixes for v5.15-rc8: - Fix fence leak in ttm_transfered_destroy. - Add quirk for Aya Neo 2021 - Reset property count for each drm damage selftest so full run will work correctly. ---------------------------------------------------------------- Bryant Mairs (1): drm: panel-orientation-quirks: Add quirk for Aya Neo 2021 Christian König (1): drm/ttm: fix memleak in ttm_transfered_destroy Daniel Vetter (1): drm/i915/selftests: Properly reset mock object propers for each test drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++++++ drivers/gpu/drm/selftests/test-drm_damage_helper.c | 1 + drivers/gpu/drm/ttm/ttm_bo_util.c | 1 + 3 files changed, 8 insertions(+)

1 0

[PATCH v2 0/9] drm/i915: PREEMPT_RT related fixups.
by Sebastian Andrzej Siewior 26 Oct '21

26 Oct '21

the following patches are from the PREEMPT_RT queue. It is mostly about disabling interrupts/preemption which leads to problems. Patches 1-4 are independent of PREEMPT_RT. Unfortunately DRM_I915_LOW_LEVEL_TRACEPOINTS had to be disabled because it acquires locks from within trace points. It has been pointed out in the previous post that this makes any kind of debugging impossible. Making the uncore.lock a raw_spinlock_t doubles the latencies in my limited testing [0]. I don't know the difference on other hardware. Also it worries me a little that wait_for_atomic() has 50ms as the upper spin/wait limit if the condition does not become true. I tested it on a SandyBridge with built-in i915 by using X, OpenGL and playing videos without noticing any warnings. However, some code paths were not entered. [0] https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@linutronix.de/ Sebastian

1 9

[PATCH 1/2] drm/i915/gtt: flush the scratch page
by Matthew Auld 26 Oct '21

26 Oct '21

The scratch page is directly visible in the users address space, and while this is forced as CACHE_LLC, by the kernel, we still have to contend with things like "Bypass-LLC" MOCS. So just flush no matter what. Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Ramalingam C <ramalingam.c(a)intel.com> --- drivers/gpu/drm/i915/gt/intel_gtt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c b/drivers/gpu/drm/i915/gt/intel_gtt.c index 67d14afa6623..b6c088423319 100644 --- a/drivers/gpu/drm/i915/gt/intel_gtt.c +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c @@ -273,6 +273,7 @@ static void poison_scratch_page(struct drm_i915_gem_object *scratch) val = POISON_FREE; memset(vaddr, val, scratch->base.size); + clflush_cache_range(vaddr, scratch->base.size); } int setup_scratch_page(struct i915_address_space *vm) -- 2.26.3

2 4

[PATCH] drm/i915/guc: Fix recursive lock in GuC submission
by Matthew Brost 26 Oct '21

26 Oct '21

Use __release_guc_id (lock held) rather than release_guc_id (acquires lock), add lockdep annotations. 213.280129] i915: Running i915_perf_live_selftests/live_noa_gpr [ 213.283459] ============================================ [ 213.283462] WARNING: possible recursive locking detected {{[ 213.283466] 5.15.0-rc6+ #18 Tainted: G U W }} [ 213.283470] -------------------------------------------- [ 213.283472] kworker/u24:0/8 is trying to acquire lock: [ 213.283475] ffff8ffc4f6cc1e8 (&guc->submission_state.lock){....}-{2:2}, at: destroyed_worker_func+0x2df/0x350 [i915] {{[ 213.283618] }} {{ but task is already holding lock:}} [ 213.283621] ffff8ffc4f6cc1e8 (&guc->submission_state.lock){....}-{2:2}, at: destroyed_worker_func+0x4f/0x350 [i915] {{[ 213.283720] }} {{ other info that might help us debug this:}} [ 213.283724] Possible unsafe locking scenario:[ 213.283727] CPU0 [ 213.283728] ---- [ 213.283730] lock(&guc->submission_state.lock); [ 213.283734] lock(&guc->submission_state.lock); {{[ 213.283737] }} {{ *** DEADLOCK ***}}[ 213.283740] May be due to missing lock nesting notation[ 213.283744] 3 locks held by kworker/u24:0/8: [ 213.283747] #0: ffff8ffb80059d38 ((wq_completion)events_unbound){..}-{0:0}, at: process_one_work+0x1f3/0x550 [ 213.283757] #1: ffffb509000e3e78 ((work_completion)(&guc->submission_state.destroyed_worker)){..}-{0:0}, at: process_one_work+0x1f3/0x550 [ 213.283766] #2: ffff8ffc4f6cc1e8 (&guc->submission_state.lock){....}-{2:2}, at: destroyed_worker_func+0x4f/0x350 [i915] {{[ 213.283860] }} {{ stack backtrace:}} [ 213.283863] CPU: 8 PID: 8 Comm: kworker/u24:0 Tainted: G U W 5.15.0-rc6+ #18 [ 213.283868] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021 [ 213.283873] Workqueue: events_unbound destroyed_worker_func [i915] [ 213.283957] Call Trace: [ 213.283960] dump_stack_lvl+0x57/0x72 [ 213.283966] __lock_acquire.cold+0x191/0x2d3 [ 213.283972] lock_acquire+0xb5/0x2b0 [ 213.283978] ? destroyed_worker_func+0x2df/0x350 [i915] [ 213.284059] ? destroyed_worker_func+0x2d7/0x350 [i915] [ 213.284139] ? lock_release+0xb9/0x280 [ 213.284143] _raw_spin_lock_irqsave+0x48/0x60 [ 213.284148] ? destroyed_worker_func+0x2df/0x350 [i915] [ 213.284226] destroyed_worker_func+0x2df/0x350 [i915] [ 213.284310] process_one_work+0x270/0x550 [ 213.284315] worker_thread+0x52/0x3b0 [ 213.284319] ? process_one_work+0x550/0x550 [ 213.284322] kthread+0x135/0x160 [ 213.284326] ? set_kthread_struct+0x40/0x40 [ 213.284331] ret_from_fork+0x1f/0x30 and a bit later in the trace: {{ 227.499864] do_raw_spin_lock+0x94/0xa0}} [ 227.499868] _raw_spin_lock_irqsave+0x50/0x60 [ 227.499871] ? guc_flush_destroyed_contexts+0x4f/0xf0 [i915] [ 227.499995] guc_flush_destroyed_contexts+0x4f/0xf0 [i915] [ 227.500104] intel_guc_submission_reset_prepare+0x99/0x4b0 [i915] [ 227.500209] ? mark_held_locks+0x49/0x70 [ 227.500212] intel_uc_reset_prepare+0x46/0x50 [i915] [ 227.500320] reset_prepare+0x78/0x90 [i915] [ 227.500412] __intel_gt_set_wedged.part.0+0x13/0xe0 [i915] [ 227.500485] intel_gt_set_wedged.part.0+0x54/0x100 [i915] [ 227.500556] intel_gt_set_wedged_on_fini+0x1a/0x30 [i915] [ 227.500622] intel_gt_driver_unregister+0x1e/0x60 [i915] [ 227.500694] i915_driver_remove+0x4a/0xf0 [i915] [ 227.500767] i915_pci_probe+0x84/0x170 [i915] [ 227.500838] local_pci_probe+0x42/0x80 [ 227.500842] pci_device_probe+0xd9/0x190 [ 227.500844] really_probe+0x1f2/0x3f0 [ 227.500847] __driver_probe_device+0xfe/0x180 [ 227.500848] driver_probe_device+0x1e/0x90 [ 227.500850] __driver_attach+0xc4/0x1d0 [ 227.500851] ? __device_attach_driver+0xe0/0xe0 [ 227.500853] ? __device_attach_driver+0xe0/0xe0 [ 227.500854] bus_for_each_dev+0x64/0x90 [ 227.500856] bus_add_driver+0x12e/0x1f0 [ 227.500857] driver_register+0x8f/0xe0 [ 227.500859] i915_init+0x1d/0x8f [i915] [ 227.500934] ? 0xffffffffc144a000 [ 227.500936] do_one_initcall+0x58/0x2d0 [ 227.500938] ? rcu_read_lock_sched_held+0x3f/0x80 [ 227.500940] ? kmem_cache_alloc_trace+0x238/0x2d0 [ 227.500944] do_init_module+0x5c/0x270 [ 227.500946] __do_sys_finit_module+0x95/0xe0 [ 227.500949] do_syscall_64+0x38/0x90 [ 227.500951] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 227.500953] RIP: 0033:0x7ffa59d2ae0d [ 227.500954] Code: c8 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3b 80 0c 00 f7 d8 64 89 01 48 [ 227.500955] RSP: 002b:00007fff320bbf48 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 227.500956] RAX: ffffffffffffffda RBX: 00000000022ea710 RCX: 00007ffa59d2ae0d [ 227.500957] RDX: 0000000000000000 RSI: 00000000022e1d90 RDI: 0000000000000004 [ 227.500958] RBP: 0000000000000020 R08: 00007ffa59df3a60 R09: 0000000000000070 [ 227.500958] R10: 00000000022e1d90 R11: 0000000000000246 R12: 00000000022e1d90 [ 227.500959] R13: 00000000022e58e0 R14: 0000000000000043 R15: 00000000022e42c0 v2: (CI build) - Fix build error Fixes: 1a52faed31311 ("drm/i915/guc: Take engine PM when a context is pinned with GuC submission") Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index d7710debcd47..38b47e73e35d 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -2373,6 +2373,7 @@ static inline void guc_lrc_desc_unpin(struct intel_context *ce) unsigned long flags; bool disabled; + lockdep_assert_held(&guc->submission_state.lock); GEM_BUG_ON(!intel_gt_pm_is_awake(gt)); GEM_BUG_ON(!lrc_desc_registered(guc, ce->guc_id.id)); GEM_BUG_ON(ce != __get_context(guc, ce->guc_id.id)); @@ -2388,7 +2389,7 @@ static inline void guc_lrc_desc_unpin(struct intel_context *ce) } spin_unlock_irqrestore(&ce->guc_state.lock, flags); if (unlikely(disabled)) { - release_guc_id(guc, ce); + __release_guc_id(guc, ce); __guc_context_destroy(ce); return; } -- 2.32.0

3 4

[PATCH] dma-buf: add attachments empty check for dma_buf_release
by guangming.cao＠mediatek.com 26 Oct '21

26 Oct '21

From: Guangming Cao <Guangming.Cao(a)mediatek.com> Since there is no mandatory inspection for attachments in dma_buf_release. There will be a case that dma_buf already released but attachment is still in use, which can points to the dmabuf, and it maybe cause some unexpected issues. With IOMMU, when this cases occurs, there will have IOMMU address translation fault(s) followed by this warning, I think it's useful for dma devices to debug issue. Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> --- drivers/dma-buf/dma-buf.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 511fe0d217a0..672404857d6a 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -74,6 +74,29 @@ static void dma_buf_release(struct dentry *dentry) */ BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active); + /* attachment check */ + if (dma_resv_trylock(dmabuf->resv) && WARN(!list_empty(&dmabuf->attachments), + "%s err, inode:%08lu size:%08zu name:%s exp_name:%s flags:0x%08x mode:0x%08x, %s\n", + __func__, file_inode(dmabuf->file)->i_ino, dmabuf->size, + dmabuf->name, dmabuf->exp_name, + dmabuf->file->f_flags, dmabuf->file->f_mode, + "Release dmabuf before detach all attachments, dump attach:\n")) { + int attach_cnt = 0; + dma_addr_t dma_addr; + struct dma_buf_attachment *attach_obj; + /* dump all attachment info */ + list_for_each_entry(attach_obj, &dmabuf->attachments, node) { + dma_addr = (dma_addr_t)0; + if (attach_obj->sgt) + dma_addr = sg_dma_address(attach_obj->sgt->sgl); + pr_err("attach[%d]: dev:%s dma_addr:0x%-12lx\n", + attach_cnt, dev_name(attach_obj->dev), dma_addr); + attach_cnt++; + } + pr_err("Total %d devices attached\n\n", attach_cnt); + dma_resv_unlock(dmabuf->resv); + } + dmabuf->ops->release(dmabuf); if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) -- 2.17.1

3 4

[PATCH] drm/i915/dmabuf: include asm/smp.h for cache operations
by Arnd Bergmann 26 Oct '21

26 Oct '21

From: Arnd Bergmann <arnd(a)arndb.de> The x86 low-level cache management operations are declared in asm/smp.h, so drivers that call into this code need to include the header: drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:248:3: error: implicit declaration of function 'wbinvd_on_all_cpus' [-Werror,-Wimplicit-function-declaration] wbinvd_on_all_cpus(); ^ Fixes: a035154da45d ("drm/i915/dmabuf: add paranoid flush-on-acquire") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c index 1adcd8e02d29..853a989fcb9b 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c @@ -7,6 +7,7 @@ #include <linux/dma-buf.h> #include <linux/highmem.h> #include <linux/dma-resv.h> +#include <asm/smp.h> #include "i915_drv.h" #include "i915_gem_object.h" -- 2.29.2

1 0

← Newer
1
...
28
29
30
31
32
33
34
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2021