[PATCH v5] dt-bindings: iommu: renesas, ipmmu-vmsa: convert to json-schema
Convert Renesas VMSA-Compatible IOMMU bindings documentation
to json-schema.
Note that original documentation doesn't mention renesas,ipmmu-vmsa
for R-Mobile APE6. But, R-Mobile APE6 is similar to the R-Car
Gen2. So, renesas,ipmmu-r8a73a4 belongs the renesas,ipmmu-vmsa
section.
Signed-off-by: Yoshihiro Shimoda
---
Changes from v4:
- Fix description about cell counts on #iommu-cells and renesas,ipmmu-main.
- Fix node name on the example.
https://patchwork.kernel.org/patch/11494231/
Changes from v3:
- Fix renesas,ipmmu-r8a7795's section
https://patchwork.kernel.org/patch/11494079/
Changes from v2:
- Add a description for R-Mobile APE6 on the commit log.
- Change renesas,ipmmu-r8a73a4 section on the compatible.
- Add items on the interrupts.
- Add power-domains to required.
- Add oneOf for interrupts and renesas,ipmmu-main
https://patchwork.kernel.org/patch/11490581/
Changes from v1:
- Fix typo in the subject.
- Add a description on #iommu-cells.
https://patchwork.kernel.org/patch/11485415/
.../bindings/iommu/renesas,ipmmu-vmsa.txt | 73
.../bindings/iommu/renesas,ipmmu-vmsa.yaml | 98 ++
2 files changed, 98 insertions(+), 73 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
create mode 100644
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
deleted file mode 100644
index 020d6f2..
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-* Renesas VMSA-Compatible IOMMU
-
-The IPMMU is an IOMMU implementation compatible with the ARM VMSA page tables.
-It provides address translation for bus masters outside of the CPU, each
-connected to the IPMMU through a port called micro-TLB.
-
-
-Required Properties:
-
- - compatible: Must contain SoC-specific and generic entry below in case
-the device is compatible with the R-Car Gen2 VMSA-compatible IPMMU.
-
-- "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU.
-- "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU.
-- "renesas,ipmmu-r8a7744" for the R8A7744 (RZ/G1N) IPMMU.
-- "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU.
-- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU.
-- "renesas,ipmmu-r8a774b1" for the R8A774B1 (RZ/G2N) IPMMU.
-- "renesas,ipmmu-r8a774c0" for the R8A774C0 (RZ/G2E) IPMMU.
-- "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU.
-- "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU.
-- "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU.
-- "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
-- "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU.
-- "renesas,ipmmu-r8a7796" for the R8A7796 (R-Car M3-W) IPMMU.
-- "renesas,ipmmu-r8a77965" for the R8A77965 (R-Car M3-N) IPMMU.
-- "renesas,ipmmu-r8a77970" for the R8A77970 (R-Car V3M) IPMMU.
-- "renesas,ipmmu-r8a77980" for the R8A77980 (R-Car V3H) IPMMU.
-- "renesas,ipmmu-r8a77990" for the R8A77990 (R-Car E3) IPMMU.
-- "renesas,ipmmu-r8a77995" for the R8A77995 (R-Car D3) IPMMU.
-- "renesas,ipmmu-vmsa" for generic R-Car Gen2 or RZ/G1 VMSA-compatible
- IPMMU.
-
- - reg: Base address and size of the IPMMU registers.
- - interrupts: Specifiers for the MMU fault interrupts. For instances that
-support secure mode two interrupts must be specified, for non-secure and
-secure mode, in that order. For instances that don't support secure mode a
-single interrupt must be specified. Not required for cache IPMMUs.
-
- - #iommu-cells: Must be 1.
-
-Optional properties:
-
- - renesas,ipmmu-main: reference to the main IPMMU instance in two cells.
-The first cell is a phandle to the main IPMMU and the second cell is
-the interrupt bit number associated with the particular cache IPMMU device.
-The interrupt bit number needs to match the main IPMMU IMSSTR register.
-Only used by cache IPMMU instances.
-
-
-Each bus master connected to an IPMMU must reference the IPMMU in its device
-node with the following property:
-
- - iommus: A reference to the IPMMU in two cells. The first cell is a phandle
-to the IPMMU and the second cell the number of the micro-TLB that the
-device is connected to.
-
-
-Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
-
- ipmmu_mx: mmu@fe951000 {
- compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
- reg = <0 0xfe951000 0 0x1000>;
- interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-<0 221 IRQ_TYPE_LEVEL_HIGH>;
- #iommu-cells = <1>;
- };
-
- vsp@fe928000 {
- ...
- iommus = <_mx 13>;
- ...
- };
diff --git
RE: [PATCH] dt-bndings: iommu: renesas,ipmmu-vmsa: convert to json-schema
Hi Rob,
Thank you for the review!
> From: Rob Herring, Sent: Tuesday, April 21, 2020 4:27 AM
>
> On Mon, Apr 13, 2020 at 07:25:33PM +0900, Yoshihiro Shimoda wrote:
> > Convert Renesas VMSA-Compatible IOMMU bindings documentation
> > to json-schema.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> > new file mode 100644
> > index ..3820b10
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> > @@ -0,0 +1,90 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iommu/renesas,ipmmu-vmsa.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Renesas VMSA-Compatible IOMMU
> > +
> > +maintainers:
> > + - Yoshihiro Shimoda
> > +
> > +description:
> > + The IPMMU is an IOMMU implementation compatible with the ARM VMSA page
> > tables.
> > + It provides address translation for bus masters outside of the CPU, each
> > + connected to the IPMMU through a port called micro-TLB.
> > +
> > +properties:
> > + compatible:
> > +oneOf:
> > + - items:
> > + - enum:
> > + - renesas,ipmmu-r8a7743 # RZ/G1M
> > + - renesas,ipmmu-r8a7744 # RZ/G1N
> > + - renesas,ipmmu-r8a7745 # RZ/G1E
> > + - renesas,ipmmu-r8a7790 # R-Car H2
> > + - renesas,ipmmu-r8a7791 # R-Car M2-W
> > + - renesas,ipmmu-r8a7793 # R-Car M2-N
> > + - renesas,ipmmu-r8a7794 # R-Car E2
> > + - renesas,ipmmu-r8a7795 # R-Car H3
> > + - const: renesas,ipmmu-vmsa # R-Car Gen2 or RZ/G1
> > + - items:
> > + - enum:
> > + - renesas,ipmmu-r8a73a4 # R-Mobile APE6
> > + - renesas,ipmmu-r8a774a1 # RZ/G2M
> > + - renesas,ipmmu-r8a774b1 # RZ/G2N
> > + - renesas,ipmmu-r8a774c0 # RZ/G2E
> > + - renesas,ipmmu-r8a7796 # R-Car M3-W
> > + - renesas,ipmmu-r8a77965 # R-Car M3-N
> > + - renesas,ipmmu-r8a77970 # R-Car V3M
> > + - renesas,ipmmu-r8a77980 # R-Car V3H
> > + - renesas,ipmmu-r8a77990 # R-Car E3
> > + - renesas,ipmmu-r8a77995 # R-Car D3
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + interrupts:
> > +minItems: 1
> > +maxItems: 2
> > +description:
> > + Specifiers for the MMU fault interrupts. For instances that support
> > + secure mode two interrupts must be specified, for non-secure and
> > secure
> > + mode, in that order. For instances that don't support secure mode a
> > + single interrupt must be specified. Not required for cache IPMMUs.
> > +
> > + '#iommu-cells':
> > +const: 1
> > +
> > + power-domains:
> > +maxItems: 1
> > +
> > + renesas,ipmmu-main:
> > +$ref: /schemas/types.yaml#/definitions/phandle-array
> > +description:
> > + Reference to the main IPMMU instance in two cells. The first cell is
> > + a phandle to the main IPMMU and the second cell is the interrupt bit
>
> The cell counting is wrong here. We don't count the phandle as a cell.
> It's a 'phandle plus 1 cell'.
I got it. I'll fix it.
> Same goes for 'iommus'.
I understood it. I'll also fix '#iommu-cells' description.
> > + number associated with the particular cache IPMMU device. The
> > interrupt
> > + bit number needs to match the main IPMMU IMSSTR register. Only used
> > by
> > + cache IPMMU instances.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - '#iommu-cells'
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +#include
> > +
> > +ipmmu_mx: mmu@fe951000 {
>
> iommu@...
I got it.
BTW, all Renesas related dts files are described as "mmu" now.
So, I'll also fix dts files later. Thank you for the pointed it out!
Best regards,
Yoshihiro Shimoda
> > +compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
> > +reg = <0xfe951000 0x1000>;
> > +interrupts = ,
> > + ;
> > +#iommu-cells = <1>;
> > +};
> > --
> > 2.7.4
> >
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] of_device: removed #include that caused a recursion in included headers
On Mon, Apr 13, 2020 at 04:35:53PM +0300, Hadar Gat wrote: > Both of_platform.h and of_device.h were included each other. > In of_device.h, removed unneeded #include to of_platform.h > and added include to of_platform.h in the files that needs it. Guess we forgot about that temporary comment! Both of these headers have a lot of things we don't want 'normal' drivers calling. The most common thing needed from of_device.h is of_match_device/of_device_get_match_data. A good number are only for ibmebus. Maybe the header should be split or the former just moved to of.h. For of_platform.h, it seems we have a bunch of unneeded includes: $ git grep 'of_platform\.h' drivers/ | wc 5601120 36049 $ git grep -E 'of_(platform_(pop|def)|find_device)' drivers/ | wc 2481215 20630 Would nice to drop those (or switch to of_device.h?) too. Be sure to build on Sparc. It's the oddball. > > Signed-off-by: Hadar Gat > --- > drivers/base/platform.c | 1 + > drivers/bus/vexpress-config.c | 1 + > drivers/dma/at_hdmac.c| 1 + > drivers/dma/stm32-dmamux.c| 1 + > drivers/dma/ti/dma-crossbar.c | 1 + > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 + > drivers/gpu/drm/msm/hdmi/hdmi.c | 1 + > drivers/gpu/drm/msm/msm_drv.c | 1 + > drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1 + > drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 + > drivers/iio/adc/stm32-adc-core.c | 1 + > drivers/iio/adc/stm32-dfsdm-adc.c | 1 + > drivers/iio/adc/stm32-dfsdm-core.c| 1 + > drivers/iommu/tegra-smmu.c| 1 + > drivers/memory/atmel-ebi.c| 1 + > drivers/mfd/palmas.c | 1 + > drivers/mfd/ssbi.c| 1 + > drivers/mtd/nand/raw/omap2.c | 1 + > drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 1 + > drivers/net/ethernet/ti/cpsw.c| 1 + > drivers/phy/tegra/xusb.c | 1 + > drivers/pinctrl/nomadik/pinctrl-nomadik.c | 1 + > drivers/soc/samsung/exynos-pmu.c | 1 + > drivers/soc/sunxi/sunxi_sram.c| 1 + > include/linux/of_device.h | 2 -- > lib/genalloc.c| 1 + > 26 files changed, 25 insertions(+), 2 deletions(-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bndings: iommu: renesas,ipmmu-vmsa: convert to json-schema
On Mon, Apr 13, 2020 at 07:25:33PM +0900, Yoshihiro Shimoda wrote:
> Convert Renesas VMSA-Compatible IOMMU bindings documentation
> to json-schema.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> .../bindings/iommu/renesas,ipmmu-vmsa.txt | 73 --
> .../bindings/iommu/renesas,ipmmu-vmsa.yaml | 90
> ++
> 2 files changed, 90 insertions(+), 73 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
> create mode 100644
> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
>
> diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
> b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
> deleted file mode 100644
> index 020d6f2..
> --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
> +++ /dev/null
> @@ -1,73 +0,0 @@
> -* Renesas VMSA-Compatible IOMMU
> -
> -The IPMMU is an IOMMU implementation compatible with the ARM VMSA page
> tables.
> -It provides address translation for bus masters outside of the CPU, each
> -connected to the IPMMU through a port called micro-TLB.
> -
> -
> -Required Properties:
> -
> - - compatible: Must contain SoC-specific and generic entry below in case
> -the device is compatible with the R-Car Gen2 VMSA-compatible IPMMU.
> -
> -- "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU.
> -- "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU.
> -- "renesas,ipmmu-r8a7744" for the R8A7744 (RZ/G1N) IPMMU.
> -- "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU.
> -- "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU.
> -- "renesas,ipmmu-r8a774b1" for the R8A774B1 (RZ/G2N) IPMMU.
> -- "renesas,ipmmu-r8a774c0" for the R8A774C0 (RZ/G2E) IPMMU.
> -- "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU.
> -- "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU.
> -- "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU.
> -- "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
> -- "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU.
> -- "renesas,ipmmu-r8a7796" for the R8A7796 (R-Car M3-W) IPMMU.
> -- "renesas,ipmmu-r8a77965" for the R8A77965 (R-Car M3-N) IPMMU.
> -- "renesas,ipmmu-r8a77970" for the R8A77970 (R-Car V3M) IPMMU.
> -- "renesas,ipmmu-r8a77980" for the R8A77980 (R-Car V3H) IPMMU.
> -- "renesas,ipmmu-r8a77990" for the R8A77990 (R-Car E3) IPMMU.
> -- "renesas,ipmmu-r8a77995" for the R8A77995 (R-Car D3) IPMMU.
> -- "renesas,ipmmu-vmsa" for generic R-Car Gen2 or RZ/G1 VMSA-compatible
> -IPMMU.
> -
> - - reg: Base address and size of the IPMMU registers.
> - - interrupts: Specifiers for the MMU fault interrupts. For instances that
> -support secure mode two interrupts must be specified, for non-secure and
> -secure mode, in that order. For instances that don't support secure mode
> a
> -single interrupt must be specified. Not required for cache IPMMUs.
> -
> - - #iommu-cells: Must be 1.
> -
> -Optional properties:
> -
> - - renesas,ipmmu-main: reference to the main IPMMU instance in two cells.
> -The first cell is a phandle to the main IPMMU and the second cell is
> -the interrupt bit number associated with the particular cache IPMMU
> device.
> -The interrupt bit number needs to match the main IPMMU IMSSTR register.
> -Only used by cache IPMMU instances.
> -
> -
> -Each bus master connected to an IPMMU must reference the IPMMU in its device
> -node with the following property:
> -
> - - iommus: A reference to the IPMMU in two cells. The first cell is a
> phandle
> -to the IPMMU and the second cell the number of the micro-TLB that the
> -device is connected to.
> -
> -
> -Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
> -
> - ipmmu_mx: mmu@fe951000 {
> - compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
> - reg = <0 0xfe951000 0 0x1000>;
> - interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
> - <0 221 IRQ_TYPE_LEVEL_HIGH>;
> - #iommu-cells = <1>;
> - };
> -
> - vsp@fe928000 {
> - ...
> - iommus = <_mx 13>;
> - ...
> - };
> diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> new file mode 100644
> index ..3820b10
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/renesas,ipmmu-vmsa.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas VMSA-Compatible IOMMU
> +
> +maintainers:
> + - Yoshihiro Shimoda
> +
> +description:
> + The IPMMU is an IOMMU implementation compatible with the ARM
Re: [PATCHv3 2/6] iommu/arm-smmu: Allow client devices to select direct mapping
On 2020-04-20 22:27, Robin Murphy wrote: On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote: From: Jordan Crouse Some client devices want to directly map the IOMMU themselves instead of using the DMA domain. Allow those devices to opt in to direct mapping by way of a list of compatible strings. Neat and tidy :) Reviewed-by: Robin Murphy Strictly, I think patch #3/6 should really have come before this one (with the header change moved accordingly), but don't bother resending just for that. Thanks, I have sent the updated version with this change as well in addition to the commit msg update for modem requesting direct mapping. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv4 6/6] arm64: dts: qcom: sdm845-cheza: Add iommus property
From: Sibi Sankar
Add iommus property to remoteproc modem node.
Following SMMU global faults are seen without it.
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x,
GFSYNR1 0x0781, GFSYNR2 0x
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x,
GFSYNR1 0x0461, GFSYNR2 0x
Signed-off-by: Sibi Sankar
Signed-off-by: Sai Prakash Ranjan
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
index 9070be43a309..07081da2c83e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -631,6 +631,11 @@ ap_ts_i2c: {
status = "okay";
};
+_pil {
+ iommus = <_smmu 0x780 0x1>,
+<_smmu 0x724 0x3>;
+};
+
_pwrkey {
status = "disabled";
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv4 2/6] iommu/arm-smmu: Implement iommu_ops->def_domain_type call-back
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Signed-off-by: Sai Prakash Ranjan
Reviewed-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 12
drivers/iommu/arm-smmu.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index e622f4e33379..b345a86085ce 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1609,6 +1609,17 @@ static void arm_smmu_get_resv_regions(struct device *dev,
iommu_dma_get_resv_regions(dev, head);
}
+static int arm_smmu_def_domain_type(struct device *dev)
+{
+ struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
+ const struct arm_smmu_impl *impl = cfg->smmu->impl;
+
+ if (impl && impl->def_domain_type)
+ return impl->def_domain_type(dev);
+
+ return 0;
+}
+
static struct iommu_ops arm_smmu_ops = {
.capable= arm_smmu_capable,
.domain_alloc = arm_smmu_domain_alloc,
@@ -1627,6 +1638,7 @@ static struct iommu_ops arm_smmu_ops = {
.of_xlate = arm_smmu_of_xlate,
.get_resv_regions = arm_smmu_get_resv_regions,
.put_resv_regions = generic_iommu_put_resv_regions,
+ .def_domain_type= arm_smmu_def_domain_type,
.pgsize_bitmap = -1UL, /* Restricted during device attach */
};
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index 8d1cd54d82a6..d172c024be61 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -386,6 +386,7 @@ struct arm_smmu_impl {
int (*init_context)(struct arm_smmu_domain *smmu_domain);
void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
int status);
+ int (*def_domain_type)(struct device *dev);
};
static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv4 3/6] iommu/arm-smmu: Allow client devices to select direct mapping
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Signed-off-by: Jordan Crouse
Co-developed-by: Sai Prakash Ranjan
Signed-off-by: Sai Prakash Ranjan
Reviewed-by: Robin Murphy
---
drivers/iommu/arm-smmu-qcom.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 64a4ab270ab7..5bedf21587a5 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -3,6 +3,7 @@
* Copyright (c) 2019, The Linux Foundation. All rights reserved.
*/
+#include
#include
#include "arm-smmu.h"
@@ -11,6 +12,23 @@ struct qcom_smmu {
struct arm_smmu_device smmu;
};
+static const struct of_device_id qcom_smmu_client_of_match[] = {
+ { .compatible = "qcom,adreno" },
+ { .compatible = "qcom,mdp4" },
+ { .compatible = "qcom,mdss" },
+ { .compatible = "qcom,sc7180-mdss" },
+ { .compatible = "qcom,sdm845-mdss" },
+ { }
+};
+
+static int qcom_smmu_def_domain_type(struct device *dev)
+{
+ const struct of_device_id *match =
+ of_match_device(qcom_smmu_client_of_match, dev);
+
+ return match ? IOMMU_DOMAIN_IDENTITY : 0;
+}
+
static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
{
int ret;
@@ -41,6 +59,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
}
static const struct arm_smmu_impl qcom_smmu_impl = {
+ .def_domain_type = qcom_smmu_def_domain_type,
.reset = qcom_smmu500_reset,
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv4 5/6] dt-bindings: remoteproc: qcom: Add iommus property
From: Sibi Sankar Add iommus property to allow Q6 modem to boot on platforms which do not have trustZone. Signed-off-by: Sibi Sankar Signed-off-by: Sai Prakash Ranjan Acked-by: Rob Herring --- Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 88dfa3fc15f7..130e50aab741 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -184,6 +184,9 @@ For the compatible strings below the following phandle references are required: followed by the offset within syscon for conn_box_spare0 register. +The Hexagon node must contain iommus property as described in ../iommu/iommu.txt +on platforms which do not have TrustZone. + = SUBNODES: The Hexagon node must contain two subnodes, named "mba" and "mpss" representing the memory regions used by the Hexagon firmware. Each sub-node must contain: -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv4 0/6] iommu/arm-smmu: Allow client devices to select identity mapping
This series allows DRM, Modem devices to set a default identity mapping in qcom smmu implementation. Patch 1 is cleanup to support other SoCs to call into QCOM specific implementation. Patch 2 sets the default identity domain for DRM devices. Patch 3 implements def_domain_type callback for arm-smmu. Patch 4 sets the default identity domain for modem device. Patch 5-6 adds the iommus property for mss pil. This is based on Joerg's tree: - https://git.kernel.org/pub/scm/linux/kernel/git/joro/linux.git/log/?h=iommu-probe-device-v2 v4: * Updated commit msg for mss pil requesting direct mapping v3: * Use arm_smmu_master_cfg to get impl instead of long way as per Robin. * Use def_domain_type name for the callback in arm_smmu_imp as per Robin Jordan Crouse (1): iommu/arm-smmu: Allow client devices to select direct mapping Sai Prakash Ranjan (2): iommu: arm-smmu-impl: Convert to a generic reset implementation iommu/arm-smmu: Implement iommu_ops->def_domain_type call-back Sibi Sankar (3): iommu/arm-smmu-qcom: Request direct mapping for modem device dt-bindings: remoteproc: qcom: Add iommus property arm64: dts: qcom: sdm845-cheza: Add iommus property .../bindings/remoteproc/qcom,q6v5.txt | 3 ++ arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi| 5 +++ drivers/iommu/arm-smmu-impl.c | 8 ++-- drivers/iommu/arm-smmu-qcom.c | 37 +-- drivers/iommu/arm-smmu.c | 12 ++ drivers/iommu/arm-smmu.h | 1 + 6 files changed, 60 insertions(+), 6 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv4 4/6] iommu/arm-smmu-qcom: Request direct mapping for modem device
From: Sibi Sankar
The Q6 modem sub-system has direct access to DDR through memnoc.
Also SMMU is not expected to provide access control/translation
for these SIDs (sandboxing of the modem is achieved through XPUs
engaged using SMC calls). So request direct mapping for modem on
platforms which don't have TrustZone.
Signed-off-by: Sibi Sankar
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu-qcom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 5bedf21587a5..cf01d0215a39 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -17,7 +17,9 @@ static const struct of_device_id qcom_smmu_client_of_match[]
= {
{ .compatible = "qcom,mdp4" },
{ .compatible = "qcom,mdss" },
{ .compatible = "qcom,sc7180-mdss" },
+ { .compatible = "qcom,sc7180-mss-pil" },
{ .compatible = "qcom,sdm845-mdss" },
+ { .compatible = "qcom,sdm845-mss-pil" },
{ }
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv4 1/6] iommu: arm-smmu-impl: Convert to a generic reset implementation
Currently the QCOM specific smmu reset implementation is very
specific to SDM845 SoC and has a wait-for-safe logic which
may not be required for other SoCs. So move the SDM845 specific
logic to its specific reset function. Also add SC7180 SMMU
compatible for calling into QCOM specific implementation.
Signed-off-by: Sai Prakash Ranjan
Reviewed-by: Bjorn Andersson
Reviewed-by: Stephen Boyd
Reviewed-by: Robin Murphy
---
drivers/iommu/arm-smmu-impl.c | 8 +---
drivers/iommu/arm-smmu-qcom.c | 16 +---
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
index 74d97a886e93..c75b9d957b70 100644
--- a/drivers/iommu/arm-smmu-impl.c
+++ b/drivers/iommu/arm-smmu-impl.c
@@ -150,6 +150,8 @@ static const struct arm_smmu_impl arm_mmu500_impl = {
struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
{
+ const struct device_node *np = smmu->dev->of_node;
+
/*
* We will inevitably have to combine model-specific implementation
* quirks with platform-specific integration quirks, but everything
@@ -166,11 +168,11 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
arm_smmu_device *smmu)
break;
}
- if (of_property_read_bool(smmu->dev->of_node,
- "calxeda,smmu-secure-config-access"))
+ if (of_property_read_bool(np, "calxeda,smmu-secure-config-access"))
smmu->impl = _impl;
- if (of_device_is_compatible(smmu->dev->of_node, "qcom,sdm845-smmu-500"))
+ if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
+ of_device_is_compatible(np, "qcom,sc7180-smmu-500"))
return qcom_smmu_impl_init(smmu);
return smmu;
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 24c071c1d8b0..64a4ab270ab7 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -15,8 +15,6 @@ static int qcom_sdm845_smmu500_reset(struct arm_smmu_device
*smmu)
{
int ret;
- arm_mmu500_reset(smmu);
-
/*
* To address performance degradation in non-real time clients,
* such as USB and UFS, turn off wait-for-safe on sdm845 based boards,
@@ -30,8 +28,20 @@ static int qcom_sdm845_smmu500_reset(struct arm_smmu_device
*smmu)
return ret;
}
+static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
+{
+ const struct device_node *np = smmu->dev->of_node;
+
+ arm_mmu500_reset(smmu);
+
+ if (of_device_is_compatible(np, "qcom,sdm845-smmu-500"))
+ return qcom_sdm845_smmu500_reset(smmu);
+
+ return 0;
+}
+
static const struct arm_smmu_impl qcom_smmu_impl = {
- .reset = qcom_sdm845_smmu500_reset,
+ .reset = qcom_smmu500_reset,
};
struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces
On Mon, Apr 20, 2020 at 10:48:50AM -0700, Jacob Pan wrote: > On Mon, 20 Apr 2020 10:57:27 -0300 > Jason Gunthorpe wrote: > > > On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote: > > > On Thu, Apr 16, 2020 at 05:13:31AM -0700, Christoph Hellwig wrote: > > > > On Thu, Apr 16, 2020 at 10:54:02AM +0200, Jean-Philippe Brucker > > > > wrote: > > > > > On Thu, Apr 16, 2020 at 12:28:52AM -0700, Christoph Hellwig > > > > > wrote: > > > > > > > + rcu_read_lock(); > > > > > > > + hlist_for_each_entry_rcu(bond, _mm->devices, > > > > > > > mm_node) > > > > > > > + io_mm->ops->invalidate(bond->sva.dev, > > > > > > > io_mm->pasid, io_mm->ctx, > > > > > > > +start, end - start); > > > > > > > + rcu_read_unlock(); > > > > > > > +} > > > > > > > > > > > > What is the reason that the devices don't register their own > > > > > > notifiers? This kinds of multiplexing is always rather messy, > > > > > > and you do it for all the methods. > > > > > > > > > > This sends TLB and ATC invalidations through the IOMMU, it > > > > > doesn't go through device drivers > > > > > > > > I don't think we mean the same thing, probably because of my > > > > rather imprecise use of the word device. > > > > > > > > What I mean is that the mmu_notifier should not be embedded into > > > > the io_mm structure (whch btw, seems to have a way to generic > > > > name, just like all other io_* prefixed names), but instead into > > > > the iommu_bond structure. That avoid the whole multiplexing > > > > layer. > > > > > > Right, I can see the appeal. I still like having a single mmu > > > notifier per mm because it ensures we allocate a single PASID per > > > mm (as required by x86). I suppose one alternative is to maintain a > > > hashtable of mm->pasid, to avoid iterating over all bonds during > > > allocation. > > > > I've been getting rid of hash tables like this.. Adding it to the > > mm_struct does seem reasonable, I think PASID is a pretty broad > > concept now. > > > Agreed, perhaps Fenghua can consider that in his patchset. It would > help align life cycles as well. > https://lkml.org/lkml/2020/3/30/910> Seems we depend on each other: my patch defines pasid in mm_struct. I can free PASID in your detach() function. Thanks. -Fenghua ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv3 4/6] iommu/arm-smmu-qcom: Request direct mapping for modem device
Hi Robin, On 2020-04-20 22:39, Robin Murphy wrote: On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote: From: Sibi Sankar Request direct mapping for modem on platforms which don't have TrustZone (which programs the modem SIDs) to prevent the following global faults seen on Cheza/Trogdor: Not strictly true - it's patch #6/6 that prevents *those* faults (and these days the driver should be reporting unmatched streams a little more helpfully). This change would resolve the context faults and/or weird memory corruption that might result from applying patch #6 alone - this is the crazy thing where transactions sometimes go directly to DRAM round the side of the SMMU so we can never safely remap anything, right? True this doesnt prevent global faults, the fault details should go to patch6. I'll update the commit msg something like below: The Q6 modem sub-system has direct access to DDR through memnoc. Also SMMU is not expected to provide access control/translation for these SIDs (sandboxing of the modem is achieved through XPUs engaged using SMC calls). Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces
Am 2020-04-20 um 1:44 p.m. schrieb Jacob Pan: >> The bottom line is, when you allocate a PASID for a context, you want >> to know how small it needs to be for all the devices that want to use >> it. If you make it too big, some device will not be able to use it. >> If you make it too small, you waste precious PASIDs that could be >> used for other contexts that need them. >> > So for AMD, system-wide PASID allocation works with the > restriction/optimization above? > Yes for KFD. On multi-GPU systems we allocate one PASID for the whole process and use it on all GPUs. For AMDGPU graphics contexts, we allocate one PASID for each per-GPU context. But they're allocated from a single global PASID namespace managed by the AMDGPU driver and shared with KFD. So we're wasting PASIDs here, but we are compatible with a single system-wide PASID namespace. Regards, Felix ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces
On Mon, 20 Apr 2020 10:57:27 -0300 Jason Gunthorpe wrote: > On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote: > > On Thu, Apr 16, 2020 at 05:13:31AM -0700, Christoph Hellwig wrote: > > > On Thu, Apr 16, 2020 at 10:54:02AM +0200, Jean-Philippe Brucker > > > wrote: > > > > On Thu, Apr 16, 2020 at 12:28:52AM -0700, Christoph Hellwig > > > > wrote: > > > > > > + rcu_read_lock(); > > > > > > + hlist_for_each_entry_rcu(bond, _mm->devices, > > > > > > mm_node) > > > > > > + io_mm->ops->invalidate(bond->sva.dev, > > > > > > io_mm->pasid, io_mm->ctx, > > > > > > + start, end - start); > > > > > > + rcu_read_unlock(); > > > > > > +} > > > > > > > > > > What is the reason that the devices don't register their own > > > > > notifiers? This kinds of multiplexing is always rather messy, > > > > > and you do it for all the methods. > > > > > > > > This sends TLB and ATC invalidations through the IOMMU, it > > > > doesn't go through device drivers > > > > > > I don't think we mean the same thing, probably because of my > > > rather imprecise use of the word device. > > > > > > What I mean is that the mmu_notifier should not be embedded into > > > the io_mm structure (whch btw, seems to have a way to generic > > > name, just like all other io_* prefixed names), but instead into > > > the iommu_bond structure. That avoid the whole multiplexing > > > layer. > > > > Right, I can see the appeal. I still like having a single mmu > > notifier per mm because it ensures we allocate a single PASID per > > mm (as required by x86). I suppose one alternative is to maintain a > > hashtable of mm->pasid, to avoid iterating over all bonds during > > allocation. > > I've been getting rid of hash tables like this.. Adding it to the > mm_struct does seem reasonable, I think PASID is a pretty broad > concept now. > Agreed, perhaps Fenghua can consider that in his patchset. It would help align life cycles as well. https://lkml.org/lkml/2020/3/30/910 > Jason [Jacob Pan] ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces
On Mon, 20 Apr 2020 11:00:28 -0400 Felix Kuehling wrote: > Am 2020-04-20 um 8:40 a.m. schrieb Christian König: > > Am 20.04.20 um 13:55 schrieb Christoph Hellwig: > >> On Mon, Apr 20, 2020 at 01:44:56PM +0200, Christian König wrote: > >>> Am 20.04.20 um 10:10 schrieb Christoph Hellwig: > On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker > wrote: > > Right, I can see the appeal. I still like having a single mmu > > notifier per > > mm because it ensures we allocate a single PASID per mm (as > > required by > > x86). I suppose one alternative is to maintain a hashtable of > > mm->pasid, > > to avoid iterating over all bonds during allocation. > Given that the PASID is a pretty generic and important concept > can we just add it directly to the mm_struct and allocate it > lazily once we first need it? > >>> Well the problem is that the PASID might as well be device > >>> specific. E.g. > >>> some devices use 16bit PASIDs, some 15bit, some other only 12bit. > >>> > >>> So what could (at least in theory) happen is that you need to > >>> allocate different PASIDs for the same process because different > >>> devices need one. > >> This directly contradicts the statement from Jean-Philippe above > >> that x86 requires a single PASID per mm_struct. If we may need > >> different PASIDs for different devices and can actually support > >> this just allocating one per [device, mm_struct] would make most > >> sense of me, as it doesn't couple otherwise disjoint state. > > > > Well I'm not an expert on this topic. Felix can probably tell you a > > bit more about that. > > > > Maybe it is sufficient to keep the allocated PASIDs as small as > > possible and return an appropriate error if a device can't deal with > > the allocated number. > > > > If a device can only deal with 12bit PASIDs and more than 2^12 try > > to use it there isn't much else we can do than returning an error > > anyway. > > I'm probably missing some context. But let me try giving a useful > reply. > > The hardware allows you to have different PASIDs for each device > referring to the same address space. But I think it's OK for software > to choose not to do that. If Linux wants to manage one PASID > namespace for all devices, that's a reasonable choice IMO. > On VT-d, system wide PASID namespace is required. Here is a section of the documentation I am working on. Namespaces IOASIDs are limited system resources that default to 20 bits in size. Since each device has its own table, theoretically the namespace can be per device also. However, VT-d also supports shared workqueue and ENQCMD[1] where one IOASID could be used to submit work on multiple devices. This requires IOASID to be system-wide on Intel VT-d platforms. This is also the reason why guest must use emulated virtual command interface to allocate IOASID from the host. On VT-d, storage of IOASID table is at per device while the granularity of assignment is per IOASID. Even though, each guest IOASID must have a backing host IOASID, guest IOASID can be different than its host IOASID. The namespace of guest IOASID is controlled by VMM, which decideds whether identity mapping of G-H IOASIDs is necessary. 1. https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf For the per mm_struct PASID question by Christian, we are proposing that in x86 context and a lazy free. https://lkml.org/lkml/2020/3/30/910 > Different devices have different limits for the size of PASID they can > support. For example AMD GPUs support 16-bits but the IOMMU supports > less. So on APUs we use small PASIDs for contexts that want to use > IOMMUv2 to access memory, but bigger PASIDs for contexts that do not. > > I choose the word "context" deliberately, because the amdgpu driver > uses PASIDs even when we're not using IOMMUv2, and we're using them to > identify GPU virtual address spaces. There can be more than one per > process. In practice you can have two, one for graphics (not SVM, > doesn't use IOMMUv2) and one for KFD compute (SVM, can use IOMMUv2 on > APUs). > > Because the IOMMUv2 supports only smaller PASIDs, we want to avoid > exhausting that space with PASID allocations that don't use the > IOMMUv2. So our PASID allocation function has a "size" parameter, and > we try to allocated a PASID as big as possible in order to leave more > precious smaller PASIDs for contexts that need them. > > The bottom line is, when you allocate a PASID for a context, you want > to know how small it needs to be for all the devices that want to use > it. If you make it too big, some device will not be able to use it. > If you make it too small, you waste precious PASIDs that could be > used for other contexts that need them. > So for AMD, system-wide PASID allocation works with the restriction/optimization above? >
Re: [PATCHv3 4/6] iommu/arm-smmu-qcom: Request direct mapping for modem device
On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote:
From: Sibi Sankar
Request direct mapping for modem on platforms which don't have TrustZone
(which programs the modem SIDs) to prevent the following global faults seen
on Cheza/Trogdor:
Not strictly true - it's patch #6/6 that prevents *those* faults (and
these days the driver should be reporting unmatched streams a little
more helpfully). This change would resolve the context faults and/or
weird memory corruption that might result from applying patch #6 alone -
this is the crazy thing where transactions sometimes go directly to DRAM
round the side of the SMMU so we can never safely remap anything, right?
Robin.
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x,
GFSYNR1 0x0781, GFSYNR2 0x
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x,
GFSYNR1 0x0461, GFSYNR2 0x
Signed-off-by: Sibi Sankar
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu-qcom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 5bedf21587a5..cf01d0215a39 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -17,7 +17,9 @@ static const struct of_device_id qcom_smmu_client_of_match[]
= {
{ .compatible = "qcom,mdp4" },
{ .compatible = "qcom,mdss" },
{ .compatible = "qcom,sc7180-mdss" },
+ { .compatible = "qcom,sc7180-mss-pil" },
{ .compatible = "qcom,sdm845-mdss" },
+ { .compatible = "qcom,sdm845-mss-pil" },
{ }
};
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv3 3/6] iommu/arm-smmu: Implement iommu_ops->def_domain_type call-back
On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote:
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Modulo any further changes to the default domain rework,
Reviewed-by: Robin Murphy
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index e622f4e33379..b345a86085ce 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1609,6 +1609,17 @@ static void arm_smmu_get_resv_regions(struct device *dev,
iommu_dma_get_resv_regions(dev, head);
}
+static int arm_smmu_def_domain_type(struct device *dev)
+{
+ struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
+ const struct arm_smmu_impl *impl = cfg->smmu->impl;
+
+ if (impl && impl->def_domain_type)
+ return impl->def_domain_type(dev);
+
+ return 0;
+}
+
static struct iommu_ops arm_smmu_ops = {
.capable= arm_smmu_capable,
.domain_alloc = arm_smmu_domain_alloc,
@@ -1627,6 +1638,7 @@ static struct iommu_ops arm_smmu_ops = {
.of_xlate = arm_smmu_of_xlate,
.get_resv_regions = arm_smmu_get_resv_regions,
.put_resv_regions = generic_iommu_put_resv_regions,
+ .def_domain_type= arm_smmu_def_domain_type,
.pgsize_bitmap = -1UL, /* Restricted during device attach */
};
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv3 2/6] iommu/arm-smmu: Allow client devices to select direct mapping
On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Neat and tidy :)
Reviewed-by: Robin Murphy
Strictly, I think patch #3/6 should really have come before this one
(with the header change moved accordingly), but don't bother resending
just for that.
Thanks,
Robin.
Signed-off-by: Jordan Crouse
Co-developed-by: Sai Prakash Ranjan
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu-qcom.c | 19 +++
drivers/iommu/arm-smmu.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 64a4ab270ab7..5bedf21587a5 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -3,6 +3,7 @@
* Copyright (c) 2019, The Linux Foundation. All rights reserved.
*/
+#include
#include
#include "arm-smmu.h"
@@ -11,6 +12,23 @@ struct qcom_smmu {
struct arm_smmu_device smmu;
};
+static const struct of_device_id qcom_smmu_client_of_match[] = {
+ { .compatible = "qcom,adreno" },
+ { .compatible = "qcom,mdp4" },
+ { .compatible = "qcom,mdss" },
+ { .compatible = "qcom,sc7180-mdss" },
+ { .compatible = "qcom,sdm845-mdss" },
+ { }
+};
+
+static int qcom_smmu_def_domain_type(struct device *dev)
+{
+ const struct of_device_id *match =
+ of_match_device(qcom_smmu_client_of_match, dev);
+
+ return match ? IOMMU_DOMAIN_IDENTITY : 0;
+}
+
static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
{
int ret;
@@ -41,6 +59,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
}
static const struct arm_smmu_impl qcom_smmu_impl = {
+ .def_domain_type = qcom_smmu_def_domain_type,
.reset = qcom_smmu500_reset,
};
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index 8d1cd54d82a6..d172c024be61 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -386,6 +386,7 @@ struct arm_smmu_impl {
int (*init_context)(struct arm_smmu_domain *smmu_domain);
void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
int status);
+ int (*def_domain_type)(struct device *dev);
};
static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv3 0/6] iommu/arm-smmu: Allow client devices to select identity mapping
This series allows DRM, Modem devices to set a default identity mapping in qcom smmu implementation. Patch 1 is cleanup to support other SoCs to call into QCOM specific implementation. Patch 2 sets the default identity domain for DRM devices. Patch 3 implements def_domain_type callback for arm-smmu. Patch 4 sets the default identity domain for modem device. Patch 5-6 adds the iommus property for mss pil. This is based on Joerg's tree: - https://git.kernel.org/pub/scm/linux/kernel/git/joro/linux.git/log/?h=iommu-probe-device-v2 v3: * Use arm_smmu_master_cfg to get impl instead of long way as per Robin. * Use def_domain_type name for the callback in arm_smmu_imp as per Robin Jordan Crouse (1): iommu/arm-smmu: Allow client devices to select direct mapping Sai Prakash Ranjan (2): iommu: arm-smmu-impl: Convert to a generic reset implementation iommu/arm-smmu: Implement iommu_ops->def_domain_type call-back Sibi Sankar (3): iommu/arm-smmu-qcom: Request direct mapping for modem device dt-bindings: remoteproc: qcom: Add iommus property arm64: dts: qcom: sdm845-cheza: Add iommus property .../bindings/remoteproc/qcom,q6v5.txt | 3 ++ arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi| 5 +++ drivers/iommu/arm-smmu-impl.c | 8 ++-- drivers/iommu/arm-smmu-qcom.c | 37 +-- drivers/iommu/arm-smmu.c | 12 ++ drivers/iommu/arm-smmu.h | 1 + 6 files changed, 60 insertions(+), 6 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv3 5/6] dt-bindings: remoteproc: qcom: Add iommus property
From: Sibi Sankar Add iommus property to allow Q6 modem to boot on platforms which do not have trustZone. Signed-off-by: Sibi Sankar Signed-off-by: Sai Prakash Ranjan Acked-by: Rob Herring --- Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 88dfa3fc15f7..130e50aab741 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -184,6 +184,9 @@ For the compatible strings below the following phandle references are required: followed by the offset within syscon for conn_box_spare0 register. +The Hexagon node must contain iommus property as described in ../iommu/iommu.txt +on platforms which do not have TrustZone. + = SUBNODES: The Hexagon node must contain two subnodes, named "mba" and "mpss" representing the memory regions used by the Hexagon firmware. Each sub-node must contain: -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv3 6/6] arm64: dts: qcom: sdm845-cheza: Add iommus property
From: Sibi Sankar
Add iommus property to remoteproc modem node.
Signed-off-by: Sibi Sankar
Signed-off-by: Sai Prakash Ranjan
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
index 9070be43a309..07081da2c83e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -631,6 +631,11 @@ ap_ts_i2c: {
status = "okay";
};
+_pil {
+ iommus = <_smmu 0x780 0x1>,
+<_smmu 0x724 0x3>;
+};
+
_pwrkey {
status = "disabled";
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv3 1/6] iommu: arm-smmu-impl: Convert to a generic reset implementation
Currently the QCOM specific smmu reset implementation is very
specific to SDM845 SoC and has a wait-for-safe logic which
may not be required for other SoCs. So move the SDM845 specific
logic to its specific reset function. Also add SC7180 SMMU
compatible for calling into QCOM specific implementation.
Signed-off-by: Sai Prakash Ranjan
Reviewed-by: Bjorn Andersson
Reviewed-by: Stephen Boyd
Reviewed-by: Robin Murphy
---
drivers/iommu/arm-smmu-impl.c | 8 +---
drivers/iommu/arm-smmu-qcom.c | 16 +---
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
index 74d97a886e93..c75b9d957b70 100644
--- a/drivers/iommu/arm-smmu-impl.c
+++ b/drivers/iommu/arm-smmu-impl.c
@@ -150,6 +150,8 @@ static const struct arm_smmu_impl arm_mmu500_impl = {
struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
{
+ const struct device_node *np = smmu->dev->of_node;
+
/*
* We will inevitably have to combine model-specific implementation
* quirks with platform-specific integration quirks, but everything
@@ -166,11 +168,11 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
arm_smmu_device *smmu)
break;
}
- if (of_property_read_bool(smmu->dev->of_node,
- "calxeda,smmu-secure-config-access"))
+ if (of_property_read_bool(np, "calxeda,smmu-secure-config-access"))
smmu->impl = _impl;
- if (of_device_is_compatible(smmu->dev->of_node, "qcom,sdm845-smmu-500"))
+ if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
+ of_device_is_compatible(np, "qcom,sc7180-smmu-500"))
return qcom_smmu_impl_init(smmu);
return smmu;
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 24c071c1d8b0..64a4ab270ab7 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -15,8 +15,6 @@ static int qcom_sdm845_smmu500_reset(struct arm_smmu_device
*smmu)
{
int ret;
- arm_mmu500_reset(smmu);
-
/*
* To address performance degradation in non-real time clients,
* such as USB and UFS, turn off wait-for-safe on sdm845 based boards,
@@ -30,8 +28,20 @@ static int qcom_sdm845_smmu500_reset(struct arm_smmu_device
*smmu)
return ret;
}
+static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
+{
+ const struct device_node *np = smmu->dev->of_node;
+
+ arm_mmu500_reset(smmu);
+
+ if (of_device_is_compatible(np, "qcom,sdm845-smmu-500"))
+ return qcom_sdm845_smmu500_reset(smmu);
+
+ return 0;
+}
+
static const struct arm_smmu_impl qcom_smmu_impl = {
- .reset = qcom_sdm845_smmu500_reset,
+ .reset = qcom_smmu500_reset,
};
struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv3 3/6] iommu/arm-smmu: Implement iommu_ops->def_domain_type call-back
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index e622f4e33379..b345a86085ce 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1609,6 +1609,17 @@ static void arm_smmu_get_resv_regions(struct device *dev,
iommu_dma_get_resv_regions(dev, head);
}
+static int arm_smmu_def_domain_type(struct device *dev)
+{
+ struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
+ const struct arm_smmu_impl *impl = cfg->smmu->impl;
+
+ if (impl && impl->def_domain_type)
+ return impl->def_domain_type(dev);
+
+ return 0;
+}
+
static struct iommu_ops arm_smmu_ops = {
.capable= arm_smmu_capable,
.domain_alloc = arm_smmu_domain_alloc,
@@ -1627,6 +1638,7 @@ static struct iommu_ops arm_smmu_ops = {
.of_xlate = arm_smmu_of_xlate,
.get_resv_regions = arm_smmu_get_resv_regions,
.put_resv_regions = generic_iommu_put_resv_regions,
+ .def_domain_type= arm_smmu_def_domain_type,
.pgsize_bitmap = -1UL, /* Restricted during device attach */
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv3 4/6] iommu/arm-smmu-qcom: Request direct mapping for modem device
From: Sibi Sankar
Request direct mapping for modem on platforms which don't have TrustZone
(which programs the modem SIDs) to prevent the following global faults seen
on Cheza/Trogdor:
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x,
GFSYNR1 0x0781, GFSYNR2 0x
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x,
GFSYNR1 0x0461, GFSYNR2 0x
Signed-off-by: Sibi Sankar
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu-qcom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 5bedf21587a5..cf01d0215a39 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -17,7 +17,9 @@ static const struct of_device_id qcom_smmu_client_of_match[]
= {
{ .compatible = "qcom,mdp4" },
{ .compatible = "qcom,mdss" },
{ .compatible = "qcom,sc7180-mdss" },
+ { .compatible = "qcom,sc7180-mss-pil" },
{ .compatible = "qcom,sdm845-mdss" },
+ { .compatible = "qcom,sdm845-mss-pil" },
{ }
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv3 2/6] iommu/arm-smmu: Allow client devices to select direct mapping
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Signed-off-by: Jordan Crouse
Co-developed-by: Sai Prakash Ranjan
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu-qcom.c | 19 +++
drivers/iommu/arm-smmu.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 64a4ab270ab7..5bedf21587a5 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -3,6 +3,7 @@
* Copyright (c) 2019, The Linux Foundation. All rights reserved.
*/
+#include
#include
#include "arm-smmu.h"
@@ -11,6 +12,23 @@ struct qcom_smmu {
struct arm_smmu_device smmu;
};
+static const struct of_device_id qcom_smmu_client_of_match[] = {
+ { .compatible = "qcom,adreno" },
+ { .compatible = "qcom,mdp4" },
+ { .compatible = "qcom,mdss" },
+ { .compatible = "qcom,sc7180-mdss" },
+ { .compatible = "qcom,sdm845-mdss" },
+ { }
+};
+
+static int qcom_smmu_def_domain_type(struct device *dev)
+{
+ const struct of_device_id *match =
+ of_match_device(qcom_smmu_client_of_match, dev);
+
+ return match ? IOMMU_DOMAIN_IDENTITY : 0;
+}
+
static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
{
int ret;
@@ -41,6 +59,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
}
static const struct arm_smmu_impl qcom_smmu_impl = {
+ .def_domain_type = qcom_smmu_def_domain_type,
.reset = qcom_smmu500_reset,
};
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index 8d1cd54d82a6..d172c024be61 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -386,6 +386,7 @@ struct arm_smmu_impl {
int (*init_context)(struct arm_smmu_domain *smmu_domain);
void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
int status);
+ int (*def_domain_type)(struct device *dev);
};
static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 2/6] iommu/arm-smmu: Allow client devices to select direct mapping
On 2020-04-20 21:27, Robin Murphy wrote:
On 2020-04-20 3:37 pm, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Signed-off-by: Jordan Crouse
Co-developed-by: Sai Prakash Ranjan
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu-qcom.c | 19 +++
drivers/iommu/arm-smmu.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/iommu/arm-smmu-qcom.c
b/drivers/iommu/arm-smmu-qcom.c
index 64a4ab270ab7..0b3f159065aa 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -3,6 +3,7 @@
* Copyright (c) 2019, The Linux Foundation. All rights reserved.
*/
+#include
#include
#include "arm-smmu.h"
@@ -11,6 +12,23 @@ struct qcom_smmu {
struct arm_smmu_device smmu;
};
+static const struct of_device_id qcom_smmu_client_of_match[] = {
+ { .compatible = "qcom,adreno" },
+ { .compatible = "qcom,mdp4" },
+ { .compatible = "qcom,mdss" },
+ { .compatible = "qcom,sc7180-mdss" },
+ { .compatible = "qcom,sdm845-mdss" },
+ { }
+};
+
+static int qcom_smmu_request_domain(struct device *dev)
+{
+ const struct of_device_id *match =
+ of_match_device(qcom_smmu_client_of_match, dev);
+
+ return match ? IOMMU_DOMAIN_IDENTITY : 0;
+}
+
static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
{
int ret;
@@ -41,6 +59,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device
*smmu)
}
static const struct arm_smmu_impl qcom_smmu_impl = {
+ .req_domain = qcom_smmu_request_domain,
.reset = qcom_smmu500_reset,
};
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index 8d1cd54d82a6..662fdb4dccd2 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -386,6 +386,7 @@ struct arm_smmu_impl {
int (*init_context)(struct arm_smmu_domain *smmu_domain);
void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
int status);
+ int (*req_domain)(struct device *dev);
Nit: since the point is to implement the full
iommu_ops::def_domain_type interface, can we call it def_domain_type
please?
Sure, will send the next version shortly.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 3/6] iommu/arm-smmu: Implement iommu_ops->def_domain_type call-back
Hi Robin,
On 2020-04-20 20:56, Robin Murphy wrote:
On 2020-04-20 3:37 pm, Sai Prakash Ranjan wrote:
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index e622f4e33379..b5d1d52dfbb8 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1609,6 +1609,25 @@ static void arm_smmu_get_resv_regions(struct
device *dev,
iommu_dma_get_resv_regions(dev, head);
}
+static int arm_smmu_def_domain_type(struct device *dev)
+{
+ struct iommu_fwspec *fwspec;
+ struct arm_smmu_device *smmu;
+
+ fwspec = dev_iommu_fwspec_get(dev);
+ if (!fwspec || fwspec->ops != _smmu_ops)
+ return -ENODEV;
+
+ smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
+ if (!smmu)
+ return -ENODEV;
+
AFAICS this should only ever be called for a device in a group, which
means an initial ->probe_device has succeeded and rather than
defensively going the long way round, we can safely assume this:
struct arm_smmu_master_cfg = dev_iommu_priv_get(dev);
struct arm_smmu_impl *impl = cfg->smmu->impl;
if (impl && impl->req_domain)
return impl->req_domain(dev);
Yes you are right, will use this.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 2/4] iommu: Add Allwinner H6 IOMMU driver
On 2020-04-20 3:39 pm, Maxime Ripard wrote: Hi, On Wed, Apr 08, 2020 at 04:06:49PM +0200, Joerg Roedel wrote: On Wed, Apr 01, 2020 at 01:47:10PM +0200, Maxime Ripard wrote: As far as I understand it, the page table can be accessed concurrently since the framework doesn't seem to provide any serialization / locking, shouldn't we have some locks to prevent concurrent access? The dma-iommu code makes sure that there are no concurrent accesses to the same address-range of the page-table, but there can (and will) be concurrent accesses to the same page-table, just for different parts of the address space. Making this lock-less usually involves updating non-leaf page-table entries using atomic compare-exchange instructions. That makes sense, thanks! I'm not sure what I should compare with though, do you want to compare with 0 to check if there's already a page table assigned to that DTE? If so, then we should also allocate the possible page table before the fact so that we have something to swap with, and deallocate it if we already had one? Indeed, for an example see arm_v7s_install_table() and how __arm_v7s_map() calls it. The LPAE version in io-pgtable-arm.c does the same too, but with some extra software-bit handshaking to track the cache maintenance state as an optimisation, which you can probably do without trying to make sense of ;) Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces
Am 20.04.20 um 13:55 schrieb Christoph Hellwig: On Mon, Apr 20, 2020 at 01:44:56PM +0200, Christian König wrote: Am 20.04.20 um 10:10 schrieb Christoph Hellwig: On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote: Right, I can see the appeal. I still like having a single mmu notifier per mm because it ensures we allocate a single PASID per mm (as required by x86). I suppose one alternative is to maintain a hashtable of mm->pasid, to avoid iterating over all bonds during allocation. Given that the PASID is a pretty generic and important concept can we just add it directly to the mm_struct and allocate it lazily once we first need it? Well the problem is that the PASID might as well be device specific. E.g. some devices use 16bit PASIDs, some 15bit, some other only 12bit. So what could (at least in theory) happen is that you need to allocate different PASIDs for the same process because different devices need one. This directly contradicts the statement from Jean-Philippe above that x86 requires a single PASID per mm_struct. If we may need different PASIDs for different devices and can actually support this just allocating one per [device, mm_struct] would make most sense of me, as it doesn't couple otherwise disjoint state. Well I'm not an expert on this topic. Felix can probably tell you a bit more about that. Maybe it is sufficient to keep the allocated PASIDs as small as possible and return an appropriate error if a device can't deal with the allocated number. If a device can only deal with 12bit PASIDs and more than 2^12 try to use it there isn't much else we can do than returning an error anyway. Regards, Christian. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 2/6] iommu/arm-smmu: Allow client devices to select direct mapping
On 2020-04-20 3:37 pm, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Signed-off-by: Jordan Crouse
Co-developed-by: Sai Prakash Ranjan
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu-qcom.c | 19 +++
drivers/iommu/arm-smmu.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 64a4ab270ab7..0b3f159065aa 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -3,6 +3,7 @@
* Copyright (c) 2019, The Linux Foundation. All rights reserved.
*/
+#include
#include
#include "arm-smmu.h"
@@ -11,6 +12,23 @@ struct qcom_smmu {
struct arm_smmu_device smmu;
};
+static const struct of_device_id qcom_smmu_client_of_match[] = {
+ { .compatible = "qcom,adreno" },
+ { .compatible = "qcom,mdp4" },
+ { .compatible = "qcom,mdss" },
+ { .compatible = "qcom,sc7180-mdss" },
+ { .compatible = "qcom,sdm845-mdss" },
+ { }
+};
+
+static int qcom_smmu_request_domain(struct device *dev)
+{
+ const struct of_device_id *match =
+ of_match_device(qcom_smmu_client_of_match, dev);
+
+ return match ? IOMMU_DOMAIN_IDENTITY : 0;
+}
+
static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
{
int ret;
@@ -41,6 +59,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
}
static const struct arm_smmu_impl qcom_smmu_impl = {
+ .req_domain = qcom_smmu_request_domain,
.reset = qcom_smmu500_reset,
};
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index 8d1cd54d82a6..662fdb4dccd2 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -386,6 +386,7 @@ struct arm_smmu_impl {
int (*init_context)(struct arm_smmu_domain *smmu_domain);
void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
int status);
+ int (*req_domain)(struct device *dev);
Nit: since the point is to implement the full iommu_ops::def_domain_type
interface, can we call it def_domain_type please?
Robin.
};
static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
IOVA allocation dependency between firmware buffer and remaining buffers
Hi All, I have an IOMMU master which has limitations as mentioned below: 1) The IOMMU master internally executes a firmware, and the firmware memory is allocated by the same master driver. The firmware buffer address should be of the lowest range than other address allocated by the device, or in other words, all the remaining buffer addresses should always be in a higher range than the firmware address. 2) None of the buffer addresses should go beyond 0xC000_ example: If firmware buffer address is buf_fw = 0x8000_5000; All other addresses given to the device should be greater than (0x8000_5000 + firmware size) and less than 0xC000_ Currently, this is being handled with one of the below hacks: 1) By keeping dma_mask in lower range while allocating firmware buffer, and then increasing the dma_mask to higher range for other buffers. 2) By reserving IOVA for firmware at the lowest range and creating direct mappings for the same. I want to know if there is a better way this can be handled with current framework, or if anybody is facing similar problems with their devices, please share how it is taken care. I also think there should be some way the masters can specify the IOVA range they want to limit to for current allocation. Something like a new iommu_ops callback like below: limit_iova_alloc_range(dev, iova_start, iova_end) And, in my driver, the sequence will be: limit_iova_alloc_range(dev, 0x_, 0x1000_); /* via helpers */ alloc( ) firmware buffer using DMA API limit_iova_alloc_range(dev, 0x1000_, 0xC000_); /* via helpers */ alloc( ) other buffers using DMA API Thanks, Ajay Kumar ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces
Am 2020-04-20 um 8:40 a.m. schrieb Christian König: > Am 20.04.20 um 13:55 schrieb Christoph Hellwig: >> On Mon, Apr 20, 2020 at 01:44:56PM +0200, Christian König wrote: >>> Am 20.04.20 um 10:10 schrieb Christoph Hellwig: On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote: > Right, I can see the appeal. I still like having a single mmu > notifier per > mm because it ensures we allocate a single PASID per mm (as > required by > x86). I suppose one alternative is to maintain a hashtable of > mm->pasid, > to avoid iterating over all bonds during allocation. Given that the PASID is a pretty generic and important concept can we just add it directly to the mm_struct and allocate it lazily once we first need it? >>> Well the problem is that the PASID might as well be device specific. >>> E.g. >>> some devices use 16bit PASIDs, some 15bit, some other only 12bit. >>> >>> So what could (at least in theory) happen is that you need to allocate >>> different PASIDs for the same process because different devices need >>> one. >> This directly contradicts the statement from Jean-Philippe above that >> x86 requires a single PASID per mm_struct. If we may need different >> PASIDs for different devices and can actually support this just >> allocating one per [device, mm_struct] would make most sense of me, as >> it doesn't couple otherwise disjoint state. > > Well I'm not an expert on this topic. Felix can probably tell you a > bit more about that. > > Maybe it is sufficient to keep the allocated PASIDs as small as > possible and return an appropriate error if a device can't deal with > the allocated number. > > If a device can only deal with 12bit PASIDs and more than 2^12 try to > use it there isn't much else we can do than returning an error anyway. I'm probably missing some context. But let me try giving a useful reply. The hardware allows you to have different PASIDs for each device referring to the same address space. But I think it's OK for software to choose not to do that. If Linux wants to manage one PASID namespace for all devices, that's a reasonable choice IMO. Different devices have different limits for the size of PASID they can support. For example AMD GPUs support 16-bits but the IOMMU supports less. So on APUs we use small PASIDs for contexts that want to use IOMMUv2 to access memory, but bigger PASIDs for contexts that do not. I choose the word "context" deliberately, because the amdgpu driver uses PASIDs even when we're not using IOMMUv2, and we're using them to identify GPU virtual address spaces. There can be more than one per process. In practice you can have two, one for graphics (not SVM, doesn't use IOMMUv2) and one for KFD compute (SVM, can use IOMMUv2 on APUs). Because the IOMMUv2 supports only smaller PASIDs, we want to avoid exhausting that space with PASID allocations that don't use the IOMMUv2. So our PASID allocation function has a "size" parameter, and we try to allocated a PASID as big as possible in order to leave more precious smaller PASIDs for contexts that need them. The bottom line is, when you allocate a PASID for a context, you want to know how small it needs to be for all the devices that want to use it. If you make it too big, some device will not be able to use it. If you make it too small, you waste precious PASIDs that could be used for other contexts that need them. Regards, Felix ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2 3/6] iommu/arm-smmu: Implement iommu_ops->def_domain_type call-back
On 2020-04-20 3:37 pm, Sai Prakash Ranjan wrote:
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index e622f4e33379..b5d1d52dfbb8 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1609,6 +1609,25 @@ static void arm_smmu_get_resv_regions(struct device *dev,
iommu_dma_get_resv_regions(dev, head);
}
+static int arm_smmu_def_domain_type(struct device *dev)
+{
+ struct iommu_fwspec *fwspec;
+ struct arm_smmu_device *smmu;
+
+ fwspec = dev_iommu_fwspec_get(dev);
+ if (!fwspec || fwspec->ops != _smmu_ops)
+ return -ENODEV;
+
+ smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
+ if (!smmu)
+ return -ENODEV;
+
AFAICS this should only ever be called for a device in a group, which
means an initial ->probe_device has succeeded and rather than
defensively going the long way round, we can safely assume this:
struct arm_smmu_master_cfg = dev_iommu_priv_get(dev);
struct arm_smmu_impl *impl = cfg->smmu->impl;
if (impl && impl->req_domain)
return impl->req_domain(dev);
Or have I misunderstood the flow?
Robin.
+ if (smmu->impl && smmu->impl->req_domain)
+ return smmu->impl->req_domain(dev);
+
+ return 0;
+}
+
static struct iommu_ops arm_smmu_ops = {
.capable= arm_smmu_capable,
.domain_alloc = arm_smmu_domain_alloc,
@@ -1627,6 +1646,7 @@ static struct iommu_ops arm_smmu_ops = {
.of_xlate = arm_smmu_of_xlate,
.get_resv_regions = arm_smmu_get_resv_regions,
.put_resv_regions = generic_iommu_put_resv_regions,
+ .def_domain_type= arm_smmu_def_domain_type,
.pgsize_bitmap = -1UL, /* Restricted during device attach */
};
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3] of_device: removed #include that caused a recursion in included headers
Both of_platform.h and of_device.h were included each other. In of_device.h, removed unneeded #include to of_platform.h and added include to of_platform.h in the files that needs it. Signed-off-by: Hadar Gat Reported-by: kbuild test robot Acked-by: Jonathan Cameron #for-iio Acked-by: Stephen Boyd # clk --- v3: add include to of_platform.h in more files. (reported due other builds) v2: add include to of_platform.h in more files. (reported due other builds) arch/sparc/kernel/pci.c | 1 + arch/sparc/kernel/pci_sabre.c | 1 + arch/sparc/kernel/pci_schizo.c| 1 + arch/sparc/kernel/sbus.c | 1 + arch/sparc/mm/io-unit.c | 1 + arch/sparc/mm/iommu.c | 1 + drivers/base/platform.c | 1 + drivers/bus/imx-weim.c| 1 + drivers/bus/vexpress-config.c | 1 + drivers/clk/mediatek/clk-mt7622-aud.c | 1 + drivers/dma/at_hdmac.c| 1 + drivers/dma/stm32-dmamux.c| 1 + drivers/dma/ti/dma-crossbar.c | 1 + drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 + drivers/gpu/drm/msm/hdmi/hdmi.c | 1 + drivers/gpu/drm/msm/msm_drv.c | 1 + drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1 + drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 + drivers/iio/adc/stm32-adc-core.c | 1 + drivers/iio/adc/stm32-dfsdm-adc.c | 1 + drivers/iio/adc/stm32-dfsdm-core.c| 1 + drivers/iommu/tegra-smmu.c| 1 + drivers/media/platform/coda/coda-common.c | 1 + drivers/memory/atmel-ebi.c| 1 + drivers/mfd/palmas.c | 1 + drivers/mfd/ssbi.c| 1 + drivers/mtd/nand/raw/omap2.c | 1 + drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 1 + drivers/net/ethernet/ti/cpsw.c| 1 + drivers/phy/tegra/xusb.c | 1 + drivers/pinctrl/freescale/pinctrl-imx1-core.c | 1 + drivers/pinctrl/nomadik/pinctrl-nomadik.c | 1 + drivers/soc/samsung/exynos-pmu.c | 1 + drivers/soc/sunxi/sunxi_sram.c| 1 + include/linux/of_device.h | 2 -- lib/genalloc.c| 1 + 36 files changed, 35 insertions(+), 2 deletions(-) diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c index 5ed4382..89ea658 100644 --- a/arch/sparc/kernel/pci.c +++ b/arch/sparc/kernel/pci.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #include diff --git a/arch/sparc/kernel/pci_sabre.c b/arch/sparc/kernel/pci_sabre.c index 3c38ca4..16761d0 100644 --- a/arch/sparc/kernel/pci_sabre.c +++ b/arch/sparc/kernel/pci_sabre.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include diff --git a/arch/sparc/kernel/pci_schizo.c b/arch/sparc/kernel/pci_schizo.c index 421aba0..733f069 100644 --- a/arch/sparc/kernel/pci_schizo.c +++ b/arch/sparc/kernel/pci_schizo.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include diff --git a/arch/sparc/kernel/sbus.c b/arch/sparc/kernel/sbus.c index 32141e1..2f4051f 100644 --- a/arch/sparc/kernel/sbus.c +++ b/arch/sparc/kernel/sbus.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include diff --git a/arch/sparc/mm/io-unit.c b/arch/sparc/mm/io-unit.c index 289276b..5638399 100644 --- a/arch/sparc/mm/io-unit.c +++ b/arch/sparc/mm/io-unit.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include diff --git a/arch/sparc/mm/iommu.c b/arch/sparc/mm/iommu.c index b00dde1..9cbb2e7 100644 --- a/arch/sparc/mm/iommu.c +++ b/arch/sparc/mm/iommu.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 520..f549274b 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c index 28bb65a..8c786da 100644 --- a/drivers/bus/imx-weim.c +++ b/drivers/bus/imx-weim.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/bus/vexpress-config.c b/drivers/bus/vexpress-config.c index ff70575..12b8b0b 100644 --- a/drivers/bus/vexpress-config.c +++ b/drivers/bus/vexpress-config.c @@ -8,6 +8,7 @@ #include #include #include +#include #include diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c b/drivers/clk/mediatek/clk-mt7622-aud.c index 2bd4295..8cbb68f 100644 --- a/drivers/clk/mediatek/clk-mt7622-aud.c +++
Re: [PATCH v2 2/4] iommu: Add Allwinner H6 IOMMU driver
Hi, On Wed, Apr 08, 2020 at 04:06:49PM +0200, Joerg Roedel wrote: > On Wed, Apr 01, 2020 at 01:47:10PM +0200, Maxime Ripard wrote: > > As far as I understand it, the page table can be accessed concurrently > > since the framework doesn't seem to provide any serialization / > > locking, shouldn't we have some locks to prevent concurrent access? > > The dma-iommu code makes sure that there are no concurrent accesses to > the same address-range of the page-table, but there can (and will) be > concurrent accesses to the same page-table, just for different parts of > the address space. > > Making this lock-less usually involves updating non-leaf page-table > entries using atomic compare-exchange instructions. That makes sense, thanks! I'm not sure what I should compare with though, do you want to compare with 0 to check if there's already a page table assigned to that DTE? If so, then we should also allocate the possible page table before the fact so that we have something to swap with, and deallocate it if we already had one? Maxime signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv2 4/6] iommu/arm-smmu-qcom: Request direct mapping for modem device
From: Sibi Sankar
Request direct mapping for modem on platforms which don't have TrustZone
(which programs the modem SIDs) to prevent the following global faults seen
on Cheza/Trogdor:
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x,
GFSYNR1 0x0781, GFSYNR2 0x
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x,
GFSYNR1 0x0461, GFSYNR2 0x
Signed-off-by: Sibi Sankar
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu-qcom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 0b3f159065aa..d74892d3a776 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -17,7 +17,9 @@ static const struct of_device_id qcom_smmu_client_of_match[]
= {
{ .compatible = "qcom,mdp4" },
{ .compatible = "qcom,mdss" },
{ .compatible = "qcom,sc7180-mdss" },
+ { .compatible = "qcom,sc7180-mss-pil" },
{ .compatible = "qcom,sdm845-mdss" },
+ { .compatible = "qcom,sdm845-mss-pil" },
{ }
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv2 5/6] dt-bindings: remoteproc: qcom: Add iommus property
From: Sibi Sankar Add iommus property to allow Q6 modem to boot on platforms which do not have trustZone. Signed-off-by: Sibi Sankar Signed-off-by: Sai Prakash Ranjan Acked-by: Rob Herring --- Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 88dfa3fc15f7..130e50aab741 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -184,6 +184,9 @@ For the compatible strings below the following phandle references are required: followed by the offset within syscon for conn_box_spare0 register. +The Hexagon node must contain iommus property as described in ../iommu/iommu.txt +on platforms which do not have TrustZone. + = SUBNODES: The Hexagon node must contain two subnodes, named "mba" and "mpss" representing the memory regions used by the Hexagon firmware. Each sub-node must contain: -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv2 6/6] arm64: dts: qcom: sdm845-cheza: Add iommus property
From: Sibi Sankar
Add iommus property to remoteproc modem node.
Signed-off-by: Sibi Sankar
Signed-off-by: Sai Prakash Ranjan
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
index 9070be43a309..07081da2c83e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -631,6 +631,11 @@ ap_ts_i2c: {
status = "okay";
};
+_pil {
+ iommus = <_smmu 0x780 0x1>,
+<_smmu 0x724 0x3>;
+};
+
_pwrkey {
status = "disabled";
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv2 2/6] iommu/arm-smmu: Allow client devices to select direct mapping
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Signed-off-by: Jordan Crouse
Co-developed-by: Sai Prakash Ranjan
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu-qcom.c | 19 +++
drivers/iommu/arm-smmu.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 64a4ab270ab7..0b3f159065aa 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -3,6 +3,7 @@
* Copyright (c) 2019, The Linux Foundation. All rights reserved.
*/
+#include
#include
#include "arm-smmu.h"
@@ -11,6 +12,23 @@ struct qcom_smmu {
struct arm_smmu_device smmu;
};
+static const struct of_device_id qcom_smmu_client_of_match[] = {
+ { .compatible = "qcom,adreno" },
+ { .compatible = "qcom,mdp4" },
+ { .compatible = "qcom,mdss" },
+ { .compatible = "qcom,sc7180-mdss" },
+ { .compatible = "qcom,sdm845-mdss" },
+ { }
+};
+
+static int qcom_smmu_request_domain(struct device *dev)
+{
+ const struct of_device_id *match =
+ of_match_device(qcom_smmu_client_of_match, dev);
+
+ return match ? IOMMU_DOMAIN_IDENTITY : 0;
+}
+
static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
{
int ret;
@@ -41,6 +59,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
}
static const struct arm_smmu_impl qcom_smmu_impl = {
+ .req_domain = qcom_smmu_request_domain,
.reset = qcom_smmu500_reset,
};
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index 8d1cd54d82a6..662fdb4dccd2 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -386,6 +386,7 @@ struct arm_smmu_impl {
int (*init_context)(struct arm_smmu_domain *smmu_domain);
void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
int status);
+ int (*req_domain)(struct device *dev);
};
static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv2 3/6] iommu/arm-smmu: Implement iommu_ops->def_domain_type call-back
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index e622f4e33379..b5d1d52dfbb8 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1609,6 +1609,25 @@ static void arm_smmu_get_resv_regions(struct device *dev,
iommu_dma_get_resv_regions(dev, head);
}
+static int arm_smmu_def_domain_type(struct device *dev)
+{
+ struct iommu_fwspec *fwspec;
+ struct arm_smmu_device *smmu;
+
+ fwspec = dev_iommu_fwspec_get(dev);
+ if (!fwspec || fwspec->ops != _smmu_ops)
+ return -ENODEV;
+
+ smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
+ if (!smmu)
+ return -ENODEV;
+
+ if (smmu->impl && smmu->impl->req_domain)
+ return smmu->impl->req_domain(dev);
+
+ return 0;
+}
+
static struct iommu_ops arm_smmu_ops = {
.capable= arm_smmu_capable,
.domain_alloc = arm_smmu_domain_alloc,
@@ -1627,6 +1646,7 @@ static struct iommu_ops arm_smmu_ops = {
.of_xlate = arm_smmu_of_xlate,
.get_resv_regions = arm_smmu_get_resv_regions,
.put_resv_regions = generic_iommu_put_resv_regions,
+ .def_domain_type= arm_smmu_def_domain_type,
.pgsize_bitmap = -1UL, /* Restricted during device attach */
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv2 1/6] iommu: arm-smmu-impl: Convert to a generic reset implementation
Currently the QCOM specific smmu reset implementation is very
specific to SDM845 SoC and has a wait-for-safe logic which
may not be required for other SoCs. So move the SDM845 specific
logic to its specific reset function. Also add SC7180 SMMU
compatible for calling into QCOM specific implementation.
Signed-off-by: Sai Prakash Ranjan
Reviewed-by: Bjorn Andersson
Reviewed-by: Stephen Boyd
Reviewed-by: Robin Murphy
---
drivers/iommu/arm-smmu-impl.c | 8 +---
drivers/iommu/arm-smmu-qcom.c | 16 +---
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
index 74d97a886e93..c75b9d957b70 100644
--- a/drivers/iommu/arm-smmu-impl.c
+++ b/drivers/iommu/arm-smmu-impl.c
@@ -150,6 +150,8 @@ static const struct arm_smmu_impl arm_mmu500_impl = {
struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
{
+ const struct device_node *np = smmu->dev->of_node;
+
/*
* We will inevitably have to combine model-specific implementation
* quirks with platform-specific integration quirks, but everything
@@ -166,11 +168,11 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
arm_smmu_device *smmu)
break;
}
- if (of_property_read_bool(smmu->dev->of_node,
- "calxeda,smmu-secure-config-access"))
+ if (of_property_read_bool(np, "calxeda,smmu-secure-config-access"))
smmu->impl = _impl;
- if (of_device_is_compatible(smmu->dev->of_node, "qcom,sdm845-smmu-500"))
+ if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
+ of_device_is_compatible(np, "qcom,sc7180-smmu-500"))
return qcom_smmu_impl_init(smmu);
return smmu;
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 24c071c1d8b0..64a4ab270ab7 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -15,8 +15,6 @@ static int qcom_sdm845_smmu500_reset(struct arm_smmu_device
*smmu)
{
int ret;
- arm_mmu500_reset(smmu);
-
/*
* To address performance degradation in non-real time clients,
* such as USB and UFS, turn off wait-for-safe on sdm845 based boards,
@@ -30,8 +28,20 @@ static int qcom_sdm845_smmu500_reset(struct arm_smmu_device
*smmu)
return ret;
}
+static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
+{
+ const struct device_node *np = smmu->dev->of_node;
+
+ arm_mmu500_reset(smmu);
+
+ if (of_device_is_compatible(np, "qcom,sdm845-smmu-500"))
+ return qcom_sdm845_smmu500_reset(smmu);
+
+ return 0;
+}
+
static const struct arm_smmu_impl qcom_smmu_impl = {
- .reset = qcom_sdm845_smmu500_reset,
+ .reset = qcom_smmu500_reset,
};
struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCHv2 0/6] iommu/arm-smmu: Allow client devices to select identity mapping
This series allows DRM, Modem devices to set a default identity mapping in qcom smmu implementation. Patch 1 is cleanup to support other SoCs to call into QCOM specific implementation. Patch 2 sets the default identity domain for DRM devices. Patch 3 implements def_domain_type callback for arm-smmu. Patch 4 sets the default identity domain for modem device. Patch 5-6 adds the iommus property for mss pil. This is based on Joerg's tree: - https://git.kernel.org/pub/scm/linux/kernel/git/joro/linux.git/log/?h=iommu-probe-device-v2 Jordan Crouse (1): iommu/arm-smmu: Allow client devices to select direct mapping Sai Prakash Ranjan (2): iommu: arm-smmu-impl: Convert to a generic reset implementation iommu/arm-smmu: Implement iommu_ops->def_domain_type call-back Sibi Sankar (3): iommu/arm-smmu-qcom: Request direct mapping for modem device dt-bindings: remoteproc: qcom: Add iommus property arm64: dts: qcom: sdm845-cheza: Add iommus property .../bindings/remoteproc/qcom,q6v5.txt | 3 ++ arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi| 5 +++ drivers/iommu/arm-smmu-impl.c | 8 ++-- drivers/iommu/arm-smmu-qcom.c | 37 +-- drivers/iommu/arm-smmu.c | 20 ++ drivers/iommu/arm-smmu.h | 1 + 6 files changed, 68 insertions(+), 6 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces
On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote: > On Thu, Apr 16, 2020 at 05:13:31AM -0700, Christoph Hellwig wrote: > > On Thu, Apr 16, 2020 at 10:54:02AM +0200, Jean-Philippe Brucker wrote: > > > On Thu, Apr 16, 2020 at 12:28:52AM -0700, Christoph Hellwig wrote: > > > > > + rcu_read_lock(); > > > > > + hlist_for_each_entry_rcu(bond, _mm->devices, mm_node) > > > > > + io_mm->ops->invalidate(bond->sva.dev, io_mm->pasid, > > > > > io_mm->ctx, > > > > > +start, end - start); > > > > > + rcu_read_unlock(); > > > > > +} > > > > > > > > What is the reason that the devices don't register their own notifiers? > > > > This kinds of multiplexing is always rather messy, and you do it for > > > > all the methods. > > > > > > This sends TLB and ATC invalidations through the IOMMU, it doesn't go > > > through device drivers > > > > I don't think we mean the same thing, probably because of my rather > > imprecise use of the word device. > > > > What I mean is that the mmu_notifier should not be embedded into the > > io_mm structure (whch btw, seems to have a way to generic name, just > > like all other io_* prefixed names), but instead into the > > iommu_bond structure. That avoid the whole multiplexing layer. > > Right, I can see the appeal. I still like having a single mmu notifier per > mm because it ensures we allocate a single PASID per mm (as required by > x86). I suppose one alternative is to maintain a hashtable of mm->pasid, > to avoid iterating over all bonds during allocation. I've been getting rid of hash tables like this.. Adding it to the mm_struct does seem reasonable, I think PASID is a pretty broad concept now. Jason ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH] iommu/amd: fix a race in fetch_pte()
> On Apr 18, 2020, at 2:34 PM, Joerg Roedel wrote:
>
> On Sat, Apr 18, 2020 at 09:01:35AM -0400, Qian Cai wrote:
>> Hard to tell without testing further. I’ll leave that optimization in
>> the future, and focus on fixing those races first.
>
> Yeah right, we should fix the existing races first before introducing
> new ones ;)
>
> Btw, THANKS A LOT for tracking down all these race condition bugs, I am
> not even remotely able to trigger them with the hardware I have around.
>
> I did some hacking and the attached diff shows how I think this race
> condition needs to be fixed. I boot-tested this fix on-top of v5.7-rc1,
> but did no further testing. Can you test it please?
No dice. There could be some other races. For example,
> @@ -1536,16 +1571,19 @@ static u64 *fetch_pte(struct protection_domain
> *domain,
> unsigned long address,
> unsigned long *page_size)
...
> amd_iommu_domain_get_pgtable(domain, );
>
> if (address > PM_LEVEL_SIZE(pgtable.mode))
> return NULL;
>
> level = pgtable.mode - 1;
> pte= [PM_LEVEL_INDEX(level, address)];
<— increase_address_space()
> *page_size = PTE_LEVEL_PAGE_SIZE(level);
>
while (level > 0) {
*page_size = PTE_LEVEL_PAGE_SIZE(level);
Then in iommu_unmap_page(),
while (unmapped < page_size) {
pte = fetch_pte(dom, bus_addr, _size);
…
bus_addr = (bus_addr & ~(unmap_size - 1)) + unmap_size;
bus_addr would be unsync with dom->mode when it enter fetch_pte() again.
Could that be a problem?
[ 5159.274829][ T4057] LTP: starting oom02
[ 5160.382787][ C52] perf: interrupt took too long (7443 > 6208), lowering
kernel.perf_event_max_sample_rate to 26800
[ 5167.951785][ T812] smartpqi :23:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x0027 address=0xfffc flags=0x0010]
[ 5167.964540][ T812] smartpqi :23:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x0027 address=0xfffc1000 flags=0x0010]
[ 5167.977442][ T812] smartpqi :23:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x0027 address=0xfffc1900 flags=0x0010]
[ 5167.989901][ T812] smartpqi :23:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x0027 address=0xfffc1d00 flags=0x0010]
[ 5168.002291][ T812] smartpqi :23:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x0027 address=0xfffc2000 flags=0x0010]
[ 5168.014665][ T812] smartpqi :23:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x0027 address=0xfffc2400 flags=0x0010]
[ 5168.027132][ T812] smartpqi :23:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x0027 address=0xfffc2800 flags=0x0010]
[ 5168.039566][ T812] smartpqi :23:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x0027 address=0xfffc2c00 flags=0x0010]
[ 5168.051956][ T812] smartpqi :23:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x0027 address=0xfffc3000 flags=0x0010]
[ 5168.064310][ T812] smartpqi :23:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x0027 address=0xfffc3400 flags=0x0010]
[ 5168.076652][ T812] AMD-Vi: Event logged [IO_PAGE_FAULT device=23:00.0
domain=0x0027 address=0xfffc3800 flags=0x0010]
[ 5168.088290][ T812] AMD-Vi: Event logged [IO_PAGE_FAULT device=23:00.0
domain=0x0027 address=0xfffc3c00 flags=0x0010]
[ 5183.695829][C8] smartpqi :23:00.0: controller is offline: status
code 0x14803
[ 5183.704390][C8] smartpqi :23:00.0: controller offline
[ 5183.756594][ C101] blk_update_request: I/O error, dev sda, sector 22306304
op 0x1:(WRITE) flags 0x800 phys_seg 4 prio class 0
[ 5183.756628][ C34] sd 0:1:0:0: [sda] tag#655 UNKNOWN(0x2003) Result:
hostbyte=0x01 driverbyte=0x00 cmd_age=15s
[ 5183.756759][ C56] blk_update_request: I/O error, dev sda, sector 58480128
op 0x1:(WRITE) flags 0x8004000 phys_seg 4 prio class 0
[ 5183.756810][ C79] sd 0:1:0:0: [sda] tag#234 UNKNOWN(0x2003) Result:
hostbyte=0x01 driverbyte=0x00 cmd_age=15s
[ 5183.756816][ C121] sd 0:1:0:0: [sda] tag#104 UNKNOWN(0x2003) Result:
hostbyte=0x01 driverbyte=0x00 cmd_age=15s
[ 5183.756837][ T53] sd 0:1:0:0: [sda] tag#4 UNKNOWN(0x2003) Result:
hostbyte=0x01 driverbyte=0x00 cmd_age=15s
[ 5183.756882][ C121] sd 0:1:0:0: [sda] tag#104 CDB: opcode=0x2a 2a 00 00 4d
d4 00 00 02 00 00
[ 5183.756892][ C79] sd 0:1:0:0: [sda] tag#234 CDB: opcode=0x2a 2a 00 02 03
e4 00 00 02 00 00
[ 5183.756909][ C121] blk_update_request: I/O error, dev sda, sector 5100544
op 0x1:(WRITE) flags 0x8004000 phys_seg 4 prio class 0
[ 5183.756920][ C79] blk_update_request: I/O error, dev sda, sector 33809408
op 0x1:(WRITE) flags 0x8004000 phys_seg 4 prio class 0
[ 5183.756939][ T53] sd 0:1:0:0: [sda] tag#4 CDB: opcode=0x2a 2a 00 02 4b f8
00 00 02 00 00
[ 5183.756967][ T53] blk_update_request: I/O error, dev sda, sector 38533120
op 0x1:(WRITE) flags 0x8004000
Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces
Am 20.04.20 um 10:10 schrieb Christoph Hellwig: On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote: Right, I can see the appeal. I still like having a single mmu notifier per mm because it ensures we allocate a single PASID per mm (as required by x86). I suppose one alternative is to maintain a hashtable of mm->pasid, to avoid iterating over all bonds during allocation. Given that the PASID is a pretty generic and important concept can we just add it directly to the mm_struct and allocate it lazily once we first need it? Well the problem is that the PASID might as well be device specific. E.g. some devices use 16bit PASIDs, some 15bit, some other only 12bit. So what could (at least in theory) happen is that you need to allocate different PASIDs for the same process because different devices need one. Regards, Christian. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces
On Mon, Apr 20, 2020 at 01:44:56PM +0200, Christian König wrote: > Am 20.04.20 um 10:10 schrieb Christoph Hellwig: > > On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote: > > > Right, I can see the appeal. I still like having a single mmu notifier per > > > mm because it ensures we allocate a single PASID per mm (as required by > > > x86). I suppose one alternative is to maintain a hashtable of mm->pasid, > > > to avoid iterating over all bonds during allocation. > > Given that the PASID is a pretty generic and important concept can > > we just add it directly to the mm_struct and allocate it lazily once > > we first need it? > > Well the problem is that the PASID might as well be device specific. E.g. > some devices use 16bit PASIDs, some 15bit, some other only 12bit. > > So what could (at least in theory) happen is that you need to allocate > different PASIDs for the same process because different devices need one. This directly contradicts the statement from Jean-Philippe above that x86 requires a single PASID per mm_struct. If we may need different PASIDs for different devices and can actually support this just allocating one per [device, mm_struct] would make most sense of me, as it doesn't couple otherwise disjoint state. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 24/29] mm: remove __vmalloc_node_flags_caller
Hi Christoph,
On Tue, Apr 14, 2020 at 3:21 PM Christoph Hellwig wrote:
> Just use __vmalloc_node instead which gets and extra argument. To be
> able to to use __vmalloc_node in all caller make it available outside
> of vmalloc and implement it in nommu.c.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Peter Zijlstra (Intel)
One more nommu failure below...
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -150,8 +150,8 @@ void *__vmalloc(unsigned long size, gfp_t gfp_mask)
> }
> EXPORT_SYMBOL(__vmalloc);
>
> -void *__vmalloc_node_flags_caller(unsigned long size, int node, gfp_t flags,
> - void *caller)
> +void *__vmalloc_node(unsigned long size, unsigned long align, gfp_t gfp_mask,
> + int node, const void *caller)
> {
> return __vmalloc(size, flags);
On Mon, Apr 20, 2020 at 10:39 AM wrote:
> FAILED linux-next/m5272c3_defconfig/m68k-gcc8 Mon Apr 20, 18:38
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/14213623/
>
> mm/nommu.c:164:25: error: 'flags' undeclared (first use in this function);
> did you mean 'class'?
"return __vmalloc(size, gfp_mask);"
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 26/29] mm: remove vmalloc_user_node_flags
Hi Christoph,
On Tue, Apr 14, 2020 at 3:22 PM Christoph Hellwig wrote:
> Open code it in __bpf_map_area_alloc, which is the only caller. Also
> clean up __bpf_map_area_alloc to have a single vmalloc call with
> slightly different flags instead of the current two different calls.
>
> For this to compile for the nommu case add a __vmalloc_node_range stub
> to nommu.c.
Apparently your nommu-cross-compilers are in quarantaine? ;-)
> Signed-off-by: Christoph Hellwig
> Acked-by: Peter Zijlstra (Intel)
> Acked-by: Johannes Weiner
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -150,6 +150,14 @@ void *__vmalloc(unsigned long size, gfp_t gfp_mask)
> }
> EXPORT_SYMBOL(__vmalloc);
>
> +void *__vmalloc_node_range(unsigned long size, unsigned long align,
> + unsigned long start, unsigned long end, gfp_t gfp_mask,
> + pgprot_t prot, unsigned long vm_flags, int node,
> + const void *caller)
> +{
> + return __vmalloc(size, flags);
On Mon, Apr 20, 2020 at 10:39 AM wrote:
> FAILED linux-next/m5272c3_defconfig/m68k-gcc8 Mon Apr 20, 18:38
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/14213623/
>
> mm/nommu.c:158:25: error: 'flags' undeclared (first use in this function);
> did you mean 'class'?
"return __vmalloc(size, gfp_mask);", I assume?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces
On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote: > Right, I can see the appeal. I still like having a single mmu notifier per > mm because it ensures we allocate a single PASID per mm (as required by > x86). I suppose one alternative is to maintain a hashtable of mm->pasid, > to avoid iterating over all bonds during allocation. Given that the PASID is a pretty generic and important concept can we just add it directly to the mm_struct and allocate it lazily once we first need it? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/2] iommu: Remove iommu_sva_ops::mm_exit()
On Thu, Apr 16, 2020 at 01:58:29PM -0700, Jacob Pan wrote: > On Wed, 15 Apr 2020 09:47:36 +0200 > Jean-Philippe Brucker wrote: > > > On Fri, Apr 10, 2020 at 08:52:49AM -0700, Jacob Pan wrote: > > > On Thu, 9 Apr 2020 16:50:58 +0200 > > > Jean-Philippe Brucker wrote: > > > > > > > > So unbind is coming anyway, the difference in handling in mmu > > > > > release notifier is whether we silently drop DMA fault vs. > > > > > reporting fault? > > > > > > > > What I meant is, between mmu release notifier and unbind(), we > > > > can't print any error from DMA fault on dmesg, because an mm exit > > > > is easily triggered by userspace. Look at the lifetime of the > > > > bond: > > > > > > > > bind() > > > > | > > > > : Here any DMA fault is handled by mm, and on error we don't > > > > print : anything to dmesg. Userspace can easily trigger faults by > > > > issuing DMA : on unmapped buffers. > > > > | > > > > mm exit -> clear pgd, invalidate IOTLBs > > > > | > > > > : Here the PASID descriptor doesn't have the pgd anymore, but we > > > > don't : print out any error to dmesg either. DMA is likely still > > > > running but : any fault has to be ignored. > > > > : > > > > : We also can't free the PASID yet, since transactions are still > > > > coming : in with this PASID. > > > > | > > > > unbind() -> clear context descriptor, release PASID and mmu > > > > notifier | > > > > : Here the PASID descriptor is clear. If DMA is still running the > > > > device : driver really messed up and we have to print out any > > > > fault. > > > > > > > > For that middle state I had to introduce a new pasid descriptor > > > > state in the SMMU driver, to avoid reporting errors between mm > > > > exit and unbind(). > > > I must have missed something, but why bother with a state when you > > > can always check if the mm is dead by mmget_not_zero()? You would > > > not handle IOPF if the mm is dead anyway, similarly for other DMA > > > errors. > > > > In the SMMU a cleared PASID descriptor results in unrecoverable > > faults, which do not go through the I/O page fault handler. I've been > > thinking about injecting everything to the IOPF handler, recoverable > > or not, but filtering down the stream is complicated. Most of the > > time outside this small window, we really need to print out those > > messages because they would indicate serious bugs. > > > VT-d also results in unrecoverable fault for a cleared PASID. I am > assuming in the fault record, SMMU can also identify the PASID and > source ID. So that should be able to find the matching mm. > Then you can check if the mm is defunct? I'd rather not add a PASID lookup in the SMMU event thread, as that function needs to be fast and there already is a PASID lookup in the IOPF worker > > > Also, since you are not freeing ioasid in mmu_notifier release > > > anymore, does it mean the IOASID notifier chain can be non-atomic? > > > > Unfortunately not, ioasid_free() is called from > > mmu_notifier_ops::free_notifier() in the RCU callback that results > > from mmu_notifier_put(). > > > I agree. I looked at the code, it is much more clean with the > mmu_notifier_get/put. > > I am thinking perhaps adding a reclaim mechanism such that IOASID not > directly freed can stay in an in_active list (while waiting for its > states get cleared) until it can be reclaimed. Do you see this is > useful for SMMU? Probably not useful for SMMU, but I don't see any issue with adding it. > This is useful for VT-d, since we have more consumers for a given PASID, > i.e. VMCS, VDCM, and IOMMU. Each consumer has its own PASID context to > clean up. Right I'm still having trouble understanding the whole picture, will need to read more about this. The main point is not adding too much work in the mm exit path. Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 02/25] iommu/sva: Manage process address spaces
On Thu, Apr 16, 2020 at 05:13:31AM -0700, Christoph Hellwig wrote: > On Thu, Apr 16, 2020 at 10:54:02AM +0200, Jean-Philippe Brucker wrote: > > On Thu, Apr 16, 2020 at 12:28:52AM -0700, Christoph Hellwig wrote: > > > > + rcu_read_lock(); > > > > + hlist_for_each_entry_rcu(bond, _mm->devices, mm_node) > > > > + io_mm->ops->invalidate(bond->sva.dev, io_mm->pasid, > > > > io_mm->ctx, > > > > + start, end - start); > > > > + rcu_read_unlock(); > > > > +} > > > > > > What is the reason that the devices don't register their own notifiers? > > > This kinds of multiplexing is always rather messy, and you do it for > > > all the methods. > > > > This sends TLB and ATC invalidations through the IOMMU, it doesn't go > > through device drivers > > I don't think we mean the same thing, probably because of my rather > imprecise use of the word device. > > What I mean is that the mmu_notifier should not be embedded into the > io_mm structure (whch btw, seems to have a way to generic name, just > like all other io_* prefixed names), but instead into the > iommu_bond structure. That avoid the whole multiplexing layer. Right, I can see the appeal. I still like having a single mmu notifier per mm because it ensures we allocate a single PASID per mm (as required by x86). I suppose one alternative is to maintain a hashtable of mm->pasid, to avoid iterating over all bonds during allocation. Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] of_device: removed #include that caused a recursion in included headers
Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on stm32/stm32-next]
[also build test ERROR on sunxi/sunxi/for-next linus/master v5.7-rc1
next-20200416]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Hadar-Gat/of_device-removed-include-that-caused-a-recursion-in-included-headers/20200417-155422
base: https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
stm32-next
config: sparc64-defconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross
ARCH=sparc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
arch/sparc/kernel/sbus.c: In function 'sbus_init':
>> arch/sparc/kernel/sbus.c:669:32: error: implicit declaration of function
>> 'of_find_device_by_node'; did you mean 'bus_find_device_by_fwnode'?
>> [-Werror=implicit-function-declaration]
669 | struct platform_device *op = of_find_device_by_node(dp);
|^~
|bus_find_device_by_fwnode
>> arch/sparc/kernel/sbus.c:669:32: error: initialization of 'struct
>> platform_device *' from 'int' makes pointer from integer without a cast
>> [-Werror=int-conversion]
cc1: all warnings being treated as errors
--
arch/sparc/kernel/pci.c: In function 'of_create_pci_dev':
>> arch/sparc/kernel/pci.c:276:7: error: implicit declaration of function
>> 'of_find_device_by_node'; did you mean 'bus_find_device_by_fwnode'?
>> [-Werror=implicit-function-declaration]
276 | op = of_find_device_by_node(node);
| ^~
| bus_find_device_by_fwnode
>> arch/sparc/kernel/pci.c:276:5: error: assignment to 'struct platform_device
>> *' from 'int' makes pointer from integer without a cast
>> [-Werror=int-conversion]
276 | op = of_find_device_by_node(node);
| ^
cc1: all warnings being treated as errors
--
arch/sparc/kernel/pci_sabre.c: In function 'sabre_register_error_handlers':
>> arch/sparc/kernel/pci_sabre.c:324:7: error: implicit declaration of function
>> 'of_find_device_by_node'; did you mean 'bus_find_device_by_fwnode'?
>> [-Werror=implicit-function-declaration]
324 | op = of_find_device_by_node(dp);
| ^~
| bus_find_device_by_fwnode
arch/sparc/kernel/pci_sabre.c:324:5: error: assignment to 'struct
platform_device *' from 'int' makes pointer from integer without a cast
[-Werror=int-conversion]
324 | op = of_find_device_by_node(dp);
| ^
cc1: all warnings being treated as errors
--
arch/sparc/kernel/pci_schizo.c: In function
'tomatillo_register_error_handlers':
>> arch/sparc/kernel/pci_schizo.c:850:31: error: implicit declaration of
>> function 'of_find_device_by_node'; did you mean 'bus_find_device_by_fwnode'?
>> [-Werror=implicit-function-declaration]
850 | struct platform_device *op =
of_find_device_by_node(pbm->op->dev.of_node);
| ^~
| bus_find_device_by_fwnode
arch/sparc/kernel/pci_schizo.c:850:31: error: initialization of 'struct
platform_device *' from 'int' makes pointer from integer without a cast
[-Werror=int-conversion]
arch/sparc/kernel/pci_schizo.c: In function 'schizo_register_error_handlers':
arch/sparc/kernel/pci_schizo.c:945:31: error: initialization of 'struct
platform_device *' from 'int' makes pointer from integer without a cast
[-Werror=int-conversion]
945 | struct platform_device *op =
of_find_device_by_node(pbm->op->dev.of_node);
| ^~
cc1: all warnings being treated as errors
vim +669 arch/sparc/kernel/sbus.c
8fae097debdf8a arch/sparc64/kernel/sbus.c David S. Miller 2006-06-20 663
046e26a8ba10b8 arch/sparc64/kernel/sbus.c David S. Miller 2008-08-27 664
static int __init sbus_init(void)
576c352e89e57c arch/sparc64/kernel/sbus.c David S. Miller 2006-06-23 665 {
046e26a8ba10b8 arch/sparc64/kernel/sbus.c David S. Miller 2008-08-27 666
struct device_node *dp;
046e26a8ba10b8 arch/sparc64/kernel/sbus.c David S. Miller 2008-08-27 667
046e26a8ba10b8 arch/sparc64/kernel/sbus.c David S. Miller 2008-08-27 668
for_each_node_by_name(dp, "sbus") {
cd4cd7306a403f arch/sparc/kernel/sbus.c Grant Likely2010-07-22 @669
Re: [PATCH v2] of_device: removed #include that caused a recursion in included headers
Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on stm32/stm32-next]
[also build test ERROR on sunxi/sunxi/for-next linus/master v5.7-rc1
next-20200416]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Hadar-Gat/of_device-removed-include-that-caused-a-recursion-in-included-headers/20200417-155422
base: https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
stm32-next
config: arm-imx_v6_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/media/platform/coda/coda-common.c: In function 'coda_get_vdoa_data':
>> drivers/media/platform/coda/coda-common.c:385:14: error: implicit
>> declaration of function 'of_find_device_by_node'; did you mean
>> 'of_find_spi_device_by_node'? [-Werror=implicit-function-declaration]
385 | vdoa_pdev = of_find_device_by_node(vdoa_node);
| ^~
| of_find_spi_device_by_node
drivers/media/platform/coda/coda-common.c:385:12: warning: assignment to
'struct platform_device *' from 'int' makes pointer from integer without a cast
[-Wint-conversion]
385 | vdoa_pdev = of_find_device_by_node(vdoa_node);
|^
cc1: some warnings being treated as errors
vim +385 drivers/media/platform/coda/coda-common.c
927933f7b4b213 drivers/media/platform/coda.c Philipp Zabel
2013-09-30 374
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 375 static struct vdoa_data *coda_get_vdoa_data(void)
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 376 {
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 377struct device_node *vdoa_node;
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 378struct platform_device *vdoa_pdev;
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 379struct vdoa_data *vdoa_data = NULL;
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 380
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 381vdoa_node = of_find_compatible_node(NULL, NULL,
"fsl,imx6q-vdoa");
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 382if (!vdoa_node)
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 383return NULL;
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 384
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 @385vdoa_pdev = of_find_device_by_node(vdoa_node);
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 386if (!vdoa_pdev)
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 387goto out;
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 388
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 389vdoa_data = platform_get_drvdata(vdoa_pdev);
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 390if (!vdoa_data)
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 391vdoa_data = ERR_PTR(-EPROBE_DEFER);
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 392
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 393 out:
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 394of_node_put(vdoa_node);
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 395
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 396return vdoa_data;
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 397 }
e7f3c548103508 drivers/media/platform/coda/coda-common.c Michael Tretter
2017-01-20 398
:: The code at line 385 was first introduced by commit
:: e7f3c54810350827823d241905fb7823eee30c21 [media] coda: use VDOA for
un-tiling
