Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3 |
|
#
79e2cf2e |
| 17-Oct-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
drm/gem: Take reservation lock for vmap/vunmap operations
The new common dma-buf locking convention will require buffer importers to hold the reservation lock around mapping operations. Make DRM GEM
drm/gem: Take reservation lock for vmap/vunmap operations
The new common dma-buf locking convention will require buffer importers to hold the reservation lock around mapping operations. Make DRM GEM core to take the lock around the vmapping operations and update DRM drivers to use the locked functions for the case where DRM core now holds the lock. This patch prepares DRM core and drivers to the common dynamic dma-buf locking convention.
Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221017172229.42269-4-dmitry.osipenko@collabora.com
show more ...
|
Revision tags: v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20 |
|
#
7938f421 |
| 04-Feb-2022 |
Lucas De Marchi <lucas.demarchi@intel.com> |
dma-buf-map: Rename to iosys-map
Rename struct dma_buf_map to struct iosys_map and corresponding APIs. Over time dma-buf-map grew up to more functionality than the one used by dma-buf: in fact it's
dma-buf-map: Rename to iosys-map
Rename struct dma_buf_map to struct iosys_map and corresponding APIs. Over time dma-buf-map grew up to more functionality than the one used by dma-buf: in fact it's just a shim layer to abstract system memory, that can be accessed via regular load and store, from IO memory that needs to be acessed via arch helpers.
The idea is to extend this API so it can fulfill other needs, internal to a single driver. Example: in the i915 driver it's desired to share the implementation for integrated graphics, which uses mostly system memory, with discrete graphics, which may need to access IO memory.
The conversion was mostly done with the following semantic patch:
@r1@ @@ - struct dma_buf_map + struct iosys_map
@r2@ @@ ( - DMA_BUF_MAP_INIT_VADDR + IOSYS_MAP_INIT_VADDR | - dma_buf_map_set_vaddr + iosys_map_set_vaddr | - dma_buf_map_set_vaddr_iomem + iosys_map_set_vaddr_iomem | - dma_buf_map_is_equal + iosys_map_is_equal | - dma_buf_map_is_null + iosys_map_is_null | - dma_buf_map_is_set + iosys_map_is_set | - dma_buf_map_clear + iosys_map_clear | - dma_buf_map_memcpy_to + iosys_map_memcpy_to | - dma_buf_map_incr + iosys_map_incr )
@@ @@ - #include <linux/dma-buf-map.h> + #include <linux/iosys-map.h>
Then some files had their includes adjusted and some comments were update to remove mentions to dma-buf-map.
Since this is not specific to dma-buf anymore, move the documentation to the "Bus-Independent Device Accesses" section.
v2: - Squash patches
v3: - Fix wrong removal of dma-buf.h from MAINTAINERS - Move documentation from dma-buf.rst to device-io.rst
v4: - Change documentation title and level
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220204170541.829227-1-lucas.demarchi@intel.com
show more ...
|
Revision tags: v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2 |
|
#
a193f3b4 |
| 08-Nov-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/shmem-helper: Pass GEM shmem object in public interfaces
Change all GEM SHMEM object functions that receive a GEM object of type struct drm_gem_object to expect an object of type struct drm_gem_
drm/shmem-helper: Pass GEM shmem object in public interfaces
Change all GEM SHMEM object functions that receive a GEM object of type struct drm_gem_object to expect an object of type struct drm_gem_shmem_object instead.
This change reduces the number of upcasts from struct drm_gem_object by moving them into callers. The C compiler can now verify that the GEM SHMEM functions are called with the correct type.
For consistency, the patch also renames drm_gem_shmem_free_object to drm_gem_shmem_free. It further updates documentation for a number of functions.
v3: * fix docs for drm_gem_shmem_object_free() v2: * mention _object_ callbacks in docs (Daniel)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211108093149.7226-4-tzimmermann@suse.de
show more ...
|
Revision tags: v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61 |
|
#
e9ae220d |
| 25-Aug-2021 |
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> |
drm/panfrost: Use upper/lower_32_bits helpers
Use upper_32_bits/lower_32_bits helpers instead of open-coding them. This is easier to scan quickly compared to bitwise manipulation, and it is pleasing
drm/panfrost: Use upper/lower_32_bits helpers
Use upper_32_bits/lower_32_bits helpers instead of open-coding them. This is easier to scan quickly compared to bitwise manipulation, and it is pleasingly symmetric. I noticed this when debugging lock_region, which had a particularly "creative" way of writing upper_32_bits.
v2: Use helpers for one more call site and add review tag (Steven).
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Rob Herring <robh@kernel.org> (v1) Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210825153348.4980-1-alyssa.rosenzweig@collabora.com
show more ...
|
#
ff0087df |
| 08-Nov-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/shmem-helper: Pass GEM shmem object in public interfaces
[ Upstream commit a193f3b4e050e35c506a34d0870c838d8e0b0449 ]
Change all GEM SHMEM object functions that receive a GEM object of type str
drm/shmem-helper: Pass GEM shmem object in public interfaces
[ Upstream commit a193f3b4e050e35c506a34d0870c838d8e0b0449 ]
Change all GEM SHMEM object functions that receive a GEM object of type struct drm_gem_object to expect an object of type struct drm_gem_shmem_object instead.
This change reduces the number of upcasts from struct drm_gem_object by moving them into callers. The C compiler can now verify that the GEM SHMEM functions are called with the correct type.
For consistency, the patch also renames drm_gem_shmem_free_object to drm_gem_shmem_free. It further updates documentation for a number of functions.
v3: * fix docs for drm_gem_shmem_object_free() v2: * mention _object_ callbacks in docs (Daniel)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211108093149.7226-4-tzimmermann@suse.de Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
49a3f51d |
| 03-Nov-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends
This patch replaces the vmap/vunmap's use of raw pointers in GEM object functions with instances of struct dma_buf_map. GEM b
drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends
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 <tzimmermann@suse.de> Acked-by: Christian König <christian.koenig@amd.com> Tested-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-7-tzimmermann@suse.de
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47 |
|
#
9df0e0c1 |
| 14-Jun-2020 |
Navid Emamdoost <navid.emamdoost@gmail.com> |
drm/panfrost: perfcnt: fix ref count leak in panfrost_perfcnt_enable_locked
in panfrost_perfcnt_enable_locked, pm_runtime_get_sync is called which increments the counter even in case of failure, lea
drm/panfrost: perfcnt: fix ref count leak in panfrost_perfcnt_enable_locked
in panfrost_perfcnt_enable_locked, pm_runtime_get_sync is called which increments the counter even in case of failure, leading to incorrect ref count. In case of failure, decrement the ref count before returning.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200614063619.44944-1-navid.emamdoost@gmail.com
show more ...
|
Revision tags: v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42 |
|
#
496d0cc6 |
| 15-May-2020 |
Emil Velikov <emil.velikov@collabora.com> |
drm/panfrost: remove _unlocked suffix in drm_gem_object_put_unlocked
Spelling out _unlocked for each and every driver is a annoying. Especially if we consider how many drivers, do not know (or need
drm/panfrost: remove _unlocked suffix in drm_gem_object_put_unlocked
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
Cc: Rob Herring <robh@kernel.org> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Steven Price <steven.price@arm.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200515095118.2743122-28-emil.l.velikov@gmail.com
show more ...
|
Revision tags: v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19 |
|
#
dde2bb2d |
| 06-Feb-2020 |
Boris Brezillon <boris.brezillon@collabora.com> |
drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context
We need to use the AS attached to the opened FD when dumping counters.
Reported-by: Antonio Caggiano <antonio.caggiano@
drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context
We need to use the AS attached to the opened FD when dumping counters.
Reported-by: Antonio Caggiano <antonio.caggiano@collabora.com> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: <stable@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Tested-by: Antonio Caggiano <antonio.caggiano@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200206141327.446127-1-boris.brezillon@collabora.com
show more ...
|
Revision tags: v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13 |
|
#
bdefca2d |
| 15-Jan-2020 |
Boris Brezillon <boris.brezillon@collabora.com> |
drm/panfrost: Add the panfrost_gem_mapping concept
With the introduction of per-FD address space, the same BO can be mapped in different address space if the BO is globally visible (GEM_FLINK) and o
drm/panfrost: Add the panfrost_gem_mapping concept
With the introduction of per-FD address space, the same BO can be mapped in different address space if the BO is globally visible (GEM_FLINK) and opened in different context or if the dmabuf is self-imported. The current implementation does not take case into account, and attaches the mapping directly to the panfrost_gem_object.
Let's create a panfrost_gem_mapping struct and allow multiple mappings per BO.
The mappings are refcounted which helps solve another problem where mappings were torn down (GEM handle closed by userspace) while GPU jobs accessing those BOs were still in-flight. Jobs now keep a reference on the mappings they use.
v2 (robh): - Minor review comment clean-ups from Steven - Use list_is_singular helper - Just WARN if we add a mapping when madvise state is not WILLNEED. With that, drop the use of object_name_lock.
v3 (robh): - Revert returning list iterator in panfrost_gem_mapping_get()
Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: <stable@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116021554.15090-1-robh@kernel.org
show more ...
|
Revision tags: v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2 |
|
#
0a523998 |
| 29-Nov-2019 |
Boris Brezillon <boris.brezillon@collabora.com> |
drm/panfrost: Open/close the perfcnt BO
Commit a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") moved the drm_mm_insert_node_generic() call to the gem->open() hook, but forgot to u
drm/panfrost: Open/close the perfcnt BO
Commit a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") moved the drm_mm_insert_node_generic() call to the gem->open() hook, but forgot to update perfcnt accordingly.
Patch the perfcnt logic to call panfrost_gem_open/close() where appropriate.
Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") Cc: <stable@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191129135908.2439529-6-boris.brezillon@collabora.com
show more ...
|
Revision tags: v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8 |
|
#
6f39188c |
| 24-Oct-2019 |
Yi Wang <wang.yi59@zte.com.cn> |
drm/panfrost: fix -Wmissing-prototypes warnings
We get these warnings when build kernel W=1: drivers/gpu/drm/panfrost/panfrost_perfcnt.c:35:6: warning: no previous prototype for ‘panfrost_perfcnt_cl
drm/panfrost: fix -Wmissing-prototypes warnings
We get these warnings when build kernel W=1: drivers/gpu/drm/panfrost/panfrost_perfcnt.c:35:6: warning: no previous prototype for ‘panfrost_perfcnt_clean_cache_done’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_perfcnt.c:40:6: warning: no previous prototype for ‘panfrost_perfcnt_sample_done’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_perfcnt.c:190:5: warning: no previous prototype for ‘panfrost_ioctl_perfcnt_enable’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_perfcnt.c:218:5: warning: no previous prototype for ‘panfrost_ioctl_perfcnt_dump’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_perfcnt.c:250:6: warning: no previous prototype for ‘panfrost_perfcnt_close’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_perfcnt.c:264:5: warning: no previous prototype for ‘panfrost_perfcnt_init’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_perfcnt.c:320:6: warning: no previous prototype for ‘panfrost_perfcnt_fini’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_mmu.c:227:6: warning: no previous prototype for ‘panfrost_mmu_flush_range’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_mmu.c:435:5: warning: no previous prototype for ‘panfrost_mmu_map_fault_addr’ [-Wmissing-prototypes]
For file panfrost_mmu.c, make functions static to fix this. For file panfrost_perfcnt.c, include header file can fix this.
Signed-off-by: Yi Wang <wang.yi59@zte.com.cn> Reviewed-by: Steven Price <steven.price@arm.com> Cc: stable@vger.kernel.org [robh: fixup function parameter alignment] Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/1571967015-42854-1-git-send-email-wang.yi59@zte.com.cn
show more ...
|
Revision tags: v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12 |
|
#
7786fd10 |
| 18-Jun-2019 |
Boris Brezillon <boris.brezillon@collabora.com> |
drm/panfrost: Expose performance counters through unstable ioctls
Expose performance counters through 2 driver specific ioctls: one to enable/disable the perfcnt block, and one to dump the counter v
drm/panfrost: Expose performance counters through unstable ioctls
Expose performance counters through 2 driver specific ioctls: one to enable/disable the perfcnt block, and one to dump the counter values.
There are discussions to expose global performance monitors (those counters that can't be retrieved on a per-job basis) in a consistent way, but this is likely to take time to settle on something that works for various HW/users. The ioctls are marked unstable so we can get rid of them when the time comes. We initally went for a debugfs-based interface, but this was making the transition to per-FD address space more complicated (we need to specify the namespace the GPU has to use when dumping the perf counters), hence the decision to switch back to driver specific ioctls which are passed the FD they operate on and thus will have a dedicated address space attached to them.
Other than that, the implementation is pretty simple: it basically dumps all counters and copy the values to a userspace buffer. The parsing is left to userspace which has to know the specific layout that's used by the GPU (layout differs on a per-revision basis).
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190618081648.17297-5-boris.brezillon@collabora.com
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47 |
|
#
9df0e0c1 |
| 14-Jun-2020 |
Navid Emamdoost <navid.emamdoost@gmail.com> |
drm/panfrost: perfcnt: fix ref count leak in panfrost_perfcnt_enable_locked in panfrost_perfcnt_enable_locked, pm_runtime_get_sync is called which increments the counter even in case of
drm/panfrost: perfcnt: fix ref count leak in panfrost_perfcnt_enable_locked in panfrost_perfcnt_enable_locked, pm_runtime_get_sync is called which increments the counter even in case of failure, leading to incorrect ref count. In case of failure, decrement the ref count before returning. Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200614063619.44944-1-navid.emamdoost@gmail.com
show more ...
|
Revision tags: v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42 |
|
#
496d0cc6 |
| 15-May-2020 |
Emil Velikov <emil.velikov@collabora.com> |
drm/panfrost: remove _unlocked suffix in drm_gem_object_put_unlocked Spelling out _unlocked for each and every driver is a annoying. Especially if we consider how many drivers, do not kn
drm/panfrost: remove _unlocked suffix in drm_gem_object_put_unlocked 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 Cc: Rob Herring <robh@kernel.org> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Steven Price <steven.price@arm.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200515095118.2743122-28-emil.l.velikov@gmail.com
show more ...
|
Revision tags: v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19 |
|
#
dde2bb2d |
| 06-Feb-2020 |
Boris Brezillon <boris.brezillon@collabora.com> |
drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context We need to use the AS attached to the opened FD when dumping counters. Reported-by: Antonio Caggiano <a
drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context We need to use the AS attached to the opened FD when dumping counters. Reported-by: Antonio Caggiano <antonio.caggiano@collabora.com> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: <stable@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Tested-by: Antonio Caggiano <antonio.caggiano@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200206141327.446127-1-boris.brezillon@collabora.com
show more ...
|
Revision tags: v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13 |
|
#
bdefca2d |
| 15-Jan-2020 |
Boris Brezillon <boris.brezillon@collabora.com> |
drm/panfrost: Add the panfrost_gem_mapping concept With the introduction of per-FD address space, the same BO can be mapped in different address space if the BO is globally visible (GEM_
drm/panfrost: Add the panfrost_gem_mapping concept With the introduction of per-FD address space, the same BO can be mapped in different address space if the BO is globally visible (GEM_FLINK) and opened in different context or if the dmabuf is self-imported. The current implementation does not take case into account, and attaches the mapping directly to the panfrost_gem_object. Let's create a panfrost_gem_mapping struct and allow multiple mappings per BO. The mappings are refcounted which helps solve another problem where mappings were torn down (GEM handle closed by userspace) while GPU jobs accessing those BOs were still in-flight. Jobs now keep a reference on the mappings they use. v2 (robh): - Minor review comment clean-ups from Steven - Use list_is_singular helper - Just WARN if we add a mapping when madvise state is not WILLNEED. With that, drop the use of object_name_lock. v3 (robh): - Revert returning list iterator in panfrost_gem_mapping_get() Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: <stable@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116021554.15090-1-robh@kernel.org
show more ...
|
#
7315c0ed |
| 12-Dec-2019 |
Dave Airlie <airlied@redhat.com> |
Merge tag 'drm-misc-next-fixes-2019-12-12' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes -mgag200: more startadd mitigation (Thomas) -panfrost: devfreq fix + several memor
Merge tag 'drm-misc-next-fixes-2019-12-12' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes -mgag200: more startadd mitigation (Thomas) -panfrost: devfreq fix + several memory fixes (Steven, Boris) Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20191212140145.GA145200@art_vandelay
show more ...
|
Revision tags: v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2 |
|
#
0a523998 |
| 29-Nov-2019 |
Boris Brezillon <boris.brezillon@collabora.com> |
drm/panfrost: Open/close the perfcnt BO Commit a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") moved the drm_mm_insert_node_generic() call to the gem->open() hook,
drm/panfrost: Open/close the perfcnt BO Commit a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") moved the drm_mm_insert_node_generic() call to the gem->open() hook, but forgot to update perfcnt accordingly. Patch the perfcnt logic to call panfrost_gem_open/close() where appropriate. Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") Cc: <stable@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191129135908.2439529-6-boris.brezillon@collabora.com
show more ...
|
Revision tags: v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8 |
|
#
6f39188c |
| 24-Oct-2019 |
Yi Wang <wang.yi59@zte.com.cn> |
drm/panfrost: fix -Wmissing-prototypes warnings We get these warnings when build kernel W=1: drivers/gpu/drm/panfrost/panfrost_perfcnt.c:35:6: warning: no previous prototype for ‘panfros
drm/panfrost: fix -Wmissing-prototypes warnings We get these warnings when build kernel W=1: drivers/gpu/drm/panfrost/panfrost_perfcnt.c:35:6: warning: no previous prototype for ‘panfrost_perfcnt_clean_cache_done’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_perfcnt.c:40:6: warning: no previous prototype for ‘panfrost_perfcnt_sample_done’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_perfcnt.c:190:5: warning: no previous prototype for ‘panfrost_ioctl_perfcnt_enable’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_perfcnt.c:218:5: warning: no previous prototype for ‘panfrost_ioctl_perfcnt_dump’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_perfcnt.c:250:6: warning: no previous prototype for ‘panfrost_perfcnt_close’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_perfcnt.c:264:5: warning: no previous prototype for ‘panfrost_perfcnt_init’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_perfcnt.c:320:6: warning: no previous prototype for ‘panfrost_perfcnt_fini’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_mmu.c:227:6: warning: no previous prototype for ‘panfrost_mmu_flush_range’ [-Wmissing-prototypes] drivers/gpu/drm/panfrost/panfrost_mmu.c:435:5: warning: no previous prototype for ‘panfrost_mmu_map_fault_addr’ [-Wmissing-prototypes] For file panfrost_mmu.c, make functions static to fix this. For file panfrost_perfcnt.c, include header file can fix this. Signed-off-by: Yi Wang <wang.yi59@zte.com.cn> Reviewed-by: Steven Price <steven.price@arm.com> Cc: stable@vger.kernel.org [robh: fixup function parameter alignment] Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/1571967015-42854-1-git-send-email-wang.yi59@zte.com.cn
show more ...
|
Revision tags: v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12 |
|
#
7786fd10 |
| 18-Jun-2019 |
Boris Brezillon <boris.brezillon@collabora.com> |
drm/panfrost: Expose performance counters through unstable ioctls Expose performance counters through 2 driver specific ioctls: one to enable/disable the perfcnt block, and one to dump t
drm/panfrost: Expose performance counters through unstable ioctls Expose performance counters through 2 driver specific ioctls: one to enable/disable the perfcnt block, and one to dump the counter values. There are discussions to expose global performance monitors (those counters that can't be retrieved on a per-job basis) in a consistent way, but this is likely to take time to settle on something that works for various HW/users. The ioctls are marked unstable so we can get rid of them when the time comes. We initally went for a debugfs-based interface, but this was making the transition to per-FD address space more complicated (we need to specify the namespace the GPU has to use when dumping the perf counters), hence the decision to switch back to driver specific ioctls which are passed the FD they operate on and thus will have a dedicated address space attached to them. Other than that, the implementation is pretty simple: it basically dumps all counters and copy the values to a userspace buffer. The parsing is left to userspace which has to know the specific layout that's used by the GPU (layout differs on a per-revision basis). Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190618081648.17297-5-boris.brezillon@collabora.com
show more ...
|