arm64: dts: juno: Enable some SMMUs
Subsystems (2)
PATCH 1/1 arm64: dts: juno: Enable some SMMUs
The IOMMU-backed DMA API support has now been in place for a while and proven stable, so there's no real need to keep most of Juno's SMMUs disabled. The USB, HDLCDs, and CoreSight ETR all just need to map RAM buffers for DMA - enabling their SMMUs obviates CPU bounce buffering for USB's streaming DMA to the upper memory bank, and lets the other two allocate their relatively large coherent buffers without pressuring CMA.
Some more software work is still needed for the DMA-330 and PCIe before those can accommodate SMMU translation correctly in all cases, so we leave those alone for now.
--- arch/arm64/boot/dts/arm/juno-base.dtsi | 4 ---- 1 file changed, 4 deletions(-)
arch/arm64/boot/dts/arm/juno-base.dtsi +0 -4
@@ -53,7 +53,6 @@ #global-interrupts = <1>; dma-coherent; power-domains = <&scpi_devpd 0>; - status = "disabled"; }; gic: interrupt-controller at 2c010000 {
@@ -546,7 +545,6 @@ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; #iommu-cells = <1>; #global-interrupts = <1>; - status = "disabled"; }; smmu_hdlcd0: iommu at 7fb20000 {
@@ -556,7 +554,6 @@ <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>; #iommu-cells = <1>; #global-interrupts = <1>; - status = "disabled"; }; smmu_usb: iommu at 7fb30000 {
@@ -567,7 +564,6 @@ #iommu-cells = <1>; #global-interrupts = <1>; dma-coherent; - status = "disabled"; }; dma at 7ff00000 {
Signature · 1 line
2.12.2.dirty
PATCH 1/1 arm64: dts: juno: Enable some SMMUs
Quoted 7 lines · Robin Murphy
The IOMMU-backed DMA API support has now been in place for a while and proven stable, so there's no real need to keep most of Juno's SMMUs disabled. The USB, HDLCDs, and CoreSight ETR all just need to map RAM buffers for DMA - enabling their SMMUs obviates CPU bounce buffering for USB's streaming DMA to the upper memory bank, and lets the other two allocate their relatively large coherent buffers without pressuring CMA.
Quoted 6 lines
Some more software work is still needed for the DMA-330 and PCIe before those can accommodate SMMU translation correctly in all cases, so we leave those alone for now.
Signed-off-by Robin Murphy <[email protected]>---
For those that don't already know, status = "disabled" for smmu is broken in Linux 4.12-rc1, and this fixes it...
https://lkml.org/lkml/2017/5/17/344
Quoted 39 lines
arch/arm64/boot/dts/arm/juno-base.dtsi | 4 ---- 1 file changed, 4 deletions(-)arch/arm64/boot/dts/arm/juno-base.dtsi +0
-4@@ -53,7 +53,6 @@ #global-interrupts = <1>; dma-coherent; power-domains = <&scpi_devpd 0>; - status = "disabled"; }; gic: interrupt-controller at 2c010000 {@@ -546,7 +545,6 @@ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; #iommu-cells = <1>; #global-interrupts = <1>; - status = "disabled"; }; smmu_hdlcd0: iommu at 7fb20000 {@@ -556,7 +554,6 @@ <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>; #iommu-cells = <1>; #global-interrupts = <1>; - status = "disabled"; }; smmu_usb: iommu at 7fb30000 {@@ -567,7 +564,6 @@ #iommu-cells = <1>; #global-interrupts = <1>; dma-coherent; - status = "disabled"; }; dma at 7ff00000 {
Liviu Dudau
maintainerPATCH 1/1 arm64: dts: juno: Enable some SMMUs
Quoted 12 lines · Jon Medhurst (Tixy)
Quoted 11 lines · Robin Murphy
The IOMMU-backed DMA API support has now been in place for a while and proven stable, so there's no real need to keep most of Juno's SMMUs disabled. The USB, HDLCDs, and CoreSight ETR all just need to map RAM buffers for DMA - enabling their SMMUs obviates CPU bounce buffering for USB's streaming DMA to the upper memory bank, and lets the other two allocate their relatively large coherent buffers without pressuring CMA.
Some more software work is still needed for the DMA-330 and PCIe before those can accommodate SMMU translation correctly in all cases, so we leave those alone for now.
Quoted 6 lines
Quoted 2 lines
Signed-off-by Robin Murphy <[email protected]>---
For those that don't already know, status = "disabled" for smmu is broken in Linux 4.12-rc1, and this fixes it...
https://lkml.org/lkml/2017/5/17/344
Hey, fancy that!! I was just starting to wonder why some of my "disabled" nodes in the juno-base.dts were showing as "okay". :)
Thanks Tixy for the tip!
Liviu
Quoted 40 lines
Quoted 40 lines
arch/arm64/boot/dts/arm/juno-base.dtsi | 4 ---- 1 file changed, 4 deletions(-)arch/arm64/boot/dts/arm/juno-base.dtsi +0
-4@@ -53,7 +53,6 @@ #global-interrupts = <1>; dma-coherent; power-domains = <&scpi_devpd 0>; - status = "disabled"; }; gic: interrupt-controller at 2c010000 {@@ -546,7 +545,6 @@ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; #iommu-cells = <1>; #global-interrupts = <1>; - status = "disabled"; }; smmu_hdlcd0: iommu at 7fb20000 {@@ -556,7 +554,6 @@ <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>; #iommu-cells = <1>; #global-interrupts = <1>; - status = "disabled"; }; smmu_usb: iommu at 7fb30000 {@@ -567,7 +564,6 @@ #iommu-cells = <1>; #global-interrupts = <1>; dma-coherent; - status = "disabled"; }; dma at 7ff00000 {
Signature · 8 lines
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?PATCH 1/1 arm64: dts: juno: Enable some SMMUs
In reply to Jon Medhurst (Tixy)Quoted 12 lines · Jon Medhurst (Tixy)
Quoted 11 lines · Robin Murphy
The IOMMU-backed DMA API support has now been in place for a while and proven stable, so there's no real need to keep most of Juno's SMMUs disabled. The USB, HDLCDs, and CoreSight ETR all just need to map RAM buffers for DMA - enabling their SMMUs obviates CPU bounce buffering for USB's streaming DMA to the upper memory bank, and lets the other two allocate their relatively large coherent buffers without pressuring CMA.
Some more software work is still needed for the DMA-330 and PCIe before those can accommodate SMMU translation correctly in all cases, so we leave those alone for now.
Quoted 6 lines
Quoted 2 lines
Signed-off-by Robin Murphy <[email protected]>---
For those that don't already know, status = "disabled" for smmu is broken in Linux 4.12-rc1, and this fixes it...
https://lkml.org/lkml/2017/5/17/344
Well, it's not *technically* broken - we do stop waiting for disabled IOMMUs that never appear, you just need to get to an initramfs or other workable userspace to load another driver such that the deferred probe queue gets kicked again after that point :P
But yeah, the whole business reminded me that it was about time to do this anyway. I should dig up that pl330 patch I started, too...
Robin.
Quoted 39 lines
Quoted 39 lines
arch/arm64/boot/dts/arm/juno-base.dtsi | 4 ---- 1 file changed, 4 deletions(-)arch/arm64/boot/dts/arm/juno-base.dtsi +0
-4@@ -53,7 +53,6 @@ #global-interrupts = <1>; dma-coherent; power-domains = <&scpi_devpd 0>; - status = "disabled"; }; gic: interrupt-controller at 2c010000 {@@ -546,7 +545,6 @@ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; #iommu-cells = <1>; #global-interrupts = <1>; - status = "disabled"; }; smmu_hdlcd0: iommu at 7fb20000 {@@ -556,7 +554,6 @@ <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>; #iommu-cells = <1>; #global-interrupts = <1>; - status = "disabled"; }; smmu_usb: iommu at 7fb30000 {@@ -567,7 +564,6 @@ #iommu-cells = <1>; #global-interrupts = <1>; dma-coherent; - status = "disabled"; }; dma at 7ff00000 {
Liviu Dudau
maintainerPATCH 1/1 arm64: dts: juno: Enable some SMMUs
In reply to Robin MurphyQuoted 7 lines · Robin Murphy
The IOMMU-backed DMA API support has now been in place for a while and proven stable, so there's no real need to keep most of Juno's SMMUs disabled. The USB, HDLCDs, and CoreSight ETR all just need to map RAM buffers for DMA - enabling their SMMUs obviates CPU bounce buffering for USB's streaming DMA to the upper memory bank, and lets the other two allocate their relatively large coherent buffers without pressuring CMA.
Quoted 5 lines
Some more software work is still needed for the DMA-330 and PCIe before those can accommodate SMMU translation correctly in all cases, so we leave those alone for now.
Signed-off-by Robin Murphy <[email protected]>
For the HDLCDs' ones, you can have my Tested-by: Liviu Dudau <[email protected]>.
For the whole thing:
Best regards,
Liviu
Quoted 43 lines
--- arch/arm64/boot/dts/arm/juno-base.dtsi | 4 ---- 1 file changed, 4 deletions(-)arch/arm64/boot/dts/arm/juno-base.dtsi +0
-4@@ -53,7 +53,6 @@ #global-interrupts = <1>; dma-coherent; power-domains = <&scpi_devpd 0>; - status = "disabled"; }; gic: interrupt-controller at 2c010000 {@@ -546,7 +545,6 @@ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; #iommu-cells = <1>; #global-interrupts = <1>; - status = "disabled"; }; smmu_hdlcd0: iommu at 7fb20000 {@@ -556,7 +554,6 @@ <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>; #iommu-cells = <1>; #global-interrupts = <1>; - status = "disabled"; }; smmu_usb: iommu at 7fb30000 {@@ -567,7 +564,6 @@ #iommu-cells = <1>; #global-interrupts = <1>; dma-coherent; - status = "disabled"; }; dma at 7ff00000 {Signature · 1 line
2.12.2.dirty
Signature · 8 lines
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?PATCH 1/1 arm64: dts: juno: Enable some SMMUs
In reply to Robin MurphyQuoted 11 lines · Robin Murphy
The IOMMU-backed DMA API support has now been in place for a while and proven stable, so there's no real need to keep most of Juno's SMMUs disabled. The USB, HDLCDs, and CoreSight ETR all just need to map RAM buffers for DMA - enabling their SMMUs obviates CPU bounce buffering for USB's streaming DMA to the upper memory bank, and lets the other two allocate their relatively large coherent buffers without pressuring CMA.
Some more software work is still needed for the DMA-330 and PCIe before those can accommodate SMMU translation correctly in all cases, so we leave those alone for now.
Queued for v4.13 [1]
IIUC, it's not a fix and can wait for v4.13. Let me know if that's not the case.
Signature · 4 lines
Regards, Sudeep [1] https://git.kernel.org/sudeep.holla/linux/h/for-next/juno-updates
PATCH 1/1 arm64: dts: juno: Enable some SMMUs
In reply to Robin MurphyHello,
Quoted 10 lines · Robin Murphy
The IOMMU-backed DMA API support has now been in place for a while and proven stable, so there's no real need to keep most of Juno's SMMUs disabled. The USB, HDLCDs, and CoreSight ETR all just need to map RAM buffers for DMA - enabling their SMMUs obviates CPU bounce buffering for USB's streaming DMA to the upper memory bank, and lets the other two allocate their relatively large coherent buffers without pressuring CMA.
Some more software work is still needed for the DMA-330 and PCIe before those can accommodate SMMU translation correctly in all cases, so we leave those alone for now.
Out of curiosity, what is missing for DMA-330? I can use dmatest over SMMU on my juno-r1 by enabling the node, but I don't have any complex workload yet. Guest pass-through is really unreliable and I'm trying to figure out why.
Thanks,
Jean
PATCH 1/1 arm64: dts: juno: Enable some SMMUs
Quoted 10 lines · Jean-Philippe Brucker
Hello,
Quoted 7 lines · Robin Murphy
The IOMMU-backed DMA API support has now been in place for a while and proven stable, so there's no real need to keep most of Juno's SMMUs disabled. The USB, HDLCDs, and CoreSight ETR all just need to map RAM buffers for DMA - enabling their SMMUs obviates CPU bounce buffering for USB's streaming DMA to the upper memory bank, and lets the other two allocate their relatively large coherent buffers without pressuring CMA.
Quoted 7 lines
Quoted 3 lines
Some more software work is still needed for the DMA-330 and PCIe before those can accommodate SMMU translation correctly in all cases, so we leave those alone for now.
Out of curiosity, what is missing for DMA-330? I can use dmatest over SMMU on my juno-r1 by enabling the node, but I don't have any complex workload yet. Guest pass-through is really unreliable and I'm trying to figure out why.
Yes, dmatest has always been fine* since both ends get mapped for DMA appropriately by the client. The missing bit is, or should I say was, 4d6d74e22096 currently in linux-next.
Robin.
* For certain values of fine, anyway. There are a number of catastrophic races in the driver that make it generally a bad idea to use more than 1 thread per channel.
Quoted 4 lines
Thanks,
Jean
PATCH 1/1 arm64: dts: juno: Enable some SMMUs
Quoted 23 lines · Robin Murphy
Quoted 10 lines · Jean-Philippe Brucker
Hello,
Quoted 7 lines · Robin Murphy
The IOMMU-backed DMA API support has now been in place for a while and proven stable, so there's no real need to keep most of Juno's SMMUs disabled. The USB, HDLCDs, and CoreSight ETR all just need to map RAM buffers for DMA - enabling their SMMUs obviates CPU bounce buffering for USB's streaming DMA to the upper memory bank, and lets the other two allocate their relatively large coherent buffers without pressuring CMA.
Quoted 7 lines
Quoted 3 lines
Some more software work is still needed for the DMA-330 and PCIe before those can accommodate SMMU translation correctly in all cases, so we leave those alone for now.
Out of curiosity, what is missing for DMA-330? I can use dmatest over SMMU on my juno-r1 by enabling the node, but I don't have any complex workload yet. Guest pass-through is really unreliable and I'm trying to figure out why.
Yes, dmatest has always been fine* since both ends get mapped for DMA appropriately by the client. The missing bit is, or should I say was,
4d6d74e22096currently in linux-next.
Quoted 5 lines
Robin.
* For certain values of fine, anyway. There are a number of catastrophic races in the driver that make it generally a bad idea to use more than 1 thread per channel.
Ah I see, thanks. The issue I was seeing was mismatched dma-coherency, which I fixed. But my guest does sometimes hang when running 1024 threads/chan in dmatest, so that might be it.
Thanks,
Jean