> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Tuesday, March 06, 2018 0:22
>
> On 05/03/18 18:39, Christoph Hellwig wrote:
> > On Mon, Mar 05, 2018 at 03:48:32PM +, Robin Murphy wrote:
> >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's
> >> software-d
When the power domain is powered off, the IOMMU cannot be accessed and
register programming must be deferred until the power domain becomes
enabled.
Add runtime PM support, and use runtime PM device link from IOMMU to
master to startup and shutdown IOMMU.
Signed-off-by: Jeffy Chen
---
Changes i
It's hard to undo bus_set_iommu() in the error path, so move it to the
end of rk_iommu_probe().
Signed-off-by: Jeffy Chen
Reviewed-by: Tomasz Figa
Reviewed-by: Robin Murphy
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
Mo
Converts the rockchip-iommu driver to use the OF_IOMMU infrastructure,
which allows attaching master devices to their IOMMUs automatically
according to DT properties.
Signed-off-by: Jeffy Chen
Reviewed-by: Robin Murphy
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v
There would be some masters sharing the same IOMMU device. Put them in
the same iommu group and share the same iommu domain.
Signed-off-by: Jeffy Chen
Reviewed-by: Robin Murphy
---
Changes in v7:
Use iommu_group_ref_get to avoid ref leak
Changes in v6: None
Changes in v5: None
Changes in v4: N
Use the first registered IOMMU device for dma mapping operations, and
drop the domain platform device.
This is similar to exynos iommu driver.
Signed-off-by: Jeffy Chen
Reviewed-by: Tomasz Figa
Reviewed-by: Robin Murphy
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes i
Add clock property, since we are going to control clocks in rockchip
iommu driver.
Signed-off-by: Jeffy Chen
Reviewed-by: Rob Herring
---
Changes in v7: None
Changes in v6:
Fix dt-binding as Robin suggested.
Use aclk and iface clk as Rob and Robin suggested, and split binding
patch.
Changes in
From: Tomasz Figa
Current code relies on master driver enabling necessary clocks before
IOMMU is accessed, however there are cases when the IOMMU should be
accessed while the master is not running yet, for example allocating
V4L2 videobuf2 buffers, which is done by the VB2 framework using DMA
map
From: Tomasz Figa
Due to the bug in current code, only first IOMMU has the TLB lines
flushed in rk_iommu_zap_lines. This patch fixes the inner loop to
execute for all IOMMUs and properly flush the TLB.
Signed-off-by: Tomasz Figa
Signed-off-by: Jeffy Chen
---
Changes in v7: None
Changes in v6:
From: Tomasz Figa
Currently if the driver encounters an error while attaching device, it
will leave the IOMMU in an inconsistent state. Even though it shouldn't
really happen in reality, let's just add proper error path to keep
things consistent.
Signed-off-by: Tomasz Figa
Signed-off-by: Jeffy
From: Tomasz Figa
This patch converts the rockchip-iommu driver to use the in-kernel
iopoll helpers to wait for certain status bits to change in registers
instead of an open-coded custom macro.
Signed-off-by: Tomasz Figa
Signed-off-by: Jeffy Chen
Reviewed-by: Robin Murphy
---
Changes in v7:
Removal of IOMMUs cannot be done reliably.
This is similar to exynos iommu driver.
Signed-off-by: Jeffy Chen
Reviewed-by: Tomasz Figa
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
Rewrite commit message.
Changes in v3:
Also remove remove() and module_exit() as
This series fixes some issues in rockchip iommu driver, and add of_iommu
support in it.
Changes in v7:
Add WARN_ON in irq isr, and modify iommu archdata comment.
Use iommu_group_ref_get to avoid ref leak
Changes in v6:
Add clk names, and modify all iommu nodes in all existing rockchip dts
Fix dt
Move request_irq to the end of rk_iommu_probe().
Suggested-by: Robin Murphy
Signed-off-by: Jeffy Chen
Reviewed-by: Tomasz Figa
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
Loop platform_get_irq() as Robin suggested.
Changes in v2: None
d
Add missing iommu_device_sysfs_remove in error path.
Signed-off-by: Jeffy Chen
Reviewed-by: Tomasz Figa
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/iommu/rockchip-iommu.c | 6 +-
1 file changed, 5 inse
Hi Rob,
Thanks for your reply.
On 03/06/2018 10:27 AM, Rob Herring wrote:
On Thu, Mar 01, 2018 at 06:18:32PM +0800, Jeffy Chen wrote:
Add clock property, since we are going to control clocks in rockchip
iommu driver.
Signed-off-by: Jeffy Chen
---
Changes in v6: None
Really? There was a di
On Thu, Mar 01, 2018 at 06:18:32PM +0800, Jeffy Chen wrote:
> Add clock property, since we are going to control clocks in rockchip
> iommu driver.
>
> Signed-off-by: Jeffy Chen
> ---
>
> Changes in v6: None
Really? There was a different number of clocks before.
> Changes in v5: None
> Changes
Hi Tomasz,
Thanks for your reply.
On 03/05/2018 09:49 PM, Tomasz Figa wrote:
> struct rk_iommudata {
>+ struct device_link *link; /* runtime PM link from IOMMU to master */
Kerneldoc comment for the struct could be added instead.
i saw this in the kerneldoc:
* An MMU device exists alo
On 2/12/2018 1:33 PM, Jean-Philippe Brucker wrote:
> +static struct workqueue_struct *iommu_fault_queue;
Is there anyway we can make this fault queue per struct device?
Since this is common code, I think it needs some care.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of
On 2/12/2018 1:33 PM, Jean-Philippe Brucker wrote:
> +static int iommu_queue_fault(struct iommu_domain *domain, struct device *dev,
> + struct iommu_fault_event *evt)
> +{
> + struct iommu_fault_group *group;
> + struct iommu_fault_context *fault, *next;
> +
> +
On Mon, Feb 26, 2018 at 06:57:13PM +0100, Jacopo Mondi wrote:
> Add Renesas R-Car M3-N (R8A77965) compat string to IPMMU DT bindings
> documentation.
>
> Signed-off-by: Jacopo Mondi
> ---
> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 +
> 1 file changed, 1 insertion(+)
Re
On 05/03/18 18:39, Christoph Hellwig wrote:
On Mon, Mar 05, 2018 at 03:48:32PM +, Robin Murphy wrote:
Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's
software-discoverable and the only thing described in DT is the bus "host",
thus we need the same sort of thing as f
On Mon, Mar 05, 2018 at 03:48:32PM +, Robin Murphy wrote:
> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's
> software-discoverable and the only thing described in DT is the bus "host",
> thus we need the same sort of thing as for PCI to map from the child
> devices
Hi Robin,
On 3/5/2018 5:46 PM, Robin Murphy wrote:
Hi Vivek,
On 05/03/18 09:06, Vivek Gautam wrote:
Hi all,
I have a question regarding usage of 'dma-ranges', can someone point
me in the right direction?
On qcom soc, few of the master devices with iommu attached to them,
have limitations i
Now that set_memory_decrypted is always available we can just call it
directly.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/mem_encrypt.h | 2 --
arch/x86/mm/mem_encrypt.c | 9 -
lib/swiotlb.c | 12 ++--
3 files changed, 6 insertions(
Unused now that everyone uses swiotlb_{alloc,free}.
Signed-off-by: Christoph Hellwig
---
include/linux/swiotlb.h | 8
lib/swiotlb.c | 38 --
2 files changed, 46 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
in
Give the basic phys_to_dma and dma_to_phys helpers a __-prefix and add
the memory encryption mask to the non-prefixed versions. Use the
__-prefixed versions directly instead of clearing the mask again in
various places.
With that in place the generic dma-direct routines can be used to
allocate no
Hi all,
this series switches the x86 code the the dma-direct implementation
for direct (non-iommu) dma and the generic swiotlb ops. This includes
getting rid of the special ops for the AMD memory encryption case and
the STA2x11 SOC. The generic implementations are based on the x86
code, so they
Signed-off-by: Christoph Hellwig
---
include/linux/set_memory.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
index e5140648f638..da5178216da5 100644
--- a/include/linux/set_memory.h
+++ b/include/linux/set_memory.h
@@ -1
This cleans up the code a lot by removing duplicate logic.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/amd_iommu.c | 68 +++
2 files changed, 22 insertions(+), 47 deletions(-)
diff --git a/drivers/iommu/Kconfig
These days all devices (including the ISA fallback device) have a coherent
DMA mask set, so remove the workaround.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/dma-mapping.h | 18 ++
arch/x86/kernel/pci-dma.c | 10 --
arch/x86/mm/mem_encrypt.c
We want to phase out looking at the magic GFP_DMA flag in the dma mapping
routines, so switch the gart driver to use the coherent_dma_mask instead,
which is used to select the GFP_DMA flag in the caller.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/amd_gart_64.c | 2 +-
1 file changed, 1
Use the dma_direct_* helpers and cleanup the code flow.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel-iommu.c | 62 -
2 files changed, 17 insertions(+), 46 deletions(-)
diff --git a/drivers/iommu/Kconfig
All dma_ops implementations used on x86 now take care of setting their own
required GFP_ masks for the allocation. And given that the common code
now clears harmful flags itself that means we can stop the flags in all
the iommu implementations as well.
Signed-off-by: Christoph Hellwig
---
arch/
The generic swiotlb dma ops were based on the x86 ones and provide
equivalent functionality, so use them.
Also fix the sta2x11 case. For that SOC the dma map ops need an
additional physical to dma address translations. For swiotlb buffers
that is done throught the phys_to_dma helper, but the sta
There were only a few Pentium Pro multiprocessors systems where this
errata applied. They are more than 20 years old now, and we've slowly
dropped places where put the workarounds in and discouraged anyone
from enabling the workaround.
Get rid of it for good.
Signed-off-by: Christoph Hellwig
---
The generic dma-direct implementation is now functionally equivalent to
the x86 nommu dma_map implementation, so switch over to using it.
Note that the various iommu drivers are switched from x86_dma_supported
to dma_direct_supported to provide identical functionality, although the
checks looks fa
This gains support for CMA allocations for the force_iommu case, and
cleans up the code a bit.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/amd_gart_64.c | 36 ++--
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/arch/x86/kernel/amd_gart_64
Hi Tomasz,
On 3/5/2018 6:55 PM, Tomasz Figa wrote:
Hi Vivek,
On Fri, Mar 2, 2018 at 7:10 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 introduced device links patches, which lets t
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Monday, March 05, 2018 21:07
> To: Nipun Gupta ; will.dea...@arm.com;
> mark.rutl...@arm.com; catalin.mari...@arm.com
> Cc: iommu@lists.linux-foundation.org; robh...@kernel.org; h...@lst.de;
> m.szyprow...@sam
On 05/03/18 15:08, Christoph Hellwig wrote:
We should not add any new hardocded busses here. Please mark them in
OF/ACPI.
Unfortunately for us, fsl-mc is conceptually rather like PCI in that
it's software-discoverable and the only thing described in DT is the bus
"host", thus we need the sam
On 05/03/18 15:00, Nipun Gupta wrote:
-Original Message-
From: Robin Murphy [mailto:robin.mur...@arm.com]
Sent: Monday, March 05, 2018 20:23
To: Nipun Gupta ; will.dea...@arm.com;
mark.rutl...@arm.com; catalin.mari...@arm.com
Cc: iommu@lists.linux-foundation.org; robh...@kernel.org; h.
On 2/12/2018 1:33 PM, Jean-Philippe Brucker wrote:
> +static void io_mm_free(struct io_mm *io_mm)
> +{
> + struct mm_struct *mm;
> + void (*release)(struct io_mm *);
> +
> + release = io_mm->release;
> + mm = io_mm->mm;
> +
> + release(io_mm);
Is there any reason why you can't
On Sat, Mar 03, 2018 at 07:19:06PM +0100, Fredrik Noring wrote:
> Christoph, Alan,
>
> > If it is allocating / freeing this memory all the time in the hot path
> > it should really use a dma pool (see include/ilinux/dmapool.h).
> > The dma coherent APIs aren't really built for being called in the
We should not add any new hardocded busses here. Please mark them in
OF/ACPI.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Monday, March 05, 2018 20:23
> To: Nipun Gupta ; will.dea...@arm.com;
> mark.rutl...@arm.com; catalin.mari...@arm.com
> Cc: iommu@lists.linux-foundation.org; robh...@kernel.org; h...@lst.de;
> m.szyprow...@sam
Hi Joerg,
What do you think about v3?
It looks like, I can solve my softlookups with just a bit more proper
ratelimiting..
On Thu, 2018-02-15 at 19:17 +, Dmitry Safonov wrote:
> There is a ratelimit for printing, but it's incremented each time the
> cpu recives dmar fault interrupt. While one
On 05/03/18 14:29, Nipun Gupta wrote:
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a binding for
mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
Given that allowing "msi-parent" for #msi-cells > 1
Hello Joerg Roedel,
This is a semi-automatic email about new static checker warnings.
The patch 9648cbc9625b: "iommu/arm-smmu: Make use of the
iommu_register interface" from Feb 1, 2017, leads to the following
Smatch complaint:
./drivers/iommu/arm-smmu-v3.c:1957 arm_smmu_remove_device()
On Mon, Mar 5, 2018 at 11:13 PM, Robin Murphy wrote:
> On 05/03/18 13:49, Tomasz Figa wrote:
> [...]
>>>
>>> @@ -518,7 +520,12 @@ static irqreturn_t rk_iommu_irq(int irq, void
>>> *dev_id)
>>> u32 int_status;
>>> dma_addr_t iova;
>>> irqreturn_t ret = IRQ_NONE;
>>> -
Signed-off-by: Nipun Gupta
---
drivers/base/dma-mapping.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..2279c4d 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -334,6 +334,7 @@ void dma
Signed-off-by: Nipun Gupta
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1f15492 100644
--- a/arch/arm64/bo
The dma setup for fsl-mc devices is being done from device_add()
function. So, no need to call in mc bus driver.
Signed-off-by: Nipun Gupta
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fs
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
Signed-off-by: Nipun Gupta
---
drivers/iommu/arm-smmu.c | 7 +++
drivers/iommu/iommu.c| 21 +
include/linux/fsl/mc.h | 8
include/
Signed-off-by: Nipun Gupta
---
drivers/iommu/of_iommu.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..cc2fb9c 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
#
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a binding for
mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
Signed-off-by: Nipun Gupta
---
.../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31
This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.
These patches
- Define the new property 'iommu-parent' for fsl-mc bus (patch 1)
- Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3)
- Adds the dma-mapping support for
On 05/03/18 13:49, Tomasz Figa wrote:
[...]
@@ -518,7 +520,12 @@ static irqreturn_t rk_iommu_irq(int irq, void *dev_id)
u32 int_status;
dma_addr_t iova;
irqreturn_t ret = IRQ_NONE;
- int i;
+ int i, err, need_runtime_put;
nit: need_runtime_put could be a b
Hi Jeffy,
On Thu, Mar 1, 2018 at 7:18 PM, Jeffy Chen wrote:
> When the power domain is powered off, the IOMMU cannot be accessed and
> register programming must be deferred until the power domain becomes
> enabled.
>
> Add runtime PM support, and use runtime PM device link from IOMMU to
> master
Hi Jeffy,
On Thu, Mar 1, 2018 at 7:18 PM, Jeffy Chen wrote:
> Move request_irq to the end of rk_iommu_probe().
>
> Suggested-by: Robin Murphy
> Signed-off-by: Jeffy Chen
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> Loop platform_get_irq() as Robin
Hi Vivek,
On Fri, Mar 2, 2018 at 7:10 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 introduced device links patches, which lets the smmu's
> runtime to follow the master's runtime
On 05/03/18 12:29, Dongdong Liu wrote:
>>
>> +static int arm_smmu_enable_pri(struct arm_smmu_master_data *master)
>> +{
>> +int ret, pos;
>> +struct pci_dev *pdev;
>> +/*
>> + * TODO: find a good inflight PPR number. We should divide the PRI queue
>> + * by the number of PRI-cap
+static int arm_smmu_enable_pri(struct arm_smmu_master_data *master)
+{
+ int ret, pos;
+ struct pci_dev *pdev;
+ /*
+* TODO: find a good inflight PPR number. We should divide the PRI queue
+* by the number of PRI-capable devices, but it's impossible to know
+
Hi Vivek,
On 05/03/18 09:06, Vivek Gautam wrote:
Hi all,
I have a question regarding usage of 'dma-ranges', can someone point me
in the right direction?
On qcom soc, few of the master devices with iommu attached to them, have
limitations in using the iova address range. They can allow the iov
Hi all,
I have a question regarding usage of 'dma-ranges', can someone point me
in the right direction?
On qcom soc, few of the master devices with iommu attached to them, have
limitations in using the iova address range. They can allow the iova to
be only in a certain range, e.g. video codec
65 matches
Mail list logo
