Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS
From: Robin Murphy @ 2017-01-13 11:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1484305674-15018-1-git-send-email-geert+renesas@glider.be>

On 13/01/17 11:07, Geert Uytterhoeven wrote:
> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code.
> This allows to allocate physically contiguous DMA buffers on arm64
> systems with an IOMMU.

Can anyone explain what this attribute is actually used for? I've never
quite figured it out.

> Note that as this uses the CMA allocator, setting this attribute has a
> runtime-dependency on CONFIG_DMA_CMA, just like on arm32.
> 
> For arm64 systems using swiotlb, no changes are needed to support the
> allocation of physically contiguous DMA buffers:
>   - swiotlb always uses physically contiguous buffers (up to
>     IO_TLB_SEGSIZE = 128 pages),
>   - arm64's __dma_alloc_coherent() already calls
>     dma_alloc_from_contiguous() when CMA is available.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  arch/arm64/mm/dma-mapping.c |  4 ++--
>  drivers/iommu/dma-iommu.c   | 44 ++++++++++++++++++++++++++++++++++----------
>  include/linux/dma-iommu.h   |  2 +-
>  3 files changed, 37 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 1d7d5d2881db7c19..5fba14a21163e41f 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -589,7 +589,7 @@ static void *__iommu_alloc_attrs(struct device *dev, size_t size,
>  		addr = dma_common_pages_remap(pages, size, VM_USERMAP, prot,
>  					      __builtin_return_address(0));
>  		if (!addr)
> -			iommu_dma_free(dev, pages, iosize, handle);
> +			iommu_dma_free(dev, pages, iosize, handle, attrs);
>  	} else {
>  		struct page *page;
>  		/*
> @@ -642,7 +642,7 @@ static void __iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
>  
>  		if (WARN_ON(!area || !area->pages))
>  			return;
> -		iommu_dma_free(dev, area->pages, iosize, &handle);
> +		iommu_dma_free(dev, area->pages, iosize, &handle, attrs);
>  		dma_common_free_remap(cpu_addr, size, VM_USERMAP);
>  	} else {
>  		iommu_dma_unmap_page(dev, handle, iosize, 0, 0);
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 2db0d641cf4505b5..b991e8dcbbbb35c5 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -30,6 +30,7 @@
>  #include <linux/pci.h>
>  #include <linux/scatterlist.h>
>  #include <linux/vmalloc.h>
> +#include <linux/dma-contiguous.h>
>  
>  struct iommu_dma_msi_page {
>  	struct list_head	list;
> @@ -238,15 +239,21 @@ static void __iommu_dma_unmap(struct iommu_domain *domain, dma_addr_t dma_addr)
>  	__free_iova(iovad, iova);
>  }
>  
> -static void __iommu_dma_free_pages(struct page **pages, int count)
> +static void __iommu_dma_free_pages(struct device *dev, struct page **pages,
> +				   int count, unsigned long attrs)
>  {
> -	while (count--)
> -		__free_page(pages[count]);
> +	if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
> +		dma_release_from_contiguous(dev, pages[0], count);
> +	} else {
> +		while (count--)
> +			__free_page(pages[count]);
> +	}
>  	kvfree(pages);
>  }
>  
> -static struct page **__iommu_dma_alloc_pages(unsigned int count,
> -		unsigned long order_mask, gfp_t gfp)
> +static struct page **__iommu_dma_alloc_pages(struct device *dev,
> +		unsigned int count, unsigned long order_mask, gfp_t gfp,
> +		unsigned long attrs)
>  {
>  	struct page **pages;
>  	unsigned int i = 0, array_size = count * sizeof(*pages);
> @@ -265,6 +272,20 @@ static struct page **__iommu_dma_alloc_pages(unsigned int count,
>  	/* IOMMU can map any pages, so himem can also be used here */
>  	gfp |= __GFP_NOWARN | __GFP_HIGHMEM;
>  
> +	if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
> +		int order = get_order(count << PAGE_SHIFT);
> +		struct page *page;
> +
> +		page = dma_alloc_from_contiguous(dev, count, order);
> +		if (!page)
> +			return NULL;
> +
> +		while (count--)
> +			pages[i++] = page++;
> +
> +		return pages;
> +	}
> +

This is really yuck. Plus it's entirely pointless to go through the
whole page array/scatterlist dance when we know the buffer is going to
be physically contiguous - it should just be allocate, map, done. I'd
much rather see standalone iommu_dma_{alloc,free}_contiguous()
functions, and let the arch code handle dispatching appropriately.

Robin.

>  	while (count) {
>  		struct page *page = NULL;
>  		unsigned int order_size;
> @@ -294,7 +315,7 @@ static struct page **__iommu_dma_alloc_pages(unsigned int count,
>  			__free_pages(page, order);
>  		}
>  		if (!page) {
> -			__iommu_dma_free_pages(pages, i);
> +			__iommu_dma_free_pages(dev, pages, i, attrs);
>  			return NULL;
>  		}
>  		count -= order_size;
> @@ -310,15 +331,17 @@ static struct page **__iommu_dma_alloc_pages(unsigned int count,
>   * @pages: Array of buffer pages as returned by iommu_dma_alloc()
>   * @size: Size of buffer in bytes
>   * @handle: DMA address of buffer
> + * @attrs: DMA attributes used for allocation of this buffer
>   *
>   * Frees both the pages associated with the buffer, and the array
>   * describing them
>   */
>  void iommu_dma_free(struct device *dev, struct page **pages, size_t size,
> -		dma_addr_t *handle)
> +		dma_addr_t *handle, unsigned long attrs)
>  {
>  	__iommu_dma_unmap(iommu_get_domain_for_dev(dev), *handle);
> -	__iommu_dma_free_pages(pages, PAGE_ALIGN(size) >> PAGE_SHIFT);
> +	__iommu_dma_free_pages(dev, pages, PAGE_ALIGN(size) >> PAGE_SHIFT,
> +			       attrs);
>  	*handle = DMA_ERROR_CODE;
>  }
>  
> @@ -365,7 +388,8 @@ struct page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
>  		alloc_sizes = min_size;
>  
>  	count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> -	pages = __iommu_dma_alloc_pages(count, alloc_sizes >> PAGE_SHIFT, gfp);
> +	pages = __iommu_dma_alloc_pages(dev, count, alloc_sizes >> PAGE_SHIFT,
> +					gfp, attrs);
>  	if (!pages)
>  		return NULL;
>  
> @@ -403,7 +427,7 @@ struct page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
>  out_free_iova:
>  	__free_iova(iovad, iova);
>  out_free_pages:
> -	__iommu_dma_free_pages(pages, count);
> +	__iommu_dma_free_pages(dev, pages, count, attrs);
>  	return NULL;
>  }
>  
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 7f7e9a7e3839966c..35fa6b7f9bac9b35 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -44,7 +44,7 @@ struct page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
>  		unsigned long attrs, int prot, dma_addr_t *handle,
>  		void (*flush_page)(struct device *, const void *, phys_addr_t));
>  void iommu_dma_free(struct device *dev, struct page **pages, size_t size,
> -		dma_addr_t *handle);
> +		dma_addr_t *handle, unsigned long attrs);
>  
>  int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct *vma);
>  
> 

^ permalink raw reply

* [PATCH] arm64: defconfig: disable CONFIG_DEVMEM
From: Leif Lindholm @ 2017-01-13 11:37 UTC (permalink / raw)
  To: linux-arm-kernel

/dev/mem is the opposite of what an operating system is for.
Additionally, on arm* it opens up for denial-of-service attacks from
userspace. So leave it disabled by default, requiring people who need
it to enable it explicitly.

Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 33b744d..55ba73a 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -210,6 +210,7 @@ CONFIG_INPUT_HISI_POWERKEY=y
 # CONFIG_SERIO_SERPORT is not set
 CONFIG_SERIO_AMBAKMI=y
 CONFIG_LEGACY_PTY_COUNT=16
+# CONFIG_DEVMEM is not set
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_EXTENDED=y
-- 
2.10.2

^ permalink raw reply related

* [PATCH] arm64: defconfig: disable CONFIG_DEVMEM
From: Ard Biesheuvel @ 2017-01-13 11:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170113113734.16524-1-leif.lindholm@linaro.org>

On 13 January 2017 at 11:37, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> /dev/mem is the opposite of what an operating system is for.
> Additionally, on arm* it opens up for denial-of-service attacks from
> userspace. So leave it disabled by default, requiring people who need
> it to enable it explicitly.
>
> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>

Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

> ---
>  arch/arm64/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 33b744d..55ba73a 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -210,6 +210,7 @@ CONFIG_INPUT_HISI_POWERKEY=y
>  # CONFIG_SERIO_SERPORT is not set
>  CONFIG_SERIO_AMBAKMI=y
>  CONFIG_LEGACY_PTY_COUNT=16
> +# CONFIG_DEVMEM is not set
>  CONFIG_SERIAL_8250=y
>  CONFIG_SERIAL_8250_CONSOLE=y
>  CONFIG_SERIAL_8250_EXTENDED=y
> --
> 2.10.2
>

^ permalink raw reply

* [PATCH v29 3/9] arm64: kdump: reserve memory for crash dump kernel
From: Mark Rutland @ 2017-01-13 11:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170113081617.GI20972@linaro.org>

On Fri, Jan 13, 2017 at 05:16:18PM +0900, AKASHI Takahiro wrote:
> On Thu, Jan 12, 2017 at 03:09:26PM +0000, Mark Rutland wrote:
> > > +static int __init export_crashkernel(void)

> > > +	/* Add /chosen/linux,crashkernel-* properties */

> > > +	of_remove_property(node, of_find_property(node,
> > > +				"linux,crashkernel-base", NULL));
> > > +	of_remove_property(node, of_find_property(node,
> > > +				"linux,crashkernel-size", NULL));
> > > +
> > > +	ret = of_add_property(node, &crash_base_prop);
> > > +	if (ret)
> > > +		goto ret_err;
> > > +
> > > +	ret = of_add_property(node, &crash_size_prop);
> > > +	if (ret)
> > > +		goto ret_err;

> > I very much do not like this.
> > 
> > I don't think we should be modifying the DT exposed to userspace in this
> > manner, in the usual boot path, especially given that the kernel itself
> > does not appear to be a consumer of this property. I do not think that
> > it is right to use the DT exposed to userspace as a communication
> > channel solely between the kernel and userspace.
> 
> As you mentioned in your comments against my patch#9, this property
> originates from PPC implementation.
> I added it solely from the sympathy for dt-based architectures.
>
> > So I think we should drop the above, and for arm64 have userspace
> > consistently use /proc/iomem (or perhaps a new kexec-specific file) to
> > determine the region reserved for the crash kernel, if it needs to know
> > this.
> 
> As a matter of fact, my port of kexec-tools doesn't check this property
> and dropping it won't cause any problem.

Ok. It sounds like we're both happy for this to go, then.

While it's unfortunate that architectures differ, I think we have
legitimate reasons to differ, and it's preferable to do so. We have a
different set of constraints (e.g. supporting EFI memory maps), and
following the PPC approach creates longer term issues for us, making it
harder to do the right thing consistently.

> > > +/*
> > > + * reserve_crashkernel() - reserves memory for crash kernel
> > > + *
> > > + * This function reserves memory area given in "crashkernel=" kernel command
> > > + * line parameter. The memory reserved is used by dump capture kernel when
> > > + * primary kernel is crashing.
> > > + */
> > > +static void __init reserve_crashkernel(void)

> > > +	memblock_reserve(crash_base, crash_size);
> > 
> > This will mean that the crash kernel will have a permanent alias in the linear
> > map which is vulnerable to being clobbered. There could also be issues
> > with mismatched attributes in future.
> 
> Good point, I've never thought of that except making the memblock
> region "reserved."
> 
> > We're probably ok for now, but in future we'll likely want to fix this
> > up to remove the region (or mark it nomap), and only map it temporarily
> > when loading things into the region.
> 
> Well, I found that the following commit is already in:
>         commit 9b492cf58077
>         Author: Xunlei Pang <xlpang@redhat.com>
>         Date:   Mon May 23 16:24:10 2016 -0700
> 
>             kexec: introduce a protection mechanism for the crashkernel
>             reserved memory
> 
> To make best use of this framework, I'd like to re-use set_memory_ro/rx()
> instead of removing the region from linear mapping. But to do so,
> we need to
> * make memblock_isolate_range() global,
> * allow set_memory_ro/rx() to be applied to regions in linear mapping
> since set_memory_ro/rx() works only on page-level mappings.
> 
> What do you think?
> (See my tentative solution below.)

Great! I think it would be better to follow the approach of
mark_rodata_ro(), rather than opening up set_memory_*(), but otherwise,
it looks like it should work.

Either way, this still leaves us with an RO alias on crashed cores (and
potential cache attribute mismatches in future). Do we need to read from
the region later, or could we unmap it entirely?

Thanks,
Mark.

> ===8<===
> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> index c0fc3d458195..bb21c0473b8e 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -211,6 +211,44 @@ void machine_kexec(struct kimage *kimage)
>  	BUG(); /* Should never get here. */
>  }
>  
> +static int kexec_mark_range(unsigned long start, unsigned long end,
> +							bool protect)
> +{
> +	unsigned int nr_pages;
> +
> +	if (!end || start >= end)
> +		return 0;
> +
> +	nr_pages = (end >> PAGE_SHIFT) - (start >> PAGE_SHIFT) + 1;
> +
> +	if (protect)
> +		return set_memory_ro(__phys_to_virt(start), nr_pages);
> +	else
> +		return set_memory_rw(__phys_to_virt(start), nr_pages);
> +}
> +
> +static void kexec_mark_crashkres(bool protect)
> +{
> +	unsigned long control;
> +
> +	/* Don't touch the control code page used in crash_kexec().*/
> +	control = page_to_phys(kexec_crash_image->control_code_page);
> +	kexec_mark_range(crashk_res.start, control - 1, protect);
> +
> +	control += KEXEC_CONTROL_PAGE_SIZE;
> +	kexec_mark_range(control, crashk_res.end, protect);
> +}
> +
> +void arch_kexec_protect_crashkres(void)
> +{
> +	kexec_mark_crashkres(true);
> +}
> +
> +void arch_kexec_unprotect_crashkres(void)
> +{
> +	kexec_mark_crashkres(false);
> +}
> +
>  static void machine_kexec_mask_interrupts(void)
>  {
>  	unsigned int i;
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 569ec3325bc8..764ec89c4f76 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -90,6 +90,7 @@ early_param("initrd", early_initrd);
>  static void __init reserve_crashkernel(void)
>  {
>  	unsigned long long crash_size, crash_base;
> +	int start_rgn, end_rgn;
>  	int ret;
>  
>  	ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> @@ -121,6 +122,9 @@ static void __init reserve_crashkernel(void)
>  		}
>  	}
>  	memblock_reserve(crash_base, crash_size);
> +	memblock_isolate_range(&memblock.memory, crash_base, crash_size,
> +			&start_rgn, &end_rgn);
> +
>  
>  	pr_info("Reserving %lldMB of memory at %lldMB for crashkernel\n",
>  		crash_size >> 20, crash_base >> 20);
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 17243e43184e..0f60f19c287b 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -22,6 +22,7 @@
>  #include <linux/kernel.h>
>  #include <linux/errno.h>
>  #include <linux/init.h>
> +#include <linux/kexec.h>
>  #include <linux/libfdt.h>
>  #include <linux/mman.h>
>  #include <linux/nodemask.h>
> @@ -362,6 +363,17 @@ static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end
>  	unsigned long kernel_start = __pa(_text);
>  	unsigned long kernel_end = __pa(__init_begin);
>  
> +#ifdef CONFIG_KEXEC_CORE
> +	if (crashk_res.end && start >= crashk_res.start &&
> +			end <= (crashk_res.end + 1)) {
> +		__create_pgd_mapping(pgd, start, __phys_to_virt(start),
> +				     end - start, PAGE_KERNEL,
> +				     early_pgtable_alloc,
> +				     true);
> +		return;
> +	}
> +#endif
> +
>  	/*
>  	 * Take care not to create a writable alias for the
>  	 * read-only text and rodata sections of the kernel image.
> ===>8===

^ permalink raw reply

* [PATCH] arm64: defconfig: disable CONFIG_DEVMEM
From: Mark Rutland @ 2017-01-13 11:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170113113734.16524-1-leif.lindholm@linaro.org>

On Fri, Jan 13, 2017 at 11:37:34AM +0000, Leif Lindholm wrote:
> /dev/mem is the opposite of what an operating system is for.
> Additionally, on arm* it opens up for denial-of-service attacks from
> userspace. So leave it disabled by default, requiring people who need
> it to enable it explicitly.
> 
> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>

Generally I'd agree that the use of /dev/mem is a bad idea (TM), so I'm
surprised we have it in our defconfig.

FWIW:

Acked-by: Mark Rutland <mark.rutland@arm.com>

Mark.

> ---
>  arch/arm64/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 33b744d..55ba73a 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -210,6 +210,7 @@ CONFIG_INPUT_HISI_POWERKEY=y
>  # CONFIG_SERIO_SERPORT is not set
>  CONFIG_SERIO_AMBAKMI=y
>  CONFIG_LEGACY_PTY_COUNT=16
> +# CONFIG_DEVMEM is not set
>  CONFIG_SERIAL_8250=y
>  CONFIG_SERIAL_8250_CONSOLE=y
>  CONFIG_SERIAL_8250_EXTENDED=y
> -- 
> 2.10.2
> 

^ permalink raw reply

* [PATCH] arm64/mm: use phys_addr_t
From: Mark Rutland @ 2017-01-13 11:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKv+Gu__4S+0B39SXn46sqxsH0OXeusotZOBmvzZmw-yRRzdjA@mail.gmail.com>

On Fri, Jan 13, 2017 at 11:27:48AM +0000, Ard Biesheuvel wrote:
> On 13 January 2017 at 11:22, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Jan 13, 2017 at 01:59:35PM +0800, miles.chen at mediatek.com wrote:
> >> From: Miles Chen <miles.chen@mediatek.com>
> >>
> >> Use phys_addr_t instead of unsigned long for the
> >> return value of __pa(), make code easy to understand.
> >>
> >> Signed-off-by: Miles Chen <miles.chen@mediatek.com>
> >
> > This looks sensible to me. It's consistent with the types these
> > variables are compared against, and with the types of function
> > parameters these are passed as.
> >
> 
> Indeed. But doesn't it clash with Laura's series?

Good point.

Yes, but only for the RHS of the assignment changing. This'll need to be
rebased atop of the arm64 for-next/core branch, or Catalin/Will might
fix it up when applying, perhaps?

Thanks,
Mark.

> > Acked-by: Mark Rutland <mark.rutland@arm.com>
> >
> > Thanks,
> > Mark.
> >
> >> ---
> >>  arch/arm64/mm/mmu.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >> index 17243e4..7eb7c21 100644
> >> --- a/arch/arm64/mm/mmu.c
> >> +++ b/arch/arm64/mm/mmu.c
> >> @@ -359,8 +359,8 @@ static void create_mapping_late(phys_addr_t phys, unsigned long virt,
> >>
> >>  static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end)
> >>  {
> >> -     unsigned long kernel_start = __pa(_text);
> >> -     unsigned long kernel_end = __pa(__init_begin);
> >> +     phys_addr_t kernel_start = __pa(_text);
> >> +     phys_addr_t kernel_end = __pa(__init_begin);
> >>
> >>       /*
> >>        * Take care not to create a writable alias for the
> >> --
> >> 1.9.1
> >>
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v7 08/15] ACPI: IORT: rename iort_node_map_rid() to make it generic
From: Lorenzo Pieralisi @ 2017-01-13 11:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1484147199-4267-9-git-send-email-hanjun.guo@linaro.org>

On Wed, Jan 11, 2017 at 11:06:32PM +0800, Hanjun Guo wrote:
> iort_node_map_rid() was designed for both PCI and platform
> device, but the rid means requester id is for ITS mappings,

I do not understand what this means sorry.

> rename iort_node_map_rid() to iort_node_map_id() and update
> its argument names to make it more generic.
> 

"iort_node_map_rid() was designed to take an input id (that is not
necessarily a PCI requester id) and map it to an output id (eg an SMMU
streamid or an ITS deviceid) according to the mappings provided by an
IORT node mapping entries. This means that the iort_node_map_rid() input
id is not always a PCI requester id as its name, parameters and local
variables suggest, which is misleading.

Apply the s/rid/id substitution to the iort_node_map_rid() mapping
function and its users to make sure its intended usage is clearer."

Lorenzo

> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> ---
>  drivers/acpi/arm64/iort.c | 30 +++++++++++++++---------------
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 208eac9..069a690 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -355,11 +355,11 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
>  	return NULL;
>  }
>  
> -static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
> -						u32 rid_in, u32 *rid_out,
> -						u8 type_mask)
> +static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,
> +					       u32 id_in, u32 *id_out,
> +					       u8 type_mask)
>  {
> -	u32 rid = rid_in;
> +	u32 id = id_in;
>  
>  	/* Parse the ID mapping tree to find specified node type */
>  	while (node) {
> @@ -367,8 +367,8 @@ static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
>  		int i;
>  
>  		if (IORT_TYPE_MASK(node->type) & type_mask) {
> -			if (rid_out)
> -				*rid_out = rid;
> +			if (id_out)
> +				*id_out = id;
>  			return node;
>  		}
>  
> @@ -385,9 +385,9 @@ static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
>  			goto fail_map;
>  		}
>  
> -		/* Do the RID translation */
> +		/* Do the ID translation */
>  		for (i = 0; i < node->mapping_count; i++, map++) {
> -			if (!iort_id_map(map, node->type, rid, &rid))
> +			if (!iort_id_map(map, node->type, id, &id))
>  				break;
>  		}
>  
> @@ -399,9 +399,9 @@ static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
>  	}
>  
>  fail_map:
> -	/* Map input RID to output RID unchanged on mapping failure*/
> -	if (rid_out)
> -		*rid_out = rid_in;
> +	/* Map input ID to output ID unchanged on mapping failure */
> +	if (id_out)
> +		*id_out = id_in;
>  
>  	return NULL;
>  }
> @@ -439,7 +439,7 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
>  	if (!node)
>  		return req_id;
>  
> -	iort_node_map_rid(node, req_id, &dev_id, IORT_MSI_TYPE);
> +	iort_node_map_id(node, req_id, &dev_id, IORT_MSI_TYPE);
>  	return dev_id;
>  }
>  
> @@ -462,7 +462,7 @@ static int iort_dev_find_its_id(struct device *dev, u32 req_id,
>  	if (!node)
>  		return -ENXIO;
>  
> -	node = iort_node_map_rid(node, req_id, NULL, IORT_MSI_TYPE);
> +	node = iort_node_map_id(node, req_id, NULL, IORT_MSI_TYPE);
>  	if (!node)
>  		return -ENXIO;
>  
> @@ -591,8 +591,8 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
>  		if (!node)
>  			return NULL;
>  
> -		parent = iort_node_map_rid(node, rid, &streamid,
> -					   IORT_IOMMU_TYPE);
> +		parent = iort_node_map_id(node, rid, &streamid,
> +					  IORT_IOMMU_TYPE);
>  
>  		ops = iort_iommu_xlate(dev, parent, streamid);
>  
> -- 
> 1.9.1
> 

^ permalink raw reply

* [RFC] Kernel panic down to swiotlb when doing insmod a simple driver
From: Robin Murphy @ 2017-01-13 11:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-aaGuHmshi=aiexUD=dxuia7tHKm3LQt3RG-7D_3v9Mw@mail.gmail.com>

On 13/01/17 11:25, Ard Biesheuvel wrote:
> On 13 January 2017 at 11:03, Robin Murphy <robin.murphy@arm.com> wrote:
>> On 13/01/17 10:00, Shawn Lin wrote:
>>> Hi,
>>>
>>> Sorry for sending this RFC for help as I couldn't find some useful hint
>>> to slove my issue by git-log the swiotlb commit from kernel v4.4 to
>>> v4.9 and I'm also not familar with these stuff. So could you kindly
>>> point me to the right direction to debug it? Thanks. :)
>>>
>>> --------------------------------------
>>> We just have a very simple wifi driver *built as ko module* which only
>>> have a probe function to do the basic init work and call SDIO API to
>>> transfer some bytes.
>>>
>>> Env: kernel 4.4 stable tree, ARM64(rk3399)
>>>
>>> Two cases are included:
>>
>> And they are both wrong :)
>>
>>> The crash case:
>>>
>>> u8 __aligned(32) buf[PAGE_SIZE]; //global here in ko driver file
>>
>> It is only valid to do DMA from linear map addresses - I'm not sure if
>> the modules area was in the linear map before, but either way it
>> probably isn't now (Ard, Mark?). Either way, I don't believe static data
>> honours ARCH_DMA_MINALIGN in general, so it's still highly inadvisable.
>>
> 
> The __aligned() modifier should work fine: the alignment is propagated
> to the ELF section alignment, which in turn is honoured by the module
> loader. The problem is that '32' is too low for non-coherent DMA to be
> safe. In general, alignments up to 4 KB should work everywhere.

Does that alignment also implicitly apply to the size, though? In other
words, given:

static int X
static int __aligned(32) Y;
static int Z;

is it guaranteed that if, say, X gets placed at .data + 0, so Y goes to
.data + 32, then Z *cannot* be placed at .data + 36?

Robin.

> I am surprised though that this ever  worked as a module, given that
> modules are (and have always been) loaded in the vmalloc area, which
> means VA to PA translations performed in the DMA layer on the
> addresses of statically allocated buffers are unlikely to return
> correct values (as your panic log proves)
> 
>>> static int wifi_probe(struct sdio_func *func, const struct
>>> sdio_device_id *id)
>>> {
>>>   // prepare some SDIO work before
>>>   printk("wifi_probe: buf = 0x%x\n", buf);
>>>   sdio_memcpy_toio(func, 0, buf, 200);
>>> }
>>>
>>> The workable case:
>>>
>>> static int wifi_probe(struct sdio_func *func, const struct
>>> sdio_device_id *id)
>>> {
>>>
>>>    u8 __aligned(32) buf[PAGE_SIZE]; //move inside the probe function
>>
>> No. DMA from the stack is right out, both for the aforementioned
>> alignment reasons, and the fact that we now have (or will have)
>> virtually-mapped stacks. One of the benefits of the latter is that it
>> catches bugs like this ;)
>>
> 
> Actually, aligned stack variables also work fine. But DMA involving
> the stack is not, so that is not really relevant.
> 
>> Get your buffer from kmalloc() or a page allocation, and everything
>> should be correct.
>>
> 
> Agreed.
> 

^ permalink raw reply

* [PATCH] arm64: defconfig: disable CONFIG_DEVMEM
From: Will Deacon @ 2017-01-13 11:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170113113734.16524-1-leif.lindholm@linaro.org>

On Fri, Jan 13, 2017 at 11:37:34AM +0000, Leif Lindholm wrote:
> /dev/mem is the opposite of what an operating system is for.
> Additionally, on arm* it opens up for denial-of-service attacks from
> userspace. So leave it disabled by default, requiring people who need
> it to enable it explicitly.

I really like the idea, but are we sure that nothing common breaks without
this? For example, does Debian still boot nicely with this patch applied?

Just trying to get a feel for how much userspace this has seen (particularly
on ACPI-based systems, which I seem to remember like poking about in here).

Will

^ permalink raw reply

* [RFC] Kernel panic down to swiotlb when doing insmod a simple driver
From: Ard Biesheuvel @ 2017-01-13 11:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <bf4b1861-7190-c888-b9be-646e2a2297bb@arm.com>

On 13 January 2017 at 11:47, Robin Murphy <robin.murphy@arm.com> wrote:
> On 13/01/17 11:25, Ard Biesheuvel wrote:
>> On 13 January 2017 at 11:03, Robin Murphy <robin.murphy@arm.com> wrote:
>>> On 13/01/17 10:00, Shawn Lin wrote:
>>>> Hi,
>>>>
>>>> Sorry for sending this RFC for help as I couldn't find some useful hint
>>>> to slove my issue by git-log the swiotlb commit from kernel v4.4 to
>>>> v4.9 and I'm also not familar with these stuff. So could you kindly
>>>> point me to the right direction to debug it? Thanks. :)
>>>>
>>>> --------------------------------------
>>>> We just have a very simple wifi driver *built as ko module* which only
>>>> have a probe function to do the basic init work and call SDIO API to
>>>> transfer some bytes.
>>>>
>>>> Env: kernel 4.4 stable tree, ARM64(rk3399)
>>>>
>>>> Two cases are included:
>>>
>>> And they are both wrong :)
>>>
>>>> The crash case:
>>>>
>>>> u8 __aligned(32) buf[PAGE_SIZE]; //global here in ko driver file
>>>
>>> It is only valid to do DMA from linear map addresses - I'm not sure if
>>> the modules area was in the linear map before, but either way it
>>> probably isn't now (Ard, Mark?). Either way, I don't believe static data
>>> honours ARCH_DMA_MINALIGN in general, so it's still highly inadvisable.
>>>
>>
>> The __aligned() modifier should work fine: the alignment is propagated
>> to the ELF section alignment, which in turn is honoured by the module
>> loader. The problem is that '32' is too low for non-coherent DMA to be
>> safe. In general, alignments up to 4 KB should work everywhere.
>
> Does that alignment also implicitly apply to the size, though? In other
> words, given:
>
> static int X
> static int __aligned(32) Y;
> static int Z;
>
> is it guaranteed that if, say, X gets placed at .data + 0, so Y goes to
> .data + 32, then Z *cannot* be placed at .data + 36?
>

I'm not sure if I understand the question: why would it be incorrect
for Z to be placed at .data + 36?

^ permalink raw reply

* [RFC] Kernel panic down to swiotlb when doing insmod a simple driver
From: Robin Murphy @ 2017-01-13 11:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_5QC4=9SmyBWTZaQUcsJudKB=2g5Bs=MVyRPUGtWPJ4w@mail.gmail.com>

On 13/01/17 11:49, Ard Biesheuvel wrote:
> On 13 January 2017 at 11:47, Robin Murphy <robin.murphy@arm.com> wrote:
>> On 13/01/17 11:25, Ard Biesheuvel wrote:
>>> On 13 January 2017 at 11:03, Robin Murphy <robin.murphy@arm.com> wrote:
>>>> On 13/01/17 10:00, Shawn Lin wrote:
>>>>> Hi,
>>>>>
>>>>> Sorry for sending this RFC for help as I couldn't find some useful hint
>>>>> to slove my issue by git-log the swiotlb commit from kernel v4.4 to
>>>>> v4.9 and I'm also not familar with these stuff. So could you kindly
>>>>> point me to the right direction to debug it? Thanks. :)
>>>>>
>>>>> --------------------------------------
>>>>> We just have a very simple wifi driver *built as ko module* which only
>>>>> have a probe function to do the basic init work and call SDIO API to
>>>>> transfer some bytes.
>>>>>
>>>>> Env: kernel 4.4 stable tree, ARM64(rk3399)
>>>>>
>>>>> Two cases are included:
>>>>
>>>> And they are both wrong :)
>>>>
>>>>> The crash case:
>>>>>
>>>>> u8 __aligned(32) buf[PAGE_SIZE]; //global here in ko driver file
>>>>
>>>> It is only valid to do DMA from linear map addresses - I'm not sure if
>>>> the modules area was in the linear map before, but either way it
>>>> probably isn't now (Ard, Mark?). Either way, I don't believe static data
>>>> honours ARCH_DMA_MINALIGN in general, so it's still highly inadvisable.
>>>>
>>>
>>> The __aligned() modifier should work fine: the alignment is propagated
>>> to the ELF section alignment, which in turn is honoured by the module
>>> loader. The problem is that '32' is too low for non-coherent DMA to be
>>> safe. In general, alignments up to 4 KB should work everywhere.
>>
>> Does that alignment also implicitly apply to the size, though? In other
>> words, given:
>>
>> static int X
>> static int __aligned(32) Y;
>> static int Z;
>>
>> is it guaranteed that if, say, X gets placed at .data + 0, so Y goes to
>> .data + 32, then Z *cannot* be placed at .data + 36?
>>
> 
> I'm not sure if I understand the question: why would it be incorrect
> for Z to be placed at .data + 36?

Because they'd then wind up in the same cache line, so non-coherent DMA
to Y will result in concurrent CPU updates to Z being lost/corrupted.
ARCH_DMA_MINALIGN isn't about alignemnt per se, it's about keeping
things in distinct cache writeback granules.

Robin.

^ permalink raw reply

* [RFC] Kernel panic down to swiotlb when doing insmod a simple driver
From: Ard Biesheuvel @ 2017-01-13 11:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <039058a7-9e5a-d931-5bec-f0f3ccc86cf3@arm.com>

On 13 January 2017 at 11:52, Robin Murphy <robin.murphy@arm.com> wrote:
> On 13/01/17 11:49, Ard Biesheuvel wrote:
>> On 13 January 2017 at 11:47, Robin Murphy <robin.murphy@arm.com> wrote:
>>> On 13/01/17 11:25, Ard Biesheuvel wrote:
>>>> On 13 January 2017 at 11:03, Robin Murphy <robin.murphy@arm.com> wrote:
>>>>> On 13/01/17 10:00, Shawn Lin wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Sorry for sending this RFC for help as I couldn't find some useful hint
>>>>>> to slove my issue by git-log the swiotlb commit from kernel v4.4 to
>>>>>> v4.9 and I'm also not familar with these stuff. So could you kindly
>>>>>> point me to the right direction to debug it? Thanks. :)
>>>>>>
>>>>>> --------------------------------------
>>>>>> We just have a very simple wifi driver *built as ko module* which only
>>>>>> have a probe function to do the basic init work and call SDIO API to
>>>>>> transfer some bytes.
>>>>>>
>>>>>> Env: kernel 4.4 stable tree, ARM64(rk3399)
>>>>>>
>>>>>> Two cases are included:
>>>>>
>>>>> And they are both wrong :)
>>>>>
>>>>>> The crash case:
>>>>>>
>>>>>> u8 __aligned(32) buf[PAGE_SIZE]; //global here in ko driver file
>>>>>
>>>>> It is only valid to do DMA from linear map addresses - I'm not sure if
>>>>> the modules area was in the linear map before, but either way it
>>>>> probably isn't now (Ard, Mark?). Either way, I don't believe static data
>>>>> honours ARCH_DMA_MINALIGN in general, so it's still highly inadvisable.
>>>>>
>>>>
>>>> The __aligned() modifier should work fine: the alignment is propagated
>>>> to the ELF section alignment, which in turn is honoured by the module
>>>> loader. The problem is that '32' is too low for non-coherent DMA to be
>>>> safe. In general, alignments up to 4 KB should work everywhere.
>>>
>>> Does that alignment also implicitly apply to the size, though? In other
>>> words, given:
>>>
>>> static int X
>>> static int __aligned(32) Y;
>>> static int Z;
>>>
>>> is it guaranteed that if, say, X gets placed at .data + 0, so Y goes to
>>> .data + 32, then Z *cannot* be placed at .data + 36?
>>>
>>
>> I'm not sure if I understand the question: why would it be incorrect
>> for Z to be placed at .data + 36?
>
> Because they'd then wind up in the same cache line, so non-coherent DMA
> to Y will result in concurrent CPU updates to Z being lost/corrupted.
> ARCH_DMA_MINALIGN isn't about alignemnt per se, it's about keeping
> things in distinct cache writeback granules.
>

I understand that. But the original code did

 u8 __aligned(32) buf[PAGE_SIZE]; //global here in ko driver file

so there the size is guaranteed to be a multiple of the CWG

So to answer your question: no, the compiler will not round up the
size of the allocation to the alignment, it will only align the start.

^ permalink raw reply

* [PATCH v3 01/24] [media] dt-bindings: Add bindings for i.MX media driver
From: Philipp Zabel @ 2017-01-13 11:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1483755102-24785-2-git-send-email-steve_longerbeam@mentor.com>

Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> Add bindings documentation for the i.MX media driver.
> 
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
>  Documentation/devicetree/bindings/media/imx.txt | 57 +++++++++++++++++++++++++
>  1 file changed, 57 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/imx.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/imx.txt b/Documentation/devicetree/bindings/media/imx.txt
> new file mode 100644
> index 0000000..254b64a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx.txt
> @@ -0,0 +1,57 @@
> +Freescale i.MX Media Video Devices
> +
> +Video Media Controller node
> +---------------------------
> +
> +This is the parent media controller node for video capture support.
> +
> +Required properties:
> +- compatible : "fsl,imx-media";

Would you be opposed to calling this "capture-subsystem" instead of
"imx-media"? We already use "fsl,imx-display-subsystem" and
"fsl,imx-gpu-subsystem" for the display and GPU compound devices.

> +- ports      : Should contain a list of phandles pointing to camera
> +  	       sensor interface ports of IPU devices
> +
> +
> +fim child node
> +--------------
> +
> +This is an optional child node of the ipu_csi port nodes. If present and
> +available, it enables the Frame Interval Monitor. Its properties can be
> +used to modify the method in which the FIM measures frame intervals.
> +Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
> +Frame Interval Monitor.
> +
> +Optional properties:
> +- fsl,input-capture-channel: an input capture channel and channel flags,
> +			     specified as <chan flags>. The channel number
> +			     must be 0 or 1. The flags can be
> +			     IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
> +			     IRQ_TYPE_EDGE_BOTH, and specify which input
> +			     capture signal edge will trigger the input
> +			     capture event. If an input capture channel is
> +			     specified, the FIM will use this method to
> +			     measure frame intervals instead of via the EOF
> +			     interrupt. The input capture method is much
> +			     preferred over EOF as it is not subject to
> +			     interrupt latency errors. However it requires
> +			     routing the VSYNC or FIELD output signals of
> +			     the camera sensor to one of the i.MX input
> +			     capture pads (SD1_DAT0, SD1_DAT1), which also
> +			     gives up support for SD1.

This is a clever method to get better frame timestamps. Too bad about
the routing requirements. Can this be used on Nitrogen6X?

> +
> +mipi_csi2 node
> +--------------
> +
> +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
> +CSI-2 sensors.
> +
> +Required properties:
> +- compatible	: "fsl,imx6-mipi-csi2";

I think this should get an additional "snps,dw-mipi-csi2" compatible,
since the only i.MX6 specific part is the bolted-on IPU2CSI gasket.

> +- reg           : physical base address and length of the register set;
> +- clocks	: the MIPI CSI-2 receiver requires three clocks: hsi_tx
> +                  (the DPHY clock), video_27m, and eim_sel;

Note that hsi_tx is incorrectly named. CCGR3[CG8] just happens to be the
shared gate bit that gates the HSI clocks as well as the MIPI
"ac_clk_125m", "cfg_clk", "ips_clk", and "pll_refclk" inputs to the mipi
csi-2 core, but we are missing shared gate clocks in the clock tree for
these.
Both cfg_clk and pll_refclk are sourced from video_27m, so "cfg" ->
video_27m seems fine.
But I don't get "dphy". Which input clock would that correspond to?
"pll_refclk?"
Also the pixel clock input is a gate after aclk_podf (which we call
eim_podf), not aclk_sel (eim_sel).

> +- clock-names	: must contain "dphy", "cfg", "pix";
> +
> +Optional properties:
> +- interrupts	: must contain two level-triggered interrupts,
> +                  in order: 100 and 101;

regards
Philipp

^ permalink raw reply

* [PATCH v3 02/24] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
From: Philipp Zabel @ 2017-01-13 11:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1483755102-24785-3-git-send-email-steve_longerbeam@mentor.com>

Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> Add to the MIPI CSI2 receiver node: compatible string, interrupt sources,
> clocks.
> 
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
>  arch/arm/boot/dts/imx6qdl.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 53e6e63..42926e9 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -1125,7 +1125,14 @@
>  			};
>  
>  			mipi_csi: mipi at 021dc000 {
> +				compatible = "fsl,imx6-mipi-csi2";
>  				reg = <0x021dc000 0x4000>;
> +				interrupts = <0 100 0x04>, <0 101 0x04>;
> +				clocks = <&clks IMX6QDL_CLK_HSI_TX>,
> +					 <&clks IMX6QDL_CLK_VIDEO_27M>,
> +					 <&clks IMX6QDL_CLK_EIM_SEL>;

I think the latter should be EIM_PODF

> +				clock-names = "dphy", "cfg", "pix";

and I'm not sure dphy is the right name for this one. Is that the pll
ref input?

> +				status = "disabled";
>  			};
>  
>  			mipi_dsi: mipi at 021e0000 {

regards
Philipp

^ permalink raw reply

* [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS
From: Geert Uytterhoeven @ 2017-01-13 11:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <d336ef3b-4fe6-5ebb-9fed-071fa79028df@arm.com>

Hi Robin,

On Fri, Jan 13, 2017 at 12:32 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 13/01/17 11:07, Geert Uytterhoeven wrote:
>> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code.
>> This allows to allocate physically contiguous DMA buffers on arm64
>> systems with an IOMMU.
>
> Can anyone explain what this attribute is actually used for? I've never
> quite figured it out.

My understanding is that DMA_ATTR_FORCE_CONTIGUOUS is needed when using
an IOMMU but wanting the buffers to be both contiguous in IOVA space and
physically contiguous to allow passing to devices without IOMMU.

Main users are graphic and remote processors.

>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c

>> @@ -265,6 +272,20 @@ static struct page **__iommu_dma_alloc_pages(unsigned int count,
>>       /* IOMMU can map any pages, so himem can also be used here */
>>       gfp |= __GFP_NOWARN | __GFP_HIGHMEM;
>>
>> +     if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
>> +             int order = get_order(count << PAGE_SHIFT);
>> +             struct page *page;
>> +
>> +             page = dma_alloc_from_contiguous(dev, count, order);
>> +             if (!page)
>> +                     return NULL;
>> +
>> +             while (count--)
>> +                     pages[i++] = page++;
>> +
>> +             return pages;
>> +     }
>> +
>
> This is really yuck. Plus it's entirely pointless to go through the
> whole page array/scatterlist dance when we know the buffer is going to
> be physically contiguous - it should just be allocate, map, done. I'd
> much rather see standalone iommu_dma_{alloc,free}_contiguous()
> functions, and let the arch code handle dispatching appropriately.

Fair enough.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* [PATCH v3 05/24] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround
From: Philipp Zabel @ 2017-01-13 11:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1483755102-24785-6-git-send-email-steve_longerbeam@mentor.com>

Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> There is a pin conflict with GPIO_6. This pin functions as a power
> input pin to the OV5642 camera sensor, but ENET uses it as the h/w
> workaround for erratum ERR006687, to wake-up the ARM cores on normal
> RX and TX packet done events. So we need to remove the h/w workaround
> to support the OV5642. The result is that the CPUidle driver will no
> longer allow entering the deep idle states on the sabrelite.
> 
> This is a partial revert of
> 
> commit 6261c4c8f13e ("ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC
> 			interrupt.")
> commit a28eeb43ee57 ("ARM: dts: imx6: tag boards that have the HW workaround
> 			for ERR006687")
> 
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>

Pity this has to be removed for all, Nitrogen6X should really use DT
overlays for the add-on boards / cameras.

regards
Philipp

^ permalink raw reply

* [PATCH] KVM: arm64: Increase number of memslots to 512
From: Marc Zyngier @ 2017-01-13 12:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1484153537-20984-1-git-send-email-linucherian@gmail.com>

Hi Linu,

On 11/01/17 16:52, linucherian at gmail.com wrote:
> From: Linu Cherian <linu.cherian@cavium.com>
> 
> Having only 32 memslots is a real constraint for the maximum number of
> PCI devices that can be assigned to a single guest. Assuming each PCI
> device/virtual function having two memory BAR regions, we could assign
> only 15 devices/virtual functions to a guest.
> 
> So increase KVM_MEM_SLOTS_NUM to 512 as done in other archs like x86 and
> powerpc. For this, KVM_USER_MEM_SLOTS has been changed to 508.
> 
> Signed-off-by: Linu Cherian <linu.cherian@cavium.com>
> ---
>  arch/arm/kvm/arm.c                | 3 +++
>  arch/arm64/include/asm/kvm_host.h | 2 +-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 8f92efa..a19389b 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -221,6 +221,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>  	case KVM_CAP_MAX_VCPUS:
>  		r = KVM_MAX_VCPUS;
>  		break;
> +	case KVM_CAP_NR_MEMSLOTS:
> +		r = KVM_USER_MEM_SLOTS;
> +		break;
>  	case KVM_CAP_MSI_DEVID:
>  		if (!kvm)
>  			r = -EINVAL;
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index e505038..88f017d 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -30,7 +30,7 @@
>  
>  #define __KVM_HAVE_ARCH_INTC_INITIALIZED
>  
> -#define KVM_USER_MEM_SLOTS 32
> +#define KVM_USER_MEM_SLOTS 508
>  #define KVM_PRIVATE_MEM_SLOTS 4
>  #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
>  #define KVM_HALT_POLL_NS_DEFAULT 500000
> 

I'm not opposed to that patch, but if I may ask: how has that been tested?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply

* [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
From: Philipp Zabel @ 2017-01-13 12:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1483755102-24785-7-git-send-email-steve_longerbeam@mentor.com>

Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
> Both hang off the same i2c2 bus, so they require different (and non-
> default) i2c slave addresses.
> 
> The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
> 
> The OV5640 connects to the input port on the MIPI CSI-2 receiver on
> mipi_csi. It is set to transmit over MIPI virtual channel 1.
> 
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
>  arch/arm/boot/dts/imx6dl-sabrelite.dts   |   5 ++
>  arch/arm/boot/dts/imx6q-sabrelite.dts    |   6 ++
>  arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 118 +++++++++++++++++++++++++++++++
>  3 files changed, 129 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6dl-sabrelite.dts b/arch/arm/boot/dts/imx6dl-sabrelite.dts
> index 0f06ca5..fec2524 100644
> --- a/arch/arm/boot/dts/imx6dl-sabrelite.dts
> +++ b/arch/arm/boot/dts/imx6dl-sabrelite.dts
> @@ -48,3 +48,8 @@
>  	model = "Freescale i.MX6 DualLite SABRE Lite Board";
>  	compatible = "fsl,imx6dl-sabrelite", "fsl,imx6dl";
>  };
> +
> +&ipu1_csi1_from_ipu1_csi1_mux {
> +	data-lanes = <0 1>;
> +	clock-lanes = <2>;
> +};
> diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts b/arch/arm/boot/dts/imx6q-sabrelite.dts
> index 66d10d8..9e2d26d 100644
> --- a/arch/arm/boot/dts/imx6q-sabrelite.dts
> +++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
> @@ -52,3 +52,9 @@
>  &sata {
>  	status = "okay";
>  };
> +
> +&ipu1_csi1_from_mipi_vc1 {
> +	data-lanes = <0 1>;
> +	clock-lanes = <2>;
> +};
> +
> diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> index 795b5a5..bca9fed 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> @@ -39,6 +39,8 @@
>   *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>   *     OTHER DEALINGS IN THE SOFTWARE.
>   */
> +
> +#include <dt-bindings/clock/imx6qdl-clock.h>
>  #include <dt-bindings/gpio/gpio.h>
>  #include <dt-bindings/input/input.h>
>  
> @@ -96,6 +98,15 @@
>  		};
>  	};
>  
> +	mipi_xclk: mipi_xclk {
> +		compatible = "pwm-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <22000000>;
> +		clock-output-names = "mipi_pwm3";
> +		pwms = <&pwm3 0 45>; /* 1 / 45 ns = 22 MHz */
> +		status = "okay";
> +	};
> +
>  	gpio-keys {
>  		compatible = "gpio-keys";
>  		pinctrl-names = "default";
> @@ -220,6 +231,22 @@
>  	};
>  };
>  
> +&ipu1_csi0_from_ipu1_csi0_mux {
> +	bus-width = <8>;
> +	data-shift = <12>; /* Lines 19:12 used */
> +	hsync-active = <1>;
> +	vync-active = <1>;
> +};
> +
> +&ipu1_csi0_mux_from_parallel_sensor {
> +	remote-endpoint = <&ov5642_to_ipu1_csi0_mux>;
> +};
> +
> +&ipu1_csi0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ipu1_csi0>;
> +};
> +
>  &audmux {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_audmux>;
> @@ -299,6 +326,52 @@
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_i2c2>;
>  	status = "okay";
> +
> +	ov5640: camera at 40 {
> +		compatible = "ovti,ov5640";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_ov5640>;
> +		clocks = <&mipi_xclk>;
> +		clock-names = "xclk";
> +		reg = <0x40>;
> +		xclk = <22000000>;

This is superfluous, you can use clk_get_rate on mipi_xclk.

> +		reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; /* NANDF_D5 */
> +		pwdn-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>; /* NANDF_WP_B */
> +
> +		port {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			ov5640_to_mipi_csi: endpoint at 1 {
> +				reg = <1>;
> +				remote-endpoint = <&mipi_csi_from_mipi_sensor>;
> +				data-lanes = <0 1>;
> +				clock-lanes = <2>;
> +			};
> +		};
> +	};
> +
> +	ov5642: camera at 42 {
> +		compatible = "ovti,ov5642";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_ov5642>;
> +		clocks = <&clks IMX6QDL_CLK_CKO2>;
> +		clock-names = "xclk";
> +		reg = <0x42>;
> +		xclk = <24000000>;

Same here, use assigned-clock-rates on IMX6QDL_CLK_CKO2 if necessary.

> +		reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
> +		pwdn-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
> +		gp-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
> +
> +		port {
> +			ov5642_to_ipu1_csi0_mux: endpoint {
> +				remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
> +				bus-width = <8>;
> +				hsync-active = <1>;
> +				vsync-active = <1>;
> +			};
> +		};
> +	};
>  };
>  
>  &i2c3 {
> @@ -412,6 +485,23 @@
>  			>;
>  		};
>  
> +		pinctrl_ipu1_csi0: ipu1csi0grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12    0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13    0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14    0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15    0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16    0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17    0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18    0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19    0x1b0b0
> +				MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK   0x1b0b0
> +				MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC      0x1b0b0
> +				MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC     0x1b0b0
> +				MX6QDL_PAD_CSI0_DATA_EN__IPU1_CSI0_DATA_EN 0x1b0b0
> +			>;
> +		};
> +
>  		pinctrl_j15: j15grp {
>  			fsl,pins = <
>  				MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10
> @@ -445,6 +535,22 @@
>  			>;
>  		};
>  
> +		pinctrl_ov5640: ov5640grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_NANDF_D5__GPIO2_IO05   0x000b0
> +				MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09 0x0b0b0
> +			>;
> +		};
> +
> +		pinctrl_ov5642: ov5642grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD1_DAT0__GPIO1_IO16 0x1b0b0
> +				MX6QDL_PAD_GPIO_6__GPIO1_IO06   0x1b0b0
> +				MX6QDL_PAD_GPIO_8__GPIO1_IO08   0x130b0
> +				MX6QDL_PAD_GPIO_3__CCM_CLKO2    0x000b0
> +			>;
> +		};
> +
>  		pinctrl_pwm1: pwm1grp {
>  			fsl,pins = <
>  				MX6QDL_PAD_SD1_DAT3__PWM1_OUT 0x1b0b1
> @@ -601,3 +707,15 @@
>  	vmmc-supply = <&reg_3p3v>;
>  	status = "okay";
>  };
> +
> +&mipi_csi {
> +        status = "okay";
> +};
> +
> +/* Incoming port from sensor */
> +&mipi_csi_from_mipi_sensor {
> +        remote-endpoint = <&ov5640_to_mipi_csi>;
> +        data-lanes = <0 1>;
> +        clock-lanes = <2>;
> +};
> +

regards
Philipp

^ permalink raw reply

* [RESEND] spi: davinci: Allow device tree devices to use DMA
From: Mark Brown @ 2017-01-13 12:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <m24m146jzh.fsf@baylibre.com>

On Thu, Jan 12, 2017 at 01:34:10PM -0800, Kevin Hilman wrote:

> I thinks this driver needs an update to use spi_map_buf() to be able to
> handle vmalloc'd buffers before always enabling DMA.

Right.  As I said elsewhere in the thread the driver looks like it needs
some very serious TLC based on a quick scan through.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170113/c376e85e/attachment-0001.sig>

^ permalink raw reply

* [PATCH v3] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: Sekhar Nori @ 2017-01-13 12:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1484253167-27568-1-git-send-email-david@lechnology.com>

On Friday 13 January 2017 02:02 AM, David Lechner wrote:
> This adds a device tree definition file for LEGO MINDSTORMS EV3.
> 
> What is working:
> 
> * Pin muxing
> * Pinconf
> * GPIOs
> * MicroSD card reader
> * UART on input port 1
> * Buttons
> * LEDs
> * Poweroff/reset
> * Flash memory
> * EEPROM
> * USB host port
> * USB peripheral port
> 
> What is not working/to be added later:
> 
> * Speaker - have patch submitted to get pwm-beeper working - maybe someday
>   it will have a real sound driver that uses PRU
> * A/DC chip - have driver submitted and accepted - waiting for ack on
>   device tree bindings
> * Display - waiting for "simple DRM" to be mainlined
> * Bluetooth - needs new driver for sequencing power/enable/clock
> * Input and output ports - need some sort of new phy or extcon driver as
>   well as PRU UART and PRU I2C drivers
> * Battery indication - needs new power supply driver
> 
> Note on flash partitions:
> 
> These partitions are based on the official EV3 firmware from LEGO. It is
> expected that most users of the mainline kernel on EV3 will be booting from
> an SD card while retaining the official firmware in the flash memory.
> Furthermore, the official firmware uses an ancient U-Boot (2009) that has
> no device tree support. So, it makes sense to have this partition table in
> the EV3 device tree file. In the unlikely case that anyone does create their
> own firmware image with different partitioning, they can use a modern
> U-Boot in their own firmware image that modifies the device tree with the
> custom partitions.
> 
> Signed-off-by: David Lechner <david@lechnology.com>

There are couple of checkpatch errors that show up. The compatible
"lego,ev3" needs to be documented in
Documentation/devicetree/bindings/arm/davinci.txt

"at24,24c128" is undocumented. Is that an atmel chip on the EV3? If the
manufacturer name is not clear,
Documentation/devicetree/bindings/eeprom/eeprom.txt advises using just
"24c128"

Finally, lego needs to be added to
Documentation/devicetree/bindings/vendor-prefixes.txt

Can you please submit the documentation portions as separate patches in
a series along with this patch.

Thanks,
Sekhar

^ permalink raw reply

* [RFC] Kernel panic down to swiotlb when doing insmod a simple driver
From: Robin Murphy @ 2017-01-13 12:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9PX17PKR7qAgmh1nryTdpnUOErVZGbXKEFPE46=gf-yw@mail.gmail.com>

On 13/01/17 11:54, Ard Biesheuvel wrote:
> On 13 January 2017 at 11:52, Robin Murphy <robin.murphy@arm.com> wrote:
>> On 13/01/17 11:49, Ard Biesheuvel wrote:
>>> On 13 January 2017 at 11:47, Robin Murphy <robin.murphy@arm.com> wrote:
>>>> On 13/01/17 11:25, Ard Biesheuvel wrote:
>>>>> On 13 January 2017 at 11:03, Robin Murphy <robin.murphy@arm.com> wrote:
>>>>>> On 13/01/17 10:00, Shawn Lin wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Sorry for sending this RFC for help as I couldn't find some useful hint
>>>>>>> to slove my issue by git-log the swiotlb commit from kernel v4.4 to
>>>>>>> v4.9 and I'm also not familar with these stuff. So could you kindly
>>>>>>> point me to the right direction to debug it? Thanks. :)
>>>>>>>
>>>>>>> --------------------------------------
>>>>>>> We just have a very simple wifi driver *built as ko module* which only
>>>>>>> have a probe function to do the basic init work and call SDIO API to
>>>>>>> transfer some bytes.
>>>>>>>
>>>>>>> Env: kernel 4.4 stable tree, ARM64(rk3399)
>>>>>>>
>>>>>>> Two cases are included:
>>>>>>
>>>>>> And they are both wrong :)
>>>>>>
>>>>>>> The crash case:
>>>>>>>
>>>>>>> u8 __aligned(32) buf[PAGE_SIZE]; //global here in ko driver file
>>>>>>
>>>>>> It is only valid to do DMA from linear map addresses - I'm not sure if
>>>>>> the modules area was in the linear map before, but either way it
>>>>>> probably isn't now (Ard, Mark?). Either way, I don't believe static data
>>>>>> honours ARCH_DMA_MINALIGN in general, so it's still highly inadvisable.
>>>>>>
>>>>>
>>>>> The __aligned() modifier should work fine: the alignment is propagated
>>>>> to the ELF section alignment, which in turn is honoured by the module
>>>>> loader. The problem is that '32' is too low for non-coherent DMA to be
>>>>> safe. In general, alignments up to 4 KB should work everywhere.
>>>>
>>>> Does that alignment also implicitly apply to the size, though? In other
>>>> words, given:
>>>>
>>>> static int X
>>>> static int __aligned(32) Y;
>>>> static int Z;
>>>>
>>>> is it guaranteed that if, say, X gets placed at .data + 0, so Y goes to
>>>> .data + 32, then Z *cannot* be placed at .data + 36?
>>>>
>>>
>>> I'm not sure if I understand the question: why would it be incorrect
>>> for Z to be placed at .data + 36?
>>
>> Because they'd then wind up in the same cache line, so non-coherent DMA
>> to Y will result in concurrent CPU updates to Z being lost/corrupted.
>> ARCH_DMA_MINALIGN isn't about alignemnt per se, it's about keeping
>> things in distinct cache writeback granules.
>>
> 
> I understand that. But the original code did
> 
>  u8 __aligned(32) buf[PAGE_SIZE]; //global here in ko driver file
> 
> so there the size is guaranteed to be a multiple of the CWG
> 
> So to answer your question: no, the compiler will not round up the
> size of the allocation to the alignment, it will only align the start.

Right. I was deliberately ignoring the "you happen to get away with it
in this case because..." part because I think the "DMA to static
data/stack is not safe in general" message is important :)

Thanks for the clarification.

Robin.

^ permalink raw reply

* [PATCH v3 15/24] media: Add userspace header file for i.MX
From: Philipp Zabel @ 2017-01-13 12:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1483755102-24785-16-git-send-email-steve_longerbeam@mentor.com>

Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> This adds a header file for use by userspace programs wanting to interact
> with the i.MX media driver. It defines custom v4l2 controls and events
> generated by the i.MX v4l2 subdevices.
> 
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
>  include/uapi/media/Kbuild |  1 +
>  include/uapi/media/imx.h  | 30 ++++++++++++++++++++++++++++++
>  2 files changed, 31 insertions(+)
>  create mode 100644 include/uapi/media/imx.h
> 
> diff --git a/include/uapi/media/Kbuild b/include/uapi/media/Kbuild
> index aafaa5a..fa78958 100644
> --- a/include/uapi/media/Kbuild
> +++ b/include/uapi/media/Kbuild
> @@ -1 +1,2 @@
>  # UAPI Header export list
> +header-y += imx.h
> diff --git a/include/uapi/media/imx.h b/include/uapi/media/imx.h
> new file mode 100644
> index 0000000..2421d9c
> --- /dev/null
> +++ b/include/uapi/media/imx.h
> @@ -0,0 +1,30 @@
> +/*
> + * Copyright (c) 2014-2015 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version
> + */
> +
> +#ifndef __UAPI_MEDIA_IMX_H__
> +#define __UAPI_MEDIA_IMX_H__
> +
> +/*
> + * events from the subdevs
> + */
> +#define V4L2_EVENT_IMX_CLASS          V4L2_EVENT_PRIVATE_START
> +#define V4L2_EVENT_IMX_NFB4EOF        (V4L2_EVENT_IMX_CLASS + 1)
> +#define V4L2_EVENT_IMX_EOF_TIMEOUT    (V4L2_EVENT_IMX_CLASS + 2)
> +#define V4L2_EVENT_IMX_FRAME_INTERVAL (V4L2_EVENT_IMX_CLASS + 3)

Aren't these generic enough to warrant common events? I would think
there have to be other capture IP cores that can signal aborted frames
or frame timeouts.

> +
> +enum imx_ctrl_id {
> +	V4L2_CID_IMX_MOTION = (V4L2_CID_USER_IMX_BASE + 0),
> +	V4L2_CID_IMX_FIM_ENABLE,
> +	V4L2_CID_IMX_FIM_NUM,
> +	V4L2_CID_IMX_FIM_TOLERANCE_MIN,
> +	V4L2_CID_IMX_FIM_TOLERANCE_MAX,
> +	V4L2_CID_IMX_FIM_NUM_SKIP,
> +};
> +
> +#endif

regards
Philipp

^ permalink raw reply

* [PATCH] arm64/mm: use phys_addr_t
From: Will Deacon @ 2017-01-13 12:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170113114553.GD26804@leverpostej>

On Fri, Jan 13, 2017 at 11:45:54AM +0000, Mark Rutland wrote:
> On Fri, Jan 13, 2017 at 11:27:48AM +0000, Ard Biesheuvel wrote:
> > On 13 January 2017 at 11:22, Mark Rutland <mark.rutland@arm.com> wrote:
> > > On Fri, Jan 13, 2017 at 01:59:35PM +0800, miles.chen at mediatek.com wrote:
> > >> From: Miles Chen <miles.chen@mediatek.com>
> > >>
> > >> Use phys_addr_t instead of unsigned long for the
> > >> return value of __pa(), make code easy to understand.
> > >>
> > >> Signed-off-by: Miles Chen <miles.chen@mediatek.com>
> > >
> > > This looks sensible to me. It's consistent with the types these
> > > variables are compared against, and with the types of function
> > > parameters these are passed as.
> > >
> > 
> > Indeed. But doesn't it clash with Laura's series?
> 
> Good point.
> 
> Yes, but only for the RHS of the assignment changing. This'll need to be
> rebased atop of the arm64 for-next/core branch, or Catalin/Will might
> fix it up when applying, perhaps?

Yeah, it's dead easy for me to fix up.

Will

^ permalink raw reply

* [PATCH v7 09/15] ACPI: platform-msi: retrieve dev id from IORT
From: Lorenzo Pieralisi @ 2017-01-13 12:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1484147199-4267-10-git-send-email-hanjun.guo@linaro.org>

On Wed, Jan 11, 2017 at 11:06:33PM +0800, Hanjun Guo wrote:
> For devices connecting to ITS, it needs dev id to identify itself, and
> this dev id is represented in the IORT table in named component node
> [1] for platform devices, so in this patch we will scan the IORT to
> retrieve device's dev id.
> 
> For named components we know that there are always two steps
> involved (second optional):
> 
> (1) Retrieve the initial id (this may well provide the final mapping)
> (2) Map the id (optional if (1) represents the map type we need), this
>     is needed for use cases such as NC (named component) -> SMMU -> ITS
>     mappings.
> 
> we have API iort_node_get_id() for step (1) above and
> iort_node_map_rid() for step (2), so create a wrapper
> iort_node_map_platform_id() to retrieve the dev id.
> 
> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf

This patch should be split and IORT changes should be squashed with
patch 10.

> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Suggested-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Sinan Kaya <okaya@codeaurora.org>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
>  drivers/acpi/arm64/iort.c                     | 56 +++++++++++++++++++++++++++
>  drivers/irqchip/irq-gic-v3-its-platform-msi.c |  4 +-
>  include/linux/acpi_iort.h                     |  8 ++++
>  3 files changed, 67 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 069a690..95fd20b 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -30,6 +30,7 @@
>  #define IORT_MSI_TYPE		(1 << ACPI_IORT_NODE_ITS_GROUP)
>  #define IORT_IOMMU_TYPE		((1 << ACPI_IORT_NODE_SMMU) |	\
>  				(1 << ACPI_IORT_NODE_SMMU_V3))
> +#define IORT_TYPE_ANY		(IORT_MSI_TYPE | IORT_IOMMU_TYPE)
>  
>  struct iort_its_msi_chip {
>  	struct list_head	list;
> @@ -406,6 +407,34 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,
>  	return NULL;
>  }
>  
> +static
> +struct acpi_iort_node *iort_node_map_platform_id(struct acpi_iort_node *node,
> +						 u32 *id_out, u8 type_mask,
> +						 int index)
> +{
> +	struct acpi_iort_node *parent;
> +	u32 id;
> +
> +	/* step 1: retrieve the initial dev id */
> +	parent = iort_node_get_id(node, &id, IORT_TYPE_ANY, index);
> +	if (!parent)
> +		return NULL;
> +
> +	/*
> +	 * optional step 2: map the initial dev id if its parent is not
> +	 * the target type we wanted, map it again for the use cases such
> +	 * as NC (named component) -> SMMU -> ITS. If the type is matched,
> +	 * return the parent pointer directly.
> +	 */
> +	if (!(IORT_TYPE_MASK(parent->type) & type_mask))
> +		parent = iort_node_map_id(parent, id, id_out, type_mask);
> +	else
> +		if (id_out)

Remove this pointer check.

> +			*id_out = id;
> +
> +	return parent;
> +}
> +
>  static struct acpi_iort_node *iort_find_dev_node(struct device *dev)
>  {
>  	struct pci_bus *pbus;
> @@ -444,6 +473,33 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
>  }
>  
>  /**
> + * iort_pmsi_get_dev_id() - Get the device id for a device
> + * @dev: The device for which the mapping is to be done.
> + * @dev_id: The device ID found.
> + *
> + * Returns: 0 for successful find a dev id, errors otherwise

Nit: -ENODEV on error

> + */
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{
> +	int i;
> +	struct acpi_iort_node *node;
> +
> +	if (!iort_table)
> +		return -ENODEV;

I do not think this iort_table check is needed.

> +	node = iort_find_dev_node(dev);
> +	if (!node)
> +		return -ENODEV;
> +
> +	for (i = 0; i < node->mapping_count; i++) {
> +		if(iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i))
                  ^

Nit: Missing a space.

Lorenzo

> +			return 0;
> +	}
> +
> +	return -ENODEV;
> +}
> +
> +/**
>   * iort_dev_find_its_id() - Find the ITS identifier for a device
>   * @dev: The device.
>   * @req_id: Device's requester ID
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index ebe933e..e801fc0 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -15,6 +15,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/acpi_iort.h>
>  #include <linux/device.h>
>  #include <linux/msi.h>
>  #include <linux/of.h>
> @@ -56,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
>  
>  	msi_info = msi_get_domain_info(domain->parent);
>  
> -	ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
> +	ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) :
> +		iort_pmsi_get_dev_id(dev, &dev_id);
>  	if (ret)
>  		return ret;
>  
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 77e0809..ef99fd52 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -33,6 +33,7 @@
>  void acpi_iort_init(void);
>  bool iort_node_match(u8 type);
>  u32 iort_msi_map_rid(struct device *dev, u32 req_id);
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
>  struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
>  /* IOMMU interface */
>  void iort_set_dma_mask(struct device *dev);
> @@ -42,9 +43,16 @@ static inline void acpi_iort_init(void) { }
>  static inline bool iort_node_match(u8 type) { return false; }
>  static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
>  { return req_id; }
> +
>  static inline struct irq_domain *iort_get_device_domain(struct device *dev,
>  							u32 req_id)
>  { return NULL; }
> +
> +static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{
> +	return -ENODEV;
> +}
> +
>  /* IOMMU interface */
>  static inline void iort_set_dma_mask(struct device *dev) { }
>  static inline
> -- 
> 1.9.1
> 

^ permalink raw reply

* [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS
From: Robin Murphy @ 2017-01-13 12:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAMuHMdWBfTm_QRuB7x-ZDh0bgGmHokqm7=F2b0rjQTYzizC9hA@mail.gmail.com>

On 13/01/17 11:59, Geert Uytterhoeven wrote:
> Hi Robin,
> 
> On Fri, Jan 13, 2017 at 12:32 PM, Robin Murphy <robin.murphy@arm.com> wrote:
>> On 13/01/17 11:07, Geert Uytterhoeven wrote:
>>> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code.
>>> This allows to allocate physically contiguous DMA buffers on arm64
>>> systems with an IOMMU.
>>
>> Can anyone explain what this attribute is actually used for? I've never
>> quite figured it out.
> 
> My understanding is that DMA_ATTR_FORCE_CONTIGUOUS is needed when using
> an IOMMU but wanting the buffers to be both contiguous in IOVA space and
> physically contiguous to allow passing to devices without IOMMU.
> 
> Main users are graphic and remote processors.

Sure, I assumed it must be to do with buffer sharing, but the systems
I'm aware of which have IOMMUs in their media subsystems tend to have
them in front of every IP block involved, so I was curious as to what
bit of non-IOMMU hardware wanted to play too. The lone in-tree use in
the Exynos DRM driver was never very revealing, and the new one I see in
the Qualcomm PIL driver frankly looks redundant to me.

Robin.

>>> --- a/drivers/iommu/dma-iommu.c
>>> +++ b/drivers/iommu/dma-iommu.c
> 
>>> @@ -265,6 +272,20 @@ static struct page **__iommu_dma_alloc_pages(unsigned int count,
>>>       /* IOMMU can map any pages, so himem can also be used here */
>>>       gfp |= __GFP_NOWARN | __GFP_HIGHMEM;
>>>
>>> +     if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
>>> +             int order = get_order(count << PAGE_SHIFT);
>>> +             struct page *page;
>>> +
>>> +             page = dma_alloc_from_contiguous(dev, count, order);
>>> +             if (!page)
>>> +                     return NULL;
>>> +
>>> +             while (count--)
>>> +                     pages[i++] = page++;
>>> +
>>> +             return pages;
>>> +     }
>>> +
>>
>> This is really yuck. Plus it's entirely pointless to go through the
>> whole page array/scatterlist dance when we know the buffer is going to
>> be physically contiguous - it should just be allocate, map, done. I'd
>> much rather see standalone iommu_dma_{alloc,free}_contiguous()
>> functions, and let the arch code handle dispatching appropriately.
> 
> Fair enough.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox