docs: move DMA kAPI to Documentation/core-api

Move those files to the core-api, where they belong, renaming
them to ReST and adding to the core API index file.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/a1517185418cb9d987f566ef85a5dd5c7c99f34e.1588345503.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

1 files changed, 0 insertions, 745 deletions

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
deleted file mode 100644
index 2d8d2fed7317..000000000000
--- a/Documentation/DMA-API.txt
+++ /dev/null
@@ -1,745 +0,0 @@
-============================================
-Dynamic DMA mapping using the generic device
-============================================
-
-:Author: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
-
-This document describes the DMA API.  For a more gentle introduction
-of the API (and actual examples), see Documentation/DMA-API-HOWTO.txt.
-
-This API is split into two pieces.  Part I describes the basic API.
-Part II describes extensions for supporting non-consistent memory
-machines.  Unless you know that your driver absolutely has to support
-non-consistent platforms (this is usually only legacy platforms) you
-should only use the API described in part I.
-
-Part I - dma_API
-----------------
-
-To get the dma_API, you must #include <linux/dma-mapping.h>.  This
-provides dma_addr_t and the interfaces described below.
-
-A dma_addr_t can hold any valid DMA address for the platform.  It can be
-given to a device to use as a DMA source or target.  A CPU cannot reference
-a dma_addr_t directly because there may be translation between its physical
-address space and the DMA address space.
-
-Part Ia - Using large DMA-coherent buffers
-------------------------------------------
-
-::
-
-	void *
-	dma_alloc_coherent(struct device *dev, size_t size,
-			   dma_addr_t *dma_handle, gfp_t flag)
-
-Consistent memory is memory for which a write by either the device or
-the processor can immediately be read by the processor or device
-without having to worry about caching effects.  (You may however need
-to make sure to flush the processor's write buffers before telling
-devices to read that memory.)
-
-This routine allocates a region of <size> bytes of consistent memory.
-
-It returns a pointer to the allocated region (in the processor's virtual
-address space) or NULL if the allocation failed.
-
-It also returns a <dma_handle> which may be cast to an unsigned integer the
-same width as the bus and given to the device as the DMA address base of
-the region.
-
-Note: consistent memory can be expensive on some platforms, and the
-minimum allocation length may be as big as a page, so you should
-consolidate your requests for consistent memory as much as possible.
-The simplest way to do that is to use the dma_pool calls (see below).
-
-The flag parameter (dma_alloc_coherent() only) allows the caller to
-specify the ``GFP_`` flags (see kmalloc()) for the allocation (the
-implementation may choose to ignore flags that affect the location of
-the returned memory, like GFP_DMA).
-
-::
-
-	void
-	dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
-			  dma_addr_t dma_handle)
-
-Free a region of consistent memory you previously allocated.  dev,
-size and dma_handle must all be the same as those passed into
-dma_alloc_coherent().  cpu_addr must be the virtual address returned by
-the dma_alloc_coherent().
-
-Note that unlike their sibling allocation calls, these routines
-may only be called with IRQs enabled.
-
-
-Part Ib - Using small DMA-coherent buffers
-------------------------------------------
-
-To get this part of the dma_API, you must #include <linux/dmapool.h>
-
-Many drivers need lots of small DMA-coherent memory regions for DMA
-descriptors or I/O buffers.  Rather than allocating in units of a page
-or more using dma_alloc_coherent(), you can use DMA pools.  These work
-much like a struct kmem_cache, except that they use the DMA-coherent allocator,
-not __get_free_pages().  Also, they understand common hardware constraints
-for alignment, like queue heads needing to be aligned on N-byte boundaries.
-
-
-::
-
-	struct dma_pool *
-	dma_pool_create(const char *name, struct device *dev,
-			size_t size, size_t align, size_t alloc);
-
-dma_pool_create() initializes a pool of DMA-coherent buffers
-for use with a given device.  It must be called in a context which
-can sleep.
-
-The "name" is for diagnostics (like a struct kmem_cache name); dev and size
-are like what you'd pass to dma_alloc_coherent().  The device's hardware
-alignment requirement for this type of data is "align" (which is expressed
-in bytes, and must be a power of two).  If your device has no boundary
-crossing restrictions, pass 0 for alloc; passing 4096 says memory allocated
-from this pool must not cross 4KByte boundaries.
-
-::
-
-	void *
-	dma_pool_zalloc(struct dma_pool *pool, gfp_t mem_flags,
-		        dma_addr_t *handle)
-
-Wraps dma_pool_alloc() and also zeroes the returned memory if the
-allocation attempt succeeded.
-
-
-::
-
-	void *
-	dma_pool_alloc(struct dma_pool *pool, gfp_t gfp_flags,
-		       dma_addr_t *dma_handle);
-
-This allocates memory from the pool; the returned memory will meet the
-size and alignment requirements specified at creation time.  Pass
-GFP_ATOMIC to prevent blocking, or if it's permitted (not
-in_interrupt, not holding SMP locks), pass GFP_KERNEL to allow
-blocking.  Like dma_alloc_coherent(), this returns two values:  an
-address usable by the CPU, and the DMA address usable by the pool's
-device.
-
-::
-
-	void
-	dma_pool_free(struct dma_pool *pool, void *vaddr,
-		      dma_addr_t addr);
-
-This puts memory back into the pool.  The pool is what was passed to
-dma_pool_alloc(); the CPU (vaddr) and DMA addresses are what
-were returned when that routine allocated the memory being freed.
-
-::
-
-	void
-	dma_pool_destroy(struct dma_pool *pool);
-
-dma_pool_destroy() frees the resources of the pool.  It must be
-called in a context which can sleep.  Make sure you've freed all allocated
-memory back to the pool before you destroy it.
-
-
-Part Ic - DMA addressing limitations
-------------------------------------
-
-::
-
-	int
-	dma_set_mask_and_coherent(struct device *dev, u64 mask)
-
-Checks to see if the mask is possible and updates the device
-streaming and coherent DMA mask parameters if it is.
-
-Returns: 0 if successful and a negative error if not.
-
-::
-
-	int
-	dma_set_mask(struct device *dev, u64 mask)
-
-Checks to see if the mask is possible and updates the device
-parameters if it is.
-
-Returns: 0 if successful and a negative error if not.
-
-::
-
-	int
-	dma_set_coherent_mask(struct device *dev, u64 mask)
-
-Checks to see if the mask is possible and updates the device
-parameters if it is.
-
-Returns: 0 if successful and a negative error if not.
-
-::
-
-	u64
-	dma_get_required_mask(struct device *dev)
-
-This API returns the mask that the platform requires to
-operate efficiently.  Usually this means the returned mask
-is the minimum required to cover all of memory.  Examining the
-required mask gives drivers with variable descriptor sizes the
-opportunity to use smaller descriptors as necessary.
-
-Requesting the required mask does not alter the current mask.  If you
-wish to take advantage of it, you should issue a dma_set_mask()
-call to set the mask to the value returned.
-
-::
-
-	size_t
-	dma_max_mapping_size(struct device *dev);
-
-Returns the maximum size of a mapping for the device. The size parameter
-of the mapping functions like dma_map_single(), dma_map_page() and
-others should not be larger than the returned value.
-
-::
-
-	unsigned long
-	dma_get_merge_boundary(struct device *dev);
-
-Returns the DMA merge boundary. If the device cannot merge any the DMA address
-segments, the function returns 0.
-
-Part Id - Streaming DMA mappings
---------------------------------
-
-::
-
-	dma_addr_t
-	dma_map_single(struct device *dev, void *cpu_addr, size_t size,
-		       enum dma_data_direction direction)
-
-Maps a piece of processor virtual memory so it can be accessed by the
-device and returns the DMA address of the memory.
-
-The direction for both APIs may be converted freely by casting.
-However the dma_API uses a strongly typed enumerator for its
-direction:
-
-======================= =============================================
-DMA_NONE		no direction (used for debugging)
-DMA_TO_DEVICE		data is going from the memory to the device
-DMA_FROM_DEVICE		data is coming from the device to the memory
-DMA_BIDIRECTIONAL	direction isn't known
-======================= =============================================
-
-.. note::
-
-	Not all memory regions in a machine can be mapped by this API.
-	Further, contiguous kernel virtual space may not be contiguous as
-	physical memory.  Since this API does not provide any scatter/gather
-	capability, it will fail if the user tries to map a non-physically
-	contiguous piece of memory.  For this reason, memory to be mapped by
-	this API should be obtained from sources which guarantee it to be
-	physically contiguous (like kmalloc).
-
-	Further, the DMA address of the memory must be within the
-	dma_mask of the device (the dma_mask is a bit mask of the
-	addressable region for the device, i.e., if the DMA address of
-	the memory ANDed with the dma_mask is still equal to the DMA
-	address, then the device can perform DMA to the memory).  To
-	ensure that the memory allocated by kmalloc is within the dma_mask,
-	the driver may specify various platform-dependent flags to restrict
-	the DMA address range of the allocation (e.g., on x86, GFP_DMA
-	guarantees to be within the first 16MB of available DMA addresses,
-	as required by ISA devices).
-
-	Note also that the above constraints on physical contiguity and
-	dma_mask may not apply if the platform has an IOMMU (a device which
-	maps an I/O DMA address to a physical memory address).  However, to be
-	portable, device driver writers may *not* assume that such an IOMMU
-	exists.
-
-.. warning::
-
-	Memory coherency operates at a granularity called the cache
-	line width.  In order for memory mapped by this API to operate
-	correctly, the mapped region must begin exactly on a cache line
-	boundary and end exactly on one (to prevent two separately mapped
-	regions from sharing a single cache line).  Since the cache line size
-	may not be known at compile time, the API will not enforce this
-	requirement.  Therefore, it is recommended that driver writers who
-	don't take special care to determine the cache line size at run time
-	only map virtual regions that begin and end on page boundaries (which
-	are guaranteed also to be cache line boundaries).
-
-	DMA_TO_DEVICE synchronisation must be done after the last modification
-	of the memory region by the software and before it is handed off to
-	the device.  Once this primitive is used, memory covered by this
-	primitive should be treated as read-only by the device.  If the device
-	may write to it at any point, it should be DMA_BIDIRECTIONAL (see
-	below).
-
-	DMA_FROM_DEVICE synchronisation must be done before the driver
-	accesses data that may be changed by the device.  This memory should
-	be treated as read-only by the driver.  If the driver needs to write
-	to it at any point, it should be DMA_BIDIRECTIONAL (see below).
-
-	DMA_BIDIRECTIONAL requires special handling: it means that the driver
-	isn't sure if the memory was modified before being handed off to the
-	device and also isn't sure if the device will also modify it.  Thus,
-	you must always sync bidirectional memory twice: once before the
-	memory is handed off to the device (to make sure all memory changes
-	are flushed from the processor) and once before the data may be
-	accessed after being used by the device (to make sure any processor
-	cache lines are updated with data that the device may have changed).
-
-::
-
-	void
-	dma_unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size,
-			 enum dma_data_direction direction)
-
-Unmaps the region previously mapped.  All the parameters passed in
-must be identical to those passed in (and returned) by the mapping
-API.
-
-::
-
-	dma_addr_t
-	dma_map_page(struct device *dev, struct page *page,
-		     unsigned long offset, size_t size,
-		     enum dma_data_direction direction)
-
-	void
-	dma_unmap_page(struct device *dev, dma_addr_t dma_address, size_t size,
-		       enum dma_data_direction direction)
-
-API for mapping and unmapping for pages.  All the notes and warnings
-for the other mapping APIs apply here.  Also, although the <offset>
-and <size> parameters are provided to do partial page mapping, it is
-recommended that you never use these unless you really know what the
-cache width is.
-
-::
-
-	dma_addr_t
-	dma_map_resource(struct device *dev, phys_addr_t phys_addr, size_t size,
-			 enum dma_data_direction dir, unsigned long attrs)
-
-	void
-	dma_unmap_resource(struct device *dev, dma_addr_t addr, size_t size,
-			   enum dma_data_direction dir, unsigned long attrs)
-
-API for mapping and unmapping for MMIO resources. All the notes and
-warnings for the other mapping APIs apply here. The API should only be
-used to map device MMIO resources, mapping of RAM is not permitted.
-
-::
-
-	int
-	dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
-
-In some circumstances dma_map_single(), dma_map_page() and dma_map_resource()
-will fail to create a mapping. A driver can check for these errors by testing
-the returned DMA address with dma_mapping_error(). A non-zero return value
-means the mapping could not be created and the driver should take appropriate
-action (e.g. reduce current DMA mapping usage or delay and try again later).
-
-::
-
-	int
-	dma_map_sg(struct device *dev, struct scatterlist *sg,
-		   int nents, enum dma_data_direction direction)
-
-Returns: the number of DMA address segments mapped (this may be shorter
-than <nents> passed in if some elements of the scatter/gather list are
-physically or virtually adjacent and an IOMMU maps them with a single
-entry).
-
-Please note that the sg cannot be mapped again if it has been mapped once.
-The mapping process is allowed to destroy information in the sg.
-
-As with the other mapping interfaces, dma_map_sg() can fail. When it
-does, 0 is returned and a driver must take appropriate action. It is
-critical that the driver do something, in the case of a block driver
-aborting the request or even oopsing is better than doing nothing and
-corrupting the filesystem.
-
-With scatterlists, you use the resulting mapping like this::
-
-	int i, count = dma_map_sg(dev, sglist, nents, direction);
-	struct scatterlist *sg;
-
-	for_each_sg(sglist, sg, count, i) {
-		hw_address[i] = sg_dma_address(sg);
-		hw_len[i] = sg_dma_len(sg);
-	}
-
-where nents is the number of entries in the sglist.
-
-The implementation is free to merge several consecutive sglist entries
-into one (e.g. with an IOMMU, or if several pages just happen to be
-physically contiguous) and returns the actual number of sg entries it
-mapped them to. On failure 0, is returned.
-
-Then you should loop count times (note: this can be less than nents times)
-and use sg_dma_address() and sg_dma_len() macros where you previously
-accessed sg->address and sg->length as shown above.
-
-::
-
-	void
-	dma_unmap_sg(struct device *dev, struct scatterlist *sg,
-		     int nents, enum dma_data_direction direction)
-
-Unmap the previously mapped scatter/gather list.  All the parameters
-must be the same as those and passed in to the scatter/gather mapping
-API.
-
-Note: <nents> must be the number you passed in, *not* the number of
-DMA address entries returned.
-
-::
-
-	void
-	dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle,
-				size_t size,
-				enum dma_data_direction direction)
-
-	void
-	dma_sync_single_for_device(struct device *dev, dma_addr_t dma_handle,
-				   size_t size,
-				   enum dma_data_direction direction)
-
-	void
-	dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
-			    int nents,
-			    enum dma_data_direction direction)
-
-	void
-	dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
-			       int nents,
-			       enum dma_data_direction direction)
-
-Synchronise a single contiguous or scatter/gather mapping for the CPU
-and device. With the sync_sg API, all the parameters must be the same
-as those passed into the single mapping API. With the sync_single API,
-you can use dma_handle and size parameters that aren't identical to
-those passed into the single mapping API to do a partial sync.
-
-
-.. note::
-
-   You must do this:
-
-   - Before reading values that have been written by DMA from the device
-     (use the DMA_FROM_DEVICE direction)
-   - After writing values that will be written to the device using DMA
-     (use the DMA_TO_DEVICE) direction
-   - before *and* after handing memory to the device if the memory is
-     DMA_BIDIRECTIONAL
-
-See also dma_map_single().
-
-::
-
-	dma_addr_t
-	dma_map_single_attrs(struct device *dev, void *cpu_addr, size_t size,
-			     enum dma_data_direction dir,
-			     unsigned long attrs)
-
-	void
-	dma_unmap_single_attrs(struct device *dev, dma_addr_t dma_addr,
-			       size_t size, enum dma_data_direction dir,
-			       unsigned long attrs)
-
-	int
-	dma_map_sg_attrs(struct device *dev, struct scatterlist *sgl,
-			 int nents, enum dma_data_direction dir,
-			 unsigned long attrs)
-
-	void
-	dma_unmap_sg_attrs(struct device *dev, struct scatterlist *sgl,
-			   int nents, enum dma_data_direction dir,
-			   unsigned long attrs)
-
-The four functions above are just like the counterpart functions
-without the _attrs suffixes, except that they pass an optional
-dma_attrs.
-
-The interpretation of DMA attributes is architecture-specific, and
-each attribute should be documented in Documentation/DMA-attributes.txt.
-
-If dma_attrs are 0, the semantics of each of these functions
-is identical to those of the corresponding function
-without the _attrs suffix. As a result dma_map_single_attrs()
-can generally replace dma_map_single(), etc.
-
-As an example of the use of the ``*_attrs`` functions, here's how
-you could pass an attribute DMA_ATTR_FOO when mapping memory
-for DMA::
-
-	#include <linux/dma-mapping.h>
-	/* DMA_ATTR_FOO should be defined in linux/dma-mapping.h and
-	* documented in Documentation/DMA-attributes.txt */
-	...
-
-		unsigned long attr;
-		attr |= DMA_ATTR_FOO;
-		....
-		n = dma_map_sg_attrs(dev, sg, nents, DMA_TO_DEVICE, attr);
-		....
-
-Architectures that care about DMA_ATTR_FOO would check for its
-presence in their implementations of the mapping and unmapping
-routines, e.g.:::
-
-	void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t dma_addr,
-				     size_t size, enum dma_data_direction dir,
-				     unsigned long attrs)
-	{
-		....
-		if (attrs & DMA_ATTR_FOO)
-			/* twizzle the frobnozzle */
-		....
-	}
-
-
-Part II - Advanced dma usage
-----------------------------
-
-Warning: These pieces of the DMA API should not be used in the
-majority of cases, since they cater for unlikely corner cases that
-don't belong in usual drivers.
-
-If you don't understand how cache line coherency works between a
-processor and an I/O device, you should not be using this part of the
-API at all.
-
-::
-
-	void *
-	dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,
-			gfp_t flag, unsigned long attrs)
-
-Identical to dma_alloc_coherent() except that when the
-DMA_ATTR_NON_CONSISTENT flags is passed in the attrs argument, the
-platform will choose to return either consistent or non-consistent memory
-as it sees fit.  By using this API, you are guaranteeing to the platform
-that you have all the correct and necessary sync points for this memory
-in the driver should it choose to return non-consistent memory.
-
-Note: where the platform can return consistent memory, it will
-guarantee that the sync points become nops.
-
-Warning:  Handling non-consistent memory is a real pain.  You should
-only use this API if you positively know your driver will be
-required to work on one of the rare (usually non-PCI) architectures
-that simply cannot make consistent memory.
-
-::
-
-	void
-	dma_free_attrs(struct device *dev, size_t size, void *cpu_addr,
-		       dma_addr_t dma_handle, unsigned long attrs)
-
-Free memory allocated by the dma_alloc_attrs().  All common
-parameters must be identical to those otherwise passed to dma_free_coherent,
-and the attrs argument must be identical to the attrs passed to
-dma_alloc_attrs().
-
-::
-
-	int
-	dma_get_cache_alignment(void)
-
-Returns the processor cache alignment.  This is the absolute minimum
-alignment *and* width that you must observe when either mapping
-memory or doing partial flushes.
-
-.. note::
-
-	This API may return a number *larger* than the actual cache
-	line, but it will guarantee that one or more cache lines fit exactly
-	into the width returned by this call.  It will also always be a power
-	of two for easy alignment.
-
-::
-
-	void
-	dma_cache_sync(struct device *dev, void *vaddr, size_t size,
-		       enum dma_data_direction direction)
-
-Do a partial sync of memory that was allocated by dma_alloc_attrs() with
-the DMA_ATTR_NON_CONSISTENT flag starting at virtual address vaddr and
-continuing on for size.  Again, you *must* observe the cache line
-boundaries when doing this.
-
-::
-
-	int
-	dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr,
-				    dma_addr_t device_addr, size_t size);
-
-Declare region of memory to be handed out by dma_alloc_coherent() when
-it's asked for coherent memory for this device.
-
-phys_addr is the CPU physical address to which the memory is currently
-assigned (this will be ioremapped so the CPU can access the region).
-
-device_addr is the DMA address the device needs to be programmed
-with to actually address this memory (this will be handed out as the
-dma_addr_t in dma_alloc_coherent()).
-
-size is the size of the area (must be multiples of PAGE_SIZE).
-
-As a simplification for the platforms, only *one* such region of
-memory may be declared per device.
-
-For reasons of efficiency, most platforms choose to track the declared
-region only at the granularity of a page.  For smaller allocations,
-you should use the dma_pool() API.
-
-Part III - Debug drivers use of the DMA-API
--------------------------------------------
-
-The DMA-API as described above has some constraints. DMA addresses must be
-released with the corresponding function with the same size for example. With
-the advent of hardware IOMMUs it becomes more and more important that drivers
-do not violate those constraints. In the worst case such a violation can
-result in data corruption up to destroyed filesystems.
-
-To debug drivers and find bugs in the usage of the DMA-API checking code can
-be compiled into the kernel which will tell the developer about those
-violations. If your architecture supports it you can select the "Enable
-debugging of DMA-API usage" option in your kernel configuration. Enabling this
-option has a performance impact. Do not enable it in production kernels.
-
-If you boot the resulting kernel will contain code which does some bookkeeping
-about what DMA memory was allocated for which device. If this code detects an
-error it prints a warning message with some details into your kernel log. An
-example warning message may look like this::
-
-	WARNING: at /data2/repos/linux-2.6-iommu/lib/dma-debug.c:448
-		check_unmap+0x203/0x490()
-	Hardware name:
-	forcedeth 0000:00:08.0: DMA-API: device driver frees DMA memory with wrong
-		function [device address=0x00000000640444be] [size=66 bytes] [mapped as
-	single] [unmapped as page]
-	Modules linked in: nfsd exportfs bridge stp llc r8169
-	Pid: 0, comm: swapper Tainted: G        W  2.6.28-dmatest-09289-g8bb99c0 #1
-	Call Trace:
-	<IRQ>  [<ffffffff80240b22>] warn_slowpath+0xf2/0x130
-	[<ffffffff80647b70>] _spin_unlock+0x10/0x30
-	[<ffffffff80537e75>] usb_hcd_link_urb_to_ep+0x75/0xc0
-	[<ffffffff80647c22>] _spin_unlock_irqrestore+0x12/0x40
-	[<ffffffff8055347f>] ohci_urb_enqueue+0x19f/0x7c0
-	[<ffffffff80252f96>] queue_work+0x56/0x60
-	[<ffffffff80237e10>] enqueue_task_fair+0x20/0x50
-	[<ffffffff80539279>] usb_hcd_submit_urb+0x379/0xbc0
-	[<ffffffff803b78c3>] cpumask_next_and+0x23/0x40
-	[<ffffffff80235177>] find_busiest_group+0x207/0x8a0
-	[<ffffffff8064784f>] _spin_lock_irqsave+0x1f/0x50
-	[<ffffffff803c7ea3>] check_unmap+0x203/0x490
-	[<ffffffff803c8259>] debug_dma_unmap_page+0x49/0x50
-	[<ffffffff80485f26>] nv_tx_done_optimized+0xc6/0x2c0
-	[<ffffffff80486c13>] nv_nic_irq_optimized+0x73/0x2b0
-	[<ffffffff8026df84>] handle_IRQ_event+0x34/0x70
-	[<ffffffff8026ffe9>] handle_edge_irq+0xc9/0x150
-	[<ffffffff8020e3ab>] do_IRQ+0xcb/0x1c0
-	[<ffffffff8020c093>] ret_from_intr+0x0/0xa
-	<EOI> <4>---[ end trace f6435a98e2a38c0e ]---
-
-The driver developer can find the driver and the device including a stacktrace
-of the DMA-API call which caused this warning.
-
-Per default only the first error will result in a warning message. All other
-errors will only silently counted. This limitation exist to prevent the code
-from flooding your kernel log. To support debugging a device driver this can
-be disabled via debugfs. See the debugfs interface documentation below for
-details.
-
-The debugfs directory for the DMA-API debugging code is called dma-api/. In
-this directory the following files can currently be found:
-
-=============================== ===============================================
-dma-api/all_errors		This file contains a numeric value. If this
-				value is not equal to zero the debugging code
-				will print a warning for every error it finds
-				into the kernel log. Be careful with this
-				option, as it can easily flood your logs.
-
-dma-api/disabled		This read-only file contains the character 'Y'
-				if the debugging code is disabled. This can
-				happen when it runs out of memory or if it was
-				disabled at boot time
-
-dma-api/dump			This read-only file contains current DMA
-				mappings.
-
-dma-api/error_count		This file is read-only and shows the total
-				numbers of errors found.
-
-dma-api/num_errors		The number in this file shows how many
-				warnings will be printed to the kernel log
-				before it stops. This number is initialized to
-				one at system boot and be set by writing into
-				this file
-
-dma-api/min_free_entries	This read-only file can be read to get the
-				minimum number of free dma_debug_entries the
-				allocator has ever seen. If this value goes
-				down to zero the code will attempt to increase
-				nr_total_entries to compensate.
-
-dma-api/num_free_entries	The current number of free dma_debug_entries
-				in the allocator.
-
-dma-api/nr_total_entries	The total number of dma_debug_entries in the
-				allocator, both free and used.
-
-dma-api/driver_filter		You can write a name of a driver into this file
-				to limit the debug output to requests from that
-				particular driver. Write an empty string to
-				that file to disable the filter and see
-				all errors again.
-=============================== ===============================================
-
-If you have this code compiled into your kernel it will be enabled by default.
-If you want to boot without the bookkeeping anyway you can provide
-'dma_debug=off' as a boot parameter. This will disable DMA-API debugging.
-Notice that you can not enable it again at runtime. You have to reboot to do
-so.
-
-If you want to see debug messages only for a special device driver you can
-specify the dma_debug_driver=<drivername> parameter. This will enable the
-driver filter at boot time. The debug code will only print errors for that
-driver afterwards. This filter can be disabled or changed later using debugfs.
-
-When the code disables itself at runtime this is most likely because it ran
-out of dma_debug_entries and was unable to allocate more on-demand. 65536
-entries are preallocated at boot - if this is too low for you boot with
-'dma_debug_entries=<your_desired_number>' to overwrite the default. Note
-that the code allocates entries in batches, so the exact number of
-preallocated entries may be greater than the actual number requested. The
-code will print to the kernel log each time it has dynamically allocated
-as many entries as were initially preallocated. This is to indicate that a
-larger preallocation size may be appropriate, or if it happens continually
-that a driver may be leaking mappings.
-
-::
-
-	void
-	debug_dma_mapping_error(struct device *dev, dma_addr_t dma_addr);
-
-dma-debug interface debug_dma_mapping_error() to debug drivers that fail
-to check DMA mapping errors on addresses returned by dma_map_single() and
-dma_map_page() interfaces. This interface clears a flag set by
-debug_dma_map_page() to indicate that dma_mapping_error() has been called by
-the driver. When driver does unmap, debug_dma_unmap() checks the flag and if
-this flag is still set, prints warning message that includes call trace that
-leads up to the unmap. This interface can be called from dma_mapping_error()
-routines to enable DMA mapping error check debugging.