On Wed, 2018-01-10 at 15:46 +0200, Andy Shevchenko wrote:
> On Tue, 2018-01-09 at 19:48 -0800, Sohil Mehta wrote:
> >
> > Hi All,
> >
> > This series aims to add debugfs support for Intel IOMMU. It exposes
> > IOMMU
> > registers, internal context and dumps individual table entries to
> > help
>
On Wed, 10 Jan 2018 13:51:37 +0800
Peter Xu wrote:
> after commit a1ddcbe93010 ("iommu/vt-d: Pass dmar_domain directly into
> iommu_flush_iotlb_psi", 2015-08-12), we have domain pointer as parameter
> to iommu_flush_iotlb_psi(), so no need to fetch it from cache again.
>
> More importantly, a NU
On 10/01/18 15:35, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 12:16:15PM +, Robin Murphy wrote:
On 10/01/18 08:09, Christoph Hellwig wrote:
To properly reject too small DMA masks based on the addressability of the
bounce buffer.
I reckon this is self-evident enough that it should si
On 10/01/18 15:55, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 04:55:17PM +0100, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 12:58:14PM +, Robin Murphy wrote:
On 10/01/18 08:09, Christoph Hellwig wrote:
arm64 uses ZONE_DMA for allocations below 32-bits. These days we
name the zo
On 10/01/18 15:46, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 12:22:18PM +, Robin Murphy wrote:
+ if (phys_addr == SWIOTLB_MAP_ERROR)
+ goto out_warn;
-/* Confirm address can be DMA'd by device */
- if (dev_addr + size - 1 > dma_mask) {
On 01/09/2018 09:48 PM, Sohil Mehta wrote:
From: Gayatri Kammela
IOMMU internals states such as root and context can be exported to the
userspace.
Example of such dump in Kabylake:
root@OTC-KBLH-01:~# cat
/sys/kernel/debug/intel_iommu/dmar_translation_struct
IOMMU dmar0: Extended Root Table
On 10/01/18 15:32, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 11:49:34AM +, Robin Murphy wrote:
+#ifdef CONFIG_ZONE_DMA
+ if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
+ return 0;
+#else
+ /*
+* Because 32-bit DMA masks are so common we expect every a
On 10/01/18 15:30, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 12:06:22PM +, Robin Murphy wrote:
On 10/01/18 08:00, Christoph Hellwig wrote:
To preserve the x86 behavior.
And combined with patch 10/22 of the SWIOTLB refactoring, this means
SWIOTLB allocations will also end up NUMA-aw
On Wed, Jan 10, 2018 at 04:55:17PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 12:58:14PM +, Robin Murphy wrote:
> > On 10/01/18 08:09, Christoph Hellwig wrote:
> >> arm64 uses ZONE_DMA for allocations below 32-bits. These days we
> >> name the zone for that ZONE_DMA32, which wil
On Wed, Jan 10, 2018 at 12:58:14PM +, Robin Murphy wrote:
> On 10/01/18 08:09, Christoph Hellwig wrote:
>> arm64 uses ZONE_DMA for allocations below 32-bits. These days we
>> name the zone for that ZONE_DMA32, which will allow to use the
>> dma-direct and generic swiotlb code as-is, so rename
On Wed, Jan 10, 2018 at 12:22:18PM +, Robin Murphy wrote:
>> +if (phys_addr == SWIOTLB_MAP_ERROR)
>> +goto out_warn;
>> - /* Confirm address can be DMA'd by device */
>> -if (dev_addr + size - 1 > dma_mask) {
>> -printk("hwdev DMA mask
On Wed, Jan 10, 2018 at 03:27:41PM +, Alexey Brodkin wrote:
> Hi Christoph,
>
> On Wed, 2018-01-10 at 09:00 +0100, Christoph Hellwig wrote:
> > cris currently has an incomplete direct mapping dma_map_ops implementation
> > is PCI support is enabled. Replace it with the fully feature generic
>
On Wed, Jan 10, 2018 at 03:31:08PM +, Robin Murphy wrote:
> Yes indeed, modulo Vladimir's comments - it does seem prudent to fix the
> obvious off-by-ones as we touch them. I've wanted to do something like this
> for ages, but never got around to it myself.
I've fixed these now in a separate
Hi Christoph,
On Wed, 2018-01-10 at 09:00 +0100, Christoph Hellwig wrote:
> cris currently has an incomplete direct mapping dma_map_ops implementation
> is PCI support is enabled. Replace it with the fully feature generic
_if_ PCI support is enabled.
-Alexey
On Wed, Jan 10, 2018 at 12:16:15PM +, Robin Murphy wrote:
> On 10/01/18 08:09, Christoph Hellwig wrote:
>> To properly reject too small DMA masks based on the addressability of the
>> bounce buffer.
>
> I reckon this is self-evident enough that it should simply be squashed into
> the previous
On Wed, Jan 10, 2018 at 11:49:34AM +, Robin Murphy wrote:
>> +#ifdef CONFIG_ZONE_DMA
>> +if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
>> +return 0;
>> +#else
>> +/*
>> + * Because 32-bit DMA masks are so common we expect every architecture
>> + * to be able to satisf
On 10/01/18 15:26, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 02:56:01PM +, Robin Murphy wrote:
I took a look at these, and it seems their phys_to_dma() usage is doing the
thing which we subsequently formalised as dma_map_resource(). I've had a
crack at a quick patch to update the CESA
On Wed, Jan 10, 2018 at 12:06:22PM +, Robin Murphy wrote:
> On 10/01/18 08:00, Christoph Hellwig wrote:
>> To preserve the x86 behavior.
>
> And combined with patch 10/22 of the SWIOTLB refactoring, this means
> SWIOTLB allocations will also end up NUMA-aware, right? Great, that's what
> we w
On Wed, Jan 10, 2018 at 11:59:30AM +, Robin Murphy wrote:
> Just a note that if we're all happy to enshrine the "allocations are always
> zeroed" behaviour in the API (I am too, for the record), we should remember
> to follow up once the dust settles to update the docs and I guess just
> #de
On Wed, Jan 10, 2018 at 02:56:01PM +, Robin Murphy wrote:
> I took a look at these, and it seems their phys_to_dma() usage is doing the
> thing which we subsequently formalised as dma_map_resource(). I've had a
> crack at a quick patch to update the CESA driver; qcom_nandc looks slightly
> m
On Wed, Jan 10, 2018 at 09:31:45AM +, Vladimir Murzin wrote:
> I know it is copy&paste, but it seems it has off by one error and it should be
>
> return addr + size - 1 <= *dev->dma_mask;
I've added a new patch to fix the mips dma_capable() definition,
thanks.
On 10/01/18 08:00, Christoph Hellwig wrote:
phys_to_dma, dma_to_phys and dma_capable are helpers published by
architecture code for use of swiotlb and xen-swiotlb only. Drivers are
not supposed to use these directly, but use the DMA API instead.
Move these to a new asm/dma-direct.h helper, incl
On Tue, 2018-01-09 at 19:48 -0800, Sohil Mehta wrote:
> Hi All,
>
> This series aims to add debugfs support for Intel IOMMU. It exposes
> IOMMU
> registers, internal context and dumps individual table entries to help
> debug
> Intel IOMMUs.
>
> The first patch does the ground work for the followi
On Tue, 2018-01-09 at 19:48 -0800, Sohil Mehta wrote:
> Debugfs extension for Intel IOMMU to dump Interrupt remapping table
> entries for Interrupt remapping and Interrupt posting.
>
> The file /sys/kernel/debug/intel_iommu/ir_translation_struct provides
> detailed information, such as Index, Sour
On Tue, 2018-01-09 at 19:48 -0800, Sohil Mehta wrote:
> Debugfs extension to dump the internals such as pasid table entries
> for
> each IOMMU to the userspace.
>
> Example of such dump in Kabylake:
>
> root@OTC-KBLH-01:~# cat
> /sys/kernel/debug/intel_iommu/dmar_translation_struct
>
> IOMMU dm
On Tue, 2018-01-09 at 19:48 -0800, Sohil Mehta wrote:
> Debugfs extension to dump all the register contents for each IOMMU
> device to the user space via debugfs.
>
> example:
> root@OTC-KBLH-01:~# cat /sys/kernel/debug/intel_iommu/iommu_regset
>
> DMAR: dmar1: reg_base_addr fed9
> Name
On Tue, 2018-01-09 at 19:48 -0800, Sohil Mehta wrote:
> From: Gayatri Kammela
>
> Enable Intel IOMMU debug to export Intel IOMMU internals in debugfs
> +config INTEL_IOMMU_DEBUG
> + bool "Export Intel IOMMU internals in DebugFS"
> + depends on INTEL_IOMMU && DEBUG_FS
> + default n
On 10/01/18 08:09, Christoph Hellwig wrote:
The generic swiotlb_alloc and swiotlb_free routines already take care
of CMA allocations and adding GFP_DMA32 where needed, so use them
instead of the arm specific helpers.
It took a while to satisfy myself that the GFP_DMA(32) handling ends up
equiv
On 10/01/18 08:09, Christoph Hellwig wrote:
arm64 uses ZONE_DMA for allocations below 32-bits. These days we
name the zone for that ZONE_DMA32, which will allow to use the
dma-direct and generic swiotlb code as-is, so rename it.
I do wonder if we could also "upgrade" GFP_DMA to GFP_DMA32 someh
On 17/11/17 18:55, Jacob Pan wrote:
[...]
> +static inline int iommu_register_device_fault_handler(struct device *dev,
> + iommu_dev_fault_handler_t
> handler,
> + void *data)
> +{
> + return 0;> +}
> +
> +
On 10/01/18 08:09, Christoph Hellwig wrote:
Factor out a new swiotlb_alloc_buffer helper that allocates DMA coherent
memory from the swiotlb bounce buffer.
This allows to simplify the swiotlb_alloc implemenation that uses
dma_direct_alloc to try to allocate a reachable buffer first.
Signed-off-
On 10/01/18 08:09, Christoph Hellwig wrote:
To properly reject too small DMA masks based on the addressability of the
bounce buffer.
I reckon this is self-evident enough that it should simply be squashed
into the previous patch.
Robin.
Signed-off-by: Christoph Hellwig
---
lib/swiotlb.c
On 10/01/18 08:09, Christoph Hellwig wrote:
We'll need that name for a generic implementation soon.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping
On 10/01/18 08:00, Christoph Hellwig wrote:
To preserve the x86 behavior.
And combined with patch 10/22 of the SWIOTLB refactoring, this means
SWIOTLB allocations will also end up NUMA-aware, right? Great, that's
what we want on arm64 too :)
Reviewed-by: Robin Murphy
Signed-off-by: Chris
On 10/01/18 08:00, Christoph Hellwig wrote:
[...]
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 9f28b2fa329e..88bcb1a8211d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -518,6 +518,13 @@ static inline void *dma_alloc_attrs(struct devi
On 28/12/17 19:25, Jacob Pan wrote:
[...]
>>> + * @size: 2^size of 4K pages, 0 for 4k, 9 for 2MB,
>>> etc.
>>
>> Having only power of two invalidation seems too restrictive for a
>> software interface. You might have the same problem as above, where
>> the guest or userspace needs to sen
On 10/01/18 08:00, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 1 +
lib/dma-direct.c | 19 +++
2 files changed, 20 insertions(+)
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 4788bf0bf683.
Hi Jacob,
On 17/11/17 18:55, Jacob Pan wrote:
[...]
> +/**
> + * struct iommu_fault_event - Generic per device fault data
> + *
> + * - PCI and non-PCI devices
> + * - Recoverable faults (e.g. page request), information based on PCI ATS
> + * and PASID spec.
> + * - Un-recoverable faults of device
On 10/01/18 08:00, Christoph Hellwig wrote:
The generic version now takes dma_pfn_offset into account, so there is no
more need for an architecture override.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/dma-mapping.h | 9 -
1 file changed,
On 10/01/18 08:00, Christoph Hellwig wrote:
This makes sure the generic version can be used with architectures /
devices that have a DMA offset in the direct mapping.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 2 +-
1 file changed, 1 inse
On 10/01/18 08:00, Christoph Hellwig wrote:
> 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 x
On 10/01/18 08:00, Christoph Hellwig wrote:
> index 9110988b92a1..f00833acb626 100644
> --- a/arch/mips/include/asm/mach-cavium-octeon/dma-coherence.h
> +++ b/arch/mips/include/asm/mach-cavium-octeon/dma-coherence.h
> @@ -61,6 +61,14 @@ static inline void plat_post_dma_flush(struct device *dev)
>
Acked-by: Christian König for the whole series.
Regards,
Christian.
Am 10.01.2018 um 09:09 schrieb Christoph Hellwig:
A lot of architectures have essentially identical dma_map_ops
implementations to use swiotlb. This series adds new generic
swiotlb_alloc/free helpers that take the attrs argum
These are identical to the unicore32 ops, and would also support CMA
if enabled on unicore32.
Signed-off-by: Christoph Hellwig
---
arch/unicore32/include/asm/dma-mapping.h | 9 +-
arch/unicore32/mm/Kconfig| 1 +
arch/unicore32/mm/Makefile | 2 --
arch/unicore
Currently all architectures that want to use swiotlb have to implement
their own dma_map_ops instances. Provide a generic one based on the
x86 implementation which first calls into dma_direct to try a full blown
direct mapping implementation (including e.g. CMA) before falling back
allocating from
cris currently has an incomplete direct mapping dma_map_ops implementation
is PCI support is enabled. Replace it with the fully feature generic
dma-direct implementation.
Signed-off-by: Christoph Hellwig
Acked-by: Jesper Nilsson
---
arch/cris/Kconfig | 4 ++
arch/cris/ar
We'll need that name for a generic implementation soon.
Signed-off-by: Christoph Hellwig
---
arch/ia64/hp/common/hwsw_iommu.c | 4 ++--
arch/ia64/hp/common/sba_iommu.c | 6 +++---
arch/ia64/kernel/pci-swiotlb.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/ia
tile uses ZONE_DMA for allocations below 32-bits. These days we
name the zone for that ZONE_DMA32, which will allow to use the
dma-direct and generic swiotlb code as-is, so rename it.
Signed-off-by: Christoph Hellwig
---
arch/tile/Kconfig | 2 +-
arch/tile/kernel/pci-dma.c | 4 ++--
ar
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kernel/dma-swiotlb.c | 2 +-
arch/x86/kernel/pci-swiotlb.c | 2 +-
include/linux/swiotlb.h | 4 ++--
lib/swiotlb.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/dma-swi
The generic swiotlb_alloc and swiotlb_free routines already take care
of CMA allocations and adding GFP_DMA32 where needed, so use them
instead of the arm specific helpers.
Signed-off-by: Christoph Hellwig
---
arch/arm64/Kconfig | 1 +
arch/arm64/mm/dma-mapping.c | 46 +++--
ia64 uses ZONE_DMA for allocations below 32-bits. These days we
name the zone for that ZONE_DMA32, which will allow to use the
dma-direct and generic swiotlb code as-is, so rename it.
Signed-off-by: Christoph Hellwig
---
arch/ia64/Kconfig | 2 +-
arch/ia64/kernel/pci-swiotlb.c | 2
Move the few remaining bits of swiotlb glue towards their callers,
and remove the pointless on ia64 swiotlb variable.
Signed-off-by: Christoph Hellwig
---
arch/ia64/include/asm/dma-mapping.h | 1 -
arch/ia64/include/asm/swiotlb.h | 18 --
arch/ia64/kernel/dma-mapping.c
To properly reject too small DMA masks based on the addressability of the
bounce buffer.
Signed-off-by: Christoph Hellwig
---
lib/swiotlb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 0fae2f45c3c0..539fd1099ba9 100644
--- a/lib/swiotlb.c
+++ b/lib/swio
The file is only compiled if CONFIG_INTEL_IOMMU is set to start with.
Signed-off-by: Christoph Hellwig
---
arch/ia64/kernel/pci-dma.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c
index 35e0cad33b7d..b5df084c0af4 100644
--- a/ar
For architectures that just use the generic dma_noop_ops we can provide
a generic version of dma-mapping.h.
Signed-off-by: Christoph Hellwig
---
MAINTAINERS | 1 +
arch/m32r/include/asm/Kbuild | 1 +
arch/m32r/include/asm/dma-mapping.h | 17 -
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
---
lib/dma
These are identical to the tile ops, and would also support CMA
if enabled on tile.
Signed-off-by: Christoph Hellwig
---
arch/tile/Kconfig | 1 +
arch/tile/kernel/pci-dma.c | 36 +++-
2 files changed, 4 insertions(+), 33 deletions(-)
diff --git a/arch/t
To implement the x86 forbid_dac and iommu_sac_force we want an arch hook
so that it can apply the global options across all dma_map_ops
implementations.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/dma-mapping.h | 3 +++
arch/x86/kernel/pci-dma.c | 19 ---
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 1 +
lib/dma-direct.c | 19 +++
2 files changed, 20 insertions(+)
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 4788bf0bf683..bcdb1a3e4b1f 100644
--- a/include/linux/dma-dire
These are identical to the ia64 ops, and would also support CMA
if enabled on ia64.
Signed-off-by: Christoph Hellwig
---
arch/ia64/Kconfig| 5 +
arch/ia64/hp/common/hwsw_iommu.c | 4 ++--
arch/ia64/hp/common/sba_iommu.c | 6 +++---
arch/ia64/kernel/pci-swiotlb.c | 38 ++
Try the CMA allocator for coherent allocations if supported.
Roughly modelled after the x86 code.
Signed-off-by: Christoph Hellwig
---
lib/dma-direct.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/lib/dma-direct.c b/lib/dma-direct.c
index 32fd4d9
Factor out a new swiotlb_alloc_buffer helper that allocates DMA coherent
memory from the swiotlb bounce buffer.
This allows to simplify the swiotlb_alloc implemenation that uses
dma_direct_alloc to try to allocate a reachable buffer first.
Signed-off-by: Christoph Hellwig
---
lib/swiotlb.c | 12
We'll need that name for a generic implementation soon.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/pci-swiotlb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
index 9d3e35c33d94..0d77603c2f50 100644
These already include the GFP_DMA/GFP_DMA32 usage, and will use CMA
memory if enabled, thus avoiding the GFP_NORETRY hack.
Signed-off-by: Christoph Hellwig
---
arch/mips/cavium-octeon/Kconfig | 1 +
arch/mips/cavium-octeon/dma-octeon.c | 26 +++---
arch/mips/l
From: Christian König
TTM tries to allocate coherent memory in chunks of 2MB first to improve
TLB efficiency and falls back to allocating 4K pages if that fails.
Suppress the warning when the 2MB allocations fails since there is a
valid fall back path.
Signed-off-by: Christian König
Reported-b
We'll need that name for a generic implementation soon.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/swiotlb.h | 2 +-
arch/powerpc/kernel/dma-swiotlb.c | 4 ++--
arch/powerpc/kernel/dma.c | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 2 +-
4 files changed, 5 insertions
arm64 uses ZONE_DMA for allocations below 32-bits. These days we
name the zone for that ZONE_DMA32, which will allow to use the
dma-direct and generic swiotlb code as-is, so rename it.
Signed-off-by: Christoph Hellwig
---
arch/arm64/Kconfig | 2 +-
arch/arm64/mm/dma-mapping.c | 6 +++
We'll need that name for a generic implementation soon.
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index f3a637b98487..6840426bbe77 100644
--- a
Roughly based on the x86 pci-nommu implementation.
Signed-off-by: Christoph Hellwig
---
lib/dma-direct.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/lib/dma-direct.c b/lib/dma-direct.c
index 12ea9653781b..32fd4d9e4c47 100644
--- a/lib/dma-d
All these symbols are only used by arch dma_ops implementations or
xen-swiotlb. None of which can be modular.
Signed-off-by: Christoph Hellwig
---
lib/swiotlb.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index bf2d19ee91c1..1eac51ff77a4 10064
So that they don't need to indirect through the operation vector.
Signed-off-by: Christoph Hellwig
Reviewed-by: Vladimir Murzin
---
arch/arm/mm/dma-mapping-nommu.c | 9 +++--
include/linux/dma-direct.h | 5 +
lib/dma-direct.c| 6 +++---
3 files changed, 11 insertion
Factor out a new swiotlb_free_buffer helper that checks if an address
is allocated from the swiotlb bounce buffer, and if yes frees it.
This allows to simplify the swiotlb_free implemenation that uses
dma_direct_free to free the non-bounce buffer allocations.
Signed-off-by: Christoph Hellwig
---
To preserve the x86 behavior.
Signed-off-by: Christoph Hellwig
---
lib/dma-direct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dma-direct.c b/lib/dma-direct.c
index a9ae98be7af3..f04a424f91fa 100644
--- a/lib/dma-direct.c
+++ b/lib/dma-direct.c
@@ -38,7 +38,7 @@ stat
nlm_swiotlb_dma_ops is unused code, so the whole swiotlb support is dead.
If it gets resurrected at some point it should use the generic
swiotlb_dma_ops instead.
Signed-off-by: Christoph Hellwig
---
arch/mips/include/asm/netlogic/common.h | 3 --
arch/mips/netlogic/Kconfig | 5 --
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: C
Replace the bare-bones h8300 direct dma mapping implementation with
the fully featured generic dma-direct one.
Signed-off-by: Christoph Hellwig
---
arch/h8300/Kconfig | 1 +
arch/h8300/include/asm/Kbuild| 1 +
arch/h8300/include/asm/dma-mapping.h | 12 ---
arch/h8
A lot of architectures have essentially identical dma_map_ops
implementations to use swiotlb. This series adds new generic
swiotlb_alloc/free helpers that take the attrs argument exposed
in dma_map_ops, and which do an enhanced direct allocation
modelled after x86 and reused from the dma-direct co
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
Reviewed-by: Vladimir Murzin
---
lib/dma-direct.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/li
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 th
These days all devices should have a DMA coherent mask, and most dma_ops
implementations rely on that fact. But just to be sure add an assert to
ring the warning bell if that is not the case.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 1 +
1 file changed, 1 insertion(+)
This frees the dma_direct_* namespace for a generic implementation.
Signed-off-by: Christoph Hellwig
---
arch/microblaze/include/asm/dma-mapping.h | 4 +--
arch/microblaze/kernel/dma.c | 48 +++
2 files changed, 26 insertions(+), 26 deletions(-)
diff --
And unlike the other helpers we don't require a as
this helper is a special case for ia64 only, and this keeps it as
simple as possible.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-mapping.h | 2 --
arch/arm64/include/asm/dma-mapping.h | 4
arch/ia64/Kconfig
This is not needed in drivers, so move it to a private header.
Signed-off-by: Christoph Hellwig
---
arch/s390/include/asm/dma-mapping.h | 2 --
arch/s390/include/asm/pci_dma.h | 3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/s390/include/asm/dma-mapping.h
b/arch/
Signed-off-by: Christoph Hellwig
Acked-by: Richard Kuo
---
arch/hexagon/include/asm/dma-mapping.h | 7 ---
arch/hexagon/kernel/dma.c | 1 +
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/hexagon/include/asm/dma-mapping.h
b/arch/hexagon/include/asm/dma-mappin
Lift the code from x86 so that we behave consistently. In the future we
should probably warn if any of these is set.
Signed-off-by: Christoph Hellwig
Acked-by: Jesper Nilsson
Acked-by: Geert Uytterhoeven [m68k]
---
arch/cris/arch-v32/drivers/pci/dma.c | 3 ---
arch/h8300/kernel/dma.c
Always returning 1 is the same behavior as not supplying a method at all.
Signed-off-by: Christoph Hellwig
---
arch/microblaze/kernel/dma.c | 6 --
arch/parisc/kernel/pci-dma.c | 7 ---
2 files changed, 13 deletions(-)
diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/d
phys_to_dma, dma_to_phys and dma_capable are helpers published by
architecture code for use of swiotlb and xen-swiotlb only. Drivers are
not supposed to use these directly, but use the DMA API instead.
Move these to a new asm/dma-direct.h helper, included by a
linux/dma-direct.h wrapper that prov
The generic version now takes dma_pfn_offset into account, so there is no
more need for an architecture override.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/dma-mapping.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm64/include/asm/dma-mapping.h
b/arch/arm
We want to use the dma_direct_ namespace for a generic implementation,
so rename powerpc to the second best choice: dma_nommu_.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/dma-mapping.h| 8 ++--
arch/powerpc/kernel/dma-iommu.c | 2 +-
arch/powerpc/kernel/dma-swi
Signed-off-by: Christoph Hellwig
---
arch/microblaze/kernel/dma.c | 28
1 file changed, 28 deletions(-)
diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c
index b45d8f8967af..c91e8cef98dd 100644
--- a/arch/microblaze/kernel/dma.c
+++ b/arch/micr
Signed-off-by: Christoph Hellwig
---
arch/m32r/include/asm/dma-mapping.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/m32r/include/asm/dma-mapping.h
b/arch/m32r/include/asm/dma-mapping.h
index 336ffe60814b..8967fb659691 100644
--- a/arch/m32r/include/asm/dma-mapping.h
+++ b/arc
This makes sure the generic version can be used with architectures /
devices that have a DMA offset in the direct mapping.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dma-mapping.h b/include/li
Signed-off-by: Christoph Hellwig
---
arch/m32r/include/asm/io.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index 1b653bb16f9a..a4272d8f0d9c 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -191,8 +191,6 @
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/dma-mapping.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 5a6cbe11db6f..592c7f418aa0 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+
Signed-off-by: Christoph Hellwig
---
arch/riscv/include/asm/dma-mapping.h | 8
1 file changed, 8 deletions(-)
diff --git a/arch/riscv/include/asm/dma-mapping.h
b/arch/riscv/include/asm/dma-mapping.h
index 3eec1000196d..73849e2cc761 100644
--- a/arch/riscv/include/asm/dma-mapping.h
+++
CONFIG_ALPHA_JENSEN has failed to compile since commit 6aca0503
("alpha/dma: use common noop dma ops"), so mark it as broken.
Signed-off-by: Christoph Hellwig
---
arch/alpha/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index b31b974a03cb..e9
Signed-off-by: Christoph Hellwig
---
arch/s390/include/asm/dma-mapping.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/s390/include/asm/dma-mapping.h
b/arch/s390/include/asm/dma-mapping.h
index eaf490f9c5bc..2ec7240c1ada 100644
--- a/arch/s390/include/asm/dma-mapping.h
+++ b/arc
Almost every architecture supports a direct dma mapping implementation,
where no iommu is used and the device dma address is a 1:1 mapping to
the physical address or has a simple linear offset. Currently the
code for this implementation is most duplicated over the architectures,
and the duplicated
We always use the stub definitions, so remove the unused other code.
Signed-off-by: Christoph Hellwig
Acked-by: Vineet Gupta
---
arch/arc/Kconfig | 3 ---
arch/arc/include/asm/dma-mapping.h | 7 ---
arch/arc/mm/dma.c | 14 +++---
3 files changed,
Signed-off-by: Christoph Hellwig
---
arch/hexagon/include/asm/io.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/hexagon/include/asm/io.h b/arch/hexagon/include/asm/io.h
index 66f5e9a61efc..9e8621d94ee9 100644
--- a/arch/hexagon/include/asm/io.h
+++ b/arch/hexagon/include/asm/io.h
@@
100 matches
Mail list logo
