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 |
|
#
11f38236 |
| 29-May-2023 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
drm: Don't assert held reservation lock for dma-buf mmapping
Don't assert held dma-buf reservation lock on memory mapping of exported buffer.
We're going to change dma-buf mmap() locking policy suc
drm: Don't assert held reservation lock for dma-buf mmapping
Don't assert held dma-buf reservation lock on memory mapping of exported buffer.
We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these drivers are moved to use reservation lock universally. The problem is solved by moving the lock down to exporters. This patch prepares DRM drivers for the locking policy update.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> 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/20230529223935.2672495-2-dmitry.osipenko@collabora.com Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-3-dmitry.osipenko@collabora.com Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-4-dmitry.osipenko@collabora.com Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-2-dmitry.osipenko@collabora.com Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-3-dmitry.osipenko@collabora.com Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-4-dmitry.osipenko@collabora.com
show more ...
|
Revision tags: 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 |
|
#
f75d1982 |
| 22-Mar-2023 |
Christian König <christian.koenig@amd.com> |
drm/tegra: Allow compile test on !ARM v2
This compile tests on x86 just perfectly fine.
v2: fix missing include complained by kernel test robot
Signed-off-by: Christian König <christian.koenig@amd
drm/tegra: Allow compile test on !ARM v2
This compile tests on x86 just perfectly fine.
v2: fix missing include complained by kernel test robot
Signed-off-by: Christian König <christian.koenig@amd.com> CC: Thierry Reding <thierry.reding@gmail.com> CC: Jonathan Hunter <jonathanh@nvidia.com> CC: linux-tegra@vger.kernel.org Signed-off-by: Thierry Reding <treding@nvidia.com>
show more ...
|
Revision tags: 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 |
|
#
1c71222e |
| 26-Jan-2023 |
Suren Baghdasaryan <surenb@google.com> |
mm: replace vma->vm_flags direct modifications with modifier calls
Replace direct modifications to vma->vm_flags with calls to modifier functions to be able to track flag changes and to keep vma loc
mm: replace vma->vm_flags direct modifications with modifier calls
Replace direct modifications to vma->vm_flags with calls to modifier functions to be able to track flag changes and to keep vma locking correctness.
[akpm@linux-foundation.org: fix drivers/misc/open-dice.c, per Hyeonggon Yoo] Link: https://lkml.kernel.org/r/20230126193752.297968-5-surenb@google.com Signed-off-by: Suren Baghdasaryan <surenb@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Mel Gorman <mgorman@techsingularity.net> Acked-by: Mike Rapoport (IBM) <rppt@kernel.org> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com> Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjun Roy <arjunroy@google.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: David Hildenbrand <david@redhat.com> Cc: David Howells <dhowells@redhat.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: David Rientjes <rientjes@google.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Greg Thelen <gthelen@google.com> Cc: Hugh Dickins <hughd@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: Joel Fernandes <joelaf@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: Laurent Dufour <ldufour@linux.ibm.com> Cc: Lorenzo Stoakes <lstoakes@gmail.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Minchan Kim <minchan@google.com> Cc: Paul E. McKenney <paulmck@kernel.org> Cc: Peter Oskolkov <posk@google.com> Cc: Peter Xu <peterx@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Punit Agrawal <punit.agrawal@bytedance.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Shakeel Butt <shakeelb@google.com> Cc: Soheil Hassas Yeganeh <soheil@google.com> Cc: Song Liu <songliubraving@fb.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
Revision tags: 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 |
|
#
39ce2529 |
| 10-Nov-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
drm: Assert held reservation lock for dma-buf mmapping
When userspace mmaps dma-buf's fd, the dma-buf reservation lock must be held. Add locking sanity checks to the dma-buf mmaping callbacks of DRM
drm: Assert held reservation lock for dma-buf mmapping
When userspace mmaps dma-buf's fd, the dma-buf reservation lock must be held. Add locking sanity checks to the dma-buf mmaping callbacks of DRM drivers to ensure that the locking assumptions won't regress in future.
Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221110201349.351294-3-dmitry.osipenko@collabora.com
show more ...
|
Revision tags: 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 |
|
#
f66d48c8 |
| 17-Oct-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
drm/tegra: Prepare to dynamic dma-buf locking specification
Prepare Tegra DRM driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API function
drm/tegra: Prepare to dynamic dma-buf locking specification
Prepare Tegra DRM driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions.
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-9-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 |
|
#
c7860cbe |
| 28-Jun-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
drm/tegra: Fix vmapping of prime buffers
The code assumes that Tegra GEM is permanently vmapped, which is not true for the scattered buffers. After converting Tegra video decoder driver to V4L API,
drm/tegra: Fix vmapping of prime buffers
The code assumes that Tegra GEM is permanently vmapped, which is not true for the scattered buffers. After converting Tegra video decoder driver to V4L API, we're now getting a BUG_ON from dma-buf core on playing video using libvdpau-tegra on T30+ because tegra_gem_prime_vmap() sets vaddr to NULL. Older pre-V4L video decoder driver wasn't vmapping dma-bufs. Fix it by actually vmapping the exported GEMs.
Cc: stable@vger.kernel.org Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
show more ...
|
Revision tags: 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 |
|
#
cb7e1abc |
| 06-May-2022 |
Thierry Reding <treding@nvidia.com> |
drm/tegra: gem: Do not try to dereference ERR_PTR()
When mapping the DMA-BUF attachment fails, map->sgt will be an ERR_PTR- encoded error code and the cleanup code would try to free that memory, whi
drm/tegra: gem: Do not try to dereference ERR_PTR()
When mapping the DMA-BUF attachment fails, map->sgt will be an ERR_PTR- encoded error code and the cleanup code would try to free that memory, which obviously would fail.
Zero out that pointer after extracting the error code when this happens so that kfree() can do the right thing.
Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
show more ...
|
Revision tags: 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, 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, 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, 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, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, 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 |
|
#
1f39b1df |
| 07-Feb-2020 |
Thierry Reding <treding@nvidia.com> |
drm/tegra: Implement buffer object cache
This cache is used to avoid mapping and unmapping buffer objects unnecessarily. Mappings are cached per client and stay hot until the buffer object is destro
drm/tegra: Implement buffer object cache
This cache is used to avoid mapping and unmapping buffer objects unnecessarily. Mappings are cached per client and stay hot until the buffer object is destroyed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
show more ...
|
#
c6aeaf56 |
| 09-Sep-2021 |
Thierry Reding <treding@nvidia.com> |
drm/tegra: Implement correct DMA-BUF semantics
DMA-BUF requires that each device that accesses a DMA-BUF attaches to it separately. To do so the host1x_bo_pin() and host1x_bo_unpin() functions need
drm/tegra: Implement correct DMA-BUF semantics
DMA-BUF requires that each device that accesses a DMA-BUF attaches to it separately. To do so the host1x_bo_pin() and host1x_bo_unpin() functions need to be reimplemented so that they can return a mapping, which either represents an attachment or a map of the driver's own GEM object.
Signed-off-by: Thierry Reding <treding@nvidia.com>
show more ...
|
#
16b0314a |
| 10-Oct-2021 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
dma-buf: move dma-buf symbols into the DMA_BUF module namespace
In order to better track where in the kernel the dma-buf code is used, put the symbols in the namespace DMA_BUF and modify all users o
dma-buf: move dma-buf symbols into the DMA_BUF module namespace
In order to better track where in the kernel the dma-buf code is used, put the symbols in the namespace DMA_BUF and modify all users of the symbols to properly import the namespace to not break the build at the same time.
Now the output of modinfo shows the use of these symbols, making it easier to watch for users over time:
$ modinfo drivers/misc/fastrpc.ko | grep import import_ns: DMA_BUF
Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: dri-devel@lists.freedesktop.org Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20211010124628.17691-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
f51632cc |
| 10-Jun-2021 |
Mikko Perttunen <mperttunen@nvidia.com> |
drm/tegra: Extract tegra_gem_lookup()
The static function host1x_bo_lookup() in drm.c is also useful elsewhere. Extract it as tegra_gem_lookup() in gem.c.
Signed-off-by: Mikko Perttunen <mperttunen
drm/tegra: Extract tegra_gem_lookup()
The static function host1x_bo_lookup() in drm.c is also useful elsewhere. Extract it as tegra_gem_lookup() in gem.c.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
show more ...
|
#
20e76f1a |
| 25-Sep-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces
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 ad
dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces
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 <tzimmermann@suse.de> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Tomasz Figa <tfiga@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-4-tzimmermann@suse.de
show more ...
|
#
6619ccf1 |
| 25-Sep-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces
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.
dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces
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 <tzimmermann@suse.de> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Tomasz Figa <tfiga@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-3-tzimmermann@suse.de
show more ...
|
#
dd311c6f |
| 23-Sep-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/tegra: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance call
drm/tegra: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in tegra.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-16-tzimmermann@suse.de
show more ...
|
#
d4fea3e6 |
| 28-Apr-2020 |
Marek Szyprowski <m.szyprowski@samsung.com> |
drm: tegra: fix common struct sg_table related issues
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. Ho
drm: tegra: fix common struct sg_table related issues
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 <m.szyprowski@samsung.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
show more ...
|
#
707d561f |
| 07-Sep-2020 |
Gerd Hoffmann <kraxel@redhat.com> |
drm: allow limiting the scatter list size.
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_f
drm: allow limiting the scatter list size.
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 <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20200907112425.15610-2-kraxel@redhat.com
show more ...
|
#
b8912e29 |
| 15-May-2020 |
Emil Velikov <emil.velikov@collabora.com> |
drm/tegra: 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)
drm/tegra: 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: Thierry Reding <thierry.reding@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200515095118.2743122-32-emil.l.velikov@gmail.com
show more ...
|
Revision tags: v5.4.18 |
|
#
273da5a0 |
| 04-Feb-2020 |
Thierry Reding <treding@nvidia.com> |
drm/tegra: Reuse IOVA mapping where possible
This partially reverts the DMA API support that was recently merged because it was causing performance regressions on older Tegra devices. Unfortunately,
drm/tegra: Reuse IOVA mapping where possible
This partially reverts the DMA API support that was recently merged because it was causing performance regressions on older Tegra devices. Unfortunately, the cache maintenance performed by dma_map_sg() and dma_unmap_sg() causes performance to drop by a factor of 10.
The right solution for this would be to cache mappings for buffers per consumer device, but that's a bit involved. Instead, we simply revert to the old behaviour of sharing IOVA mappings when we know that devices can do so (i.e. they share the same IOMMU domain).
Cc: <stable@vger.kernel.org> # v5.5 Reported-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
show more ...
|
Revision tags: v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, 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 |
|
#
49f82191 |
| 03-Dec-2019 |
Thierry Reding <treding@nvidia.com> |
drm/tegra: gem: Remove premature import restrictions
All the display related blocks on Tegra require contiguous memory. Using the DMA API, there is no knowing at import time which device will end up
drm/tegra: gem: Remove premature import restrictions
All the display related blocks on Tegra require contiguous memory. Using the DMA API, there is no knowing at import time which device will end up using the buffer, so it's not known whether or not an IOMMU will be used to map the buffer.
Move the check for non-contiguous buffers/mappings to the tegra_dc_pin() function which is now the earliest point where it is known if a DMA BUF can be used by the given device or not.
v2: add check for contiguous buffer/mapping in tegra_dc_pin()
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com>
show more ...
|
#
1f16deac |
| 03-Dec-2019 |
Thierry Reding <treding@nvidia.com> |
drm/tegra: gem: Properly pin imported buffers
Buffers that are imported from a DMA-BUF don't have pages allocated with them. At the same time an SG table for them can't be derived using the DMA API
drm/tegra: gem: Properly pin imported buffers
Buffers that are imported from a DMA-BUF don't have pages allocated with them. At the same time an SG table for them can't be derived using the DMA API helpers because the necessary information doesn't exist. However there's already an SG table that was created during import, so this can simply be duplicated.
Signed-off-by: Thierry Reding <treding@nvidia.com>
show more ...
|
Revision tags: v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12 |
|
#
7195cf42 |
| 18-Nov-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/tegra: Remove dma_buf->k(un)map
No in-tree users left.
Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Sumit Semwal <sumit.semwal@linar
drm/tegra: Remove dma_buf->k(un)map
No in-tree users left.
Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-tegra@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20191118103536.17675-9-daniel.vetter@ffwll.ch
show more ...
|
#
35bd71dd |
| 18-Nov-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/tegra: Delete host1x_bo_ops->k(un)map
It doesn't have any callers anymore.
Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't do userspace mmaps, but a kernel vmap. I think
drm/tegra: Delete host1x_bo_ops->k(un)map
It doesn't have any callers anymore.
Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't do userspace mmaps, but a kernel vmap. I think most places use vmap for this, except ttm, which uses kmap for vmap for added confusion. mmap seems entirely for userspace mappings set up through mmap(2) syscall.
Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-tegra@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20191118103536.17675-3-daniel.vetter@ffwll.ch
show more ...
|
Revision tags: v5.3.11, v5.3.10, v5.3.9, v5.3.8 |
|
#
af1cbfb9 |
| 28-Oct-2019 |
Thierry Reding <treding@nvidia.com> |
gpu: host1x: Support DMA mapping of buffers
If host1x_bo_pin() returns an SG table, create a DMA mapping for the buffer. For buffers that the host1x client has already mapped itself, host1x_bo_pin()
gpu: host1x: Support DMA mapping of buffers
If host1x_bo_pin() returns an SG table, create a DMA mapping for the buffer. For buffers that the host1x client has already mapped itself, host1x_bo_pin() returns NULL and the existing DMA address is used.
Signed-off-by: Thierry Reding <treding@nvidia.com>
show more ...
|
#
80327ce3 |
| 28-Oct-2019 |
Thierry Reding <treding@nvidia.com> |
gpu: host1x: Overhaul host1x_bo_{pin,unpin}() API
The host1x_bo_pin() and host1x_bo_unpin() APIs are used to pin and unpin buffers during host1x job submission. Pinning currently returns the SG tabl
gpu: host1x: Overhaul host1x_bo_{pin,unpin}() API
The host1x_bo_pin() and host1x_bo_unpin() APIs are used to pin and unpin buffers during host1x job submission. Pinning currently returns the SG table and the DMA address (an IOVA if an IOMMU is used or a physical address if no IOMMU is used) of the buffer. The DMA address is only used for buffers that are relocated, whereas the host1x driver will map gather buffers into its own IOVA space so that they can be processed by the CDMA engine.
This approach has a couple of issues. On one hand it's not very useful to return a DMA address for the buffer if host1x doesn't need it. On the other hand, returning the SG table of the buffer is suboptimal because a single SG table cannot be shared for multiple mappings, because the DMA address is stored within the SG table, and the DMA address may be different for different devices.
Subsequent patches will move the host1x driver over to the DMA API which doesn't work with a single shared SG table. Fix this by returning a new SG table each time a buffer is pinned. This allows the buffer to be referenced by multiple jobs for different engines.
Change the prototypes of host1x_bo_pin() and host1x_bo_unpin() to take a struct device *, specifying the device for which the buffer should be pinned. This is required in order to be able to properly construct the SG table. While at it, make host1x_bo_pin() return the SG table because that allows us to return an ERR_PTR()-encoded error code if we need to, or return NULL to signal that we don't need the SG table to be remapped and can simply use the DMA address as-is. At the same time, returning the DMA address is made optional because in the example of command buffers, host1x doesn't need to know the DMA address since it will have to create its own mapping anyway.
Signed-off-by: Thierry Reding <treding@nvidia.com>
show more ...
|