Re: [PATCH v2 0/8] MT2712 IOMMU SUPPORT

On Tue, 2017-08-22 at 22:38 +0800, Joerg Roedel wrote: > On Mon, Aug 21, 2017 at 07:00:13PM +0800, Yong Wu wrote: > > Yong Wu (8): > > dt-bindings: mediatek: Add binding for mt2712 IOMMU and SMI > > iommu/mediatek: Move MTK_M4U_TO_LARB/PORT into mtk_iommu.c > > iommu/mediatek: Add mt2712

Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

Hi Jean-Philippe, On 2017/9/5 20:54, Jean-Philippe Brucker wrote: > On 31/08/17 09:20, Yisheng Xie wrote: >> It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which >> means we should not disable stall mode if stall/terminate mode is not >> configuable. >> >> Meanwhile, it is also

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 2017/8/31 16:20, Yisheng Xie wrote: Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3: https://www.spinics.net/lists/arm-kernel/msg565155.html But for some platform devices(aka on-chip integrated devices), there is also SVM requirement, which works based on the SMMU

Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform devices

Hi Jean-Philippe, On 2017/9/6 8:51, Bob Liu wrote: > On 2017/9/5 20:53, Jean-Philippe Brucker wrote: >> On 31/08/17 09:20, Yisheng Xie wrote: >>> From: Jean-Philippe Brucker >>> >>> Platform device can realise SVM function by using the stall mode. That >>> is to

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

Hi Jean-Philippe, On 2017/9/5 20:56, Jean-Philippe Brucker wrote: > On 31/08/17 09:20, Yisheng Xie wrote: >> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3: >> https://www.spinics.net/lists/arm-kernel/msg565155.html >> >> But for some platform devices(aka on-chip

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 2017/9/5 20:56, Jean-Philippe Brucker wrote: > On 31/08/17 09:20, Yisheng Xie wrote: >> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3: >> https://www.spinics.net/lists/arm-kernel/msg565155.html >> >> But for some platform devices(aka on-chip integrated devices),

Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform devices

On 2017/9/5 20:53, Jean-Philippe Brucker wrote: > On 31/08/17 09:20, Yisheng Xie wrote: >> From: Jean-Philippe Brucker >> >> Platform device can realise SVM function by using the stall mode. That >> is to say, when device access a memory via iova which is not

[PATCH v2 0/2] Dual MMU support for TI DRA7xx DSPs

Hi Joerg, The following is v2 of the patch series that enhances the OMAP IOMMU driver to support the mirror-programming of the two MMUs present within the DSP subsystems on TI DRA7xx/AM57xx family of SoCs. The main changes are to address the review comments on the registration of the MMU devices

[PATCH v2 1/2] iommu/omap: Change the attach detection logic

The OMAP IOMMU driver allows only a single device (eg: a rproc device) to be attached per domain. The current attach detection logic relies on a check for an attached iommu for the respective client device. Change this logic to use the client device pointer instead in preparation for supporting

[PATCH v2 2/2] iommu/omap: Add support to program multiple iommus

A client user instantiates and attaches to an iommu_domain to program the OMAP IOMMU associated with the domain. The iommus programmed by a client user are bound with the iommu_domain through the user's device archdata. The OMAP IOMMU driver currently supports only one IOMMU per IOMMU domain per

RE: [PATCH] iommu/dma: limit the IOVA allocated to dma-ranges region

Robin, >>Why? IOVA allocation is already constrained as much as it should be - if the >>device's DMA mask is wrong that's another problem, and this isn't the right >>place to fix it. This is because of following reasons. 1. Many of the HW modules in Tegra114 and Tegra30 can't access IOVA that

Re: [v4,0/3] iommu/ipmmu-vmsa: r8a7796 support V4

Hi, Magnus, maintainers, all. On 19.06.17 14:04, Magnus Damm wrote: iommu/ipmmu-vmsa: r8a7796 support V4 [PATCH v4 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding [PATCH v4 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48 [PATCH v4 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code

Re: [PATCH v6] vfio: platform: reset: Add Broadcom FlexRM reset module

On Mon, 4 Sep 2017 15:20:11 +0530 Anup Patel wrote: > Sorry for delayed response... > > On Tue, Aug 29, 2017 at 7:39 PM, Konrad Rzeszutek Wilk > wrote: > > On Tue, Aug 29, 2017 at 09:34:46AM +0530, Anup Patel wrote: > >> This patch adds

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 31/08/17 09:20, Yisheng Xie wrote: > Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3: > https://www.spinics.net/lists/arm-kernel/msg565155.html > > But for some platform devices(aka on-chip integrated devices), there is also > SVM requirement, which works based on

Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

On 31/08/17 09:20, Yisheng Xie wrote: > It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which > means we should not disable stall mode if stall/terminate mode is not > configuable. > > Meanwhile, it is also ILLEGAL when STALL_MODEL==0b10 && CD.S==0 which > means if stall mode is

Re: [RFC PATCH 5/6] iommu/arm-smmu-v3: fix panic when handle stall mode irq

On 31/08/17 09:20, Yisheng Xie wrote: > When SMMU do not support SVM feature, however the master support SVM, > which means matser can stall and with mult-pasid number, then the user > can bind a task to device using API like iommu_bind_task(). however, > when device trigger a stall mode fault i

Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform devices

On 31/08/17 09:20, Yisheng Xie wrote: > From: Jean-Philippe Brucker > > Platform device can realise SVM function by using the stall mode. That > is to say, when device access a memory via iova which is not populated, > it will stalled and when SMMU try to translate

Re: [RFC PATCH 2/6] iommu/of: Add stall and pasid properties to iommu_fwspec

On 31/08/17 09:20, Yisheng Xie wrote: > From: Jean-Philippe Brucker > > Add stall and pasid properties to iommu_fwspec. > > Signed-off-by: Jean-Philippe Brucker No. This is a draft, I didn't sign it off. Thanks, Jean

Re: [RFC PATCH 1/6] dt-bindings: document stall and PASID properties for IOMMU masters

On 31/08/17 09:20, Yisheng Xie wrote: > From: Jean-Philippe Brucker > > Document the bindings for stall and PASID capable platform devices. > > Signed-off-by: Jean-Philippe Brucker Huh? No, I don't think I did. Please leave the

Re: [PATCH] dma-coherent: fix dma_declare_coherent_memory() logic error

Thanks Arnd, applied. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v6 3/3] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801

Hi Will, Lorenzo, Robin, I have created the patch to add DT support for this erratum. However, currently I have only added support for pci-based devices. I'm a bit stumped on how to add platform device support, or if we should also add support at all. And I would rather ask before sending the

[PATCH] dma-coherent: fix dma_declare_coherent_memory() logic error

A recent change interprets the return code of dma_init_coherent_memory as an error value, but it is instead a boolean, where 'true' indicates success. This leads causes the caller to always do the wrong thing, and also triggers a compile-time warning about it: drivers/base/dma-coherent.c: In