summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-06-28dma: Take into account dma_pfn_offsetVladimir Murzin
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 Hellwig
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 Hellwig
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 Bergmann
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 Hellwig
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 Hellwig
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 Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28dma-mapping: remove the set_dma_mask methodChristoph Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28powerpc/cell: use the dma_supported method for ops switchingChristoph Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
Same behavior, less code duplication. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28dma-mapping: remove HAVE_ARCH_DMA_SUPPORTEDChristoph Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28x86: remove arch specific dma_supported implementationChristoph Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-28hexagon: remove arch-specific dma_supported implementationChristoph Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Richard Kuo <rkuo@codeaurora.org>
2017-06-20arm64: remove DMA_ERROR_CODEChristoph Hellwig
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 Hellwig
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 Hellwig
sh does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20openrisc: remove DMA_ERROR_CODEChristoph Hellwig
openrisc does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20microblaze: remove DMA_ERROR_CODEChristoph Hellwig
microblaze does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20m32r: remove DMA_ERROR_CODEChristoph Hellwig
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 Hellwig
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 Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-06-20xen-swiotlb: implement ->mapping_errorChristoph Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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 Hellwig
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>
2017-06-20firmware/ivc: use dma_mapping_errorChristoph Hellwig
DMA_ERROR_CODE is not supposed to be used by drivers. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Thierry Reding <treding@nvidia.com>