Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 25 6月, 2020 1 次提交
  3. 30 4月, 2020 1 次提交
  5. 27 4月, 2020 1 次提交
  7. 01 4月, 2020 1 次提交
  9. 27 2月, 2020 4 次提交
  11. 26 11月, 2019 1 次提交
  13. 24 10月, 2019 2 次提交
    • C
      dma-buf: stop using the dmabuf->lock so much v2 · f45f57cc
      由 Christian König 提交于 
      The attachment list is now protected by the dma_resv object.

Stop holding the dma_buf->lock while calling ->attach/->detach,
this allows for concurrent attach/detach operations.

v2: cleanup commit message and locking in _debug_show()
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336790
      f45f57cc
    • C
      dma-buf: change DMA-buf locking convention v3 · 15fd552d
      由 Christian König 提交于 
      This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.

It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.

For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.

Issues and solutions we considered:

- We can't change all existing drivers, and existing improters have
  strong opinions about which locks they're holding while calling
  dma_buf_attachment_map/unmap. Exporters also have strong opinions about
  which locks they can acquire in their ->map/unmap callbacks, levaing no
  room for change. The solution to avoid this was to move the
  actual map/unmap out from this call, into the attach/detach callbacks,
  and cache the mapping. This works because drivers don't call
  attach/detach from deep within their code callchains (like deep in
  memory management code called from cs/execbuf ioctl), but directly from
  the fd2handle implementation.

- The caching has some troubles on some soc drivers, which set other modes
  than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
  can't re-create the mapping at _map time due to the above locking fun.
  We very carefuly step around that by only caching at attach time if the
  dynamic mode between importer/expoert mismatches.

- There's been quite some discussion on dma-buf mappings which need active
  cache management, which would all break down when caching, plus we don't
  have explicit flush operations on the attachment side. The solution to
  this was to shrug and keep the current discrepancy between what the
  dma-buf docs claim and what implementations do, with the hope that the
  begin/end_cpu_access hooks are good enough and that all necessary
  flushing to keep device mappings consistent will be done there.

v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
      15fd552d
  15. 23 10月, 2019 1 次提交
  17. 16 8月, 2019 1 次提交
  19. 13 8月, 2019 1 次提交
  21. 10 8月, 2019 1 次提交
  23. 19 6月, 2019 1 次提交
  25. 14 6月, 2019 3 次提交
  27. 22 5月, 2019 1 次提交
  29. 24 4月, 2019 2 次提交
  31. 24 12月, 2018 1 次提交
  33. 10 8月, 2018 1 次提交
  35. 20 6月, 2018 2 次提交
  37. 01 6月, 2018 1 次提交
  39. 12 2月, 2018 1 次提交
    • L
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      由 Linus Torvalds 提交于 
      This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
        L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
        for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
    done

with de-mangling cleanups yet to come.

NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do.  But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.

The next patch from Al will sort out the final differences, and we
should be all done.
Scripted-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
  41. 29 11月, 2017 1 次提交
  43. 28 11月, 2017 1 次提交
  45. 23 11月, 2017 1 次提交
  47. 02 11月, 2017 1 次提交
  49. 21 9月, 2017 1 次提交
  51. 08 5月, 2017 3 次提交
  53. 20 4月, 2017 1 次提交
  55. 04 4月, 2017 1 次提交
  57. 31 3月, 2017 1 次提交
  59. 27 2月, 2017 1 次提交