Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/frv/Kconfig | 2 +
arch/frv/include/asm/dma-mapping.h| 132 ++
arch/frv/mb93090-mb00/pci-dma-nommu.c | 72 ---
arch/frv/mb93090-mb00/pci-dma.c
Move the generic implementation to now that all
architectures support it and remove the HAVE_DMA_ATTR Kconfig symbol
now that everyone supports them.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
Documentation/DMA-API-HOWTO.txt| 10 -
.../features/io/dma_map_attr
Sparc already uses the same code as the generic code for the PCI
implementation but just fails the call sbus. This moves to the
generic implemenation which eventually return -EIO due to the NULL
dma_mask pointer in the device.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/arc/Kconfig | 1 +
arch/arc/include/asm/dma-mapping.h | 187 +
arch/arc/mm/dma.c | 151 --
3 files changed, 109 insertions(+), 230 del
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/avr32/Kconfig | 1 +
arch/avr32/include/asm/dma-mapping.h | 342 +--
arch/avr32/mm/dma-coherent.c | 115
3 files changed, 85 insertions(+), 373 deletions(-)
diff
This series converts all remaining architectures to use dma_map_ops
and the generic implementation of the DMA API. This not only
simplifies the code a lot, but also prepares for possible future
changes like more generic non-iommu dma_ops implementations or generic
per-device dma_map_ops.
A git
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/nios2/Kconfig | 1 +
arch/nios2/include/asm/dma-mapping.h | 123 ++---
arch/nios2/mm/dma-mapping.c | 147 +++
3 files changed, 85 insertions(+
We'll soon merge into
and the reference to dma_capable in the tile dma_set_mask would create a
circular dependency. Fix this by moving the implementation out of line.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/tile/include/asm/dma-mapping.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/metag/Kconfig | 1 +
arch/metag/include/asm/dma-mapping.h | 179 +--
arch/metag/kernel/dma.c | 146 +---
3 files changed, 117 insertions(+
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/cris/Kconfig| 1 +
arch/cris/arch-v32/drivers/pci/dma.c | 54 +---
arch/cris/include/asm/dma-mapping.h | 161 ++-
3 files changed, 51 insertions(+), 165 deletions(-)
diff
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/blackfin/Kconfig | 1 +
arch/blackfin/include/asm/dma-mapping.h | 127 +---
arch/blackfin/kernel/dma-mapping.c | 52 +
3 files changed, 43 insertions(+), 137 del
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/mn10300/Kconfig | 2 +
arch/mn10300/include/asm/dma-mapping.h | 161 +
arch/mn10300/mm/dma-alloc.c| 67 --
3 files changed, 67 insertions(+), 163 deletions(-)
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/parisc/Kconfig | 2 +
arch/parisc/include/asm/dma-mapping.h | 189 ++
arch/parisc/kernel/drivers.c | 2 +-
arch/parisc/kernel/pci-dma.c | 92 ++---
d
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/m68k/Kconfig | 1 +
arch/m68k/include/asm/dma-mapping.h | 112 ++--
arch/m68k/kernel/dma.c | 61 +---
3 files changed, 32 insertions(+), 142 deletions(-)
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/c6x/Kconfig | 2 +
arch/c6x/include/asm/dma-mapping.h | 96 ++
arch/c6x/kernel/dma.c | 91
3 files changed, 47 insertions(+
We have a couple architectures that do not want to support this code,
so add another Kconfig symbol that disables the code similar to what we
do for the nommu case.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/Kconfig | 3 +++
drivers/base/dma-mapping.c | 4 ++--
2
On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote:
> The dma-mapping core and the implementations do not change the
> DMA attributes passed by pointer. Thus the pointer can point to const
> data. However the attributes do not have to be a bitfield. Instead
> unsigned long will
On Wed, Jun 01, 2016 at 07:36:42AM +0200, Krzysztof Kozlowski wrote:
> > No really for this patch, but I would much prefer to document them next
> > to the code in the long run. Also I really think these BIT() macros
> > are a distraction compared to the (1 << N) notation.
>
> Not much
On Fri, Mar 11, 2016 at 01:58:46PM +0100, Niklas S?derlund wrote:
> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> the same and no special care is needed. However if you have a IOMMU you
> need to map the DMA slave phys_addr_t to a dma_addr_t using something
> like
On Thu, Mar 10, 2016 at 10:47:10PM -0800, Dan Williams wrote:
> I think it is confusing to use the dma_ prefix for this peer-to-peer
> mmio functionality. dma_addr_t is a device's view of host memory.
> Something like bus_addr_t bus_map_resource(). Doesn't this routine
> also need the source
On Thu, Mar 17, 2016 at 01:33:51PM +0200, Laurent Pinchart wrote:
> The good news is that, given that no code uses this new API at the moment,
> there isn't much to audit. The patch series implements the resource mapping
> for arch/arm only, and makes use of it in the rcar-dmac driver only.
Please add some documentation on where/how this should be used. It's
not a very obvious interface.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, Apr 25, 2016 at 04:26:19PM +0200, Niklas S?derlund wrote:
> I have followed the call path from the usage in
> drivers/dma/sh/rcar-dmac.c and made sure the dma_addr_t is not used in a
> bad way.
The dma-debug routines are called from the generic code in
include/linux/dma-mapping.h, and
I think this is moving into the wrong direction. The right fix here
is to get of all the dma_attrs boilerplate code and just replace it
with a simple enum dma_flags. This would simplify both the callers
and most importantly the wrappers for the flag-less versions a lot.
Hi all,
currently the dma-mapping code doesn't have a dedicated mailing list,
and thus posts get lots on linux-kernel. I wonder if we should add
a new separate list for it, or if it makes sense to reuse the existing
iommu list given that there is a fair amount of overlap.
On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
> I suppose another option is to just make the IOMMU and DMA ops a
> self-contained non-modular driver mirroring the VT-d/AMD-Vi IOMMUs -
> AFAICS it shouldn't have to be all that tightly coupled to the IPU bus
> code, the latter more
Please use EXPORT_SYMBOL_GPL for any of these exports, as they are
internal linux implementration details by any definition of it.
On Wed, Jul 05, 2017 at 04:12:11PM +0900, Tomasz Figa wrote:
> There is nothing wrong in having a loadable module implementing DMA API,
> for example to be used for
On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:
> Generally the user is a work in progress that should be posted in a
> very near future. You can find a reference to our downstream tree at
> chromium.org in the cover letter. Obviously I don't mind including
> patches from this series
On Tue, Jun 27, 2017 at 04:46:31PM -0400, chris hyser wrote:
> I put this in for SPARC. In our case the host bridge/RC itself follows very
> strict ordering unless the relaxed order bit is set in the TLP. This works
> great for devices that actually allow the driver to enable it. We however
>
On Wed, Jun 07, 2017 at 02:17:32PM -0500, Tom Lendacky wrote:
> Add warnings to let the user know when bounce buffers are being used for
> DMA when SME is active. Since the bounce buffers are not in encrypted
> memory, these notifications are to allow the user to determine some
> appropriate
On Fri, Jun 16, 2017 at 08:10:15PM +0200, Christoph Hellwig wrote:
> I plan to create a new dma-mapping tree to collect all this work.
> Any volunteers for co-maintainers, especially from the iommu gang?
Ok, I've created the new tree:
git://git.infradead.org/users/hch/dma-mapping.git fo
On Tue, Jun 20, 2017 at 02:14:36PM +0100, Robin Murphy wrote:
> Hi Christoph,
>
> On 20/06/17 13:41, Christoph Hellwig wrote:
> > On Fri, Jun 16, 2017 at 08:10:15PM +0200, Christoph Hellwig wrote:
> >> I plan to create a new dma-mapping tree to collect all this work.
&g
On Tue, Jun 20, 2017 at 11:04:00PM +1000, Stephen Rothwell wrote:
> git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git#dma-mapping-next
>
> Contacts: Marek Szyprowski and Kyungmin Park (cc'd)
>
> I have called your tree dma-mapping-hch for now. The other tree has
> not been updated
On Tue, Jun 20, 2017 at 11:19:02AM +0200, Daniel Vetter wrote:
> Ack for the 2 drm patches, but I can also pick them up through drm-misc if
> you prefer that (but then it'll be 4.14).
Nah, I'll plan to set up a dma-mapping tree so that we'll have common
place for dma-mapping work.
On Wed, Jun 21, 2017 at 12:24:28PM -0700, tndave wrote:
> Thanks for doing this.
> So archs can still have their own definition for dma_set_mask() if
> HAVE_ARCH_DMA_SET_MASK is y?
> (and similarly for dma_set_coherent_mask() when
> CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK is y)
> Any plan to
I always assumed that our streaming mappings are relaxed order for
TLP anyway. And at very least Documentation/DMA-attributes.txt seems
to imply something different:
DMA_ATTR_WEAK_ORDERING
--
DMA_ATTR_WEAK_ORDERING specifies that reads and writes to the mapping
may
On Wed, Jun 21, 2017 at 03:32:39PM +0200, Marek Szyprowski wrote:
> linux-next
> was a side effect of that. I think that for now it can be dropped in favor
> of
> Christoph's tree. I can also do some review and help in maintainers work if
> needed, although I was recently busy with other stuff.
>
On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote:
> I think we still need to do it. For example we have a bunch new "funky"
> cases.
I have no plan to do away with the selection - I just want a better
interface than the current one.
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: Christ
for xen_swiotlb_dma_ops can now be marked
static as well.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/arm/xen/mm.c | 17
arch/x86/xen/pci-swiotlb-xen.c | 14 ---
drivers/xen/swiotlb-xen.c | 93 ++
include/xen/swiotlb-xen.h
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/xen/swiotlb-xen.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index a0f006
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/hexagon/include/asm/dma-mapping.h | 2 --
arch/hexagon/kernel/dma.c | 12 +---
arch/hexagon/kernel/hexagon_ksyms.c| 1 -
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/hexagon/include/a
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 <h...@lst.de>
---
arch/arm64/include/asm/dma-map
sh does not return errors for dma_map_page.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/sh/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/sh/include/asm/dma-mapping.h
b/arch/sh/include/asm/dma-mapping.h
index d99008af5f73..9b06be07db4d
xtensa already implements the mapping_error method for its only
dma_map_ops instance.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/xtensa/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/xtensa/include/asm/dma-mapping.h
b/arch/xtensa/include/a
openrisc does not return errors for dma_map_page.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/openrisc/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/openrisc/include/asm/dma-mapping.h
b/arch/openrisc/include/asm/dma-mapping.h
index 0c0075
DMA_ERROR_CODE is not supposed to be used by drivers.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/firmware/tegra/ivc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/tegra/ivc.c b/drivers/firmware/tegra/ivc.c
index 29ecfd
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 <h...@lst.de>
---
drivers/net/ethernet/ibm/ibmveth.c | 159 +
1 file changed, 74 insertions(+), 85 deletions(-)
diff
microblaze does not return errors for dma_map_page.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/microblaze/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/microblaze/include/asm/dma-mapping.h
b/arch/microblaze/include/asm/dma-mapping.h
dma-noop is the only dma_mapping_ops instance for m32r and does not return
errors.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/m32r/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/m32r/include/asm/dma-mapping.h
b/arch/m32r/include/a
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/c6x/include/asm/dma-mapping.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/c6x/include/asm/dma-mapping.h
b/arch/c6x/include/asm/dma-mapping.h
index aca9f755e4f8..05daf1038111 100644
--- a/arch/c6x/include/asm/dma-map
All ia64 dma_mapping_ops instances already have a mapping_error member.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/ia64/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/ia64/include/asm/dma-mapping.h
b/arch/ia64/include/asm/dma-mapping.h
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/x86/kernel/pci-nommu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c
index a88952
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 <h...@lst.de>
---
arch/arm/common/dmabounce.c| 1 +
ar
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/x86/kernel/pci-calgary_64.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kern
Besides removing the last instance of the set_dma_mask method this also
reduced the code duplication.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/powerpc/platforms/cell/iommu.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/arch/p
And update the documentation - dma_mapping_error has been supported
everywhere for a long time.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
Documentation/DMA-API-HOWTO.txt | 31 +--
include/linux/dma-mapping.h | 5 -
2 files changed, 5 inse
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
include/linux/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index a57875309bfd..3e5908656226 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-map
All dma_map_ops instances now handle their errors through
->mapping_error.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/x86/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/dma-mapping.h
b/arch/x86/include/asm/dma-mappin
This just duplicates the generic implementation.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/xen/swiotlb-xen.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index c3a04b2d7532..82fc54f8eb77
ich means always supported.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/sparc/include/asm/dma-mapping.h | 3 ---
arch/sparc/kernel/iommu.c| 40 +++-
arch/sparc/kernel/ioport.c | 22 ++--
arch/sparc/kernel/pc
These just duplicate the default behavior if no method is provided.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
lib/dma-noop.c | 12
1 file changed, 12 deletions(-)
diff --git a/lib/dma-noop.c b/lib/dma-noop.c
index de26c8b68f34..643a074f139d 100644
--- a/lib/dma-
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/sparc/include/asm/dma-mapping.h | 2 --
arch/sparc/kernel/iommu.c| 12 +---
arch/sparc/kernel/iommu_common.h | 2 ++
arch/sparc/kernel/pci_s
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 <h...@lst.de>
---
drivers/gpu/drm/armada/armada_fb.c | 2 +-
drivers/gpu/drm/armada/armada_gem.c | 5 ++---
drivers/gpu/drm/
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 <h...@lst.de>
---
drivers/dma/ioat/init.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/dm
return 0.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index c77a5aced81a..d48fd7c918f8
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 <h...@lst.de>
---
arch/openrisc/include/asm/dma-mapping.h | 7 ---
1 file changed, 7 deletions(-)
diff --git
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/arm/common/dmabounce.c| 16 ---
arch/arm/include/asm/dma-iommu.h | 2 ++
arch/arm/include/asm/dma-mapping.h | 1 -
arch/arm/mm/dma-mapping.c
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/iommu/amd_iommu.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 63cacf
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 <h...@lst.de>
---
arch/x86/include/asm/dma-mapping.h | 3 ---
ar
Same behavior, less code duplication.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/mips/loongson64/common/dma-swiotlb.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/arch/mips/loongson64/common/dma-swiotlb.c
b/arch/mips/loongson64/comm
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/hexagon/include/asm/dma-mapping.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/hexagon/include/asm/dma-mapping.h
b/arch/hexagon/include/asm/dma-mapping.h
index 9c15cb5271a6..463dbc18f853 100644
--- a/arch/hexagon/include/a
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
Same behavior, less code duplication.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/arm/common/dmabounce.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index 4aabf117e136..d89a0b56b245
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 <h...@lst.de>
---
arch/hexagon/include/asm/dma-mapping.h | 2 --
arch/hexagon/kernel/dma.c | 9 --
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/powerpc/include/asm/dma-mapping.h | 1 -
arch/powerpc/kernel/dma.c | 13 -
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/a
We can just use pci32_dma_ops.
Btw, given that leon is 32-bit and appears to be PCI based, do even need
the special case for it in get_arch_dma_ops at all?
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/sparc/include/asm/dma-mapping.h | 3 +--
arch/sparc/kernel/ioport.c
These just duplicate the default behavior if no method is provided.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/tile/kernel/pci-dma.c | 30 --
1 file changed, 30 deletions(-)
diff --git a/arch/tile/kernel/pci-dma.c b/arch/tile/kernel/pci-dma.c
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/powerpc/kernel/dma.c | 4
include/linux/dma-mapping.h | 6 --
2 files changed, 10 deletions(-)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 41c749586bd2..466c9f07b288 100644
--- a/arch/powerpc/
These just duplicate the default behavior if no method is provided.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
lib/dma-virt.c | 12
1 file changed, 12 deletions(-)
diff --git a/lib/dma-virt.c b/lib/dma-virt.c
index dcd4df1f7174..5c4f11329721 100644
--- a/lib/dma-
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 <h...@lst.de>
---
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 <h...@lst.de>
---
arch/s390/include/asm/dma-mapping.
Hi all,
for a while we have a generic implementation of the dma mapping routines
that call into per-arch or per-device operations. But right now there
still are various bits in the interfaces where don't clearly operate
on these ops. This series tries to clean up a lot of those (but not all
Same behavior, less code duplication.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/arm/common/dmabounce.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index 6ecd5be5d37e..9a92de63426f
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/x86/kernel/pci-nommu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c
index a88952
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/c6x/include/asm/dma-mapping.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/c6x/include/asm/dma-mapping.h
b/arch/c6x/include/asm/dma-mapping.h
index aca9f755e4f8..05daf1038111 100644
--- a/arch/c6x/include/asm/dma-map
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 <h...@lst.de>
Acked-by: David S. Miller <da...@davemloft.net>
---
drivers/net/ethernet/ibm/ibmveth.c | 159 +
1
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: Christ
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 <h...@lst.de>
---
drivers/gpu/drm/armada/armada_fb.c | 2 +-
drivers/gpu/drm/armada/armada_gem.c | 5 ++---
drivers/gpu/drm/
Hi all,
for a while we have a generic implementation of the dma mapping routines
that call into per-arch or per-device operations. But right now there
still are various bits in the interfaces where don't clearly operate
on these ops. This series tries to clean up a lot of those (but not all
return 0.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index c77a5aced81a..d48fd7c918f8
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 <h...@lst.de>
Acked-by: Dave Jiang <dave.ji...@intel.com>
Acked-By: Vinod Koul <vinod.k...@intel.com>
---
drivers/dm
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 <h...@lst.de>
---
arch/arm/common/dmabounce.c| 1 +
ar
Signed-off-by: Christoph Hellwig <h...@lst.de>
Acked-by: Richard Kuo <r...@codeaurora.org>
---
arch/hexagon/include/asm/dma-mapping.h | 2 --
arch/hexagon/kernel/dma.c | 12 +---
arch/hexagon/kernel/hexagon_ksyms.c| 1 -
3 files changed, 9 insertions(+),
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 <h...@lst.de>
---
arch/x86/include/asm/dma-mapping.h | 3 ---
ar
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 <h...@lst.de>
Acked
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/powerpc/kernel/dma.c | 4
include/linux/dma-mapping.h | 6 --
2 files changed, 10 deletions(-)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 41c749586bd2..466c9f07b288 100644
--- a/arch/powerpc/
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/x86/kernel/pci-calgary_64.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kern
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/powerpc/include/asm/dma-mapping.h | 1 -
arch/powerpc/kernel/dma.c | 13 -
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/a
And update the documentation - dma_mapping_error has been supported
everywhere for a long time.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
Documentation/DMA-API-HOWTO.txt | 31 +--
include/linux/dma-mapping.h | 5 -
2 files changed, 5 inse
1 - 100 of 3995 matches
Mail list logo
