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 |
|
#
d71c11cc |
| 28-Feb-2023 |
Rob Clark <robdclark@chromium.org> |
dma-buf/sync_file: Surface sync-file uABI
We had all of the internal driver APIs, but not the all important userspace uABI, in the dma-buf doc. Fix that. And re-arrange the comments slightly as ot
dma-buf/sync_file: Surface sync-file uABI
We had all of the internal driver APIs, but not the all important userspace uABI, in the dma-buf doc. Fix that. And re-arrange the comments slightly as otherwise the comments for the ioctl nr defines would not show up.
v2: Fix docs build warning coming from newly including the uabi header in the docs build
Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
show more ...
|
Revision tags: 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, 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, 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 |
|
#
aec11c8d |
| 03-Sep-2021 |
Rob Clark <robdclark@chromium.org> |
dma-buf/dma-fence: Add deadline awareness
Add a way to hint to the fence signaler of an upcoming deadline, such as vblank, which the fence waiter would prefer not to miss. This is to aid the fence
dma-buf/dma-fence: Add deadline awareness
Add a way to hint to the fence signaler of an upcoming deadline, such as vblank, which the fence waiter would prefer not to miss. This is to aid the fence signaler in making power management decisions, like boosting frequency as the deadline approaches and awareness of missing deadlines so that can be factored in to the frequency scaling.
v2: Drop dma_fence::deadline and related logic to filter duplicate deadlines, to avoid increasing dma_fence size. The fence-context implementation will need similar logic to track deadlines of all the fences on the same timeline. [ckoenig] v3: Clarify locking wrt. set_deadline callback v4: Clarify in docs comment that this is a hint v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. v6: More docs v7: Fix typo, clarify past deadlines
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
show more ...
|
#
7852fe3a |
| 29-Jan-2023 |
Randy Dunlap <rdunlap@infradead.org> |
Documentation: driver-api: correct spelling
Correct spelling problems for Documentation/driver-api/ as reported by codespell.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Mauro Carvalho
Documentation: driver-api: correct spelling
Correct spelling problems for Documentation/driver-api/ as reported by codespell.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: linux-media@vger.kernel.org Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: nvdimm@lists.linux.dev Cc: Vinod Koul <vkoul@kernel.org> Cc: dmaengine@vger.kernel.org Cc: linux-raid@vger.kernel.org Cc: linux-usb@vger.kernel.org Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Song Liu <song@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20230129231053.20863-3-rdunlap@infradead.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
show more ...
|
#
7ee6095f |
| 29-Jan-2023 |
Jonathan Neuschäfer <j.neuschaefer@gmx.net> |
dma-buf: Add "dma-buf" to title of documentation
To make it easier to find the dma-buf documentation when looking through tables-of-contents etc., put the name "dma-buf" in the title.
Signed-off-by
dma-buf: Add "dma-buf" to title of documentation
To make it easier to find the dma-buf documentation when looking through tables-of-contents etc., put the name "dma-buf" in the title.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Link: https://lore.kernel.org/r/20230129115917.1229529-1-j.neuschaefer@gmx.net Signed-off-by: Jonathan Corbet <corbet@lwn.net>
show more ...
|
#
ae2e7f28 |
| 17-Oct-2022 |
Dmitry Osipenko <dmitry.osipenko@collabora.com> |
dma-buf: Document dynamic locking convention
Add documentation for the dynamic locking convention. The documentation tells dma-buf API users when they should take the reservation lock and when not.
dma-buf: Document dynamic locking convention
Add documentation for the dynamic locking convention. The documentation tells dma-buf API users when they should take the reservation lock and when not.
Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Reviewed-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-20-dmitry.osipenko@collabora.com
show more ...
|
#
64a8f92f |
| 11-Mar-2022 |
Christian König <christian.koenig@amd.com> |
dma-buf: add dma_fence_unwrap v2
Add a general purpose helper to deep dive into dma_fence_chain/dma_fence_array structures and iterate over all the fences in them.
This is useful when we need to fl
dma-buf: add dma_fence_unwrap v2
Add a general purpose helper to deep dive into dma_fence_chain/dma_fence_array structures and iterate over all the fences in them.
This is useful when we need to flatten out all fences in those structures.
v2: some selftests cleanup, improved function naming and documentation
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220311110244.1245-1-christian.koenig@amd.com
show more ...
|
#
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.14.1, v5.10.62 |
|
#
cba3ae8b |
| 01-Sep-2021 |
Christian König <christian.koenig@amd.com> |
dma-buf: cleanup kerneldoc of removed component
The seqno-fence was removed, cleanup the kerneldoc include as well.
Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Sumit Semwal
dma-buf: cleanup kerneldoc of removed component
The seqno-fence was removed, cleanup the kerneldoc include as well.
Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Fixes: 992c238188a8 ("dma-buf: nuke seqno-fence") Link: https://patchwork.freedesktop.org/patch/msgid/20210901080002.5892-1-christian.koenig@amd.com
show more ...
|
Revision tags: 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 |
|
#
51f52547 |
| 17-Jun-2021 |
Jason Ekstrand <jason@jlekstrand.net> |
dma-buf: Document DMA_BUF_IOCTL_SYNC (v3)
This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds documentation for DMA_BUF_IOCTL_SYNC.
v2 (Daniel Vetter): - Fix a couple typos -
dma-buf: Document DMA_BUF_IOCTL_SYNC (v3)
This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds documentation for DMA_BUF_IOCTL_SYNC.
v2 (Daniel Vetter): - Fix a couple typos - Add commentary about synchronization with other devices - Use item list format for describing flags
v3 (Pekka Paalanen): - Clarify stalling requirements. - Be more clear that that DMA_BUF_IOCTL_SYNC with SINC_END has to be called before more GPU work happens.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210617194258.579011-1-jason@jlekstrand.net
show more ...
|
Revision tags: v5.10.43 |
|
#
bdb8d06d |
| 03-Jun-2021 |
Hridya Valsaraju <hridya@google.com> |
dmabuf: Add the capability to expose DMA-BUF stats in sysfs
Overview ======== The patch adds DMA-BUF statistics to /sys/kernel/dmabuf/buffers. It allows statistics to be enabled for each DMA-BUF in
dmabuf: Add the capability to expose DMA-BUF stats in sysfs
Overview ======== The patch adds DMA-BUF statistics to /sys/kernel/dmabuf/buffers. It allows statistics to be enabled for each DMA-BUF in sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS.
The following stats will be exposed by the interface:
/sys/kernel/dmabuf/buffers/<inode_number>/exporter_name /sys/kernel/dmabuf/buffers/<inode_number>/size /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/map_counter
The inode_number is unique for each DMA-BUF and was added earlier [1] in order to allow userspace to track DMA-BUF usage across different processes.
Use Cases ========= The interface provides a way to gather DMA-BUF per-buffer statistics from production devices. These statistics will be used to derive DMA-BUF per-exporter stats and per-device usage stats for Android Bug reports. The corresponding userspace changes can be found at [2]. Telemetry tools will also capture this information(along with other memory metrics) periodically as well as on important events like a foreground app kill (which might have been triggered by Low Memory Killer). It will also contribute to provide a snapshot of the system memory usage on other events such as OOM kills and Application Not Responding events.
Background ========== Currently, there are two existing interfaces that provide information about DMA-BUFs. 1) /sys/kernel/debug/dma_buf/bufinfo debugfs is however unsuitable to be mounted in production systems and cannot be considered as an alternative to the sysfs interface being proposed. 2) proc/<pid>/fdinfo/<fd> The proc/<pid>/fdinfo/<fd> files expose information about DMA-BUF fds. However, the existing procfs interfaces can only provide information about the buffers for which processes hold fds or have the buffers mmapped into their address space. Since the procfs interfaces alone cannot provide a full picture of all DMA-BUFs in the system, there is the need for an alternate interface to provide this information on production systems.
The patch contains the following major improvements over v1: 1) Each attachment is represented by its own directory to allow creating a symlink to the importing device and to also provide room for future expansion. 2) The number of distinct mappings of each attachment is exposed in a separate file. 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers inorder to make the interface expandable in future.
All of the improvements above are based on suggestions/feedback from Daniel Vetter and Christian König.
A shell script that can be run on a classic Linux environment to read out the DMA-BUF statistics can be found at [3](suggested by John Stultz).
[1]: https://lore.kernel.org/patchwork/patch/1088791/ [2]: https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) [3]: https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Hridya Valsaraju <hridya@google.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603214758.2955251-1-hridya@google.com
show more ...
|
Revision tags: v5.10.42, v5.10.41, v5.10.40, v5.10.39 |
|
#
b970b8e9 |
| 21-May-2021 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/doc: Include fence chain api
We have this nice kerneldoc, but forgot to include it.
Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com
drm/doc: Include fence chain api
We have this nice kerneldoc, but forgot to include it.
Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20210521082457.1656333-1-daniel.vetter@ffwll.ch
show more ...
|
Revision tags: 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 |
|
#
8613385c |
| 03-Feb-2021 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
dma-fence: Document recoverable page fault implications
Recently there was a fairly long thread about recoreable hardware page faults, how they can deadlock, and what to do about that.
While the di
dma-fence: Document recoverable page fault implications
Recently there was a fairly long thread about recoreable hardware page faults, how they can deadlock, and what to do about that.
While the discussion is still fresh I figured good time to try and document the conclusions a bit. This documentation section explains what's the potential problem, and the remedies we've discussed, roughly ordered from best to worst.
v2: Linus -> Linux typoe (Dave)
v3: - Make it clear drivers only need to implement one option (Christian) - Make it clearer that implicit sync is out the window with exclusive fences (Christian) - Add the fairly theoretical option of segementing the memory (either statically or through dynamic checks at runtime for which piece of memory is managed how) and explain why it's not a great idea (Felix)
References: https://lore.kernel.org/dri-devel/20210107030127.20393-1-Felix.Kuehling@amd.com/ Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> c: Dave Airlie <airlied@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom@intel.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Jerome Glisse <jglisse@redhat.com> Cc: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20210203152921.2429937-1-daniel.vetter@ffwll.ch
show more ...
|
Revision tags: v5.10 |
|
#
26e08a6d |
| 04-Dec-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
dma-buf: Fix kerneldoc formatting
I wanted to look up something and noticed the hyperlink doesn't work. While fixing that also noticed a trivial kerneldoc comment typo in the same section, fix that
dma-buf: Fix kerneldoc formatting
I wanted to look up something and noticed the hyperlink doesn't work. While fixing that also noticed a trivial kerneldoc comment typo in the same section, fix that too.
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201204200242.2671481-1-daniel.vetter@ffwll.ch
show more ...
|
#
be98e05a |
| 04-Dec-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
dma-buf: Fix kerneldoc formatting
I wanted to look up something and noticed the hyperlink doesn't work. While fixing that also noticed a trivial kerneldoc comment typo in the same section, fix that
dma-buf: Fix kerneldoc formatting
I wanted to look up something and noticed the hyperlink doesn't work. While fixing that also noticed a trivial kerneldoc comment typo in the same section, fix that too.
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201204200242.2671481-1-daniel.vetter@ffwll.ch
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12 |
|
#
ccc22d41 |
| 25-Sep-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
dma-buf: Document struct dma_buf_map
This patch adds struct dma_buf_map and its helpers to the documentation. A short tutorial is included.
v3: * update documentation in a separate patch * expand
dma-buf: Document struct dma_buf_map
This patch adds struct dma_buf_map and its helpers to the documentation. A short tutorial is included.
v3: * update documentation in a separate patch * expand docs (Daniel) * carry-over acks from patch 1
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-5-tzimmermann@suse.de
show more ...
|
Revision tags: v5.8.11, v5.8.10, v5.8.9, v5.8.8 |
|
#
b899353d |
| 09-Sep-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
docs: dma-buf: fix some warnings
Fix those warnings:
Documentation/driver-api/dma-buf.rst:182: WARNING: Title underline too short.
Indefinite DMA Fences ~~~~~~~~~~~~~~~~~~~~
Documentation/dri
docs: dma-buf: fix some warnings
Fix those warnings:
Documentation/driver-api/dma-buf.rst:182: WARNING: Title underline too short.
Indefinite DMA Fences ~~~~~~~~~~~~~~~~~~~~
Documentation/driver-api/dma-buf.rst:88: WARNING: Unknown target name: "fence poll support".
The first one is due to a shorter markup. The second one is because the chapter name was wrong.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/b2bc0bc88eb913635cfece13cc9f6eff7668d333.1599660067.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
show more ...
|
Revision tags: v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61 |
|
#
6546d28f |
| 23-Aug-2020 |
Randy Dunlap <rdunlap@infradead.org> |
Documentation: fix dma-buf.rst underline length warning
/home/rdunlap/lnx/lnx-59-rc2/Documentation/driver-api/dma-buf.rst:182: WARNING: Title underline too short. Indefinite DMA Fences ~~~~~~~~~~~~~
Documentation: fix dma-buf.rst underline length warning
/home/rdunlap/lnx/lnx-59-rc2/Documentation/driver-api/dma-buf.rst:182: WARNING: Title underline too short. Indefinite DMA Fences ~~~~~~~~~~~~~~~~~~~~
Fixes: 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are a bad idea") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1b22d4c3-4ea5-c633-9e35-71ce65d8dbcc@infradead.org
show more ...
|
Revision tags: 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 |
|
#
72b6ede7 |
| 09-Jul-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
dma-buf.rst: Document why indefinite fences are a bad idea
Comes up every few years, gets somewhat tedious to discuss, let's write this down once and for all.
What I'm not sure about is whether the
dma-buf.rst: Document why indefinite fences are a bad idea
Comes up every few years, gets somewhat tedious to discuss, let's write this down once and for all.
What I'm not sure about is whether the text should be more explicit in flat out mandating the amdkfd eviction fences for long running compute workloads or workloads where userspace fencing is allowed.
v2: Now with dot graph!
v3: Typo (Dave Airlie)
Reviewed-by: Thomas Hellstrom <thomas.hellstrom@intel.com> Acked-by: Jason Ekstrand <jason@jlekstrand.net> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Jesse Natalie <jenatali@microsoft.com> Cc: Steve Pronovost <spronovo@microsoft.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Thomas Hellstrom <thomas.hellstrom@intel.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: linux-rdma@vger.kernel.org Cc: amd-gfx@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200709123339.547390-1-daniel.vetter@ffwll.ch
show more ...
|
Revision tags: v5.7.8, v5.4.51 |
|
#
d0b9a9ae |
| 07-Jul-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
dma-fence: prime lockdep annotations
Two in one go: - it is allowed to call dma_fence_wait() while holding a dma_resv_lock(). This is fundamental to how eviction works with ttm, so required.
-
dma-fence: prime lockdep annotations
Two in one go: - it is allowed to call dma_fence_wait() while holding a dma_resv_lock(). This is fundamental to how eviction works with ttm, so required.
- it is allowed to call dma_fence_wait() from memory reclaim contexts, specifically from shrinker callbacks (which i915 does), and from mmu notifier callbacks (which amdgpu does, and which i915 sometimes also does, and probably always should, but that's kinda a debate). Also for stuff like HMM we really need to be able to do this, or things get real dicey.
Consequence is that any critical path necessary to get to a dma_fence_signal for a fence must never a) call dma_resv_lock nor b) allocate memory with GFP_KERNEL. Also by implication of dma_resv_lock(), no userspace faulting allowed. That's some supremely obnoxious limitations, which is why we need to sprinkle the right annotations to all relevant paths.
The one big locking context we're leaving out here is mmu notifiers, added in
commit 23b68395c7c78a764e8963fc15a7cfd318bf187f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Aug 26 22:14:21 2019 +0200
mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end
that one covers a lot of other callsites, and it's also allowed to wait on dma-fences from mmu notifiers. But there's no ready-made functions exposed to prime this, so I've left it out for now.
v2: Also track against mmu notifier context.
v3: kerneldoc to spec the cross-driver contract. Note that currently i915 throws in a hard-coded 10s timeout on foreign fences (not sure why that was done, but it's there), which is why that rule is worded with SHOULD instead of MUST.
Also some of the mmu_notifier/shrinker rules might surprise SoC drivers, I haven't fully audited them all. Which is infeasible anyway, we'll need to run them with lockdep and dma-fence annotations and see what goes boom.
v4: A spelling fix from Mika
v5: #ifdef for CONFIG_MMU_NOTIFIER. Reported by 0day. Unfortunately this means lockdep enforcement is slightly inconsistent, it won't spot GFP_NOIO and GFP_NOFS allocations in the wrong spot if CONFIG_MMU_NOTIFIER is disabled in the kernel config. Oh well.
v5: Note that only drivers/gpu has a reasonable (or at least historical) excuse to use dma_fence_wait() from shrinker and mmu notifier callbacks. Everyone else should either have a better memory manager model, or better hardware. This reflects discussions with Jason Gunthorpe.
Cc: Jason Gunthorpe <jgg@mellanox.com> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: kernel test robot <lkp@intel.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com> (v4) Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Thomas Hellstrom <thomas.hellstrom@intel.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: linux-rdma@vger.kernel.org Cc: amd-gfx@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200707201229.472834-3-daniel.vetter@ffwll.ch
show more ...
|
#
5fbff813 |
| 07-Jul-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
dma-fence: basic lockdep annotations
Design is similar to the lockdep annotations for workers, but with some twists:
- We use a read-lock for the execution/worker/completion side, so that this ex
dma-fence: basic lockdep annotations
Design is similar to the lockdep annotations for workers, but with some twists:
- We use a read-lock for the execution/worker/completion side, so that this explicit annotation can be more liberally sprinkled around. With read locks lockdep isn't going to complain if the read-side isn't nested the same way under all circumstances, so ABBA deadlocks are ok. Which they are, since this is an annotation only.
- We're using non-recursive lockdep read lock mode, since in recursive read lock mode lockdep does not catch read side hazards. And we _very_ much want read side hazards to be caught. For full details of this limitation see
commit e91498589746065e3ae95d9a00b068e525eec34f Author: Peter Zijlstra <peterz@infradead.org> Date: Wed Aug 23 13:13:11 2017 +0200
locking/lockdep/selftests: Add mixed read-write ABBA tests
- To allow nesting of the read-side explicit annotations we explicitly keep track of the nesting. lock_is_held() allows us to do that.
- The wait-side annotation is a write lock, and entirely done within dma_fence_wait() for everyone by default.
- To be able to freely annotate helper functions I want to make it ok to call dma_fence_begin/end_signalling from soft/hardirq context. First attempt was using the hardirq locking context for the write side in lockdep, but this forces all normal spinlocks nested within dma_fence_begin/end_signalling to be spinlocks. That bollocks.
The approach now is to simple check in_atomic(), and for these cases entirely rely on the might_sleep() check in dma_fence_wait(). That will catch any wrong nesting against spinlocks from soft/hardirq contexts.
The idea here is that every code path that's critical for eventually signalling a dma_fence should be annotated with dma_fence_begin/end_signalling. The annotation ideally starts right after a dma_fence is published (added to a dma_resv, exposed as a sync_file fd, attached to a drm_syncobj fd, or anything else that makes the dma_fence visible to other kernel threads), up to and including the dma_fence_wait(). Examples are irq handlers, the scheduler rt threads, the tail of execbuf (after the corresponding fences are visible), any workers that end up signalling dma_fences and really anything else. Not annotated should be code paths that only complete fences opportunistically as the gpu progresses, like e.g. shrinker/eviction code.
The main class of deadlocks this is supposed to catch are:
Thread A:
mutex_lock(A); mutex_unlock(A);
dma_fence_signal();
Thread B:
mutex_lock(A); dma_fence_wait(); mutex_unlock(A);
Thread B is blocked on A signalling the fence, but A never gets around to that because it cannot acquire the lock A.
Note that dma_fence_wait() is allowed to be nested within dma_fence_begin/end_signalling sections. To allow this to happen the read lock needs to be upgraded to a write lock, which means that any other lock is acquired between the dma_fence_begin_signalling() call and the call to dma_fence_wait(), and still held, this will result in an immediate lockdep complaint. The only other option would be to not annotate such calls, defeating the point. Therefore these annotations cannot be sprinkled over the code entirely mindless to avoid false positives.
Originally I hope that the cross-release lockdep extensions would alleviate the need for explicit annotations:
https://lwn.net/Articles/709849/
But there's a few reasons why that's not an option:
- It's not happening in upstream, since it got reverted due to too many false positives:
commit e966eaeeb623f09975ef362c2866fae6f86844f9 Author: Ingo Molnar <mingo@kernel.org> Date: Tue Dec 12 12:31:16 2017 +0100
locking/lockdep: Remove the cross-release locking checks
This code (CONFIG_LOCKDEP_CROSSRELEASE=y and CONFIG_LOCKDEP_COMPLETIONS=y), while it found a number of old bugs initially, was also causing too many false positives that caused people to disable lockdep - which is arguably a worse overall outcome.
- cross-release uses the complete() call to annotate the end of critical sections, for dma_fence that would be dma_fence_signal(). But we do not want all dma_fence_signal() calls to be treated as critical, since many are opportunistic cleanup of gpu requests. If these get stuck there's still the main completion interrupt and workers who can unblock everyone. Automatically annotating all dma_fence_signal() calls would hence cause false positives.
- cross-release had some educated guesses for when a critical section starts, like fresh syscall or fresh work callback. This would again cause false positives without explicit annotations, since for dma_fence the critical sections only starts when we publish a fence.
- Furthermore there can be cases where a thread never does a dma_fence_signal, but is still critical for reaching completion of fences. One example would be a scheduler kthread which picks up jobs and pushes them into hardware, where the interrupt handler or another completion thread calls dma_fence_signal(). But if the scheduler thread hangs, then all the fences hang, hence we need to manually annotate it. cross-release aimed to solve this by chaining cross-release dependencies, but the dependency from scheduler thread to the completion interrupt handler goes through hw where cross-release code can't observe it.
In short, without manual annotations and careful review of the start and end of critical sections, cross-relese dependency tracking doesn't work. We need explicit annotations.
v2: handle soft/hardirq ctx better against write side and dont forget EXPORT_SYMBOL, drivers can't use this otherwise.
v3: Kerneldoc.
v4: Some spelling fixes from Mika
v5: Amend commit message to explain in detail why cross-release isn't the solution.
v6: Pull out misplaced .rst hunk.
Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Dave Airlie <airlied@redhat.com> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Thomas Hellstrom <thomas.hellstrom@intel.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: linux-rdma@vger.kernel.org Cc: amd-gfx@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200707201229.472834-2-daniel.vetter@ffwll.ch
show more ...
|
Revision tags: 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 |
|
#
102514ec |
| 12-Jun-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
dma-buf: minor doc touch-ups
Just some tiny edits: - fix link to struct dma_fence - give slightly more meaningful title - the polling here is about implicit fences, explicit fences (in sync_file o
dma-buf: minor doc touch-ups
Just some tiny edits: - fix link to struct dma_fence - give slightly more meaningful title - the polling here is about implicit fences, explicit fences (in sync_file or drm_syncobj) also have their own polling
v2: I misplaced the .rst include change corresponding to this patch.
Reviewed-by: Thomas Hellstrom <thomas.hellstrom@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612070535.1778368-1-daniel.vetter@ffwll.ch
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, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34 |
|
#
776d5882 |
| 20-Apr-2020 |
Gal Pressman <galpress@amazon.com> |
dma-buf: Couple of documentation typo fixes
Fix a couple of typos: "as" -> "has" and "int" -> "in".
Signed-off-by: Gal Pressman <galpress@amazon.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffw
dma-buf: Couple of documentation typo fixes
Fix a couple of typos: "as" -> "has" and "int" -> "in".
Signed-off-by: Gal Pressman <galpress@amazon.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200420074115.23931-1-galpress@amazon.com
show more ...
|
#
c7e1cc31 |
| 20-Apr-2020 |
Gal Pressman <galpress@amazon.com> |
dma-buf: Couple of documentation typo fixes
Fix a couple of typos: "as" -> "has" and "int" -> "in".
Signed-off-by: Gal Pressman <galpress@amazon.com> Link: https://lore.kernel.org/r/20200420074115.
dma-buf: Couple of documentation typo fixes
Fix a couple of typos: "as" -> "has" and "int" -> "in".
Signed-off-by: Gal Pressman <galpress@amazon.com> Link: https://lore.kernel.org/r/20200420074115.23931-1-galpress@amazon.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
show more ...
|
Revision tags: 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, v5.4.18, 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, 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, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2 |
|
#
0f546217 |
| 27-Sep-2019 |
Anna Karas <anna.karas@intel.com> |
doc: drm: Update references to previously renamed files
Update references to reservation.c and reservation.h since these files have been renamed to dma-resv.c and dma-resv.h respectively.
Cc: Chris
doc: drm: Update references to previously renamed files
Update references to reservation.c and reservation.h since these files have been renamed to dma-resv.c and dma-resv.h respectively.
Cc: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/323401/?series=65037&rev=1 Signed-off-by: Anna Karas <anna.karas@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190927111504.20136-1-anna.karas@intel.com
show more ...
|
#
f704985b |
| 01-Oct-2019 |
Jonathan Corbet <corbet@lwn.net> |
docs/driver-api: Catch up with dma_buf file-name changes
drivers/dma_buf/reservation.c was renamed to dma-resv.c (and include/linux/reservation.h to dma-resv.h), but the documentation was not update
docs/driver-api: Catch up with dma_buf file-name changes
drivers/dma_buf/reservation.c was renamed to dma-resv.c (and include/linux/reservation.h to dma-resv.h), but the documentation was not updated to match, leading to these build errors:
Error: Cannot open file ./drivers/dma-buf/reservation.c Error: Cannot open file ./drivers/dma-buf/reservation.c Error: Cannot open file ./drivers/dma-buf/reservation.c Error: Cannot open file ./include/linux/reservation.h Error: Cannot open file ./include/linux/reservation.h
Update the documentation and make the world happy again.
Fixes: 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv') Signed-off-by: Jonathan Corbet <corbet@lwn.net>
show more ...
|