aboutsummaryrefslogtreecommitdiffstats
path: root/lib/dma-direct.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2018-05-31dma-direct: don't crash on device without dma_maskChristoph Hellwig1-0/+7
Print a useful warning instead. Reported-by: Finn Thain <fthain@telegraphics.com.au> Tested-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-05-28core, dma-direct: add a flag 32-bit dma limitsChristoph Hellwig1-0/+6
Various PCI bridges (VIA PCI, Xilinx PCIe) limit DMA to only 32-bits even if the device itself supports more. Add a single bit flag to struct device (to be moved into the dma extension once we get to it) to flag such devices and reject larger DMA to them. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-19dma-mapping: provide a generic dma-noncoherent implementationChristoph Hellwig1-4/+4
Add a new dma_map_ops implementation that uses dma-direct for the address mapping of streaming mappings, and which requires arch-specific implemenations of coherent allocate/free. Architectures have to provide flushing helpers to ownership trasnfers to the device and/or CPU, and can provide optional implementations of the coherent mmap functionality, and the cache_flush routines for non-coherent long term allocations. Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Alexey Brodkin <abrodkin@synopsys.com> Acked-by: Vineet Gupta <vgupta@synopsys.com>
2018-05-07PCI: remove PCI_DMA_BUS_IS_PHYSChristoph Hellwig1-1/+0
This was used by the ide, scsi and networking code in the past to determine if they should bounce payloads. Now that the dma mapping always have to support dma to all physical memory (thanks to swiotlb for non-iommu systems) there is no need to this crude hack any more. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Palmer Dabbelt <palmer@sifive.com> (for riscv) Reviewed-by: Jens Axboe <axboe@kernel.dk>
2018-05-07dma-direct: try reallocation with GFP_DMA32 if possibleTakashi Iwai1-0/+7
As the recent swiotlb bug revealed, we seem to have given up the direct DMA allocation too early and felt back to swiotlb allocation. The reason is that swiotlb allocator expected that dma_direct_alloc() would try harder to get pages even below 64bit DMA mask with GFP_DMA32, but the function doesn't do that but only deals with GFP_DMA case. This patch adds a similar fallback reallocation with GFP_DMA32 as we've done with GFP_DMA. The condition is that the coherent mask is smaller than 64bit (i.e. some address limitation), and neither GFP_DMA nor GFP_DMA32 is set beforehand. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-04-23dma-direct: don't retry allocation for no-op GFP_DMATakashi Iwai1-1/+2
When an allocation with lower dma_coherent mask fails, dma_direct_alloc() retries the allocation with GFP_DMA. But, this is useless for architectures that hav no ZONE_DMA. Fix it by adding the check of CONFIG_ZONE_DMA before retrying the allocation. Fixes: 95f183916d4b ("dma-direct: retry allocations using GFP_DMA for small masks") Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-03-28dma-mapping: Don't clear GFP_ZERO in dma_alloc_attrsChristoph Hellwig1-0/+3
Revert the clearing of __GFP_ZERO in dma_alloc_attrs and move it to dma_direct_alloc for now. While most common architectures always zero dma cohereny allocations (and x86 did so since day one) this is not documented and at least arc and s390 do not zero without the explicit __GFP_ZERO argument. Fixes: 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in common code") Reported-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com> Reported-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com> Cc: iommu@lists.linux-foundation.org Link: https://lkml.kernel.org/r/20180328133535.17302-2-hch@lst.de
2018-03-20dma/direct: Handle force decryption for DMA coherent buffers in common codeChristoph Hellwig1-6/+26
With that in place the generic DMA-direct routines can be used to allocate non-encrypted bounce buffers, and the x86 SEV case can use the generic swiotlb ops including nice features such as using CMA allocations. Note that I'm not too happy about using sev_active() in DMA-direct, but I couldn't come up with a good enough name for a wrapper to make it worth adding. Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Joerg Roedel <joro@8bytes.org> Cc: Jon Mason <jdmason@kudzu.us> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Muli Ben-Yehuda <mulix@mulix.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: iommu@lists.linux-foundation.org Link: http://lkml.kernel.org/r/20180319103826.12853-14-hch@lst.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-12dma-direct: comment the dma_direct_free calling conventionChristoph Hellwig1-0/+4
Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-02-12dma-direct: mark as is_physChristoph Hellwig1-0/+1
Various PCI_DMA_BUS_IS_PHYS implementations rely on this flag to make proper decisions for block and networking addressability. Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-01-15dma-direct: reject too small dma masksChristoph Hellwig1-0/+19
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
2018-01-15dma-direct: make dma_direct_{alloc,free} available to other implementationsChristoph Hellwig1-3/+3
So that they don't need to indirect through the operation vector. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
2018-01-15dma-direct: retry allocations using GFP_DMA for small masksChristoph Hellwig1-1/+24
If an attempt to allocate memory succeeded, but isn't inside the supported DMA mask, retry the allocation with GFP_DMA set as a last resort. Based on the x86 code, but an off by one error in what is now dma_coherent_ok has been fixed vs the x86 code. Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-01-15dma-direct: add support for allocation from ZONE_DMA and ZONE_DMA32Christoph Hellwig1-0/+14
This allows to dip into zones for lower memory if they are available. If one of the zones is not available the corresponding GFP_* flag will evaluate to 0 so they won't change anything. We provide an arch tunable for those architectures that do not use GFP_DMA for the lowest 24-bits, given that there are a few. Roughly based on the x86 code. Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-01-15dma-direct: use node local allocations for coherent memoryChristoph Hellwig1-1/+1
To preserve the x86 behavior. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
2018-01-15dma-direct: add support for CMA allocationChristoph Hellwig1-6/+18
Try the CMA allocator for coherent allocations if supported. Roughly modelled after the x86 code. Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-01-15dma-direct: add dma address sanity checksChristoph Hellwig1-1/+30
Roughly based on the x86 pci-nommu implementation. Signed-off-by: Christoph Hellwig <hch@lst.de>
2018-01-15dma-direct: use phys_to_dmaChristoph Hellwig1-11/+7
This means it uses whatever linear remapping scheme that the architecture provides is used in the generic dma_direct ops. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
2018-01-15dma-direct: rename dma_noop to dma_directChristoph Hellwig1-0/+63
The trivial direct mapping implementation already does a virtual to physical translation which isn't strictly a noop, and will soon learn to do non-direct but linear physical to dma translations through the device offset and a few small tricks. Rename it to a better fitting name. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.