user/sven/linux.git/include/linux/dma-mapping.h, branch v4.4.183

dma-mapping: tidy up dma_parms default handling

2015-11-07T01:50:42Z

Many DMA controllers and other devices set max_segment_size to indicate their scatter-gather capability, but have no interest in segment_boundary_mask. However, the existence of a dma_parms structure precludes the use of any default value, leaving them as zeros (assuming a properly kzalloc'ed structure). If a well-behaved IOMMU (or SWIOTLB) then tries to respect this by ensuring a mapped segment does not cross a zero-byte boundary, hilarity ensues. Since zero is a nonsensical value for either parameter, treat it as an indicator for "default", as might be expected. In the process, clean up a bit by replacing the bare constants with slightly more meaningful macros and removing the superfluous "else" statements. [akpm@linux-foundation.org: dma-mapping.h needs sizes.h for SZ_64K] Signed-off-by: Robin Murphy Reviewed-by: Sumit Semwal Acked-by: Marek Szyprowski Cc: Arnd Bergmann Cc: Sakari Ailus Cc: Russell King Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

include/dma-mapping: Clarify output of dma_map_sg

2015-03-09T12:05:47Z

Although dma_map_sg returns 0 on error and it cannot return a value < 0, the function returns a signed integer. Most of the time, this function is used with a scatterlist structure. This structure uses an unsigned integer for the number of memory. A dma developer that has not read in detail DMA-API.txt, can wrongly return a value < 0 on error. Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Marek Szyprowski

dma-mapping: detect and configure IOMMU in of_dma_configure

2014-12-01T16:50:45Z

This patch extends of_dma_configure so that it sets up the IOMMU for a device, as well as the coherent/non-coherent DMA mapping ops. Acked-by: Arnd Bergmann Acked-by: Marek Szyprowski Tested-by: Robin Murphy Signed-off-by: Will Deacon

dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops

2014-12-01T16:50:32Z

set_arch_dma_coherent_ops is called from of_dma_configure in order to swizzle the architectural dma-mapping functions over to a cache-coherent implementation. This is currently implemented only for ARM. In anticipation of re-using this mechanism for IOMMU-backed dma-mapping ops too, this patch replaces the function with a broader arch_setup_dma_ops callback which will be extended in future. Acked-by: Arnd Bergmann Acked-by: Marek Szyprowski Tested-by: Robin Murphy Signed-off-by: Will Deacon

dma-mapping: Provide write-combine allocations

2014-08-26T05:39:13Z

Provide an implementation for dma_{alloc,free,mmap}_writecombine() when the architecture supports DMA attributes. Signed-off-by: Thierry Reding Acked-by: Arnd Bergmann Signed-off-by: Marek Szyprowski

Merge branch 'for-linus' of git://ftp.arm.linux.org.uk/~rmk/linux-arm into next

2014-06-05T22:57:04Z

Pull ARM updates from Russell King: - Major clean-up of the L2 cache support code. The existing mess was becoming rather unmaintainable through all the additions that others have done over time. This turns it into a much nicer structure, and implements a few performance improvements as well. - Clean up some of the CP15 control register tweaks for alignment support, moving some code and data into alignment.c - DMA properties for ARM, from Santosh and reviewed by DT people. This adds DT properties to specify bus translations we can't discover automatically, and to indicate whether devices are coherent. - Hibernation support for ARM - Make ftrace work with read-only text in modules - add suspend support for PJ4B CPUs - rework interrupt masking for undefined instruction handling, which allows us to enable interrupts earlier in the handling of these exceptions. - support for big endian page tables - fix stacktrace support to exclude stacktrace functions from the trace, and add save_stack_trace_regs() implementation so that kprobes can record stack traces. - Add support for the Cortex-A17 CPU. - Remove last vestiges of ARM710 support. - Removal of ARM "meminfo" structure, finally converting us solely to memblock to handle the early memory initialisation. * 'for-linus' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: (142 commits) ARM: ensure C page table setup code follows assembly code (part II) ARM: ensure C page table setup code follows assembly code ARM: consolidate last remaining open-coded alignment trap enable ARM: remove global cr_no_alignment ARM: remove CPU_CP15 conditional from alignment.c ARM: remove unused adjust_cr() function ARM: move "noalign" command line option to alignment.c ARM: provide common method to clear bits in CPU control register ARM: 8025/1: Get rid of meminfo ARM: 8060/1: mm: allow sub-architectures to override PCI I/O memory type ARM: 8066/1: correction for ARM patch 8031/2 ARM: 8049/1: ftrace/add save_stack_trace_regs() implementation ARM: 8065/1: remove last use of CONFIG_CPU_ARM710 ARM: 8062/1: Modify ldrt fixup handler to re-execute the userspace instruction ARM: 8047/1: rwsem: use asm-generic rwsem implementation ARM: l2c: trial at enabling some Cortex-A9 optimisations ARM: l2c: add warnings for stuff modifying aux_ctrl register values ARM: l2c: print a warning with L2C-310 caches if the cache size is modified ARM: l2c: remove old .set_debug method ARM: l2c: kill L2X0_AUX_CTRL_MASK before anyone else makes use of this ...

DMA-API: Change dma_declare_coherent_memory() CPU address to phys_addr_t

2014-05-20T22:55:23Z

dma_declare_coherent_memory() takes two addresses for a region of memory: a "bus_addr" and a "device_addr". I think the intent is that "bus_addr" is the physical address a *CPU* would use to access the region, and "device_addr" is the bus address the *device* would use to address the region. Rename "bus_addr" to "phys_addr" and change its type to phys_addr_t. Most callers already supply a phys_addr_t for this argument. The others supply a 32-bit integer (a constant, unsigned int, or __u32) and need no change. Use "unsigned long", not phys_addr_t, to hold PFNs. No functional change (this could theoretically fix a truncation in a config with 32-bit dma_addr_t and 64-bit phys_addr_t, but I don't think there are any such cases involving this code). Signed-off-by: Bjorn Helgaas Acked-by: Arnd Bergmann Acked-by: Greg Kroah-Hartman Acked-by: James Bottomley Acked-by: Randy Dunlap

DMA-API: Clarify physical/bus address distinction

2014-05-20T22:54:21Z

The DMA-API documentation sometimes refers to "physical addresses" when it really means "bus addresses." Sometimes these are identical, but they may be different if the bridge leading to the bus performs address translation. Update the documentation to use "bus address" when appropriate. Also, consistently capitalize "DMA", use parens with function names, use dev_printk() in examples, and reword a few sections for clarity. No functional change; documentation changes only. Signed-off-by: Bjorn Helgaas Acked-by: Greg Kroah-Hartman Acked-by: Arnd Bergmann Acked-by: James Bottomley Acked-by: Randy Dunlap

of: configure the platform device dma parameters

2014-05-07T13:21:21Z

Retrieve DMA configuration from DT and setup platform device's DMA parameters. The DMA configuration in DT has to be specified using "dma-ranges" and "dma-coherent" properties if supported. We setup dma_pfn_offset using "dma-ranges" and dma_coherent_ops using "dma-coherent" device tree properties. The set_arch_dma_coherent_ops macro has to be defined by arch if it supports coherent dma_ops. Otherwise, set_arch_dma_coherent_ops() is declared as nop. Cc: Greg Kroah-Hartman Cc: Russell King Cc: Arnd Bergmann Cc: Olof Johansson Cc: Grant Likely Cc: Catalin Marinas Cc: Linus Walleij Reviewed-by: Rob Herring Signed-off-by: Grygorii Strashko Signed-off-by: Santosh Shilimkar

ARM: 7795/1: mm: dma-mapping: Add dma_max_pfn(dev) helper function

2013-10-31T14:49:24Z

Most of the kernel assumes that PFN0 is the start of the physical memory (RAM). This assumptions is not true on most of the ARM SOCs and hence and if one try to update the ARM port to follow the assumptions, we end of breaking the dma bounce limit for few block layer drivers. One such example is trying to unify the meaning of max*_pfn on ARM as the bootmem layer expects, breaks few block layer driver dma bounce limit. To fix this problem, we introduce dma_max_pfn(dev) generic helper with a possibility of override from the architecture code. The helper converts a DMA bitmask of bits to a block PFN number. In all the generic cases, it is just "dev->dma_mask >> PAGE_SHIFT" and hence default behavior is maintained as is. Subsequent patches will make use of the helper. No functional change. Cc: Jens Axboe Signed-off-by: Santosh Shilimkar Signed-off-by: Russell King