linux/Documentation/DMA-API.txt, branch v5.0

dma-mapping: deprecate dma_zalloc_coherent

2018-12-20T07:14:09Z

We now always return zeroed memory from dma_alloc_coherent. Note that simply passing GFP_ZERO to dma_alloc_coherent wasn't always doing the right thing to start with given that various allocators are not backed by the page allocator and thus would ignore GFP_ZERO. Signed-off-by: Christoph Hellwig

dma-debug: Batch dma_debug_entry allocation

2018-12-11T13:32:13Z

DMA debug entries are one of those things which aren't that useful individually - we will always want some larger quantity of them - and which we don't really need to manage the exact number of - we only care about having 'enough'. In that regard, the current behaviour of creating them one-by-one leads to a lot of unwarranted function call overhead and memory wasted on alignment padding. Now that we don't have to worry about freeing anything via dma_debug_resize_entries(), we can optimise the allocation behaviour by grabbing whole pages at once, which will save considerably on the aforementioned overheads, and probably offer a little more cache/TLB locality benefit for traversing the lists under normal operation. This should also give even less reason for an architecture-level override of the preallocation size, so make the definition unconditional - if there is still any desire to change the compile-time value for some platforms it would be better off as a Kconfig option anyway. Since freeing a whole page of entries at once becomes enough of a challenge that it's not really worth complicating dma_debug_init(), we may as well tweak the preallocation behaviour such that as long as we manage to allocate *some* pages, we can leave debugging enabled on a best-effort basis rather than otherwise wasting them. Signed-off-by: Robin Murphy Tested-by: Qian Cai Signed-off-by: Christoph Hellwig

dma-debug: Make leak-like behaviour apparent

2018-12-11T13:31:18Z

Now that we can dynamically allocate DMA debug entries to cope with drivers maintaining excessively large numbers of live mappings, a driver which *does* actually have a bug leaking mappings (and is not unloaded) will no longer trigger the "DMA-API: debugging out of memory - disabling" message until it gets to actual kernel OOM conditions, which means it could go unnoticed for a while. To that end, let's inform the user each time the pool has grown to a multiple of its initial size, which should make it apparent that they either have a leak or might want to increase the preallocation size. Signed-off-by: Robin Murphy Tested-by: Qian Cai Signed-off-by: Christoph Hellwig

dma-debug: Dynamically expand the dma_debug_entry pool

2018-12-11T13:31:17Z

Certain drivers such as large multi-queue network adapters can use pools of mapped DMA buffers larger than the default dma_debug_entry pool of 65536 entries, with the result that merely probing such a device can cause DMA debug to disable itself during boot unless explicitly given an appropriate "dma_debug_entries=..." option. Developers trying to debug some other driver on such a system may not be immediately aware of this, and at worst it can hide bugs if they fail to realise that dma-debug has already disabled itself unexpectedly by the time their code of interest gets to run. Even once they do realise, it can be a bit of a pain to emprirically determine a suitable number of preallocated entries to configure, short of massively over-allocating. There's really no need for such a static limit, though, since we can quite easily expand the pool at runtime in those rare cases that the preallocated entries are insufficient, which is arguably the least surprising and most useful behaviour. To that end, refactor the prealloc_memory() logic a little bit to generalise it for runtime reallocations as well. Signed-off-by: Robin Murphy Tested-by: Qian Cai Signed-off-by: Christoph Hellwig

dma-debug: Expose nr_total_entries in debugfs

2018-12-11T13:31:17Z

Expose nr_total_entries in debugfs, so that {num,min}_free_entries become even more meaningful to users interested in current/maximum utilisation. This becomes even more relevant once nr_total_entries may change at runtime beyond just the existing AMD GART debug code. Suggested-by: John Garry Signed-off-by: Robin Murphy Tested-by: Qian Cai Signed-off-by: Christoph Hellwig

dma-coherent: remove the DMA_MEMORY_MAP and DMA_MEMORY_IO flags

2017-09-01T09:59:17Z

DMA_MEMORY_IO was never used in the tree, so remove it. That means there is no need for the DMA_MEMORY_MAP flag either now, so remove it as well and change dma_declare_coherent_memory to return a normal errno value. Signed-off-by: Christoph Hellwig Reviewed-by: Marek Szyprowski

dma-coherent: remove the DMA_MEMORY_INCLUDES_CHILDREN flag

2017-09-01T07:50:39Z

This flag was never implemented or used. Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy

dma-mapping: remove dma_alloc_noncoherent and dma_free_noncoherent

2017-08-29T08:04:02Z

No users left, everyone switched to the _attrs versions. Signed-off-by: Christoph Hellwig

DMA-API.txt: standardize document format

2017-07-14T19:51:32Z

Each text file under Documentation follows a different format. Some doesn't even have titles! Change its representation to follow the adopted standard, using ReST markups for it to be parseable by Sphinx: - Fix some title marks to match ReST; - use :Author: for author name; - foo_ is an hyperlink. Get rid of it; - Mark literal blocks as such; - Use tables on some places that are almost using the table format. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Corbet

Documentation: DMA API: fix a typo in a function name

2017-06-05T21:57:02Z

Correct the typo, the wrongly typed function does not exist. Fixes: 6c9c6d6301287e ("dma-debug: New interfaces to debug dma mapping errors") Signed-off-by: Wolfram Sang Signed-off-by: Jonathan Corbet