Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 2月, 2021 1 次提交
  3. 06 1月, 2021 1 次提交
  5. 14 12月, 2020 1 次提交
  7. 10 12月, 2020 1 次提交
  9. 09 12月, 2020 1 次提交
  11. 09 11月, 2020 1 次提交
  13. 24 9月, 2020 1 次提交
  15. 09 9月, 2020 1 次提交
  17. 25 8月, 2020 1 次提交
  19. 11 8月, 2020 1 次提交
  21. 13 7月, 2020 1 次提交
    • M
      drm: amdgpu: fix common struct sg_table related issues · 39913934
      由 Marek Szyprowski 提交于 
      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: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/371142/Signed-off-by: NChristian König <christian.koenig@amd.com>
      39913934
  23. 20 5月, 2020 2 次提交
  25. 01 4月, 2020 3 次提交
  27. 27 2月, 2020 4 次提交
  29. 06 12月, 2019 1 次提交
  31. 28 10月, 2019 2 次提交
  33. 03 10月, 2019 1 次提交
  35. 13 8月, 2019 1 次提交
  37. 06 8月, 2019 2 次提交
  39. 05 8月, 2019 1 次提交
  41. 31 7月, 2019 2 次提交
  43. 21 6月, 2019 1 次提交
    • D
      drm/prime: Align gem_prime_export with obj_funcs.export · e4fa8457
      由 Daniel Vetter 提交于 
      The idea is that gem_prime_export is deprecated in favor of
obj_funcs.export. That's much easier to do if both have matching
function signatures.
Reviewed-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: "Michel Dänzer" <michel.daenzer@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Felix Kuehling <Felix.Kuehling@amd.com>
Cc: Hawking Zhang <Hawking.Zhang@amd.com>
Cc: Feifei Xu <Feifei.Xu@amd.com>
Cc: Jim Qu <Jim.Qu@amd.com>
Cc: Evan Quan <evan.quan@amd.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Thomas Zimmermann <tdz@users.sourceforge.net>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Jilayne Lovejoy <opensource@jilayne.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Mikulas Patocka <mpatocka@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Junwei Zhang <Jerry.Zhang@amd.com>
Cc: intel-gvt-dev@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-tegra@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-10-daniel.vetter@ffwll.ch
      e4fa8457
  45. 25 5月, 2019 1 次提交
  47. 31 1月, 2019 1 次提交
    • C
      drm/amdgpu: Transfer fences to dmabuf importer · 6e11ea9d
      由 Chris Wilson 提交于 
      amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As such, on exporting a dmabuf, we must either flush all
outstanding fences (for we do not know which are writes and should have
been exclusive) or alternatively create a new exclusive fence that is
the composite of all the existing shared fences, and so will only be
signaled when all earlier fences are signaled (ensuring that we can not
be signaled before the completion of any earlier write).

v2: reservation_object is already locked by amdgpu_bo_reserve()
v3: Replace looping with get_fences_rcu and special case the promotion
of a single shared fence directly to an exclusive fence, bypassing the
fence array.
v4: Drop the fence array ref after assigning to reservation_object

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Testcase: igt/amd_prime/amd-to-i915
References: 8e94a46c ("drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5)")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Reviewed-by: N"Christian König" <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      6e11ea9d
  49. 08 12月, 2018 1 次提交
  51. 05 10月, 2018 1 次提交
  53. 14 9月, 2018 1 次提交
  55. 28 8月, 2018 1 次提交
  57. 26 7月, 2018 1 次提交
  59. 11 7月, 2018 1 次提交
  61. 06 7月, 2018 1 次提交