Re: bcm2837: tons of DMA mask not set in 4.18.0-rc6-next-20180727

Hi Geert, On 21/08/18 16:45, Geert Uytterhoeven wrote: Hi Robin, CC Lee (mfd), Wolfram (i2c), Marek (bd9571wmv + recent da9063 hacking) On Fri, Jul 27, 2018 at 6:28 PM Robin Murphy wrote: On 27/07/18 17:17, Stefan Wahren wrote: i was noticed that recent linux-next on Raspberry Pi 3 (32 bit

Re: [PATCH/RFC] drivers/vfio: Allow type-1 IOMMU instantiation with Renesas IPMMU-VMSA

Hi Geert, On 25/07/18 14:34, Geert Uytterhoeven wrote: The Renesas IPMMU-VMSA driver is compatible with the notion of a type-1 IOMMU in VFIO. This patch allows guests to use the VFIO_IOMMU_TYPE1 API on hosts equipped with a Renesas VMSA-compatible IPMMU. Signed-off-by: Geert Uytterhoeven ---

Re: [PATCH v2] base: dma-mapping: Postpone cpu addr translation on mmap()

configured with SPARSEMEM memory model, assuming a struct page is always assigned to a memory address lead to unexpected hangs during the virtual to page address translation. This patch fixes that specific issue but applies in the general case too. Reviewed-by: Robin Murphy <robin.mur...@arm.

Re: [RFC v2 2/2] base: dma-mapping: Postpone page_to_pfn() on mmap()

Hi Jacopo, On 09/04/18 08:25, jacopo mondi wrote: Hi Robin, Laurent, a long time passed, sorry about this. On Wed, Nov 15, 2017 at 01:38:23PM +, Robin Murphy wrote: On 14/11/17 17:08, Jacopo Mondi wrote: On SH4 architecture, with SPARSEMEM memory model, translating page to pfn hangs

[PATCH v2 3/3] iommu: Clean up of_iommu_init_fn

themselves, such that it can make the right decision. Reviewed-by: Sricharan R <sricha...@codeaurora.org> Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- v2: Rebase to 4.15-rc, add tags drivers/iommu/arm-smmu-v3.c | 2 +- drivers/iommu/arm-smmu.c | 12 ++-- d

[PATCH v2 1/3] iommu/msm: Claim bus ops on probe

probed. Furthermore, this should also make the driver safe for multiplatform kernels on non-MSM SoCs. Reviewed-by: Sricharan R <sricha...@codeaurora.org> Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- v2: Rebase to 4.15-rc, add tags drivers/iommu/msm_iommu.c | 16 +++-

[PATCH v2 2/3] iommu/ipmmu-vmsa: Remove redundant of_iommu_init_fn hook

Having of_iommu_init() call ipmmu_init() via ipmmu_vmsa_iommu_of_setup() does nothing that the subsys_initcall wouldn't do slightly later anyway, since probe-deferral of masters means it is no longer critical to register the driver super-early. Clean it up. Signed-off-by: Robin Murphy <robin.

Re: [RFC v2 2/2] base: dma-mapping: Postpone page_to_pfn() on mmap()

On 14/11/17 17:08, Jacopo Mondi wrote: On SH4 architecture, with SPARSEMEM memory model, translating page to pfn hangs the CPU. Post-pone translation to pfn after dma_mmap_from_dev_coherent() function call as it succeeds and make page translation not necessary. This patch was suggested by

[PATCH 2/4] iommu/ipmmu-vmsa: Simplify group allocation

data is the perfect place to keep track of a per-instance group directly. Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- drivers/iommu/ipmmu-vmsa.c | 53 -- 1 file changed, 9 insertions(+), 44 deletions(-) diff --git a/drivers/iommu/ipmmu-vm

[PATCH 4/4] iommu/ipmmu-vmsa: Unify ipmmu_ops

and improve build coverage. Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- drivers/iommu/ipmmu-vmsa.c | 69 +- 1 file changed, 19 insertions(+), 50 deletions(-) diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index 4d69c0

[PATCH 3/4] iommu/ipmmu-vmsa: Clean up struct ipmmu_vmsa_iommu_priv

Now that the IPMMU instance pointer is the only thing remaining in the private data structure, we no longer need the extra level of indirection and can simply stash that directlty in the fwspec. Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- drivers/iommu/ipmmu-vmsa.

[PATCH 0/4] ipmmu-vmsa cleanup

in the driver that led to the oversight in the first place. Build-tested successfully for arm64, ARM, and ARM + CONFIG_IOMMU_DMA. Robin. [1]:https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1510423.html Robin Murphy (4): iommu/ipmmu-vmsa: Unify domain alloc/free iommu/ipmmu-vmsa

Re: [PATCH v4 02/09] iommu/ipmmu-vmsa: Add optional root device feature

On 19/06/17 10:14, Magnus Damm wrote: > From: Magnus Damm > > Add root device handling to the IPMMU driver by allowing certain > DT compat strings to enable has_cache_leaf_nodes that in turn will > support both root devices with interrupts and leaf devices that > face

Re: [PATCH 01/04] iommu/ipmmu-vmsa: Use iommu_device_register()/unregister()

On 15/06/17 11:29, Magnus Damm wrote: > From: Magnus Damm > > Extend the driver to make use of iommu_device_register()/unregister() > functions together with iommu_device_set_ops() and iommu_set_fwnode(). > > These used to be part of the earlier posted 64-bit ARM

Re: [PATCH 00/04] iommu/ipmmu-vmsa: 32-bit ARM update

if it does actually work as intended, feel free to take it ;) Thanks, Robin. > Suggested-by: Robin Murphy <robin.mur...@arm.com> (Patch 2 and 4) > Signed-off-by: Robin Murphy <robin.mur...@arm.com> (Patch 3) > Signed-off-by: Magnus Damm <damm+rene...@opensource.se>

Re: [PATCH v8 06/08] iommu/ipmmu-vmsa: Use fwspec iommu_priv on ARM64

ut I just can't agree with the two-drivers-in-one approach. Robin. ->8- From: Robin Murphy <robin.mur...@arm.com> Subject: [PATCH] iommu/ipmmu-vmsa: Convert to iommu_fwspec The parent IPMMU pointer and set of uTLB IDs are, as intended, a perfect fit for the generic iommu_fw

Re: [PATCH] ARM: dma-mapping: Don't tear third-party mappings

ma_ops(dev); > + set_dma_ops(dev, NULL); Should we clear dma_ops_setup here for symmetry? I guess in practice it's down to the IOMMU driver so will never change after the first probe, but it still feels like a bit of a nagging loose end. With that (or firm reassurance that it's OK not to), Reviewed-by: Robin Murphy <robin.mur...@arm.com> Apologies for being too arm64-focused in the earlier reviews and overlooking this. Should the patch supersede 8674/1 currently in Russell's incoming box? Robin. > } >

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

On 16/05/17 15:10, Laurent Pinchart wrote: > Hi Robin, > > On Tuesday 16 May 2017 15:04:55 Robin Murphy wrote: >> On 16/05/17 08:17, Laurent Pinchart wrote: >>> On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote: > > [snip] > >>>&

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

day 03 May 2017 15:54:59 Sricharan R wrote: >>>>> On 5/3/2017 3:24 PM, Robin Murphy wrote: >>>>>> On 02/05/17 19:35, Geert Uytterhoeven wrote: >>>>>>> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R wrote: >>>>>>>> From

Re: [PATCH 0/2] Fix incorrect warning from dma-debug

On 07/05/17 01:06, Jon Masters wrote: > On 05/09/2016 06:00 AM, Robin Murphy wrote: >> On 09/05/16 10:37, Robin Murphy wrote: >>> Hi Niklas, >>> >>> On 08/05/16 11:59, Niklas Söderlund wrote: >>>> Hi, >>>> >>>> While

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Geert, On 02/05/17 19:35, Geert Uytterhoeven wrote: > Hi Sricharan, > > On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R wrote: >> From: Laurent Pinchart >> >> Failures to look up an IOMMU when parsing the DT iommus property

Re: [PATCH v7 06/07] iommu/ipmmu-vmsa: ARM and ARM64 archdata access

On 09/03/17 03:44, Magnus Damm wrote: > Hi Robin, > > On Wed, Mar 8, 2017 at 9:48 PM, Robin Murphy <robin.mur...@arm.com> wrote: >> On 07/03/17 03:17, Magnus Damm wrote: >>> From: Magnus Damm <damm+rene...@opensource.se> >>> >>> Not all ar

Re: [PATCH v7 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

On 07/03/17 03:17, Magnus Damm wrote: > From: Magnus Damm > > Introduce an alternative set of iommu_ops suitable for 64-bit ARM > as well as 32-bit ARM when CONFIG_IOMMU_DMA=y. Also adjust the > Kconfig to depend on ARM or IOMMU_DMA. Initialize the device > from

Re: [PATCH v3 03/09] iommu/ipmmu-vmsa: Enable multi context support

On 08/03/17 11:01, Magnus Damm wrote: > From: Magnus Damm > > Add support for up to 8 contexts. Each context is mapped to one > domain. One domain is assigned one or more slave devices. Contexts > are allocated dynamically and slave devices are grouped together >

Re: [PATCH v3 01/09] iommu/ipmmu-vmsa: Introduce features, break out alias

Hi Magnus, On 08/03/17 11:01, Magnus Damm wrote: > From: Magnus Damm > > Introduce struct ipmmu_features to track various hardware > and software implementation changes inside the driver for > different kinds of IPMMU hardware. Add use_ns_alias_offset > as a first

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

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. I think this looks about as good as it ever could now :) Reviewed-by: Robin Murphy <robin.mur...@arm

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

d-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > --- > v3: > - Add Acked-by, > - Update comment to "one of _4_ things", > - Call dma_alloc_from_contiguous() and iommu_dma_map_page() directly, > as suggested by Robin Murphy, > > v2: > -

Re: [PATCH/RFC] arm64: defconfig: Enlarge CMA alignment to 2 MiB

On 01/02/17 13:45, Magnus Damm wrote: > Hi Geert, > > On Sat, Jan 28, 2017 at 1:03 AM, Geert Uytterhoeven > wrote: >> Some IOMMUs (e.g. Renesas IPMMU/VMSA) support only page sizes of 4 KiB, >> 2 MiB, and 1 GiB. >> >> With the default setting of CONFIG_CMA_ALIGNMENT = 8,

Re: [PATCH/RFC] iommu/dma: Per-domain flag to control size-alignment

On 30/01/17 07:20, Yoshihiro Shimoda wrote: > Hi Robin, Magnus, > >> -Original Message----- >> From: Robin Murphy >> Sent: Saturday, January 28, 2017 2:38 AM >> >> Hi Magnus, >> >> On 27/01/17 06:24, Magnus Damm wrote: >>> From: M

Re: [PATCH/RFC] iommu/dma: Per-domain flag to control size-alignment

Hi Magnus, On 27/01/17 06:24, Magnus Damm wrote: > From: Magnus Damm > > Introduce the flag "no_size_align" to allow disabling size-alignment > on a per-domain basis. This follows the suggestion by the comment > in the code, however a per-device control may be

Re: [PATCH v2 1/2] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

; > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> > --- > v2: > - Provide standalone iommu_dma_{alloc,free}_contiguous() functions, as > requested by Robin Murphy, > - Simplify operations by getting rid of the page array/scatterlist > dance, as

Re: [PATCH/RFC] iommu/ipmmu-vmsa: Restrict IOMMU Domain Geometry to 32-bit address space

MAC) rightfully configures a 40-bit DMA > mask, it will still be handed out a 40-bit IOVA, outside the 32-bit IOVA > space, leading to out-of-bounds accesses of the PGD when mapping the > IOVA. > > Force a 32-bit IOMMU Domain Geometry to fix this. Reviewed-by: Robin Murphy <ro

Re: [PATCH 0/2] Fix incorrect warning from dma-debug

On 25/01/17 16:23, Geert Uytterhoeven wrote: > Hi Robin, Hi Geert, > On Mon, May 9, 2016 at 11:37 AM, Robin Murphy <robin.mur...@arm.com> wrote: >> On 08/05/16 11:59, Niklas Söderlund wrote: >>> While using CONFIG_DMA_API_DEBUG i came across this warning which I &g

Re: [PATCH/RFC 3/4] iommu: dma: iommu iova domain reset

On 25/01/17 12:54, Yoshihiro Shimoda wrote: > From: Magnus Damm > > To add a workaround code for ipmmu-vmsa driver, this patch adds > a new geometry "force_reset_when_empty" not to reuse iova space. The domain geometry is absolutely not the appropriate place for

Re: [PATCH/RFC 1/4] iommu: dma: track mapped iova

On 25/01/17 12:53, Yoshihiro Shimoda wrote: > From: Magnus Damm > > To track mapped iova for a workaround code in the future. > > Signed-off-by: Magnus Damm > Signed-off-by: Yoshihiro Shimoda > --- >

Re: [PATCH/RFC 2/4] iommu: iova: use __alloc_percpu_gfp() with GFP_NOWAIT in init_iova_rcaches()

On 25/01/17 12:54, Yoshihiro Shimoda wrote: > In the future, the init_iova_rcaches will be called in atomic. That screams "doing the wrong thing". The sole point of the rcaches is to reuse IOVAs, whereas the main point of this series seems to involve not reusing IOVAs. The fact that we have to

Re: [PATCH/RFC 1/2] arm64: mm: Silently allow devices lacking IOMMU group

Hi Magnus, On 23/01/17 12:12, Magnus Damm wrote: > From: Magnus Damm > > Consider failure of iommu_get_domain_for_dev() as non-critical and > get rid of the warning printout. This allows IOMMU properties to be > included in the DTB even though the kernel is

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

On 13/01/17 11:59, Geert Uytterhoeven wrote: > Hi Robin, > > On Fri, Jan 13, 2017 at 12:32 PM, Robin Murphy <robin.mur...@arm.com> wrote: >> On 13/01/17 11:07, Geert Uytterhoeven wrote: >>> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA cod

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS

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

Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()

On 12/01/17 13:25, Arnd Bergmann wrote: > On Thursday, January 12, 2017 12:16:24 PM CET Will Deacon wrote: >> On Thu, Jan 12, 2017 at 08:52:51AM +0300, Nikita Yushchenko wrote: > diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c > index

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

On 11/01/17 12:37, Nikita Yushchenko wrote: >> I actually have a third variation of this problem involving a PCI root >> complex which *could* drive full-width (40-bit) addresses, but won't, >> due to the way its PCI<->AXI interface is programmed. That would require >> even more complicated

Re: [PATCH] arm64: avoid increasing DMA masks above what hardware supports

On 11/01/17 16:03, Nikita Yushchenko wrote: > > > 11.01.2017 17:50, Robin Murphy пишет: >> On 11/01/17 13:41, Nikita Yushchenko wrote: >>>> Yes, I think that ought to work, although the __iommu_setup_dma_ops() >>>> call will still want a real size re

Re: [PATCH] arm64: avoid increasing DMA masks above what hardware supports

On 11/01/17 13:41, Nikita Yushchenko wrote: >> Yes, I think that ought to work, although the __iommu_setup_dma_ops() >> call will still want a real size reflecting the default mask > > I see iommu_dma_ops do not define set_dma_mask. > > So what if setup was done for size reflecting one mask and

Re: [PATCH] arm64: Add support for DMA_ATTR_SKIP_CPU_SYNC attribute to swiotlb

" rather than "(x) == 0", but the latter is already in place, so I'll leave the final word on style/consistency nitpicks to Catalin and Will. Reviewed-by: Robin Murphy <robin.mur...@arm.com> > --- > arch/arm64/mm/dma-mapping.c | 12 > 1 file

Re: [PATCH] arm64: avoid increasing DMA masks above what hardware supports

On 11/01/17 07:59, Nikita Yushchenko wrote: >>> + /* >>> +* we don't yet support buses that have a non-zero mapping. >>> +* Let's hope we won't need it >>> +*/ >>> + WARN_ON(dma_base != 0); >> >> I believe we now accomodate the bus remap bits on BCM2837 as a DMA >> offset, so

Re: [PATCH] arm64: avoid increasing DMA masks above what hardware supports

e. > > However, swiotlb or iommu still need knowledge about actual device > capabilities. To avoid breakage, actual mask must not be set wider than > device connection allows. > > Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com> > CC: Arnd Bergmann <

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

On 10/01/17 13:42, Arnd Bergmann wrote: > On Tuesday, January 10, 2017 1:25:12 PM CET Robin Murphy wrote: >> On 10/01/17 12:47, Nikita Yushchenko wrote: >>>> The point here is that an IOMMU doesn't solve your issue, and the >>>> IOMMU-backed DMA ops

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

On 10/01/17 12:47, Nikita Yushchenko wrote: > Hi > >> The point here is that an IOMMU doesn't solve your issue, and the >> IOMMU-backed DMA ops need the same treatment. In light of that, it really >> feels to me like the DMA masks should be restricted in of_dma_configure >> so that the parent

Re: [PATCH v6 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

Hi Laurent, On 11/11/16 01:50, Laurent Pinchart wrote: > Hi Robin, > > On Friday 21 Oct 2016 18:52:53 Robin Murphy wrote: >> On 20/10/16 00:36, Magnus Damm wrote: >>> From: Magnus Damm <damm+rene...@opensource.se> >>> >>> Introduce an alte

Re: [PATCH 2/2] swiotlb: Add swiotlb=nobounce debug option

Hi Geert, On 31/10/16 15:45, Geert Uytterhoeven wrote: > On architectures like arm64, swiotlb is tied intimately to the core > architecture DMA support. In addition, ZONE_DMA cannot be disabled. To be fair, that only takes a single-character change in arch/arm64/Kconfig - in fact, I'm amused to

Re: [PATCH v6 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

On 20/10/16 00:36, Magnus Damm wrote: > From: Magnus Damm > > Introduce an alternative set of iommu_ops suitable for 64-bit ARM > as well as 32-bit ARM when CONFIG_IOMMU_DMA=y. Also adjust the > Kconfig to depend on ARM or IOMMU_DMA. > > Signed-off-by: Magnus Damm

Re: [PATCH v6 06/07] iommu/ipmmu-vmsa: ARM and ARM64 archdata access

Hi Magnus, On 20/10/16 00:36, Magnus Damm wrote: > From: Magnus Damm > > Not all architectures have an iommu member in their archdata, so > use #ifdefs support build wit COMPILE_TEST on any architecture. As an alternative to this we could now use iommu_fwspec in

Re: [PATCH/RFC] iommu/ipmmu-vmsa: Update ->add_device() return value

On 20/09/16 16:03, Magnus Damm wrote: > Hi Robin, > > Thanks for your feedback!! > > On Tue, Sep 20, 2016 at 10:18 PM, Robin Murphy <robin.mur...@arm.com> wrote: >> Hi Magnus, >> >> On 20/09/16 13:41, Magnus Damm wrote: >>> From: Magnus Damm <d

Re: [PATCH/RFC] iommu/ipmmu-vmsa: Update ->add_device() return value

Hi Magnus, On 20/09/16 13:41, Magnus Damm wrote: > From: Magnus Damm > > Update the IPMMU driver to return -ENODEV when adding devices > not hooked up a particular IPMMU instance. > > Currently the ->add_device() callback implementation in the IPMMU > driver returns

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

On 16/09/16 13:05, Laurent Pinchart wrote: [...] One concern I have is that we might get an awkward situation if we ever encounter one DMA engine hardware that is used in different systems that all have an IOMMU, but on some of them the connection between the DMA master and the

Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers

On 16/09/16 10:48, Laurent Pinchart wrote: > Hi Arnd, > > On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote: >> On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote: >>> On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote: On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas

Re: [PATCHv9 6/6] dmaengine: rcar-dmac: add iommu support for slave transfers

Hi Laurent, On 05/09/16 10:52, Laurent Pinchart wrote: > Hi Niklas, > > Thank you for the patch. > > On Wednesday 10 Aug 2016 13:22:19 Niklas Söderlund wrote: >> Enable slave transfers to a device behind a IPMMU by mapping the slave >> addresses using the dma-mapping API. >> >> Signed-off-by:

Re: [PATCHv6 2/8] dma-debug: add support for resource mappings

On 19/05/16 12:21, Niklas Söderlund wrote: Hi Konrad, Thanks for your feedback. On 2016-05-17 10:50:02 -0400, Konrad Rzeszutek Wilk wrote: +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size, + int direction, dma_addr_t dma_addr) +{ +

Re: [PATCH 0/2] Fix incorrect warning from dma-debug

On 09/05/16 10:37, Robin Murphy wrote: Hi Niklas, On 08/05/16 11:59, Niklas Söderlund wrote: Hi, While using CONFIG_DMA_API_DEBUG i came across this warning which I think is a false positive. As shown dma_sync_single_for_device() are called from the dma_map_single() call path. This triggers

Re: [PATCH 0/2] Fix incorrect warning from dma-debug

Hi Niklas, On 08/05/16 11:59, Niklas Söderlund wrote: Hi, While using CONFIG_DMA_API_DEBUG i came across this warning which I think is a false positive. As shown dma_sync_single_for_device() are called from the dma_map_single() call path. This triggers the warning since the dma-debug code have

Re: [PATCH 04/04] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops

On 15/03/16 17:05, Magnus Damm wrote: From: Magnus Damm Introduce a new set of iommu_ops suitable for 64-bit ARM as well as 32-bit ARM when CONFIG_IOMMU_DMA=y. The ->of_xlate() callback is needed by the code exported by of_iommu.h and it is wrapped in #ifdefs to

Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

Hi Dan, On 11/03/16 06:47, Dan Williams wrote: On Thu, Mar 10, 2016 at 8:05 AM, Niklas S??derlund wrote: Hi Christoph, On 2016-03-07 23:38:47 -0800, Christoph Hellwig wrote: Please add some documentation on where/how this should be used. It's not a very

Re: [PATCH v3 1/3] iommu/io-pgtable: Add ARMv7 short descriptor support

Hi Geert, On 01/03/16 12:01, Geert Uytterhoeven wrote: Hi Robin, On Tue, Jan 26, 2016 at 6:13 PM, Robin Murphy <robin.mur...@arm.com> wrote: Add a nearly-complete ARMv7 short descriptor implementation, omitting only a few legacy and CPU-centric aspects which shouldn't be necessary for

Re: [PATCH v3 1/8] iommu: Add MMIO mapping type

of the existing patch, to be folded in. My original patch was only handling IOMMU_MMIO for stage 2 PTEs, so we also need the extra code to handle the different way of setting the appropriate memory type in stage 1 PTEs. Robin. * Robin Murphy <robin.mur...@arm.com> [2016-02-11 15:57:26 +]:

Re: [PATCH v3 1/8] iommu: Add MMIO mapping type

On 11/02/16 00:02, Laurent Pinchart wrote: Hi Niklas, Thank you for the patch. On Wednesday 10 February 2016 01:57:51 Niklas Söderlund wrote: From: Robin Murphy <robin.mur...@arm.com> On some platforms, MMIO regions might need slightly different treatment compared to mapping regular

Re: [PATCH v3 3/8] dma-mapping: add dma_{map,unmap}_resource

Hi Niklas, Thanks for doing this, it looks good. Just a couple of minor comments on this and the next patch... On 10/02/16 00:57, Niklas Söderlund wrote: Map/Unmap a device resource from a physical address. If no dma_map_ops method is available the operation is a no-op. Signed-off-by:

Re: [PATCH v2 1/5] dma-mapping: add dma_{map,unmap}_page_attrs

(), which would be a no-op with no IOMMU (or with IOMMUs like VT-d where magic hardware solves the problem), interacting with something like the below extension of the IOMMU API (plucked from my local MSI proof-of-concept hacks). Robin. --->8--- From: Robin Murphy <robin.mur...@arm.com>