15 Dec, 2020
2 commits
-
This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices, we can skip the CPU
syncing, which saves a lot of cache management overhead, greatly
improving performance.For folk using ION, there was a ION_FLAG_CACHED flag, which
signaled if the returned buffer should be CPU cacheable or not.
With DMA-BUF heaps, we do not yet have such a flag, and by default
the current heaps (system and cma) produce CPU cachable buffers.
So for folks transitioning from ION to DMA-BUF Heaps, this fills
in some of that missing functionality.There has been a suggestion to make this functionality a flag
(DMAHEAP_FLAG_UNCACHED?) on the system heap, similar to how
ION used the ION_FLAG_CACHED. But I want to make sure an
_UNCACHED flag would truely be a generic attribute across all
heaps. So far that has been unclear, so having it as a separate
heap seemes better for now. (But I'm open to discussion on this
point!)This is a rework of earlier efforts to add a uncached system heap,
done utilizing the exisitng system heap, adding just a bit of
logic to handle the uncached case.Feedback would be very welcome!
Many thanks to Liam Mark for his help to get this working.
Pending opensource users of this code include:
* AOSP HiKey960 gralloc:
- https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519
- Visibly improves performance over the system heap
* AOSP Codec2 (possibly, needs more review):
- https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325Signed-off-by: John Stultz
Link: https://lore.kernel.org/lkml/20201110034934.70898-8-john.stultz@linaro.org/
Bug: 170887642
Change-Id: I56cb3acf58546c7dfd423a2ce432e3d6d7fd7a69 -
Keep track of the heap device struct.
This will be useful for special DMA allocations
and actions.Signed-off-by: John Stultz
Link: https://lore.kernel.org/lkml/20201110034934.70898-7-john.stultz@linaro.org/
Bug: 170887642
Change-Id: I55b8df5fd9fd46795a8f0171318895297d2dd379
10 Dec, 2020
5 commits
-
While the system heap can return non-contiguous pages,
try to allocate larger order pages if possible.This will allow slight performance gains and make implementing
page pooling easier.Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John StultzBug: 173440990
(cherry picked from commit d963ab0f15fb0797ddd65b2653f3d65c2d7a08ec
git: //anongit.freedesktop.org/drm/drm-misc
tags/drm-misc-next-2020-11-27)
Link: https://lore.kernel.org/patchwork/patch/1343070/
Change-Id: Ic30327f6163d2ba727d08bd2dfdcfcff858064dc
Signed-off-by: John Stultz
Signed-off-by: Hridya Valsaraju -
This patch is basically a port of Ørjan Eide's similar patch for ION
https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.eide@arm.com/Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.dma-bufs may be synced at any time. It can be reached from user space
via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
syncs may be attempted, and dma_buf_end_cpu_access() and
dma_buf_begin_cpu_access() may not be paired.Since the sg_list's dma_address isn't set up until the buffer is used
on the device, and dma_map_sg() is called on it, the dma_address will be
NULL if sync is attempted on the dma-buf before it's mapped on a device.Before v5.0 (commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops
into the dma_direct code")) this was a problem as the dma-api (at least
the swiotlb_dma_ops on arm64) would use the potentially invalid
dma_address. How that failed depended on how the device handled physical
address 0. If 0 was a valid address to physical ram, that page would get
flushed a lot, while the actual pages in the buffer would not get synced
correctly. While if 0 is an invalid physical address it may cause a
fault and trigger a crash.In v5.0 this was incidentally fixed by commit 55897af63091 ("dma-direct:
merge swiotlb_dma_ops into the dma_direct code"), as this moved the
dma-api to use the page pointer in the sg_list, and (for Ion buffers at
least) this will always be valid if the sg_list exists at all.But, this issue is re-introduced in v5.3 with
commit 449fa54d6815 ("dma-direct: correct the physical addr in
dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old
behaviour and picks the dma_address that may be invalid.dma-buf core doesn't ensure that the buffer is mapped on the device, and
thus have a valid sg_list, before calling the exporter's
begin_cpu_access.Logic and commit message originally by: Ørjan Eide
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John StultzBug: 173440990
(cherry picked from commit 4c68e499bb9d6d9ec3e18fcb2f68641abb22464a
git: //anongit.freedesktop.org/drm/drm-misc
tags/drm-misc-next-2020-11-27)
Link: https://lore.kernel.org/patchwork/patch/1343071/
Change-Id: If1c7312e437a8166a7d3e65bcd4c352f46cab718
Signed-off-by: John Stultz
Signed-off-by: Hridya Valsaraju -
The heap-helpers code was not as generic as initially hoped
and it is now not being used, so remove it from the tree.Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
Bug: 173440990
(cherry picked from commit 064fae53c068a13987733ef2898d12d93a34545c
git: //anongit.freedesktop.org/drm/drm-misc
tags/drm-misc-next-2020-11-27)
Link: https://lore.kernel.org/patchwork/patch/1343072/
Change-Id: I34b597fac714dbc7f09868539ae06b5eda7d6a23
Signed-off-by: John Stultz
Signed-off-by: Hridya Valsaraju -
Since the heap-helpers logic ended up not being as generic as
hoped, move the heap-helpers dma_buf_ops implementations into
the cma_heap directly.This will allow us to remove the heap_helpers code in a following
patch.Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
Bug: 173440990
(cherry picked from commit a5d2d29e24be8967ef78a1b1fb2292413e3b3df9
git: //anongit.freedesktop.org/drm/drm-misc
tags/drm-misc-next-2020-11-27)
Link: https://lore.kernel.org/patchwork/patch/1343068/
Change-Id: I4672138353629a61c67ad7ad8aa03d7ebc6d98ed
Signed-off-by: John Stultz
[hridya: patch needed minor rebase to accomodate the kernel allocation
interface]
Signed-off-by: Hridya Valsaraju -
In preparation for some patches to optmize the system
heap code, rework the dmabuf exporter to utilize sgtables rather
then pageslists for tracking the associated pages.This will allow for large order page allocations, as well as
more efficient page pooling.In doing so, the system heap stops using the heap-helpers logic
which sadly is not quite as generic as I was hoping it to be, so
this patch adds heap specific implementations of the dma_buf_ops
function handlers.Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
Bug: 173440990
(cherry picked from commit 3812957587923ca325308ed9c4a5be5ca935e903
git: //anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-11-27)
Link: https://lore.kernel.org/patchwork/patch/1343069/
Change-Id: I69401e169ad766a4a4c46751ffaace51582b5a8c
Signed-off-by: John Stultz
[hridya: patch needed minor rebase to accommodate the kernel allocation
interface]
Signed-off-by: Hridya Valsaraju
04 Nov, 2020
1 commit
-
Allow loading cma heap as a module instead of just as a
statically built in heap.Since there isn't a good mechanism for dmabuf lifetime tracking
it isn't safe to allow the heap drivers to be unloaded, so these
drivers do not implement any module unloading functionality and
will show up in lsmod as "[permanent]".This patch also exports key functions from dmabuf heaps core and
the heap helper functions so they can be accessed by the module.Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Andrew F. Davis
Cc: Andrew Morton
Cc: Yue Hu
Cc: Mike Rapoport
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Sandeep Patil
Cc: Hridya Valsaraju
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
Change-Id: I8d4516899d42c0b6e145bde8a0fed1235ae46654
Bug: 155218010
Link: https://lore.kernel.org/lkml/20191025234834.28214-3-john.stultz@linaro.org/
Signed-off-by: Hridya Valsaraju
26 Oct, 2020
2 commits
-
…rs/hch/dma-mapping") into android-mainline
Resolves conflicts in:
kernel/dma/mapping.cSteps on the way to 5.10-rc1
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I61292201a3ac4b92c39f330585692652cf985550 -
…p.org/drm/drm") into android-mainline
Steps on the way to 5.10-rc1
Fixes merge conflicts in:
drivers/gpu/drm/bridge/lontium-lt9611.c
drivers/gpu/drm/virtio/virtgpu_display.cSigned-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I65d9d4c69ea7c79854d275462c9aca0a37d42654
22 Oct, 2020
1 commit
-
When submitting a cherry-picked version of commit c700bdd2233e
("ANDROID: dma-heap: Add proper kref handling on dma-buf heaps")
from the android-mainline tree, Greg had some feedback that
tracking the minor number wasn't necessary as it was already
stored in the heap_devt:
https://android-review.googlesource.com/c/kernel/common/+/1433176/4#message-b07e73548e082ae85b97c3f3ff889ae4ab6ab09dSo this patch reworks those changes so we don't need an extra
minor field in the dma_heap struct.Fixes: c700bdd2233e ("ANDROID: dma-heap: Add proper kref handling on dma-buf heaps")
Signed-off-by: John Stultz
Change-Id: I5f12e2249a6a02ee02dc19049b7b3577e094b0ce
Bug: 154341375
16 Oct, 2020
2 commits
-
Pull dma-mapping updates from Christoph Hellwig:
- rework the non-coherent DMA allocator
- move private definitions out of
- lower CMA_ALIGNMENT (Paul Cercueil)
- remove the omap1 dma address translation in favor of the common code
- make dma-direct aware of multiple dma offset ranges (Jim Quinlan)
- support per-node DMA CMA areas (Barry Song)
- increase the default seg boundary limit (Nicolin Chen)
- misc fixes (Robin Murphy, Thomas Tai, Xu Wang)
- various cleanups
* tag 'dma-mapping-5.10' of git://git.infradead.org/users/hch/dma-mapping: (63 commits)
ARM/ixp4xx: add a missing include of dma-map-ops.h
dma-direct: simplify the DMA_ATTR_NO_KERNEL_MAPPING handling
dma-direct: factor out a dma_direct_alloc_from_pool helper
dma-direct check for highmem pages in dma_direct_alloc_pages
dma-mapping: merge into
dma-mapping: move large parts of to kernel/dma
dma-mapping: move dma-debug.h to kernel/dma/
dma-mapping: remove
dma-mapping: merge into
dma-contiguous: remove dma_contiguous_set_default
dma-contiguous: remove dev_set_cma_area
dma-contiguous: remove dma_declare_contiguous
dma-mapping: split
cma: decrease CMA_ALIGNMENT lower limit to 2
firewire-ohci: use dma_alloc_pages
dma-iommu: implement ->alloc_noncoherent
dma-mapping: add new {alloc,free}_noncoherent dma_map_ops methods
dma-mapping: add a new dma_alloc_pages API
dma-mapping: remove dma_cache_sync
53c700: convert to dma_alloc_noncoherent
... -
Pull drm updates from Dave Airlie:
"Not a major amount of change, the i915 trees got split into display
and gt trees to better facilitate higher level review, and there's a
major refactoring of i915 GEM locking to use more core kernel concepts
(like ww-mutexes). msm gets per-process pagetables, older AMD SI cards
get DC support, nouveau got a bump in displayport support with common
code extraction from i915.Outside of drm this contains a couple of patches for hexint
moduleparams which you've acked, and a virtio common code tree that
you should also get via it's regular path.New driver:
- Cadence MHDP8546 DisplayPort bridge drivercore:
- cross-driver scatterlist cleanups
- devm_drm conversions
- remove drm_dev_init
- devm_drm_dev_alloc conversionttm:
- lots of refactoring and cleanupsbridges:
- chained bridge support in more driverspanel:
- misc new panelsscheduler:
- cleanup priority levelsdisplayport:
- refactor i915 code into helpers for nouveaui915:
- split into display and GT trees
- WW locking refactoring in GEM
- execbuf2 extension mechanism
- syncobj timeline support
- GEN 12 HOBL display powersaving
- Rocket Lake display additions
- Disable FBC on Tigerlake
- Tigerlake Type-C + DP improvements
- Hotplug interrupt refactoringamdgpu:
- Sienna Cichlid updates
- Navy Flounder updates
- DCE6 (SI) support for DC
- Plane rotation enabled
- TMZ state info ioctl
- PCIe DPC recovery support
- DC interrupt handling refactor
- OLED panel fixesamdkfd:
- add SMI events for thermal throttling
- SMI interface events ioctl update
- process eviction countersradeon:
- move to dma_ for allocations
- expose sclk via sysfsmsm:
- DSI support for sm8150/sm8250
- per-process GPU pagetable support
- Displayport supportmediatek:
- move HDMI phy driver to PHY
- convert mtk-dpi to bridge API
- disable mt2701 tmdstegra:
- bridge supportexynos:
- misc cleanupsvc4:
- dual display cleanupsast:
- cleanupsgma500:
- conversion to GPIOd APIhisilicon:
- misc reworksingenic:
- clock handling and format improvementsmcde:
- DSI supportmgag200:
- desktop g200 supportmxsfb:
- i.MX7 + i.MX8M
- alpha plane supportpanfrost:
- devfreq support
- amlogic SoC supportps8640:
- EDID from eDP retrievaltidss:
- AM65xx YUV workaroundvirtio:
- virtio-gpu exported resourcesrcar-du:
- R8A7742, R8A774E1 and R8A77961 support
- YUV planar format fixes
- non-visible plane handling
- VSP device reference count fix
- Kconfig fix to avoid displaying disabled options in .config"* tag 'drm-next-2020-10-15' of git://anongit.freedesktop.org/drm/drm: (1494 commits)
drm/ingenic: Fix bad revert
drm/amdgpu: Fix invalid number of character '{' in amdgpu_acpi_init
drm/amdgpu: Remove warning for virtual_display
drm/amdgpu: kfd_initialized can be static
drm/amd/pm: setup APU dpm clock table in SMU HW initialization
drm/amdgpu: prevent spurious warning
drm/amdgpu/swsmu: fix ARC build errors
drm/amd/display: Fix OPTC_DATA_FORMAT programming
drm/amd/display: Don't allow pstate if no support in blank
drm/panfrost: increase readl_relaxed_poll_timeout values
MAINTAINERS: Update entry for st7703 driver after the rename
Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"
drm/amd/display: HDMI remote sink need mode validation for Linux
drm/amd/display: Change to correct unit on audio rate
drm/amd/display: Avoid set zero in the requested clk
drm/amdgpu: align frag_end to covered address space
drm/amdgpu: fix NULL pointer dereference for Renoir
drm/vmwgfx: fix regression in thp code due to ttm init refactor.
drm/amdgpu/swsmu: add interrupt work handler for smu11 parts
drm/amdgpu/swsmu: add interrupt work function
...
06 Oct, 2020
1 commit
-
Merge dma-contiguous.h into dma-map-ops.h, after removing the comment
describing the contiguous allocator into kernel/dma/contigous.c.Signed-off-by: Christoph Hellwig
27 Sep, 2020
1 commit
-
…x/kernel/git/jejb/scsi") into 'android-mainline'
Fixes up a merge issue in:
net/ipv6/route.c
on the way to a 5.9-rc7 release.Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I4eb508eb3761b95ad8f39dd79f03b3352481ceaf
23 Sep, 2020
1 commit
-
drm-misc-next for 5.10:
UAPI Changes:
Cross-subsystem Changes:
- virtio: Merged a PR for patches that will affect drm/virtioCore Changes:
- dev: More devm_drm convertions and removal of drm_dev_init
- atomic: Split out drm_atomic_helper_calc_timestamping_constants of
drm_atomic_helper_update_legacy_modeset_state
- ttm: More reworkDriver Changes:
- i915: selftests improvements
- panfrost: support for Amlogic SoC
- vc4: one fix
- tree-wide: conversions to devm_drm_dev_alloc,
- ast: simplifications of the atomic modesetting code
- panfrost: multiple fixes
- vc4: multiple fixes
Signed-off-by: Dave AirlieFrom: Maxime Ripard
Link: https://patchwork.freedesktop.org/patch/msgid/20200921152956.2gxnsdgxmwhvjyut@gilmour.lan
21 Sep, 2020
1 commit
-
NULL pointer dereference is observed while exporting the dmabuf but
failed to allocate the 'struct file' which results into the dropping of
the allocated dentry corresponding to this file in the dmabuf fs, which
is ending up in dma_buf_release() and accessing the uninitialzed
dentry->d_fsdata.Call stack on 5.4 is below:
dma_buf_release+0x2c/0x254 drivers/dma-buf/dma-buf.c:88
__dentry_kill+0x294/0x31c fs/dcache.c:584
dentry_kill fs/dcache.c:673 [inline]
dput+0x250/0x380 fs/dcache.c:859
path_put+0x24/0x40 fs/namei.c:485
alloc_file_pseudo+0x1a4/0x200 fs/file_table.c:235
dma_buf_getfile drivers/dma-buf/dma-buf.c:473 [inline]
dma_buf_export+0x25c/0x3ec drivers/dma-buf/dma-buf.c:585Fix this by checking for the valid pointer in the dentry->d_fsdata.
Fixes: 4ab59c3c638c ("dma-buf: Move dma_buf_release() from fops to dentry_ops")
Cc: [5.7+]
Signed-off-by: Charan Teja Reddy
Reviewed-by: Christian König
Link: https://patchwork.freedesktop.org/patch/391319/
Signed-off-by: Christian König
17 Sep, 2020
2 commits
-
GPU drivers need this in their shrinkers, to be able to throw out
mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
but that loop is resolved by trylocking in shrinkers.So full hierarchy is now (ignore some of the other branches we already
have primed):mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write
I hope that's not inconsistent with anything mm or fs does, adding
relevant people.Reviewed-by: Thomas Hellström
Reviewed-by: Christian König
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: Dave Chinner
Cc: Qian Cai
Cc: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: Thomas Hellström (Intel)
Cc: Andrew Morton
Cc: Jason Gunthorpe
Cc: linux-mm@kvack.org
Cc: linux-rdma@vger.kernel.org
Cc: Maarten Lankhorst
Link: https://patchwork.freedesktop.org/patch/msgid/20200728135839.1035515-1-daniel.vetter@ffwll.ch -
Please pull a set of fixes for various DRM drivers that finally resolve
incorrect usage of the scatterlists (struct sg_table nents and orig_nents
entries), what causes issues when IOMMU is used.Signed-off-by: Dave Airlie
From: Marek Szyprowski
Link: https://patchwork.freedesktop.org/patch/msgid/20200910080505.24456-1-m.szyprowski@samsung.com
15 Sep, 2020
1 commit
-
Paul Cercueil needs some patches in -rc5 to apply new patches for ingenic
properly.Signed-off-by: Maxime Ripard
14 Sep, 2020
1 commit
-
Linux 5.9-rc5
Signed-off-by: Greg Kroah-Hartman
Change-Id: Ia4878d9973d7f9adf94f38e9c5703112c605ca56
10 Sep, 2020
1 commit
-
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
Acked-by: Gerd Hoffmann
07 Sep, 2020
1 commit
-
Make sure we can use this on mixed systems.
Signed-off-by: Kristian H. Kristensen
Link: http://patchwork.freedesktop.org/patch/msgid/20200903181652.432067-1-hoegsberg@google.com
Signed-off-by: Gerd Hoffmann
03 Sep, 2020
2 commits
-
Fix W=1 compile warnings (invalid kerneldoc):
drivers/dma-buf/dma-fence-chain.c:233: warning: Function parameter or member 'seqno' not described in 'dma_fence_chain_init'
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Sumit Semwal
Link: https://patchwork.freedesktop.org/patch/msgid/20200819175134.19261-2-krzk@kernel.org -
Fix W=1 compile warnings (invalid kerneldoc):
drivers/dma-buf/dma-buf.c:328: warning: Function parameter or member 'dmabuf' not described in 'dma_buf_set_name'
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Sumit Semwal
Link: https://patchwork.freedesktop.org/patch/msgid/20200819175134.19261-1-krzk@kernel.org
02 Sep, 2020
1 commit
-
Add @cookie to dma_fence_end_signalling() to prevent kernel-doc
warning in drivers/dma-buf/dma-fence.c:../drivers/dma-buf/dma-fence.c:291: warning: Function parameter or member 'cookie' not described in 'dma_fence_end_signalling'
Signed-off-by: Randy Dunlap
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: Christian König
Link: https://patchwork.freedesktop.org/patch/388527/
Signed-off-by: Christian König
22 Aug, 2020
4 commits
-
…ufs from specific heaps
This allows drivers who don't want to create their own
DMA-BUF exporter to be able to allocate DMA-BUFs directly
from existing DMA-BUF Heaps.There is some concern that the premise of DMA-BUF heaps is
that userland knows better about what type of heap memory
is needed for a pipeline, so it would likely be best for
drivers to import and fill DMA-BUFs allocated by userland
instead of allocating one themselves, but this is still
up for debate.Unfortunately we don't have any public users of this, so
we cannot push it upstream. However, vendors have asked
for this, so I'm submitting it to Andorid Common in the
hopes that we can eventually find what vendors are doing.Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: I7b5ef690cefd2bfbbc2e01220ada49e44ef4fa04
Bug: 154341375 -
While most uses will want to allocate a fd for a dmabuf, there
are some cases where it might be useful to have just a dma_buf structure.So refactor the heap allocaiton functions to return a struct dma_buf
and add a dma_heap_bufferfd_alloc() function to convert that return a fd.Signed-off-by: John Stultz
Change-Id: Id6fd7e8471b9555a08bcdf8ca210feb589fa51c1
Bug: 154341375 -
Refactor the code to make in-kernel use a bit more clean.
Signed-off-by: John Stultz
Change-Id: I909a36ea6f2351415decbd489fd71ea03b2c2171
Bug: 154341375 -
Add proper refcounting on the dma_heap structure.
While existing heaps are built-in, we may eventually
have heaps loaded from modules, and we'll need to be
able to properly handle the references to the heapsAlso moves minor tracking into the heap structure so
we can properly free things.Cc: Sumit Semwal
Cc: Andrew F. Davis
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
Change-Id: I9f9e27f640c926882a639d6ad5dc3019d7e2c2b0
Link: https://lore.kernel.org/lkml/20200725032633.125006-1-john.stultz@linaro.org/T/#u
Bug: 154341375
---
v2: Fix potential race with kref_put being called while another
cpu was scanning the list to take a ref, pointed out by
Hridya
14 Aug, 2020
1 commit
-
Export dma_heap_add in order to allow heaps to be compiled as modules.
Bug: 155218010
Signed-off-by: Chris Goldsworthy
Change-Id: I7e63c8e757d8cbbfaa1ef34eba8f589d70ba0b91
11 Aug, 2020
2 commits
-
…ub/scm/linux/kernel/git/acme/linux") into android-mainline
Tiny steps on the way to 5.9-rc1.
Fixes conflicts in:
fs/f2fs/inline.cSigned-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I16d863ae44a51156499458e8c3486587cbe2babe -
Pull locking updates from Thomas Gleixner:
"A set of locking fixes and updates:- Untangle the header spaghetti which causes build failures in
various situations caused by the lockdep additions to seqcount to
validate that the write side critical sections are non-preemptible.- The seqcount associated lock debug addons which were blocked by the
above fallout.seqcount writers contrary to seqlock writers must be externally
serialized, which usually happens via locking - except for strict
per CPU seqcounts. As the lock is not part of the seqcount, lockdep
cannot validate that the lock is held.This new debug mechanism adds the concept of associated locks.
sequence count has now lock type variants and corresponding
initializers which take a pointer to the associated lock used for
writer serialization. If lockdep is enabled the pointer is stored
and write_seqcount_begin() has a lockdep assertion to validate that
the lock is held.Aside of the type and the initializer no other code changes are
required at the seqcount usage sites. The rest of the seqcount API
is unchanged and determines the type at compile time with the help
of _Generic which is possible now that the minimal GCC version has
been moved up.Adding this lockdep coverage unearthed a handful of seqcount bugs
which have been addressed already independent of this.While generally useful this comes with a Trojan Horse twist: On RT
kernels the write side critical section can become preemtible if
the writers are serialized by an associated lock, which leads to
the well known reader preempts writer livelock. RT prevents this by
storing the associated lock pointer independent of lockdep in the
seqcount and changing the reader side to block on the lock when a
reader detects that a writer is in the write side critical section.- Conversion of seqcount usage sites to associated types and
initializers"* tag 'locking-urgent-2020-08-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (25 commits)
locking/seqlock, headers: Untangle the spaghetti monster
locking, arch/ia64: Reduce header dependencies by moving XTP bits into the new header
x86/headers: Remove APIC headers from
seqcount: More consistent seqprop names
seqcount: Compress SEQCNT_LOCKNAME_ZERO()
seqlock: Fold seqcount_LOCKNAME_init() definition
seqlock: Fold seqcount_LOCKNAME_t definition
seqlock: s/__SEQ_LOCKDEP/__SEQ_LOCK/g
hrtimer: Use sequence counter with associated raw spinlock
kvm/eventfd: Use sequence counter with associated spinlock
userfaultfd: Use sequence counter with associated spinlock
NFSv4: Use sequence counter with associated spinlock
iocost: Use sequence counter with associated spinlock
raid5: Use sequence counter with associated spinlock
vfs: Use sequence counter with associated spinlock
timekeeping: Use sequence counter with associated raw spinlock
xfrm: policy: Use sequence counters with associated lock
netfilter: nft_set_rbtree: Use sequence counter with associated rwlock
netfilter: conntrack: Use sequence counter with associated spinlock
sched: tasks: Use sequence counter with associated spinlock
...
07 Aug, 2020
1 commit
-
…into android-mainline
Steps on the way to 5.9-rc1
Resolves conflicts in:
drivers/irqchip/qcom-pdc.c
include/linux/device.h
net/xfrm/xfrm_state.c
security/lsm_audit.cSigned-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I4aeb3d04f4717714a421721eb3ce690c099bb30a
29 Jul, 2020
2 commits
-
A sequence counter write side critical section must be protected by some
form of locking to serialize writers. If the serialization primitive is
not disabling preemption implicitly, preemption has to be explicitly
disabled before entering the sequence counter write side critical
section.The dma-buf reservation subsystem uses plain sequence counters to manage
updates to reservations. Writer serialization is accomplished through a
wound/wait mutex.Acquiring a wound/wait mutex does not disable preemption, so this needs
to be done manually before and after the write side critical section.Use the newly-added seqcount_ww_mutex_t instead:
- It associates the ww_mutex with the sequence count, which enables
lockdep to validate that the write side critical section is properly
serialized.- It removes the need to explicitly add preempt_disable/enable()
around the write side critical section because the write_begin/end()
functions for this new data type automatically do this.If lockdep is disabled this ww_mutex lock association is compiled out
and has neither storage size nor runtime overhead.Signed-off-by: Ahmed S. Darwish
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Daniel Vetter
Link: https://lkml.kernel.org/r/20200720155530.1173732-13-a.darwish@linutronix.de -
Commit 3c3b177a9369 ("reservation: add support for read-only access
using rcu") introduced a sequence counter to manage updates to
reservations. Back then, the reservation object initializer
reservation_object_init() was always inlined.Having the sequence counter initialization inlined meant that each of
the call sites would have a different lockdep class key, which would've
broken lockdep's deadlock detection. The aforementioned commit thus
introduced, and exported, a custom seqcount lockdep class key and name.The commit 8735f16803f00 ("dma-buf: cleanup reservation_object_init...")
transformed the reservation object initializer to a normal non-inlined C
function. seqcount_init(), which automatically defines the seqcount
lockdep class key and must be called non-inlined, can now be safely used.Remove the seqcount custom lockdep class key, name, and export. Use
seqcount_init() inside the dma reservation object initializer.Signed-off-by: Ahmed S. Darwish
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Sebastian Andrzej Siewior
Acked-by: Daniel Vetter
Link: https://lkml.kernel.org/r/20200720155530.1173732-12-a.darwish@linutronix.de
24 Jul, 2020
1 commit
-
I've got a silent conflict + two trees based on fixes to merge.
Fixes a silent merge with amdgpu
Signed-off-by: Dave Airlie
23 Jul, 2020
2 commits
-
The sparse tool complains as follows:
drivers/dma-buf/dma-fence.c:249:25: warning:
symbol 'dma_fence_lockdep_map' was not declared. Should it be static?This variable is not used outside of dma-fence.c, so this commit
marks it static.Fixes: 5fbff813a4a3 ("dma-fence: basic lockdep annotations")
Reported-by: Hulk Robot
Signed-off-by: Wei YongjunReviewed-by: Christian König
Signed-off-by: Dave AirlieLink: https://patchwork.freedesktop.org/patch/msgid/dc5e3b19-2087-44ab-a28c-ddb38ff8861a@email.android.com
-
drm-misc-next for v5.9:
UAPI Changes:
Cross-subsystem Changes:
- Convert panel-dsi-cm and ingenic bindings to YAML.
- Add lockdep annotations for dma-fence. \o/
- Describe why indefinite fences are a bad idea
- Update binding for rocktech jh057n00900.Core Changes:
- Add vblank workers.
- Use spin_(un)lock_irq instead of the irqsave/restore variants in crtc code.
- Add managed vram helpers.
- Convert more logging to drm functions.
- Replace more http links with https in core and drivers.
- Cleanup to ttm iomem functions and implementation.
- Remove TTM CMA memtype as it doesn't work correctly.
- Remove TTM_MEMTYPE_FLAG_MAPPABLE for many drivers that have no
unmappable memory resources.Driver Changes:
- Add CRC support to nouveau, using the new vblank workers.
- Dithering and atomic state fix for nouveau.
- Fixes for Frida FRD350H54004 panel.
- Add support for OSD mode (sprite planes), IPU (scaling) and multiple
panels/bridges to ingenic.
- Use managed vram helpers in ast.
- Assorted small fixes to ingenic, i810, mxsfb.
- Remove optional unused ttm dummy functions.Signed-off-by: Dave Airlie
From: Maarten Lankhorst
Link: https://patchwork.freedesktop.org/patch/msgid/d6bf269e-ccb2-8a7b-fdae-226e9e3f8274@linux.intel.com
21 Jul, 2020
1 commit
-
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 incommit 23b68395c7c78a764e8963fc15a7cfd318bf187f
Author: Daniel Vetter
Date: Mon Aug 26 22:14:21 2019 +0200mm/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
Cc: Felix Kuehling
Cc: kernel test robot
Acked-by: Christian König
Acked-by: Dave Airlie
Reviewed-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström (v4)
Cc: Mika Kuoppala
Cc: Thomas Hellstrom
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
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
Link: https://patchwork.freedesktop.org/patch/msgid/20200707201229.472834-3-daniel.vetter@ffwll.ch