Re: [PATCH] mm: kmemleak: Ignore kmemleak scanning on CMA regions

On Sun, Nov 28, 2021 at 09:50:53AM +0800, Calvin Zhang wrote: > On Sat, Nov 27, 2021 at 04:07:18PM -0800, Andrew Morton wrote: > >On Fri, 26 Nov 2021 10:47:11 +0800 Calvin Zhang > >wrote: > >> Just like this: > >> commit 620951e27457 ("mm/cma: make kmemleak ignore CMA regions"). > >> > >> Add

Re: [PATCH 1/1] dma: coherent: check no-map property for arm64

On Mon, Jun 14, 2021 at 06:07:04PM +0800, Dong Aisheng wrote: > On Mon, Jun 14, 2021 at 4:36 PM Will Deacon wrote: > > On Fri, Jun 11, 2021 at 09:10:56PM +0800, Dong Aisheng wrote: > > > Coherent dma on ARM64 also can't work with mapped system ram, > > > that means 'no-map' property must be

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

On Thu, Nov 19, 2020 at 06:25:29PM +0100, Nicolas Saenz Julienne wrote: > On Thu, 2020-11-19 at 17:10 +0000, Catalin Marinas wrote: > > On Thu, Nov 19, 2020 at 03:09:58PM +0100, Nicolas Saenz Julienne wrote: > > > On Fri, 2020-11-13 at 11:29 +0000, Cat

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

On Thu, Nov 19, 2020 at 05:10:49PM +, Catalin Marinas wrote: > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > index ed71b1c305d7..acdec0c67d3b 100644 > --- a/arch/arm64/mm/mmu.c > +++ b/arch/arm64/mm/mmu.c > @@ -469,6 +469,21 @@ void __init mark_linear_tex

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

On Thu, Nov 19, 2020 at 03:09:58PM +0100, Nicolas Saenz Julienne wrote: > On Fri, 2020-11-13 at 11:29 +0000, Catalin Marinas wrote: > [...] > > > > > Let me stress that knowing the DMA constraints in the system before > > > > > reserving > > > >

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

Hi Nicolas, On Thu, Nov 12, 2020 at 04:56:38PM +0100, Nicolas Saenz Julienne wrote: > On Tue, 2020-11-10 at 18:17 +0000, Catalin Marinas wrote: > > On Fri, Nov 06, 2020 at 07:46:29PM +0100, Nicolas Saenz Julienne wrote: > > > On Thu, 2020-11-05 at 16:11 +, James Morse wrote

Re: [PATCH v6 1/7] arm64: mm: Move reserve_crashkernel() into mem_init()

On Fri, Nov 06, 2020 at 07:46:29PM +0100, Nicolas Saenz Julienne wrote: > On Thu, 2020-11-05 at 16:11 +, James Morse wrote: > > On 03/11/2020 17:31, Nicolas Saenz Julienne wrote: > > > crashkernel might reserve memory located in ZONE_DMA. We plan to delay > > > ZONE_DMA's initialization after

Re: [PATCH v5 0/7] arm64: Default to 32-bit wide ZONE_DMA

On Tue, Nov 03, 2020 at 06:00:33PM +0100, Nicolas Saenz Julienne wrote: > On Fri, 2020-10-30 at 18:11 +0000, Catalin Marinas wrote: > > On Thu, Oct 29, 2020 at 06:25:43PM +0100, Nicolas Saenz Julienne wrote: > > > Ard Biesheuvel (1): > > > arm64: mm: Set ZONE_DMA si

Re: [PATCH v5 0/7] arm64: Default to 32-bit wide ZONE_DMA

. --8<- >From 3ae252d888be4984a612236124f5b099e804c745 Mon Sep 17 00:00:00 2001 From: Catalin Marinas Date: Fri, 30 Oct 2020 18:07:34 + Subject: [PATCH] arm64: Ignore any DMA offsets in the max_zone_phys() calculation Currently, the ker

Re: [PATCH v5 6/7] arm64: mm: Set ZONE_DMA size based on early IORT scan

On Thu, Oct 29, 2020 at 06:25:49PM +0100, Nicolas Saenz Julienne wrote: > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c > index 9929ff50c0c0..05fe4a076bab 100644 > --- a/drivers/acpi/arm64/iort.c > +++ b/drivers/acpi/arm64/iort.c > @@ -1718,3 +1718,55 @@ void __init

Re: [PATCH v4 5/7] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

On Fri, Oct 23, 2020 at 05:27:49PM +0200, Nicolas Saenz Julienne wrote: > On Thu, 2020-10-22 at 19:06 +0100, Catalin Marinas wrote: > > On Wed, Oct 21, 2020 at 02:34:35PM +0200, Nicolas Saenz Julienne wrote: > > > @@ -188,9 +186,11 @@ static phys_addr_t __init max_zone

Re: [PATCH v4 5/7] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

On Wed, Oct 21, 2020 at 02:34:35PM +0200, Nicolas Saenz Julienne wrote: > @@ -188,9 +186,11 @@ static phys_addr_t __init max_zone_phys(unsigned int > zone_bits) > static void __init zone_sizes_init(unsigned long min, unsigned long max) > { > unsigned long max_zone_pfns[MAX_NR_ZONES] =

Re: [PATCH v3 7/8] arm64: mm: Set ZONE_DMA size based on early IORT scan

On Thu, Oct 15, 2020 at 10:26:18PM +0800, Hanjun Guo wrote: > On 2020/10/15 3:12, Nicolas Saenz Julienne wrote: > > From: Ard Biesheuvel > > > > We recently introduced a 1 GB sized ZONE_DMA to cater for platforms > > incorporating masters that can address less than 32 bits of DMA, in > >

Re: [PATCH v2 1/5] arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()

On Sat, Oct 10, 2020 at 05:12:31PM +0200, Nicolas Saenz Julienne wrote: > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index f6902a2b4ea6..0eca5865dcb1 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -196,14 +196,16 @@ static void __init zone_sizes_init(unsigned

Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711

On Mon, Oct 12, 2020 at 08:47:15AM +0200, Christoph Hellwig wrote: > On Fri, Oct 09, 2020 at 06:10:52PM +0100, Catalin Marinas wrote: > > kdump wants DMA-able memory and, > > DMAable by whom? The only way to guranteed DMAable memory is to use > the DMA memory allocator(s) a

Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711

On Sat, Oct 10, 2020 at 12:53:19PM +0200, Nicolas Saenz Julienne wrote: > On Sat, 2020-10-10 at 12:36 +0200, Ard Biesheuvel wrote: > > On Fri, 9 Oct 2020 at 19:10, Catalin Marinas > > wrote: > > > On Fri, Oct 09, 2020 at 06:23:06PM +0200, Ard Biesheuvel wrote: > > &

Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711

On Fri, Oct 09, 2020 at 06:23:06PM +0200, Ard Biesheuvel wrote: > On Fri, 9 Oct 2020 at 17:24, Lorenzo Pieralisi > wrote: > > We can move this check to IORT code and call it from arm64 if it > > can be made to work. > > Finding the smallest value in the IORT, and assigning it to > zone_dma_bits

Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711

On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote: > On Fri, 2020-10-02 at 12:55 +0100, Catalin Marinas wrote: > > On Thu, Oct 01, 2020 at 07:31:19PM +0200, Nicolas Saenz Julienne wrote: > > > On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote: >

Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711

On Thu, Oct 01, 2020 at 07:31:19PM +0200, Nicolas Saenz Julienne wrote: > On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote: > > On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote: > > > On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote:

Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711

On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote: > Hi Nicolas, > > Thanks for putting this together. > > On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote: > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > > index 4602e4

Re: [PATCH 4/4] mm: Update DMA zones description

On Thu, Oct 01, 2020 at 06:17:40PM +0200, Nicolas Saenz Julienne wrote: > The default behavior for arm64 changed, so reflect that. > > Signed-off-by: Nicolas Saenz Julienne Acked-by: Catalin Marinas ___ iommu mailing list iommu@li

Re: [PATCH 3/4] arm64: Default to 32-bit ZONE_DMA

On Thu, Oct 01, 2020 at 06:17:39PM +0200, Nicolas Saenz Julienne wrote: > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index e1a69a618832..3c3f462466eb 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -43,8 +43,6 @@ > #include > #include > > -#define

Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711

Hi Nicolas, Thanks for putting this together. On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote: > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > index 4602e467ca8b..cd0d115ef329 100644 > --- a/drivers/of/fdt.c > +++ b/drivers/of/fdt.c > @@ -25,6 +25,7 @@ > #include >

Re: [PATCH 04/15] arm64: numa: simplify dummy_numa_init()

span itself, so the loop > over memblock.memory regions is redundant. > > Replace the loop with a single call to memblock_set_node() to the entire > memory. > > Signed-off-by: Mike Rapoport Acked-by: Catalin Marinas ___ iom

Re: [PATCH v2 00/12] ACPI/OF: Upgrade MSI/IOMMU ID mapping APIs

On Fri, 19 Jun 2020 09:20:01 +0100, Lorenzo Pieralisi wrote: > This series is a v2 of a previous posting: > > v1 -> v2 > > - Removed _rid() wrappers > - Fixed !CONFIG_ACPI compilation issue > - Converted of_pci_iommu_init() to use of_iommu_configure_dev_id() > > [...] Applied to arm64

Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable

On Thu, Oct 31, 2019 at 05:58:53PM +0100, Christoph Hellwig wrote: > On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote: > > OK, I see what you mean now. It's wrong indeed. > > > > The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be > > affected by this

Re: [PATCH RFC 0/5] ARM: Raspberry Pi 4 DMA support

On Tue, Oct 15, 2019 at 09:48:22AM +0200, Nicolas Saenz Julienne wrote: > A little off topic but I was wondering if you have a preferred way to refer to > the arm architecture in a way that it unambiguously excludes arm64 (for > example > arm32 would work). arm32 should be fine. Neither arm64

Re: [PATCH RFC 0/5] ARM: Raspberry Pi 4 DMA support

On Mon, Oct 14, 2019 at 08:31:02PM +0200, Nicolas Saenz Julienne wrote: > the Raspberry Pi 4 offers up to 4GB of memory, of which only the first > is DMA capable device wide. This forces us to use of bounce buffers, > which are currently not very well supported by ARM's custom DMA ops. > Among

Re: [PATCH v2 01/11] asm-generic: add dma_zone_size

On Mon, Aug 26, 2019 at 03:46:52PM +0200, Nicolas Saenz Julienne wrote: > On Mon, 2019-08-26 at 09:09 +0200, Christoph Hellwig wrote: > > On Tue, Aug 20, 2019 at 04:58:09PM +0200, Nicolas Saenz Julienne wrote: > > > Some architectures have platform specific DMA addressing limitations. > > > This

Re: [PATCH 1/2] dma-mapping: fix page attributes for dma_mmap_*

ot, > unsigned long attrs) > { > - if (!dev_is_dma_coherent(dev) || (attrs & DMA_ATTR_WRITE_COMBINE)) > - return pgprot_writecombine(prot); > - return prot; > + return pgprot_writecombine(prot); > } For arm64: Acked-by: Catalin Marinas

Re: [PATCH 5/8] arm64: use ZONE_DMA on DMA addressing limited devices

On Wed, Jul 31, 2019 at 05:47:48PM +0200, Nicolas Saenz Julienne wrote: > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index 1c4ffabbe1cb..f5279ef85756 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -50,6 +50,13 @@ > s64 memstart_addr __ro_after_init = -1; >

Re: [RFC 3/4] dma-direct: add dma_direct_min_mask

On Fri, Jul 19, 2019 at 03:08:52PM +0200, Nicolas Saenz Julienne wrote: > On Thu, 2019-07-18 at 13:18 +0200, Nicolas Saenz Julienne wrote: > > On Thu, 2019-07-18 at 11:15 +0200, Christoph Hellwig wrote: > > > On Wed, Jul 17, 2019 at 05:31:34PM +0200, Nicolas Saenz Julienne wrote: > > > >

Re: implement generic dma_map_ops for IOMMUs v4

On Thu, May 02, 2019 at 03:22:08PM +0200, Christoph Hellwig wrote: > can you quickly look over the arm64 parts? I'd really like to still > get this series in for this merge window as it would conflict with > a lot of dma-mapping work for next merge window, and we also have > the amd and possibly

Re: [PATCH 24/25] arm64: switch copyright boilerplace to SPDX in dma-mapping.c

On Tue, Apr 30, 2019 at 06:52:13AM -0400, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > Acked-by: Robin Murphy > Reviewed-by: Mukesh Ojha Acked-by: Catalin Marinas ___ iommu mailing list iommu@lists.linux-foundation.

Re: [PATCH 25/25] arm64: trim includes in dma-mapping.c

On Tue, Apr 30, 2019 at 06:52:14AM -0400, Christoph Hellwig wrote: > With most of the previous functionality now elsewhere a lot of the > headers included in this file are not needed. > > Signed-off-by: Christoph Hellwig Acked-by: Cat

Re: [PATCH 04/25] iommu/dma: Remove the flush_page callback

On Fri, May 03, 2019 at 12:43:35PM +0100, Catalin Marinas wrote: > On Tue, Apr 30, 2019 at 06:51:53AM -0400, Christoph Hellwig wrote: > > We now have a arch_dma_prep_coherent architecture hook that is used > > for the generic DMA remap allocator, and we should use the sam

Re: [PATCH 06/25] iommu/dma: move the arm64 wrappers to common code

frastructure for now, so we'll have to make the > DMA_IOMMU support depend on it, but this will be relaxed soon. > > Signed-off-by: Christoph Hellwig > Acked-by: Robin Murphy Acked-by: Catalin Marinas ___ iommu mailing list iommu@lists.li

Re: [PATCH 04/25] iommu/dma: Remove the flush_page callback

On Tue, Apr 30, 2019 at 06:51:53AM -0400, Christoph Hellwig wrote: > We now have a arch_dma_prep_coherent architecture hook that is used > for the generic DMA remap allocator, and we should use the same > interface for the dma-iommu code. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Robin

Re: [PATCH 02/25] dma-mapping: add a Kconfig symbol to indicated arch_dma_prep_coherent presence

ing to be built for cache coherent architectures. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Robin Murphy Acked-by: Catalin Marinas ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 01/25] arm64/iommu: handle non-remapped addresses in ->mmap and ->get_sgtable

er > case. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Robin Murphy Acked-by: Catalin Marinas ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 RFC/RFT 1/5] ARM: dma-mapping: Add fallback normal page allocations

(catching up on email) On Wed, Apr 24, 2019 at 09:26:52PM +0200, Christoph Hellwig wrote: > On Wed, Apr 24, 2019 at 11:33:11AM -0700, Nicolin Chen wrote: > > I feel it's similar to my previous set, which did most of these > > internally except the renaming part. But Catalin had a concern > > that

Re: [patch V2 08/29] mm/kmemleak: Simplify stacktrace handling

On Thu, Apr 18, 2019 at 10:41:27AM +0200, Thomas Gleixner wrote: > Replace the indirection through struct stack_trace by using the storage > array based interfaces. > > Signed-off-by: Thomas Gleixner > Cc: Catalin Marinas > Cc: linux...@kvack.org Acked-b

Re: [PATCH v2 RFC/RFT] dma-contiguous: Get normal pages for single-page allocations

On Fri, Mar 22, 2019 at 01:09:26PM -0700, Nicolin Chen wrote: > On Fri, Mar 22, 2019 at 10:57:13AM +0000, Catalin Marinas wrote: > > > > Do you have any numbers to back this up? You don't seem to address > > > > dma_direct_alloc() either but, as I said above, it's not

Re: [PATCH v2 RFC/RFT] dma-contiguous: Get normal pages for single-page allocations

Hi Nicolin, On Thu, Mar 21, 2019 at 04:32:49PM -0700, Nicolin Chen wrote: > On Tue, Mar 19, 2019 at 02:43:01PM +0000, Catalin Marinas wrote: > > On Tue, Mar 05, 2019 at 10:32:02AM -0800, Nicolin Chen wrote: > > > The addresses within a single page are always contiguous, so

Re: [PATCH v2 RFC/RFT] dma-contiguous: Get normal pages for single-page allocations

On Tue, Mar 05, 2019 at 10:32:02AM -0800, Nicolin Chen wrote: > The addresses within a single page are always contiguous, so it's > not so necessary to always allocate one single page from CMA area. > Since the CMA area has a limited predefined size of space, it may > run out of space in heavy use

Re: add config symbols for arch_{setup,teardown}_dma_ops

On Mon, Feb 11, 2019 at 02:21:56PM +0100, Christoph Hellwig wrote: > Any chance to get a quick review on this small series? For arm64: Acked-by: Catalin Marinas ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.

Re: [PATCH 10/10] arm64: use the generic swiotlb_dma_ops

(dev, size, vaddr, dma_handle, attrs); > + if (!__free_from_pool(vaddr, PAGE_ALIGN(size))) > + void *kaddr = phys_to_virt(dma_to_phys(dev, dma_handle)); > + > + vunmap(vaddr); > + dma_direct_free_pages(dev, size, kaddr, dma_handle, attrs); > + } >

Re: [PATCH 08/10] swiotlb: don't dip into swiotlb pool for coherent allocations

swiotlb.h | 5 -- > kernel/dma/swiotlb.c| 105 +--- > 3 files changed, 5 insertions(+), 111 deletions(-) Acked-by: Catalin Marinas ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 04/10] swiotlb: remove the overflow buffer

rnel/dma/direct.c | 2 -- > kernel/dma/swiotlb.c | 59 ++- > 6 files changed, 8 insertions(+), 64 deletions(-) I went through the patches and they look fine to me (with the vunmap fix for the last patch). For

Re: [PATCH v2 16/40] arm64: mm: Pin down ASIDs for sharing mm with devices

Hi Jean-Philippe, On Fri, May 11, 2018 at 08:06:17PM +0100, Jean-Philippe Brucker wrote: > +unsigned long mm_context_get(struct mm_struct *mm) > +{ > + unsigned long flags; > + u64 asid; > + > + raw_spin_lock_irqsave(_asid_lock, flags); > + > + asid = atomic64_read(>context.id); >

Re: [PATCH v3 3/3] arm64: Force swiotlb bounce buffering for non-coherent DMA with large CWG

On Sat, May 12, 2018 at 02:38:29PM +0200, Christoph Hellwig wrote: > On Fri, May 11, 2018 at 02:55:47PM +0100, Catalin Marinas wrote: > > On systems with a Cache Writeback Granule (CTR_EL0.CWG) greater than > > ARCH_DMA_MINALIGN, DMA cache maintenance on sub-CWG ranges is not sa

[PATCH v3 0/3] arm64: Revert L1_CACHE_SHIFT back to 6 (64-byte cache line size)

ARCH_HAS_PHYS_TO_DMA on arm64 and force bounce buffering through an arch-specific dma_capable() implementation. Thanks, Catalin [1] http://lkml.kernel.org/r/20180228184720.25467-1-catalin.mari...@arm.com Catalin Marinas (3): Revert "arm64: Increase the max granular size" arm64

[PATCH v3 1/3] Revert "arm64: Increase the max granular size"

an impact on the network packet allocation in certain circumstances, requiring slightly over a 4K page with a significant performance degradation. The patch reverts L1_CACHE_SHIFT back to 6 (64-byte cache line). Cc: Will Deacon <will.dea...@arm.com> Cc: Robin Murphy <robin.mur...@arm.com>

[PATCH v3 2/3] arm64: Increase ARCH_DMA_MINALIGN to 128

.@arm.com> Signed-off-by: Catalin Marinas <catalin.mari...@arm.com> --- arch/arm64/include/asm/cache.h | 4 ++-- arch/arm64/kernel/cpufeature.c | 9 ++--- 2 files changed, 4 insertions(+), 9 deletions(-) diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h

[PATCH v3 3/3] arm64: Force swiotlb bounce buffering for non-coherent DMA with large CWG

<will.dea...@arm.com> Cc: Robin Murphy <robin.mur...@arm.com> Cc: Christoph Hellwig <h...@lst.de> Signed-off-by: Catalin Marinas <catalin.mari...@arm.com> --- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/dma-direct.h | 43

Re: [PATCH 12/14] dma-direct: handle the memory encryption bit in common code

On Mon, Mar 19, 2018 at 08:49:30PM +0100, Christoph Hellwig wrote: > On Mon, Mar 19, 2018 at 06:01:41PM +0000, Catalin Marinas wrote: > > I don't particularly like maintaining an arm64-specific dma-direct.h > > either but arm64 seems to be the only architecture that needs to > &

Re: [PATCH 12/14] dma-direct: handle the memory encryption bit in common code

On Mon, Mar 19, 2018 at 05:03:43PM +0100, Christoph Hellwig wrote: > On Mon, Mar 19, 2018 at 03:48:33PM +, Will Deacon wrote: > > Why can't we just resolve the conflict by adding the underscores? > > We can solve the conflict easily that way. But that's not the point. > > The point is that

Re: [PATCH] arm64/dma-mapping: fix DMA_ATTR_FORCE_CONTIGUOUS mmaping code

On Mon, Apr 24, 2017 at 09:58:23AM -0700, Laura Abbott wrote: > On 04/21/2017 09:12 AM, Catalin Marinas wrote: > > On Wed, Mar 29, 2017 at 01:55:32PM +0100, Robin Murphy wrote: > >> On 29/03/17 11:05, Andrzej Hajda wrote: > >>> In case of DMA_ATTR_FORCE_CONTIGU

Re: [PATCH v2] arm64/dma-mapping: fix DMA_ATTR_FORCE_CONTIGUOUS mmaping code

Hi Geert, On Fri, Apr 21, 2017 at 07:39:43PM +0200, Geert Uytterhoeven wrote: > On Fri, Apr 21, 2017 at 7:32 PM, Catalin Marinas > <catalin.mari...@arm.com> wrote: > > On Fri, Mar 31, 2017 at 01:02:51PM +0200, Andrzej Hajda wrote: > >> In case of DMA_ATTR_FORCE_CON

Re: [PATCH v2] arm64/dma-mapping: fix DMA_ATTR_FORCE_CONTIGUOUS mmaping code

On Fri, Mar 31, 2017 at 01:02:51PM +0200, Andrzej Hajda wrote: > In case of DMA_ATTR_FORCE_CONTIGUOUS allocations vm_area->pages > is invalid. __iommu_mmap_attrs and __iommu_get_sgtable should not > use it and take advantage of contiguous nature of the allocation. As I replied to your original

Re: [PATCH] arm64/dma-mapping: fix DMA_ATTR_FORCE_CONTIGUOUS mmaping code

On Wed, Mar 29, 2017 at 01:55:32PM +0100, Robin Murphy wrote: > On 29/03/17 11:05, Andrzej Hajda wrote: > > In case of DMA_ATTR_FORCE_CONTIGUOUS allocations vm_area->pages > > is invalid. __iommu_mmap_attrs and __iommu_get_sgtable cannot use > > it. In first case temporary pages array is passed to

Re: [PATCH v5] arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU

Catching up with these threads, so replying to a patch I already applied. On Tue, Mar 07, 2017 at 06:43:32PM +0100, Geert Uytterhoeven wrote: > --- a/arch/arm64/mm/dma-mapping.c > +++ b/arch/arm64/mm/dma-mapping.c > @@ -584,20 +584,7 @@ static void *__iommu_alloc_attrs(struct device *dev, >

Re: [PATCH v5] arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU

On Tue, Mar 07, 2017 at 06:43:32PM +0100, Geert Uytterhoeven wrote: > Add support for allocating physically contiguous DMA buffers on arm64 > systems with an IOMMU. This can be useful when two or more devices > with different memory requirements are involved in buffer sharing. > > Note that as

Re: [PATCH v4 1/2] iommu/dma: Implement dma_{map,unmap}_resource()

t; a concern, these can both be standalone callback implementations without > the need for arch code wrappers. > > CC: Joerg Roedel <j...@8bytes.org> > Signed-off-by: Robin Murphy <robin.mur...@arm.com> FWIW: Reviewed-by: Cata

Re: [PATCH v3 2/2] arm64: Wire up iommu_dma_{map, unmap}_resource()

On Fri, Nov 11, 2016 at 06:27:35PM +, Robin Murphy wrote: > With no coherency to worry about, just plug'em straight in. > > CC: Catalin Marinas <catalin.mari...@arm.com> > CC: Will Deacon <will.dea...@arm.com> > Signed-off-by: Robin Murphy <robin.mur...@arm.c

Re: [PATCH v3 1/2] iommu/dma: Implement dma_{map,unmap}_resource()

On Fri, Nov 11, 2016 at 06:27:34PM +, Robin Murphy wrote: > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c > index c5ab8667e6f2..8b745260b3bc 100644 > --- a/drivers/iommu/dma-iommu.c > +++ b/drivers/iommu/dma-iommu.c > @@ -432,13 +432,12 @@ int iommu_dma_mmap(struct page

Re: [PATCH v2 1/2] iommu/dma: Implement dma_{map,unmap}_resource()

On Thu, Nov 10, 2016 at 02:30:04PM +, Robin Murphy wrote: > On 10/11/16 12:24, Joerg Roedel wrote: > > On Wed, Oct 26, 2016 at 06:43:56PM +0100, Robin Murphy wrote: > >> With the new dma_{map,unmap}_resource() functions added to the DMA API > >> for the benefit of cases like slave DMA, add

Re: [PATCH v4 1/8] arm64: mm: change IOMMU notifier action to attach DMA ops

added too early on DT-based systems, so clean up the notifier > > itself plus the additional workaround from 722ec35f7fae ("arm64: > > dma-mapping: fix handling of devices registered before arch_initcall") > > > > Cc: Will Deacon <will.dea...@arm.com> > >

Re: [PATCH 4/5] iommu/rockchip: add ARM64 cache flush operation for iommu

On Tue, May 24, 2016 at 10:31:17AM +0800, Shunqian Zheng wrote: > On 2016年05月23日 21:35, Catalin Marinas wrote: > >On Mon, May 23, 2016 at 11:44:14AM +0100, Robin Murphy wrote: > >>On 23/05/16 02:37, Shunqian Zheng wrote: > >>>From: Simon <x...@rock-chips.com>

Re: [PATCH 4/5] iommu/rockchip: add ARM64 cache flush operation for iommu

On Mon, May 23, 2016 at 11:44:14AM +0100, Robin Murphy wrote: > On 23/05/16 02:37, Shunqian Zheng wrote: > >From: Simon > > > >Signed-off-by: Simon > >--- > > drivers/iommu/rockchip-iommu.c | 4 > > 1 file changed, 4 insertions(+) > > > >diff --git

Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak

On 2 December 2015 at 13:59, Borislav Petkov wrote: > On Wed, Dec 02, 2015 at 02:48:47PM +0100, Michael Wang wrote: >> I'm not sure why amd-iommu use get_page not kmalloc to initialize the >> pointer table, but if it's necessary then the conflict will be there, >> it's not the

Re: [PATCH 1/2] arm64: Workaround renaming of __GFP_WAIT

reverted at 4.4-rc1. > > CC: Mel Gorman <mgor...@techsingularity.net> > CC: Andrew Morton <a...@linux-foundation.org> > Reported-by: Sudeep Holla <sudeep.ho...@arm.com> > Signed-off-by: Robin Murphy <robin.mur...@arm.com&g

Re: [PATCH 2/2] arm64: Use gfpflags_allow_blocking()

...@linux-foundation.org> > Reported-by: Sudeep Holla <sudeep.ho...@arm.com> > Signed-off-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Catalin Marinas <catalin.mari...@arm.com> ___ iommu mailing list iommu@lists.linux-found

Re: [PATCH v6 2/3] arm64: Add IOMMU dma_ops

rry, I reviewed this patch before but forgot to ack it, so here it is: Acked-by: Catalin Marinas <catalin.mari...@arm.com> (and I'm fined for the arm64 patches here to go in via the iommu tree) I assume part of this patch will disappear at some point when the devic

Re: [PATCH v5 2/3] arm64: Add IOMMU dma_ops

robin.mur...@arm.com Reviewed-by: Catalin Marinas catalin.mari...@arm.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v5 1/3] iommu: Implement common IOMMU ops for DMA mapping

robin.mur...@arm.com Acked-by: Catalin Marinas catalin.mari...@arm.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 2/4] iommu: Implement common IOMMU ops for DMA mapping

On Thu, Jul 16, 2015 at 07:40:13PM +0100, Robin Murphy wrote: +/** + * iommu_dma_alloc - Allocate and map a buffer contiguous in IOVA space + * @dev: Device to allocate memory for. Must be a real device + *attached to an iommu_dma_domain + * @size: Size of buffer in bytes + * @gfp:

Re: [PATCH v4 3/4] arm64: Add IOMMU dma_ops

On Thu, Jul 16, 2015 at 07:40:14PM +0100, Robin Murphy wrote: +static void *__iommu_alloc_attrs(struct device *dev, size_t size, + dma_addr_t *handle, gfp_t gfp, + struct dma_attrs *attrs) +{ + bool coherent =

Re: [PATCH v4 4/4] arm64: Hook up IOMMU dma_ops

On Thu, Jul 16, 2015 at 07:40:15PM +0100, Robin Murphy wrote: With iommu_dma_ops in place, hook them up to the configuration code, so IOMMU-fronted devices will get them automatically. Signed-off-by: Robin Murphy robin.mur...@arm.com Acked-by: Catalin Marinas catalin.mari...@arm.com

Re: [PATCH v3 3/4] arm64: Add IOMMU dma_ops

On Fri, Jul 10, 2015 at 08:19:34PM +0100, Robin Murphy wrote: diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c index d16a1ce..ccadfd4 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -526,3 +526,426 @@ static int __init

Re: [PATCH v3 3/4] arm64: Add IOMMU dma_ops

On Wed, Jul 15, 2015 at 05:27:22PM +0100, Robin Murphy wrote: On 15/07/15 10:31, Catalin Marinas wrote: On Fri, Jul 10, 2015 at 08:19:34PM +0100, Robin Murphy wrote: + if (iommu_dma_mapping_error(dev, *handle)) { + if (coherent

Re: [PATCH v3 2/4] iommu: Implement common IOMMU ops for DMA mapping

On Fri, Jul 10, 2015 at 08:19:33PM +0100, Robin Murphy wrote: +/* + * IOVAs are IOMMU _input_ addresses, so there still exists the possibility + * for static bus translation between device output and IOMMU input (yuck). + */ +static inline dma_addr_t dev_dma_addr(struct device *dev,

Re: [PATCH v6 3/7] of: fix size when dma-range is not used

On Thu, Feb 05, 2015 at 09:52:55PM +, Murali Karicheri wrote: Fix the dma-range size when the DT attribute is missing. i.e set size to dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. Also add code to check invalid values of size configured in DT and log error. Cc: Joerg

Re: [PATCH v6 0/7] PCI: get DMA configuration from parent device

-mask, dma_pfn_offset, and dma ops etc using the information from DT. The prior RFCs and discussions are available at [1] and [2] below. For the series, you can add: Reviewed-by: Catalin Marinas catalin.mari...@arm.com ___ iommu mailing list iommu

Re: [PATCH v4 3/6] of: fix size when dma-range is not used

On Fri, Jan 30, 2015 at 06:06:27PM +, Murali Karicheri wrote: On 01/28/2015 12:30 PM, Catalin Marinas wrote: I think we can remove this check altogether (we leaved without it for a while) but we need to add 1 when calculating the mask: dev-coherent_dma_mask = min(DMA_BIT_MASK(32

Re: [PATCH v4 3/6] of: fix size when dma-range is not used

On Tue, Jan 27, 2015 at 06:55:15PM +, Murali Karicheri wrote: On 01/27/2015 06:27 AM, Robin Murphy wrote: On 23/01/15 22:32, Murali Karicheri wrote: Fix the dma-range size when the DT attribute is missing. i.e set size to dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. To

Re: [PATCH v4 3/6] of: fix size when dma-range is not used

On Wed, Jan 28, 2015 at 03:55:57PM +, Robin Murphy wrote: On 28/01/15 11:05, Catalin Marinas wrote: On Tue, Jan 27, 2015 at 06:55:15PM +, Murali Karicheri wrote: How about having the logic like this? ret = of_dma_get_range(np, dma_addr, paddr, size); if (ret 0

Re: [PATCH v4 3/6] of: fix size when dma-range is not used

On Wed, Jan 28, 2015 at 03:45:19PM +, Rob Herring wrote: On Wed, Jan 28, 2015 at 5:05 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Jan 27, 2015 at 06:55:15PM +, Murali Karicheri wrote: How about having the logic like this? ret = of_dma_get_range(np, dma_addr

Re: [PATCH v4 6/6] arm: dma-mapping: updates to limit dma_mask and iommu mapping size

On Tue, Jan 27, 2015 at 11:12:32AM +, Robin Murphy wrote: On 23/01/15 22:32, Murali Karicheri wrote: Limit the dma_mask to minimum of dma_mask and dma_base + size - 1. Also arm_iommu_create_mapping() has size parameter of size_t and arm_setup_iommu_dma_ops() can take a value higher

Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping

On Mon, Jan 12, 2015 at 08:48:52PM +, Robin Murphy wrote: Catalin Marinas (1): arm64: Combine coherent and non-coherent swiotlb dma_ops Robin Murphy (4): arm64: implement generic IOMMU configuration iommu: implement common IOMMU ops for DMA mapping arm64: add IOMMU dma_ops

Re: [PATCH 1/2] [RFC] arm: iommu: Refactoring common code

On Wed, Mar 19, 2014 at 02:58:26AM +, Ritesh Harjani wrote: Some suggestions/comments on this to take this discussion forward ? Just a bit of patience ;). It's likely that you won't get much feedback before 3.15-rc1 as people are busy preparing for the merging window. -- Catalin

Re: [PATCH] arm64: iommu: Refactoring common code.

On Mon, Mar 10, 2014 at 04:32:50PM +, Ritesh Harjani wrote: Hi Everyone, Please find the following patch as refactoring of the common code out from arch/arm/mm/dma-mapping.c to lib/iommu-helper.c This is just an initial version of patch to get more details and to know if this is how