summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-06-28drivers: dma-coherent: Account dma_pfn_offset when used with device treeVladimir Murzin1-2/+13
dma_declare_coherent_memory() and friends are designed to account difference in CPU and device addresses. However, when it is used with reserved memory regions there is assumption that CPU and device have the same view on address space. This assumption gets invalid when reserved memory for coherent DMA allocations is referenced by device with non-empty "dma-range" property. Simply feeding device address as rmem->base + dev->dma_pfn_offset would not work due to reserved memory region can be shared, so this patch turns device address to be expressed with help of CPU address and device's dma_pfn_offset in case memory reservation has been done via device tree; non device tree users continue to use the old scheme. Cc: Michal Nazarewicz <mina86@mina86.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Roger Quadros <rogerq@ti.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Tested-by: Andras Szemzo <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28dma: Take into account dma_pfn_offsetVladimir Murzin1-3/+6
Even though dma-noop-ops assumes 1:1 memory mapping DMA memory range can be different to RAM. For example, ARM STM32F4 MCU offers the possibility to remap SDRAM from 0xc000_0000 to 0x0 to get CPU performance boost, but DMA continue to see SDRAM at 0xc000_0000. This difference in mapping is handled via device-tree "dma-range" property which leads to dev->dma_pfn_offset is set nonzero. To handle such cases take dma_pfn_offset into account. Cc: Joerg Roedel <jroedel@suse.de> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Reported-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Tested-by: Andras Szemzo <sza@esh.hu> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28dma-mapping: replace dmam_alloc_noncoherent with dmam_alloc_attrsChristoph Hellwig4-25/+23
dmam_alloc_noncoherent is a trivial wrapper around dmam_alloc_attrs, that hardcodes one particular flag. Make the devres code more flexible by allowing the callers to pass arbitrary flags. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Tejun Heo <tj@kernel.org>
2017-06-28dma-mapping: remove dmam_free_noncoherentChristoph Hellwig3-23/+0
This function was never used since it was added. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Tejun Heo <tj@kernel.org>
2017-06-28crypto: qat - avoid an uninitialized variable warningArnd Bergmann1-19/+21
After commit 9e442aa6a753 ("x86: remove DMA_ERROR_CODE"), the inlining decisions in the qat driver changed slightly, introducing a new false-positive warning: drivers/crypto/qat/qat_common/qat_algs.c: In function 'qat_alg_sgl_to_bufl.isra.6': include/linux/dma-mapping.h:228:2: error: 'sz_out' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/crypto/qat/qat_common/qat_algs.c:676:9: note: 'sz_out' was declared here The patch that introduced this is correct, so let's just avoid the warning in this driver by rearranging the unwinding after an error to make it more obvious to the compiler what is going on. The problem here is the 'if (unlikely(dma_mapping_error(dev, blp)))' check, in which the 'unlikely' causes gcc to forget what it knew about the state of the variables. Cleaning up the dma state in the reverse order it was created means we can simplify the logic so it doesn't have to know about that state, and also makes it easier to understand. Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28au1100fb: remove a bogus dma_free_nonconsistent callChristoph Hellwig1-4/+0
au1100fb is using managed dma allocations, so it doesn't need to explicitly free the dma memory in the error path (and if it did it would have to use the managed version). Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2017-06-28MAINTAINERS: add entry for dma mapping helpersChristoph Hellwig1-0/+15
This code has been spread between getting in through arch trees, the iommu tree, -mm and the drivers tree. There will be a lot of work in this area, including consolidating various arch implementations into more common code, so ensure we have a proper git tree that facilitates cooperation with the architecture maintainers. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28powerpc: merge __dma_set_mask into dma_set_maskChristoph Hellwig2-10/+4
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28dma-mapping: remove the set_dma_mask methodChristoph Hellwig2-10/+0
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28powerpc/cell: use the dma_supported method for ops switchingChristoph Hellwig1-16/+9
Besides removing the last instance of the set_dma_mask method this also reduced the code duplication. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28powerpc/cell: clean up fixed mapping dma_ops initializationChristoph Hellwig1-20/+7
By the time cell_pci_dma_dev_setup calls cell_dma_dev_setup no device can have the fixed map_ops set yet as it's only set by the set_dma_mask method. So move the setup for the fixed case to be only called in that place instead of indirecting through cell_dma_dev_setup. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28tile: remove dma_supported and mapping_error methodsChristoph Hellwig1-30/+0
These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28xen-swiotlb: remove xen_swiotlb_set_dma_maskChristoph Hellwig1-12/+0
This just duplicates the generic implementation. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28arm: implement ->dma_supported instead of ->set_dma_maskChristoph Hellwig1-4/+3
Same behavior, less code duplication. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28mips/loongson64: implement ->dma_supported instead of ->set_dma_maskChristoph Hellwig1-14/+5
Same behavior, less code duplication. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28dma-mapping: remove HAVE_ARCH_DMA_SUPPORTEDChristoph Hellwig1-2/+0
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28x86: remove arch specific dma_supported implementationChristoph Hellwig9-11/+13
And instead wire it up as method for all the dma_map_ops instances. Note that this also means the arch specific check will be fully instead of partially applied in the AMD iommu driver. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28arm: remove arch specific dma_supported implementationChristoph Hellwig4-5/+8
And instead wire it up as method for all the dma_map_ops instances. Note that the code seems a little fishy for dmabounce and iommu, but for now I'd like to preserve the existing behavior 1:1. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28openrisc: remove arch-specific dma_supported implementationChristoph Hellwig1-7/+0
This implementation is simply bogus - openrisc only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28hexagon: remove the unused dma_is_consistent prototypeChristoph Hellwig1-1/+0
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28hexagon: remove arch-specific dma_supported implementationChristoph Hellwig2-11/+0
This implementation is simply bogus - hexagon only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Richard Kuo <rkuo@codeaurora.org>
2017-06-28dma-virt: remove dma_supported and mapping_error methodsChristoph Hellwig1-12/+0
These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28dma-noop: remove dma_supported and mapping_error methodsChristoph Hellwig1-12/+0
These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28sparc: remove arch specific dma_supported implementationsChristoph Hellwig4-43/+39
Usually dma_supported decisions are done by the dma_map_ops instance. Switch sparc to that model by providing a ->dma_supported instance for sbus that always returns false, and implementations tailored to the sun4u and sun4v cases for sparc64, and leave it unimplemented for PCI on sparc32, which means always supported. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: David S. Miller <davem@davemloft.net>
2017-06-28sparc: remove leon_dma_opsChristoph Hellwig2-6/+2
We can just use pci32_dma_ops directly. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: David S. Miller <davem@davemloft.net>
2017-06-28dma-mapping: remove DMA_ERROR_CODEChristoph Hellwig2-31/+5
And update the documentation - dma_mapping_error has been supported everywhere for a long time. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28arm: implement ->mapping_errorChristoph Hellwig4-19/+38
DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28x86: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
All dma_map_ops instances now handle their errors through ->mapping_error. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28x86/calgary: implement ->mapping_errorChristoph Hellwig1-8/+16
DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28x86/pci-nommu: implement ->mapping_errorChristoph Hellwig1-1/+9
DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28powerpc: implement ->mapping_errorChristoph Hellwig6-19/+27
DMA_ERROR_CODE is going to go away, so don't rely on it. Instead define a ->mapping_error method for all IOMMU based dma operation instances. The direct ops don't ever return an error and don't need a ->mapping_error method. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
2017-06-28sparc: implement ->mapping_errorChristoph Hellwig4-9/+21
DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: David S. Miller <davem@davemloft.net>
2017-06-28s390: implement ->mapping_errorChristoph Hellwig2-7/+13
s390 can also use noop_dma_ops, and while that currently does not return errors it will so in the future. Implementing the mapping_error method is the proper way to have per-ops error conditions. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
2017-06-28iommu/amd: implement ->mapping_errorChristoph Hellwig1-5/+13
DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28hexagon: switch to use ->mapping_error for error reportingChristoph Hellwig3-6/+9
Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Richard Kuo <rkuo@codeaurora.org>
2017-06-20arm64: remove DMA_ERROR_CODEChristoph Hellwig2-3/+1
The dma alloc interface returns an error by return NULL, and the mapping interfaces rely on the mapping_error method, which the dummy ops already implement correctly. Thus remove the DMA_ERROR_CODE define. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
2017-06-20xtensa: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
xtensa already implements the mapping_error method for its only dma_map_ops instance. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20sh: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
sh does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20openrisc: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
openrisc does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20microblaze: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
microblaze does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20m32r: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
dma-noop is the only dma_mapping_ops instance for m32r and does not return errors. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20ia64: remove DMA_ERROR_CODEChristoph Hellwig1-2/+0
All ia64 dma_mapping_ops instances already have a mapping_error member. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20c6x: remove DMA_ERROR_CODEChristoph Hellwig1-5/+0
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20xen-swiotlb: implement ->mapping_errorChristoph Hellwig1-2/+10
DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2017-06-20xen-swiotlb: consolidate xen_swiotlb_dma_opsChristoph Hellwig4-137/+49
ARM and x86 had duplicated versions of the dma_ops structure, the only difference is that x86 hasn't wired up the set_dma_mask, mmap, and get_sgtable ops yet. On x86 all of them are identical to the generic version, so they aren't needed but harmless. All the symbols used only for xen_swiotlb_dma_ops can now be marked static as well. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2017-06-20iommu/dma: don't rely on DMA_ERROR_CODEChristoph Hellwig1-8/+10
DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu driver already implements a proper ->mapping_error method, so it's only using the value internally. Add a new local define using the value that arm64 which is the only current user of dma-iommu. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20drm/armada: don't abuse DMA_ERROR_CODEChristoph Hellwig3-4/+4
dev_addr isn't even a dma_addr_t, and DMA_ERROR_CODE has never been a valid driver API. Add a bool mapped flag instead. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20drm/exynos: don't use DMA_ERROR_CODEChristoph Hellwig1-2/+2
DMA_ERROR_CODE already isn't a valid API to user for drivers and will go away soon. exynos_drm_fb_dma_addr uses it a an error return when the passed in index is invalid, but the callers never check for it but instead pass the address straight to the hardware. Add a WARN_ON instead and just return 0. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20dmaengine: ioat: don't use DMA_ERROR_CODEChristoph Hellwig1-17/+7
DMA_ERROR_CODE is not a public API and will go away. Instead properly unwind based on the loop counter. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Dave Jiang <dave.jiang@intel.com> Acked-By: Vinod Koul <vinod.koul@intel.com>
2017-06-20ibmveth: properly unwind on init errorsChristoph Hellwig1-85/+74
That way the driver doesn't have to rely on DMA_ERROR_CODE, which is not a public API and going away. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-24 06:11:01 +0300