aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_gem_shmem_helper.c
AgeCommit message (Collapse)AuthorFilesLines
2020-11-09drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backendsThomas Zimmermann1-19/+29
This patch replaces the vmap/vunmap's use of raw pointers in GEM object functions with instances of struct dma_buf_map. GEM backends are converted as well. For most of them, this simply changes the returned type. TTM-based drivers now return information about the location of the memory, either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap() et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of implementing their own vmap callbacks. v7: * init QXL cursor to mapped BO buffer (kernel test robot) v5: * update vkms after switch to shmem v4: * use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian) * fix a trailing { in drm_gem_vmap() * remove several empty functions instead of converting them (Daniel) * comment uses of raw pointers with a TODO (Daniel) * TODO list: convert more helpers to use struct dma_buf_map Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Christian König <[email protected]> Tested-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-02Merge drm/drm-next into drm-misc-nextMaxime Ripard1-6/+15
Daniel needs -rc2 in drm-misc-next to merge some patches Signed-off-by: Maxime Ripard <[email protected]>
2020-10-28drm/shme-helpers: Fix dma_buf_mmap forwarding bugDaniel Vetter1-1/+6
When we forward an mmap to the dma_buf exporter, they get to own everything. Unfortunately drm_gem_mmap_obj() overwrote vma->vm_private_data after the driver callback, wreaking the exporter complete. This was noticed because vb2_common_vm_close blew up on mali gpu with panfrost after commit 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf"). Unfortunately drm_gem_mmap_obj also acquires a surplus reference that we need to drop in shmem helpers, which is a bit of a mislayer situation. Maybe the entire dma_buf_mmap forwarding should be pulled into core gem code. Note that the only two other drivers which forward mmap in their own code (etnaviv and exynos) get this somewhat right by overwriting the gem mmap code. But they seem to still have the leak. This might be a good excuse to move these drivers over to shmem helpers completely. Reviewed-by: Boris Brezillon <[email protected]> Acked-by: Christian König <[email protected]> Cc: Christian König <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: Lucas Stach <[email protected]> Cc: Russell King <[email protected]> Cc: Christian Gmeiner <[email protected]> Cc: Inki Dae <[email protected]> Cc: Joonyoung Shim <[email protected]> Cc: Seung-Woo Kim <[email protected]> Cc: Kyungmin Park <[email protected]> Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf") Cc: Boris Brezillon <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Rob Herring <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: <[email protected]> # v5.9+ Reported-and-tested-by: [email protected] Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-29dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfacesThomas Zimmermann1-1/+2
This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to use struct dma_buf_map. The interfaces used to receive a buffer address. This address is now given in an instance of the structure. Users of the functions are updated accordingly. This is only an interface change. It is currently expected that dma-buf memory can be accessed with system memory load/store operations. v2: * include dma-buf-heaps and i915 selftests (kernel test robot) * initialize cma_obj before using it in drm_gem_cma_free_object() (kernel test robot) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sumit Semwal <[email protected]> Acked-by: Christian König <[email protected]> Acked-by: Daniel Vetter <[email protected]> Acked-by: Tomasz Figa <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-29dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfacesThomas Zimmermann1-5/+9
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use struct dma_buf_map. The interfaces used to return a buffer address. This address now gets stored in an instance of the structure that is given as an additional argument. The functions return an errno code on errors. Users of the functions are updated accordingly. This is only an interface change. It is currently expected that dma-buf memory can be accessed with system memory load/store operations. v3: * update fastrpc driver (kernel test robot) v2: * always clear map parameter in dma_buf_vmap() (Daniel) * include dma-buf-heaps and i915 selftests (kernel test robot) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sumit Semwal <[email protected]> Acked-by: Christian König <[email protected]> Acked-by: Daniel Vetter <[email protected]> Acked-by: Tomasz Figa <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-23Merge tag 'drm-misc-next-2020-09-21' of ↵Dave Airlie1-1/+1
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.10: UAPI Changes: Cross-subsystem Changes: - virtio: Merged a PR for patches that will affect drm/virtio Core Changes: - dev: More devm_drm convertions and removal of drm_dev_init - atomic: Split out drm_atomic_helper_calc_timestamping_constants of drm_atomic_helper_update_legacy_modeset_state - ttm: More rework Driver Changes: - i915: selftests improvements - panfrost: support for Amlogic SoC - vc4: one fix - tree-wide: conversions to devm_drm_dev_alloc, - ast: simplifications of the atomic modesetting code - panfrost: multiple fixes - vc4: multiple fixes Signed-off-by: Dave Airlie <[email protected]> From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-10drm: core: fix common struct sg_table related issuesMarek Szyprowski1-5/+9
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_map_sg(). struct sg_table is a common structure used for describing a non-contiguous memory buffer, used commonly in the DRM and graphics subsystems. It consists of a scatterlist with memory pages and DMA addresses (sgl entry), as well as the number of scatterlist entries: CPU pages (orig_nents entry) and DMA mapped pages (nents entry). It turned out that it was a common mistake to misuse nents and orig_nents entries, calling DMA-mapping functions with a wrong number of entries or ignoring the number of mapped entries returned by the dma_map_sg() function. To avoid such issues, lets use a common dma-mapping wrappers operating directly on the struct sg_table objects and use scatterlist page iterators where possible. This, almost always, hides references to the nents and orig_nents entries, making the code robust, easier to follow and copy/paste safe. Signed-off-by: Marek Szyprowski <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Robin Murphy <[email protected]>
2020-09-09drm: allow limiting the scatter list size.Gerd Hoffmann1-1/+1
Add drm_device argument to drm_prime_pages_to_sg(), so we can call dma_max_mapping_size() to figure the segment size limit and call into __sg_alloc_table_from_pages() with the correct limit. This fixes virtio-gpu with sev. Possibly it'll fix other bugs too given that drm seems to totaly ignore segment size limits so far ... v2: place max_segment in drm driver not gem object. v3: move max_segment next to the other gem fields. v4: just use dma_max_mapping_size(). Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-16drm/shmem-helper: Only dma-buf imports are private objDaniel Vetter1-2/+2
I broke that in my refactoring: commit 7d2cd72a9aa3df3604cafd169a2d4a525afb68ca Author: Daniel Vetter <[email protected]> Date: Fri May 29 16:05:42 2020 +0200 drm/shmem-helpers: Simplify dma-buf importing I'm not entirely sure of the history here, but I suspect that in one of the rebases or when applying the patch I moved the hunk from drm_gem_shmem_prime_import_sg_table(), where it should be, to drm_gem_shmem_create_with_handle(), which is totally wrong. Remedy this. Thanks for Thomas for the crucial hint in debugging this. Tested-by: Thomas Zimmermann <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Reported-by: Thomas Zimmermann <[email protected]> Fixes: 7d2cd72a9aa3 ("drm/shmem-helpers: Simplify dma-buf importing") Cc: Boris Brezillon <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Rob Herring <[email protected]> Cc: Noralf Trønnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-16drm/shmem-helper: Fix obj->filp derefenceDaniel Vetter1-9/+11
I broke that in my refactoring: commit 7d2cd72a9aa3df3604cafd169a2d4a525afb68ca Author: Daniel Vetter <[email protected]> Date: Fri May 29 16:05:42 2020 +0200 drm/shmem-helpers: Simplify dma-buf importing Tested-by: Thomas Zimmermann <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Reported-by: Thomas Zimmermann <[email protected]> Fixes: 7d2cd72a9aa3 ("drm/shmem-helpers: Simplify dma-buf importing") Cc: Boris Brezillon <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Rob Herring <[email protected]> Cc: Noralf Trønnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-10drm/shmem-helper: Add .gem_create_object helper that sets map_cached flagThomas Zimmermann1-0/+27
The helper drm_gem_shmem_create_object_cached() allocates an GEM SHMEM object and sets the map_cached flag. Useful for drivers that want cached mappings. v3: * style fixes Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-08drm/shmem-helpers: Simplify dma-buf importingDaniel Vetter1-37/+23
- Ditch the ->pages array - Make it a private gem bo, which means no shmem object, which means fireworks if anyone calls drm_gem_object_get_pages. But we've just made sure that's all covered. v2: Rebase v3: I forgot to remove the page_count mangling from the free path too. Noticed by Boris while testing. Cc: Boris Brezillon <[email protected]> Tested-by: Boris Brezillon <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Rob Herring <[email protected]> Cc: Noralf Trønnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-08drm/shmem-helpers: Ensure get_pages is not called on imported dma-bufDaniel Vetter1-0/+10
Just a bit of light paranoia. Also sprinkle this check over drm_gem_shmem_get_sg_table, which should only be called when exporting, same for the pin/unpin functions, on which it relies to work correctly. Acked-by: Thomas Zimmermann <[email protected]> Tested-by: Boris Brezillon <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Rob Herring <[email protected]> Cc: Noralf Trønnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-03drm/shmem-helpers: Redirect mmap for imported dma-bufDaniel Vetter1-0/+3
Currently this seems to work by converting the sgt into a pages array, and then treating it like a native object. Do the right thing and redirect mmap to the exporter. With this nothing is calling get_pages anymore on imported dma-buf, and we can start to remove the use of the ->pages array for that case. v2: Rebase Tested-by: Boris Brezillon <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Rob Herring <[email protected]> Cc: Noralf Trønnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-03drm/shmem-helpers: Don't call get/put_pages on imported dma-buf in vmapDaniel Vetter1-5/+6
There's no direct harm, because for the shmem helpers these are noops on imported buffers. The trouble is in the locks these take - I want to change dma_buf_vmap locking, and so need to make sure that we only ever take certain locks on one side of the dma-buf interface: Either for exporters, or for importers. v2: Change the control flow less compared to what's there (Thomas) Tested-by: Boris Brezillon <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Rob Herring <[email protected]> Cc: Noralf Trønnes <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-03drm/doc: Some polish for shmem helpersDaniel Vetter1-7/+32
- Move the shmem helper section to the drm-mm.rst file, next to the vram helpers. Makes a lot more sense there with the now wider scope. Also, that's where the all the other backing storage stuff resides. It's just the framebuffer helpers that should be in the kms helper section. - Try to clarify which functiosn are for implementing drm_gem_object_funcs, and which for drivers to call directly. At least one driver screwed that up a bit. Cc: Gerd Hoffmann <[email protected]> Cc: Rob Herring <[email protected]> Cc: Noralf Trønnes <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-19drm: remove _unlocked suffix in drm_gem_object_put_unlockedEmil Velikov1-2/+2
Spelling out _unlocked for each and every driver is a annoying. Especially if we consider how many drivers, do not know (or need to) about the horror stories involving struct_mutex. Just drop the suffix. It makes the API cleaner. Done via the following script: __from=drm_gem_object_put_unlocked __to=drm_gem_object_put for __file in $(git grep --name-only $__from); do sed -i "s/$__from/$__to/g" $__file; done Pay special attention to the compat #define v2: keep sed and #define removal separate Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Acked-by: Sam Ravnborg <[email protected]> (v1) Reviewed-by: Steven Price <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-02drm/shmem: drop pgprot_decrypted()Gerd Hoffmann1-1/+0
Was added by commit 95cf9264d5f3 ("x86, drm, fbdev: Do not specify encrypted memory for video mappings"), then it was kept through various changes. While vram actually needs decrypted mappings this is not correct for shmem gem objects which live in main memory not io memory, so remove the call. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-27drm/shmem: add support for per object caching flags.Gerd Hoffmann1-4/+11
Add map_cached bool to drm_gem_shmem_object, to request cached mappings on a per-object base. Check the flag before adding writecombine to pgprot bits. Cc: [email protected] Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Gurchetan Singh <[email protected]> Tested-by: Guillaume Gardet <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-12-06drm: call drm_gem_object_funcs.mmap with fake offsetGerd Hoffmann1-0/+3
The fake offset is going to stay, so change the calling convention for drm_gem_object_funcs.mmap to include the fake offset. Update all users accordingly. Note that this reverts 83b8a6f242ea ("drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap") and on top then adds the fake offset to drm_gem_prime_mmap to make sure all paths leading to obj->funcs->mmap are consistent. v3: move fake-offset tweak in drm_gem_prime_mmap() so we have this code only once in the function (Rob Herring). Fixes: 83b8a6f242ea ("drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap") Cc: Daniel Vetter <[email protected]> Cc: Rob Herring <[email protected]> Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmapRob Herring1-3/+0
Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs") introduced a GEM object mmap() hook which is expected to subtract the fake offset from vm_pgoff. However, for mmap() on dmabufs, there is not a fake offset. To fix this, let's always call mmap() object callback with an offset of 0, and leave it up to drm_gem_mmap_obj() to remove the fake offset. TTM still needs the fake offset, so we have to add it back until that's fixed. Fixes: c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs") Cc: Gerd Hoffmann <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Rob Herring <[email protected]> Acked-by: Gerd Hoffmann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/shmem: drop VM_IOGerd Hoffmann1-1/+1
VM_IO is wrong here, shmem uses normal ram not io memory. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Steven Price <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/shmem: drop VM_DONTDUMPGerd Hoffmann1-1/+1
Not obvious why this is needed. According to Deniel Vetter this is most likely a historic artefact dating back to the days where drm drivers exposed hardware registers as mmap'able gem objects, to avoid dumping touching those registers. shmem gem objects surely don't need that ... Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Steven Price <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-17drm/shmem: switch shmem helper to &drm_gem_object_funcs.mmapGerd Hoffmann1-18/+10
Switch gem shmem helper to the new mmap() workflow, from &gem_driver.fops.mmap to &drm_gem_object_funcs.mmap. v2: Fix vm_flags and vm_page_prot handling. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Steven Price <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-08-23drm/shmem: Use mutex_trylock in drm_gem_shmem_purgeRob Herring1-2/+5
Lockdep reports a circular locking dependency with pages_lock taken in the shrinker callback. The deadlock can't actually happen with current users at least as a BO will never be purgeable when pages_lock is held. To be safe, let's use mutex_trylock() instead and bail if a BO is locked already. WARNING: possible circular locking dependency detected 5.3.0-rc1+ #100 Tainted: G L ------------------------------------------------------ kswapd0/171 is trying to acquire lock: 000000009b9823fd (&shmem->pages_lock){+.+.}, at: drm_gem_shmem_purge+0x20/0x40 but task is already holding lock: 00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (fs_reclaim){+.+.}: fs_reclaim_acquire.part.18+0x34/0x40 fs_reclaim_acquire+0x20/0x28 __kmalloc_node+0x6c/0x4c0 kvmalloc_node+0x38/0xa8 drm_gem_get_pages+0x80/0x1d0 drm_gem_shmem_get_pages+0x58/0xa0 drm_gem_shmem_get_pages_sgt+0x48/0xd0 panfrost_mmu_map+0x38/0xf8 [panfrost] panfrost_gem_open+0xc0/0xe8 [panfrost] drm_gem_handle_create_tail+0xe8/0x198 drm_gem_handle_create+0x3c/0x50 panfrost_gem_create_with_handle+0x70/0xa0 [panfrost] panfrost_ioctl_create_bo+0x48/0x80 [panfrost] drm_ioctl_kernel+0xb8/0x110 drm_ioctl+0x244/0x3f0 do_vfs_ioctl+0xbc/0x910 ksys_ioctl+0x78/0xa8 __arm64_sys_ioctl+0x1c/0x28 el0_svc_common.constprop.0+0x90/0x168 el0_svc_handler+0x28/0x78 el0_svc+0x8/0xc -> #0 (&shmem->pages_lock){+.+.}: __lock_acquire+0xa2c/0x1d70 lock_acquire+0xdc/0x228 __mutex_lock+0x8c/0x800 mutex_lock_nested+0x1c/0x28 drm_gem_shmem_purge+0x20/0x40 panfrost_gem_shrinker_scan+0xc0/0x180 [panfrost] do_shrink_slab+0x208/0x500 shrink_slab+0x10c/0x2c0 shrink_node+0x28c/0x4d8 balance_pgdat+0x2c8/0x570 kswapd+0x22c/0x638 kthread+0x128/0x130 ret_from_fork+0x10/0x18 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&shmem->pages_lock); lock(fs_reclaim); lock(&shmem->pages_lock); *** DEADLOCK *** 3 locks held by kswapd0/171: #0: 00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40 #1: 00000000ceb37808 (shrinker_rwsem){++++}, at: shrink_slab+0xbc/0x2c0 #2: 00000000f31efa81 (&pfdev->shrinker_lock){+.+.}, at: panfrost_gem_shrinker_scan+0x34/0x180 [panfrost] Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers") Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Sean Paul <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Rob Herring <[email protected]> Reviewed-by: Steven Price <[email protected]> Acked-by: Alyssa Rosenzweig <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-08-23drm/shmem: Do dma_unmap_sg before purging pagesRob Herring1-0/+6
Calling dma_unmap_sg() in drm_gem_shmem_free_object() is too late if the backing pages have already been released by the shrinker. The result is the following abort: Unable to handle kernel paging request at virtual address ffff8000098ed000 Mem abort info: ESR = 0x96000147 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000147 CM = 1, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000002f51000 [ffff8000098ed000] pgd=00000000401f8003, pud=00000000401f7003, pmd=00000000401b1003, pte=00e80000098ed712 Internal error: Oops: 96000147 [#1] SMP Modules linked in: panfrost gpu_sched CPU: 5 PID: 902 Comm: gnome-shell Not tainted 5.3.0-rc1+ #95 Hardware name: 96boards Rock960 (DT) pstate: 40000005 (nZcv daif -PAN -UAO) pc : __dma_inv_area+0x40/0x58 lr : arch_sync_dma_for_cpu+0x28/0x30 sp : ffff00001321ba30 x29: ffff00001321ba30 x28: ffff00001321bd08 x27: 0000000000000000 x26: 0000000000000009 x25: 0000ffffc1f86170 x24: 0000000000000000 x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000021000 x20: ffff80003bb2d810 x19: 00000000098ed000 x18: 0000000000000000 x17: 0000000000000000 x16: ffff800023fd9480 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 00000000fffb9fff x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800023fd9c18 x7 : 0000000000000000 x6 : 00000000ffffffff x5 : 0000000000000000 x4 : 0000000000021000 Purging 5693440 bytes x3 : 000000000000003f x2 : 0000000000000040 x1 : ffff80000990e000 x0 : ffff8000098ed000 Call trace: __dma_inv_area+0x40/0x58 dma_direct_sync_single_for_cpu+0x7c/0x80 dma_direct_unmap_page+0x80/0x88 dma_direct_unmap_sg+0x54/0x80 drm_gem_shmem_free_object+0xfc/0x108 panfrost_gem_free_object+0x118/0x128 [panfrost] drm_gem_object_free+0x18/0x90 drm_gem_object_put_unlocked+0x58/0x80 drm_gem_object_handle_put_unlocked+0x64/0xb0 drm_gem_object_release_handle+0x70/0x98 drm_gem_handle_delete+0x64/0xb0 drm_gem_close_ioctl+0x28/0x38 drm_ioctl_kernel+0xb8/0x110 drm_ioctl+0x244/0x3f0 do_vfs_ioctl+0xbc/0x910 ksys_ioctl+0x78/0xa8 __arm64_sys_ioctl+0x1c/0x28 el0_svc_common.constprop.0+0x88/0x150 el0_svc_handler+0x28/0x78 el0_svc+0x8/0xc Code: 8a230000 54000060 d50b7e20 14000002 (d5087620) Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers") Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Sean Paul <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Rob Herring <[email protected]> Acked-by: Alyssa Rosenzweig <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-08-12drm/shmem: Put pages independent of a SG table being setRob Herring1-2/+2
If a driver does its own management of pages, the shmem helper object's pages array could be allocated when a SG table is not. There's not really any good reason to tie putting pages with having a SG table when freeing the object, so just put pages if the pages array is populated. Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Sean Paul <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Steven Price <[email protected]> Acked-by: Alyssa Rosenzweig <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-08-08drm/shmem: Add madvise state and purge helpersRob Herring1-0/+57
Add support to the shmem GEM helpers for tracking madvise state and purging pages. This is based on the msm implementation. The BO provides a list_head, but the list management is handled outside of the shmem helpers as there are different locking requirements. Cc: Tomeu Vizoso <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Sean Paul <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Eric Anholt <[email protected]> Acked-by: Acked-by: Alyssa Rosenzweig <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-07-19drm: direct include of drm.h in drm_gem_shmem_helper.cSam Ravnborg1-0/+1
Do not rely on including drm.h from drm_file.h, as the include in drm_file.h will be dropped. Signed-off-by: Sam Ravnborg <[email protected]> Reviewed-by: Sean Paul <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Eric Anholt <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-06-10drm/gem_shmem: Use a writecombine mapping for ->vaddrBoris Brezillon1-1/+2
Right now, the BO is mapped as a cached region when ->vmap() is called and the underlying object is not a dmabuf. Doing that makes cache management a bit more complicated (you'd need to call dma_map/unmap_sg() on the ->sgt field everytime the BO is about to be passed to the GPU/CPU), so let's map the BO with writecombine attributes instead (as done in most drivers). Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects") Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-04-01drm: shmem: Off by one in drm_gem_shmem_fault()Dan Carpenter1-1/+1
The shmem->pages[] array has "num_pages" elements so the > should be >= to prevent reading beyond the end of the array. The shmem->pages[] array is allocated in drm_gem_shmem_prime_import_sg_table(). Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Eric Anholt <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20190322064125.GA12551@kadam
2019-03-14drm: Add library for shmem backed GEM objectsNoralf Trønnes1-0/+625
This adds a library for shmem backed GEM objects. v8: - export drm_gem_shmem_create_with_handle - call mapping_set_gfp_mask to set default zone to GFP_HIGHUSER - Add helper drm_gem_shmem_get_pages_sgt() v7: - Use write-combine for mmap instead. This is the more common case. (robher) v6: - Fix uninitialized variable issue in an error path (anholt). - Add a drm_gem_shmem_vm_open() to the fops to get proper refcounting of the pages (anholt). v5: - Drop drm_gem_shmem_prime_mmap() (Daniel Vetter) - drm_gem_shmem_mmap(): Subtract drm_vma_node_start() to get the real vma->vm_pgoff - drm_gem_shmem_fault(): Use vmf->pgoff now that vma->vm_pgoff is correct v4: - Drop cache modes (Thomas Hellstrom) - Add a GEM attached vtable v3: - Grammar (Sam Ravnborg) - s/drm_gem_shmem_put_pages_unlocked/drm_gem_shmem_put_pages_locked/ (Sam Ravnborg) - Add debug output in error path (Sam Ravnborg) Signed-off-by: Noralf Trønnes <[email protected]> Signed-off-by: Eric Anholt <[email protected]> Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Eric Anholt <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]