Re: arc dma mapping cleanups/fixes and generic noncohernt dma code

On 05/18/2018 06:45 AM, Christoph Hellwig wrote: Hi all, this series continues consolidating the dma-mapping code, with a focus on architectures that do not (always) provide cache coherence for DMA. Three architectures (arm, mips and powerpc) are still left to be converted later due to

Re: add swiotlb support for riscv

On Wed, 16 May 2018 07:42:59 PDT (-0700), Christoph Hellwig wrote: Current 64-bit RISC-V cores don't have any iommu support, so they need iommu support when used with more than 4GB DRAM (or even just address space depending on the SBI). This wires the support up based on earlier patches from

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 01:35:08PM -0700, Vineet Gupta wrote: > On 05/18/2018 10:50 AM, Russell King - ARM Linux wrote: > >On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: > >>I never understood the need for this direction. And if memory serves me > >>right, at that time I was seeing

[PATCH] iommu/amd - Optimize PPR log handling

Improve the performance of the PPR log polling function (i.e. the task of emptying the log) by minimizing MMIO operations and more efficiently processing groups of log entries. Cache the head pointer, as there's never a reason to read it. Ensure the head pointer register is updated every so often,

[PATCH 16/16] iommu/arm-smmu: Add list of devices to opt out of DMA domains

Add a list of compatible strings for devices that wish to opt out of attaching to a DMA domain. This is for devices that prefer to manage their own IOMMU space for any number of reasons. Returning -ENOTSUPP for attach device will filter down and force arch_setup_dma_ops() to not set up the iommu

[PATCH 13/16] drm/msm/a5xx: Support per-instance pagetables

Add support for per-instance pagetables for 5XX targets. Create a support buffer for preemption to hold the SMMU pagetable information for a preempted ring, enable TTBR1 to support split pagetables and add the necessary PM4 commands to trigger a pagetable switch at the beginning of a user command.

[PATCH 14/16] drm/msm: Support per-instance address spaces

Create a per-instance address spaces when a new DRM file instance is opened assuming the target supports it and the underlying infrastructure exists. If the operation is unsupported fall back quietly to use the global pagetable. Signed-off-by: Jordan Crouse ---

[PATCH 15/16] iommu: Gracefully allow drivers to not attach to a default domain

Provide individual device drivers the chance to gracefully refuse to attach a device to the default domain. If the attach_device op returns -ENOTSUPP don't print a error message and don't set group->domain but still return success from iommu_group_add_dev(). This allows all the usual APIs to work

[PATCH 08/16] drm/msm: Pass the MMU domain index in struct msm_file_private

Pass the index of the MMU domain in struct msm_file_private instead of assuming gpu->id throughout the submit path. This clears the way to change ctx->aspace to a per-instance pagetable. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/msm_drv.c| 16

[PATCH 11/16] drm/msm: Add support for iommu-sva PASIDs

The IOMMU core can support creating multiple pagetables for a specific domai and making them available to a client driver that has the means to manage the pagetable itself. PASIDs are unique indexes to a software created pagetable with the same format and characteristics as the parent IOMMU

[PATCH 12/16] drm/msm: Add support for per-instance address spaces

Add a function to allocate a new pasid from a existing MMU domain and create a per-instance address space. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/msm_drv.h | 3 +++ drivers/gpu/drm/msm/msm_gem_vma.c | 37 +-- 2 files

[PATCH 09/16] drm/msm/gpu: Support using split page tables for kernel buffer objects

arm-smmu based targets can support split pagetables (TTBR0/TTBR1). This is most useful for implementing per-instance pagetables so that the "user" pagetable can be swapped out while the "kernel" or "global" pagetable remains entact. if the target specifies a global virtual memory range then try

[PATCH 10/16] drm/msm: Add msm_mmu features

Add a few simple support functions to support a bitmask of features that a specific MMU implementation supports. The first feature will be per-instance pagetables coming in the following patch. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/msm_mmu.h | 13

[PATCH 07/16] drm/msm/gpu: Enable 64 bit mode by default

A5XX GPUs can be run in either 32 or 64 bit mode. The GPU registers and the microcode use 64 bit virtual addressing in either case but the upper 32 bits are ignored if the GPU is in 32 bit mode. There is no performance disadvantage to remaining in 64 bit mode even if we are only generating 32 bit

[PATCH 06/16] iommu: arm-smmu: Add side-band function for specific PASID callbacks

Just allowing a client driver to create and manage a a private PASID isn't interesting if the client driver doesn't have enough information about the pagetable to be able to use it. Add a side band function for arm-smmu that lets the client device register pasid operations to pass the relevant

[PATCH 04/16] iommu: sva: Add support for private PASIDs

Some older SMMU implementations that do not have a fully featured hardware PASID features have alternate workarounds for using multiple pagetables. For example, MSM GPUs have logic to automatically switch the user pagetable from hardware by writing the context bank directly. Support private

[PATCH 05/16] iommu: arm-smmu: Add support for private PASIDs

Add support for allocating and populating pagetables indexed by private PASIDs. Each new PASID is allocated a pagetable with the same parameters and format as the parent domain. Signed-off-by: Jordan Crouse --- drivers/iommu/arm-smmu.c | 154

[PATCH 03/16] iommu/io-pgtable-arm: Remove ttbr[1] from io_pgtbl_cfg

Now that we have a working example of an ARM driver that implements split pagetables completely in the client driver it is apparent that we don't need to store an extra ttbr value in the io_pgtbl_cfg struct that will never get used. Signed-off-by: Jordan Crouse ---

[PATCH 02/16] iommu/arm-smmu: Add split pagetable support for arm-smmu-v2

Add support for a split pagetable (TTBR0/TTBR1) scheme for arm-smmu-v2. If split pagetables are enabled, create a pagetable for TTBR1 and set up the sign extension bit so that all IOVAs with that bit set are mapped and translated from the TTBR1 pagetable. Signed-off-by: Jordan Crouse

[RFC v2 00/16] Private PASID and per-instance pagetables

This is v2 of a patchset of changes to implmeent private PASID support for arm-smmu-v2 targets and implement per-instance pagetables for MSM GPUs. Per-instance pagetables allow the target GPU driver to create and manage an individual pagetable for each file descriptor instance and switch between

[PATCH 01/16] iommu: Add DOMAIN_ATTR_SPLIT_TABLES

Add a new domain attribute to enable split pagetable support for devices devices that support it. Signed-off-by: Jordan Crouse --- include/linux/iommu.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 07:57:34PM +, Alexey Brodkin wrote: > Hi Russel, That's Russell. > On Fri, 2018-05-18 at 18:50 +0100, Russell King - ARM Linux wrote: > > It's necessary. Take a moment to think carefully about this: > > > > dma_map_single(, dir) > > > >

Re: [PATCH v7 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

On 05/18/2018 11:49 AM, Randy Dunlap wrote: On 05/18/2018 08:20 AM, Gary R Hook wrote: On 05/15/2018 08:46 AM, Joerg Roedel wrote: On Mon, May 14, 2018 at 03:00:50PM -0500, Gary R Hook wrote: This was brought up a few weeks ago in, I believe, version 3 of this patch. That question was

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On 05/18/2018 10:50 AM, Russell King - ARM Linux wrote: On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: I never understood the need for this direction. And if memory serves me right, at that time I was seeing twice the amount of cache flushing ! It's necessary. Take a moment to

Re: [PATCH 3/6] swiotlb: merge swiotlb_unmap_page and unmap_single

On Tue, May 15, 2018 at 08:05:20PM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig Applied. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/6] swiotlb: remove a pointless comment

On Tue, May 15, 2018 at 08:05:18PM +0200, Christoph Hellwig wrote: > This comments describes an aspect of the map_sg interface that isn't > even exploited by swiotlb. > > Signed-off-by: Christoph Hellwig Applied. > --- > lib/swiotlb.c | 6 -- > 1 file changed, 6 deletions(-) >

Re: [PATCH 2/6] swiotlb: do not panic on mapping failures

On Tue, May 15, 2018 at 08:05:19PM +0200, Christoph Hellwig wrote: > We now have error handling in map_single/map_page callers (most of them Which ones are missing? Shouldn't we first fix those before we rip this out? > anyway). As swiotlb_tbl_map_single already prints a useful warning > when

Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation

On 18.05.2018 15:03, Alexey Brodkin wrote: > But the real fix of my problem is: > >8 > --- a/lib/dma-noncoherent.c > +++ b/lib/dma-noncoherent.c > @@ -35,7 +35,7 @@ static dma_addr_t dma_noncoherent_map_page(struct device

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

Hi Russel, On Fri, 2018-05-18 at 18:50 +0100, Russell King - ARM Linux wrote: > It's necessary. Take a moment to think carefully about this: > > dma_map_single(, dir) > > dma_sync_single_for_cpu(, dir) > > dma_sync_single_for_device(, dir) > >

Re: [PATCH v2 07/40] iommu: Add a page fault handler

On Fri, 11 May 2018 20:06:08 +0100 Jean-Philippe Brucker wrote: > Some systems allow devices to handle I/O Page Faults in the core mm. > For example systems implementing the PCI PRI extension or Arm SMMU > stall model. Infrastructure for reporting these recoverable

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: > I never understood the need for this direction. And if memory serves me > right, at that time I was seeing twice the amount of cache flushing ! It's necessary. Take a moment to think carefully about this: dma_map_single(,

Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation

On 05/18/2018 06:23 AM, h...@lst.de wrote: Fri, May 18, 2018 at 01:03:46PM +, Alexey Brodkin wrote: Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : DMA_FROM_DEVICE". I.e. if we're preparing for sending data dma_noncoherent_map_sg() will have DMA_TO_DEVICE

dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On 05/18/2018 06:11 AM, Alexey Brodkin wrote: void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr, size_t size, enum dma_data_direction dir) { + if (dir != DMA_TO_DEVICE){ + dump_stack(); + printk(" *** %s@%d: DMA direction

Re: [PATCH v7 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

On 05/18/2018 08:20 AM, Gary R Hook wrote: > On 05/15/2018 08:46 AM, Joerg Roedel wrote: >> On Mon, May 14, 2018 at 03:00:50PM -0500, Gary R Hook wrote: >>> This was brought up a few weeks ago in, I believe, version 3 of this patch. >>> That question was discussed (because that's what I did the

Re: arc dma mapping cleanups/fixes and generic noncohernt dma code

On Fri, May 18, 2018 at 02:49:36PM +, Alexey Brodkin wrote: > So if we set aside my complaints about direction in > arch_sync_dma_for_{device|cpu}()... Many other architectures use the argument. Various of those look bogus, but for now I want to be able to do straight forward conversions.

Re: [PATCH v7 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

On 05/15/2018 08:46 AM, Joerg Roedel wrote: On Mon, May 14, 2018 at 03:00:50PM -0500, Gary R Hook wrote: This was brought up a few weeks ago in, I believe, version 3 of this patch. That question was discussed (because that's what I did the first time out), and _someone_ _else_ asked about why I

Re: arc dma mapping cleanups/fixes and generic noncohernt dma code

Hi Christoph, On Fri, 2018-05-18 at 15:45 +0200, Christoph Hellwig wrote: > Hi all, > > this series continues consolidating the dma-mapping code, with a focus > on architectures that do not (always) provide cache coherence for DMA. > Three architectures (arm, mips and powerpc) are still left to

Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation

Hi Christoph, On Fri, 2018-05-18 at 15:27 +0200, h...@lst.de wrote: > On Fri, May 18, 2018 at 01:03:46PM +, Alexey Brodkin wrote: > > Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? > > DMA_TO_DEVICE : DMA_FROM_DEVICE". > > I.e. if we're preparing for sending data

[PATCH 5/6] arc: fix arc_dma_{map,unmap}_page

These functions should perform the same cache synchronoization as calling arc_dma_sync_single_for_{cpu,device} in addition to doing any required address translation or mapping [1]. Ensure they actually do that by calling arc_dma_sync_single_for_{cpu,device} instead of passing the dir argument

[PATCH 6/6] arc: use generic dma_noncoherent_ops

Switch to the generic noncoherent direct mapping implementation. Signed-off-by: Christoph Hellwig --- arch/arc/Kconfig | 4 + arch/arc/include/asm/Kbuild| 1 + arch/arc/include/asm/dma-mapping.h | 21 - arch/arc/mm/dma.c | 140

[PATCH 4/6] arc: fix arc_dma_sync_sg_for_{cpu,device}

These functions should perform the same functionality as calling arc_dma_sync_single_for_{cpu,device} on each S/G list element. Ensure they actually do that by calling arc_dma_sync_single_for_{cpu,device}. Otherwise we could be passing a different dir argument. Signed-off-by: Christoph Hellwig

[PATCH 3/6] arc: simplify arc_dma_sync_single_for_{cpu,device}

Remove the indirection through _dma_cache_sync. Also move the functions up a bit in the source file as we'll need them in more places soon. Signed-off-by: Christoph Hellwig --- arch/arc/mm/dma.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff

[PATCH 2/6] dma-mapping: provide a generic dma-noncoherent implementation

Add a new dma_map_ops implementation that uses dma-direct for the address mapping of streaming mappings, and which requires arch-specific implemenations of coherent allocate/free. Architectures have to provide flushing helpers to ownership trasnfers to the device and/or CPU, and can provide

[PATCH 1/6] dma-mapping: simplify Kconfig dependencies

ARCH_DMA_ADDR_T_64BIT is always true for 64-bit architectures now, so we can skip the clause requiring it. 'n' is the default default, so no need to explicitly state it. Signed-off-by: Christoph Hellwig --- lib/Kconfig | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-)

arc dma mapping cleanups/fixes and generic noncohernt dma code

Hi all, this series continues consolidating the dma-mapping code, with a focus on architectures that do not (always) provide cache coherence for DMA. Three architectures (arm, mips and powerpc) are still left to be converted later due to complexity of their dma ops selection. The dma-noncoherent

Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation

On Fri, May 18, 2018 at 01:03:46PM +, Alexey Brodkin wrote: > Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE > : DMA_FROM_DEVICE". > I.e. if we're preparing for sending data dma_noncoherent_map_sg() will have > DMA_TO_DEVICE which > is quite OK for passing to

Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation

Hi Christoph, On Fri, 2018-05-11 at 09:59 +0200, Christoph Hellwig wrote: [snip] There seems to be one subtle issue with map/unmap code. While investigating problems on ARC I added instrumentation as below: >8 ---

Re: [PATCH v11 0/4] iommu/arm-smmu: Add runtime pm/sleep support

Hi Robin, On 4/9/2018 9:52 AM, Tomasz Figa wrote: Hi Will, Robin, On Thu, Mar 22, 2018 at 7:22 PM Vivek Gautam wrote: This series provides the support for turning on the arm-smmu's clocks/power domains using runtime pm. This is done using the recently