RE: [RFC 3/3] iommu/arm-smmu: detach DMA domain if driver is managing iommu

Hi Rob, >On Wed, Feb 1, 2017 at 10:23 AM, Rob Clark wrote: >> Before the driver is probed, arm_smmu_add_device() helpfully attaches >> an IOMMU_DOMAIN_DMA domain. Which ofc does not support stalling, and >> when the driver later attaches a domain that can_stall to an smmu that >> can stall, the

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

On 2/1/2017 1:52 PM, Lorenzo Pieralisi wrote: >> Sure, send it to both Nate and me. > I debugged the issue and Nate's fix is correct, the fact that you > can't it hit it with mainline is just a matter of timing because it has > to do with the CTX pointer value (we OR it with the existing value), so

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

On Mon, Jan 30, 2017 at 03:03:06PM -0500, Sinan Kaya wrote: > On 1/30/2017 11:51 AM, Lorenzo Pieralisi wrote: > > On Mon, Jan 30, 2017 at 10:46:39AM -0500, Sinan Kaya wrote: > >> On 1/30/2017 9:54 AM, Nate Watterson wrote: > >>> On 2017-01-30 09:38, Will Deacon wrote: > On Mon, Jan 30, 2017 at

[PATCH] iommu/dma: Remove bogus dma_supported() implementation

Back when this was first written, dma_supported() was somewhat of a murky mess, with subtly different interpretations being relied upon in various places. The "does device X support DMA to address range Y?" uses assuming Y to be physical addresses, which motivated the current iommu_dma_supported()

[RFC 1/3] iommu: introduce stall/resume support

A new flag when registering the fault handler indicates that the user supports stalling, and will call iommu_domain_resume() at some point later, potentially from a workqueue. (This would allow the user to do mm related operations that could not be done from irq context.) Signed-off-by: Rob Clark

Re: [RFC 3/3] iommu/arm-smmu: detach DMA domain if driver is managing iommu

On Wed, Feb 1, 2017 at 10:23 AM, Rob Clark wrote: > Before the driver is probed, arm_smmu_add_device() helpfully attaches > an IOMMU_DOMAIN_DMA domain. Which ofc does not support stalling, and > when the driver later attaches a domain that can_stall to an smmu that > can stall, the default _DMA d

[RFC 2/3] iommu/arm-smmu: Add support to opt-in to stalling

TODO maybe some dev_dbg() or some other way to tell if stalling is actually enabled? Signed-off-by: Rob Clark --- .../devicetree/bindings/iommu/arm,smmu.txt | 3 + drivers/iommu/arm-smmu.c | 85 -- 2 files changed, 82 insertions(+), 6 deleti

[RFC 0/3] iommu/arm-smmu: stalling support (v2)

Now, as was previously discussed[1], now we have a dt property on the smmu, to indicate that the smmu supports stalling, as well as a flag on the domain (set when fault-handler is registered) to indicate that the domain supports stalling. I ran into one snag, thanks to the auto-attached DMA domain

[RFC 3/3] iommu/arm-smmu: detach DMA domain if driver is managing iommu

Before the driver is probed, arm_smmu_add_device() helpfully attaches an IOMMU_DOMAIN_DMA domain. Which ofc does not support stalling, and when the driver later attaches a domain that can_stall to an smmu that can stall, the default _DMA domain prevents stalling from being enabled. (And will cause

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

Hi Geert, Thank you for the patch. On Tuesday 31 Jan 2017 12:17:07 Geert Uytterhoeven wrote: > Currently, the IPMMU/VMSA driver supports 32-bit I/O Virtual Addresses > only, and thus sets io_pgtable_cfg.ias = 32. However, it doesn't force > a 32-bit IOVA space through the IOMMU Domain Geometry.