Re: [PATCH v6 0/5] Add Intel IOMMU debugfs support

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 >

Re: [PATCH] iommu/vt-d: use domain instead of cache fetching

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. > >

Re: [PATCH 08/22] swiotlb: wire up ->dma_supported in swiotlb_dma_ops

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

Re: [PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32

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

Re: [PATCH 10/22] swiotlb: refactor coherent buffer allocation

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) {

Re: [PATCH v6 2/5] iommu/vt-d: Add debugfs support to show context internals

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

Re: [PATCH 31/33] dma-direct: reject too small dma masks

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

Re: [PATCH 27/33] dma-direct: use node local allocations for coherent memory

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

Re: [PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32

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

Re: [PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32

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

Re: [PATCH 10/22] swiotlb: refactor coherent buffer allocation

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

Re: [PATCH 32/33] cris: use dma-direct

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

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

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

Re: [PATCH 32/33] cris: use dma-direct

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

Re: [PATCH 08/22] swiotlb: wire up ->dma_supported in swiotlb_dma_ops

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

Re: [PATCH 31/33] dma-direct: reject too small dma masks

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

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

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

Re: [PATCH 27/33] dma-direct: use node local allocations for coherent memory

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

Re: [PATCH 20/33] dma-mapping: clear harmful GFP_* flags in common code

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 >

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

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 >

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

On Wed, Jan 10, 2018 at 09:31:45AM +, Vladimir Murzin wrote: > I know it is copy, 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.

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

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,

Re: [PATCH v6 0/5] Add Intel IOMMU debugfs support

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

Re: [PATCH v6 5/5] iommu/vt-d: Add debugfs support for Interrupt remapping

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,

Re: [PATCH v6 4/5] iommu/vt-d: Add debugfs support to show Pasid table contents

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

Re: [PATCH v6 3/5] iommu/vt-d: Add debugfs support to show register contents

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

Re: [PATCH v6 1/5] iommu/vt-d: Add debugfs support for Intel IOMMU internals

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 &&

Re: [PATCH 22/22] arm64: use swiotlb_alloc and swiotlb_free

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

Re: [PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32

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

Re: [PATCH v3 10/16] iommu: introduce device fault report API

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;> +} > + >

Re: [PATCH 10/22] swiotlb: refactor coherent buffer allocation

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.

Re: [PATCH 08/22] swiotlb: wire up ->dma_supported in swiotlb_dma_ops

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 ---

Re: [PATCH 02/22] arm64: rename swiotlb_dma_ops

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(-)

Re: [PATCH 27/33] dma-direct: use node local allocations for coherent memory

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

Re: [PATCH 20/33] dma-mapping: clear harmful GFP_* flags in common code

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

Re: [PATCH v3 03/16] iommu: introduce iommu invalidate API function

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

Re: [PATCH 31/33] dma-direct: reject too small dma masks

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

Re: [PATCH v3 08/16] iommu: introduce device fault data

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

Re: [PATCH 10/33] arm64: don't override dma_max_pfn

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 ---

Re: [PATCH 09/33] dma-mapping: take dma_pfn_offset into account in dma_max_pfn

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 ---

Re: [PATCH 29/33] dma-direct: retry allocations using GFP_DMA for small masks

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

Re: [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

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) >

Re: consolidate swiotlb dma_map implementations

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

[PATCH 16/22] unicore32: use generic swiotlb_ops

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 --

[PATCH 07/22] swiotlb: add common swiotlb_map_ops

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

[PATCH 32/33] cris: use dma-direct

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

[PATCH 03/22] ia64: rename swiotlb_dma_ops

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

[PATCH 17/22] tile: replace ZONE_DMA with ZONE_DMA32

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 +-

[PATCH 06/22] swiotlb: rename swiotlb_free to swiotlb_exit

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

[PATCH 22/22] arm64: use swiotlb_alloc and swiotlb_free

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

[PATCH 12/22] ia64: replace ZONE_DMA with ZONE_DMA32

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 +-

[PATCH 14/22] ia64: clean up swiotlb support

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 --

[PATCH 08/22] swiotlb: wire up ->dma_supported in swiotlb_dma_ops

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

[PATCH 15/22] ia64: remove an ifdef around the content of pci-dma.c

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

[PATCH 22/33] dma-mapping: provide a generic asm/dma-mapping.h

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

[PATCH 29/33] dma-direct: retry allocations using GFP_DMA for small masks

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

[PATCH 18/22] tile: use generic swiotlb_ops

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

[PATCH 13/22] ia64: use generic swiotlb_ops

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 +++---

[PATCH 21/33] dma-mapping: add an arch_dma_supported hook

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

[PATCH 31/33] dma-direct: reject too small dma masks

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 ---

[PATCH 26/33] dma-direct: add support for CMA allocation

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

[PATCH 10/22] swiotlb: refactor coherent buffer allocation

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 ---

[PATCH 05/22] x86: rename swiotlb_dma_ops

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

[PATCH 20/22] mips: use swiotlb_{alloc,free}

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

[PATCH 01/22] swiotlb: suppress warning when __GFP_NOWARN is set

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.

[PATCH 04/22] powerpc: rename swiotlb_dma_ops

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

[PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32

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 +-

[PATCH 02/22] arm64: rename swiotlb_dma_ops

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

[PATCH 25/33] dma-direct: add dma address sanity checks

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

[PATCH 11/22] swiotlb: remove various exports

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

[PATCH 30/33] dma-direct: make dma_direct_{alloc, free} available to other implementations

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|

[PATCH 09/22] swiotlb: refactor coherent buffer freeing

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

[PATCH 27/33] dma-direct: use node local allocations for coherent memory

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

[PATCH 19/22] mips/netlogic: remove swiotlb support

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

[PATCH 23/33] dma-direct: rename dma_noop to dma_direct

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:

[PATCH 33/33] h8300: use dma-direct

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

consolidate swiotlb dma_map implementations

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

[PATCH 24/33] dma-direct: use phys_to_dma

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

[PATCH 28/33] dma-direct: add support for allocation from ZONE_DMA and ZONE_DMA32

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

[PATCH 19/33] dma-mapping: warn when there is no coherent_dma_mask

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

[PATCH 15/33] microblaze: rename dma_direct to dma_nommu

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

[PATCH 12/33] dma-mapping: move dma_mark_clean to dma-direct.h

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

[PATCH 18/33] s390: move s390_pci_dma_ops to asm/pci_dma.h

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

[PATCH 13/33] hexagon: use the generic dma_capable helper

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

[PATCH 20/33] dma-mapping: clear harmful GFP_* flags in common code

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] ---

[PATCH 16/33] microblaze: remove dma_nommu_dma_supported

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

[PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header

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

[PATCH 10/33] arm64: don't override dma_max_pfn

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

[PATCH 14/33] powerpc: rename dma_direct_ to dma_nommu_

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 +-

[PATCH 17/33] microblaze: remove the dead !NOT_COHERENT_CACHE dma code

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

[PATCH 06/33] m32r: remove the unused dma_capable helper

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 ---

[PATCH 09/33] dma-mapping: take dma_pfn_offset into account in dma_max_pfn

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

[PATCH 03/33] m32r: remove unused flush_write_buffers definition

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 @@

[PATCH 01/33] alpha: mark jensen as broken

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

[PATCH 04/33] powerpc: remove unused flush_write_buffers definition

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 ---

[PATCH 07/33] riscv: remove the unused dma_capable helper

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 ---

[PATCH 08/33] s390: remove the unused dma_capable helper

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 ---

consolidate direct dma mapping V3

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

[PATCH 05/33] arc: remove CONFIG_ARC_PLAT_NEEDS_PHYS_TO_DMA

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 |

[PATCH 02/33] hexagon: remove unused flush_write_buffers definition

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 +++

  1   2   >