[v9, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to get SVR(System
version register). And fix host version to avoid that incorrect version
numbers break down the ADMA data transfer.
Signed-off-by: Yangbo Lu
Acked-by: Ulf Hansson
Acked-by: Scott Wood
---
Changes for v2:
- Got SVR through iomap instead of dts
Changes for v3:
- Managed GUTS through syscon instead of iomap in eSDHC driver
Changes for v4:
- Got SVR by GUTS driver instead of SYSCON
Changes for v5:
- Changed to get SVR through API fsl_guts_get_svr()
- Combined patch 4, patch 5 and patch 6 into one
Changes for v6:
- Added 'Acked-by: Ulf Hansson'
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
---
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 0aa484c..e15e836 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -143,6 +143,7 @@ config MMC_SDHCI_OF_ESDHC
depends on MMC_SDHCI_PLTFM
depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
select MMC_SDHCI_IO_ACCESSORS
+ select FSL_GUTS
help
This selects the Freescale eSDHC controller support.
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d35..68cc020 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -28,6 +30,8 @@
struct sdhci_esdhc {
u8 vendor_ver;
u8 spec_ver;
+ u32 soc_ver;
+ u8 soc_rev;
};
/**
@@ -73,6 +77,8 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
@@ -80,6 +86,13 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
ret = value & 0x;
else
ret = (value >> shift) & 0x;
+
+ /* Workaround for T4240-R1.0-R2.0 eSDHC which has incorrect
+* vendor version and spec version information.
+*/
+ if ((spec_reg == SDHCI_HOST_VERSION) &&
+ (esdhc->soc_ver == SVR_T4240) && (esdhc->soc_rev <= 0x20))
+ ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
return ret;
}
@@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device *pdev,
struct sdhci_host *host)
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
u16 host_ver;
+ u32 svr;
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
+ fsl_guts_init();
+ svr = fsl_guts_get_svr();
+ if (svr) {
+ esdhc->soc_ver = SVR_SOC_VER(svr);
+ esdhc->soc_rev = SVR_REV(svr);
+ } else {
+ dev_err(&pdev->dev, "Failed to get SVR value!\n");
+ }
+
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
--
2.1.0.27.g96db324
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v9, 5/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
a common header file. It has been used for mpc85xx and it will
be used for ARM-based SoC as well.
Signed-off-by: Yangbo Lu
Acked-by: Wolfram Sang
Acked-by: Stephen Boyd
Acked-by: Scott Wood
Acked-by: Joerg Roedel
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include ' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
Changes for v8:
- Added 'Acked-by: Stephen Boyd' for clk part
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Joerg Roedel' for iommu part
Changes for v9:
- None
---
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c | 3 +--
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +--
drivers/net/ethernet/freescale/gianfar.c | 2 +-
arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
6 files changed, 7 insertions(+), 9 deletions(-)
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
*
*/
+#include
#include
#include
#include
#include
#include
#include
-#include
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 7bc1c45..fc7f722 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1148,8 +1149,6 @@ bad_args:
}
#ifdef CONFIG_PPC
-#include
-
static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10,/* P2040 1.0 */
(SVR_P2040 << 8) | 0x11,/* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 48ecffe..600704c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
#include
#include
#include
+#include
#include
-#include
#include
#define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
#include "fsl_pamu.h"
#include
+#include
#include
#include
-#include
-
/* define indexes for each operation mapping scenario */
#define OMI_QMAN0x00
#define OMI_FMAN0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c
b/drivers/net/ethernet/freescale/gianfar.c
index d2f917a..2224b10 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_PPC
#include
-#include
#endif
#include
#include
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
* (at your option) any later version.
*/
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
#define SVR_REV(svr) ((svr) & 0xFF) /* SOC design resision */
#define SVR_MAJ(svr) (((svr) >> 4) & 0xF) /* Major revision field*/
--
2.1.0.27.g96db324
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v9, 4/7] dt: move guts devicetree doc out of powerpc directory
Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.
Signed-off-by: Yangbo Lu
Acked-by: Scott Wood
Acked-by: Rob Herring
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
- Added 'Acked-by: Rob Herring'
Changes for v9:
- None
---
Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
1 file changed, 3 insertions(+)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
- fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
+ - little-endian : Indicates that the global utilities block is little
+ endian. The default is big endian.
+
Examples:
global-utilities@e {/* global utilities block */
compatible = "fsl,mpc8548-guts";
--
2.1.0.27.g96db324
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v9, 3/7] soc: fsl: add GUTS driver for QorIQ platforms
The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.
This patch adds GUTS driver to manage and access global utilities
block.
Signed-off-by: Yangbo Lu
Acked-by: Scott Wood
---
Changes for v4:
- Added this patch
Changes for v5:
- Modified copyright info
- Changed MODULE_LICENSE to GPL
- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
- Made FSL_GUTS user-invisible
- Added a complete compatible list for GUTS
- Stored guts info in file-scope variable
- Added mfspr() getting SVR
- Redefined GUTS APIs
- Called fsl_guts_init rather than using platform driver
- Removed useless parentheses
- Removed useless 'extern' key words
Changes for v6:
- Made guts thread safe in fsl_guts_init
Changes for v7:
- Removed 'ifdef' for function declaration in guts.h
Changes for v8:
- Fixes lines longer than 80 characters checkpatch issue
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
---
drivers/soc/Kconfig | 2 +-
drivers/soc/fsl/Kconfig | 8 +++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119
include/linux/fsl/guts.h | 126 +--
5 files changed, 207 insertions(+), 49 deletions(-)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0..7106463 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 000..b313759
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,8 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+ bool
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307f..02afb7f 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 000..fa155e6
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,119 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct guts {
+ struct ccsr_guts __iomem *regs;
+ bool little_endian;
+};
+
+static struct guts *guts;
+static DEFINE_MUTEX(guts_lock);
+
+u32 fsl_guts_get_svr(void)
+{
+ u32 svr = 0;
+
+ if (!guts || !guts->regs) {
+#ifdef CONFIG_PPC
+ svr = mfspr(SPRN_SVR);
+#endif
+ return svr;
+ }
+
+ if (guts->little_endian)
+ svr = ioread32(&guts->regs->svr);
+ else
+ svr = ioread32be(&guts->regs->svr);
+
+ return svr;
+}
+EXPORT_SYMBOL(fsl_guts_get_svr);
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id guts_of_match[] = {
+ /* For T4 & B4 Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-1.0", },
+ /* For P Series SOCs */
+ { .compatible = "fsl,qoriq-device-config-2.0", },
+ { .compatible = "fsl,p1010-guts", },
+ { .compatible = "fsl,p1020-guts", },
+ { .compatible = "fsl,p1021-guts", },
+ { .compatible = "fsl,p1022-guts", },
+ { .compatible = "fsl,p1023-guts", },
+ { .compatible = "fsl,p2020-guts", },
+ /* For BSC Series SOCs */
+ { .compatible = "fsl,bsc9131-guts", },
+ { .compatible = "fsl,bsc9132-guts", },
+ /* For MPC85xx Series SOCs */
+ { .compatible = "fsl,mpc8536-guts", },
+ { .compatible = "fsl,mpc8544-guts", },
+ { .compatible = "fsl,mpc8548-guts", },
+ { .compatible = "fsl,mpc8568-guts", },
+ { .compatible = "fsl,mpc8569-guts", },
+ { .compatible = "fsl,mpc8572-guts", },
+ /* For Layerscape Series SOCs */
+ { .compatible = "fsl,ls1021a-dcfg", },
+ { .compatible = "fsl,ls1043a-dcfg", },
+ { .compatible
[v9, 6/7] MAINTAINERS: add entry for Freescale SoC driver
Add maintainer entry for Freescale SoC driver including the QE library and the GUTS driver now. Also add maintainer for QE library. Signed-off-by: Yangbo Lu --- Changes for v8: - Added this patch Changes for v9: - Added linux-arm mail list - Removed GUTS driver entry --- MAINTAINERS | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 42e65d1..ce91db7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4622,9 +4622,18 @@ F: drivers/net/ethernet/freescale/fec_ptp.c F: drivers/net/ethernet/freescale/fec.h F: Documentation/devicetree/bindings/net/fsl-fec.txt +FREESCALE SOC DRIVER +M: Scott Wood +L: linuxppc-...@lists.ozlabs.org +L: linux-arm-ker...@lists.infradead.org +S: Maintained +F: drivers/soc/fsl/ +F: include/linux/fsl/ + FREESCALE QUICC ENGINE LIBRARY +M: Qiang Zhao L: linuxppc-...@lists.ozlabs.org -S: Orphan +S: Maintained F: drivers/soc/fsl/qe/ F: include/soc/fsl/*qe*.h F: include/soc/fsl/*ucc*.h -- 2.1.0.27.g96db324 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v9, 1/7] Documentation: DT: update Freescale DCFG compatible
Update Freescale DCFG compatible with 'fsl,-dcfg' instead of 'fsl,ls1021a-dcfg' to include more chips such as ls1021a, ls1043a, and ls2080a. Signed-off-by: Yangbo Lu --- Changes for v8: - Added this patch Changes for v9: - Added a list for the possible compatibles --- Documentation/devicetree/bindings/arm/fsl.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt index 752a685..465cba1 100644 --- a/Documentation/devicetree/bindings/arm/fsl.txt +++ b/Documentation/devicetree/bindings/arm/fsl.txt @@ -119,7 +119,11 @@ Freescale DCFG configuration and status for the device. Such as setting the secondary core start address and release the secondary core from holdoff and startup. Required properties: - - compatible: should be "fsl,ls1021a-dcfg" + - compatible: should be "fsl,-dcfg" +Possible compatibles: + "fsl,ls1021a-dcfg" + "fsl,ls1043a-dcfg" + "fsl,ls2080a-dcfg" - reg : should contain base address and length of DCFG memory-mapped registers Example: -- 2.1.0.27.g96db324 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v9, 0/7] Fix eSDHC host version register bug
This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.
So, the first four patches are to add the GUTS driver.
The following patches except the updating MAINTAINERS patch are to enable
GUTS driver support to get SVR in eSDHC driver and fix host version for T4240.
Yangbo Lu (7):
Documentation: DT: update Freescale DCFG compatible
ARM64: dts: ls2080a: add device configuration node
soc: fsl: add GUTS driver for QorIQ platforms
dt: move guts devicetree doc out of powerpc directory
powerpc/fsl: move mpc85xx.h to include/linux/fsl
MAINTAINERS: add entry for Freescale SoC driver
mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
.../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
MAINTAINERS| 11 +-
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
drivers/clk/clk-qoriq.c| 3 +-
drivers/i2c/busses/i2c-mpc.c | 2 +-
drivers/iommu/fsl_pamu.c | 3 +-
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 23
drivers/net/ethernet/freescale/gianfar.c | 2 +-
drivers/soc/Kconfig| 2 +-
drivers/soc/fsl/Kconfig| 8 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/guts.c | 119 +++
include/linux/fsl/guts.h | 126 +
.../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
17 files changed, 262 insertions(+), 60 deletions(-)
rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
create mode 100644 drivers/soc/fsl/Kconfig
create mode 100644 drivers/soc/fsl/guts.c
rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
--
2.1.0.27.g96db324
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[v9, 2/7] ARM64: dts: ls2080a: add device configuration node
Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.
Signed-off-by: Yangbo Lu
Acked-by: Scott Wood
---
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 9d746c6..8724cf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -191,6 +191,12 @@
clocks = <&sysclk>;
};
+ dcfg: dcfg@1e0 {
+ compatible = "fsl,ls2080a-dcfg", "syscon";
+ reg = <0x0 0x1e0 0x0 0x1>;
+ little-endian;
+ };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
--
2.1.0.27.g96db324
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH V3 2/7] documentation: iommu: Add bindings for msm,iommu-v0 ip
On Mon, May 02, 2016 at 12:24:30AM +0530, Sricharan R wrote:
> The MSM IOMMU is an implementation compatible with the ARM VMSA short
> descriptor page tables. It provides address translation for bus masters
> outside
> of the CPU, each connected to the IOMMU through a port called micro-TLB.
> Adding the DT bindings for the same.
>
> Signed-off-by: Sricharan R
> ---
> .../devicetree/bindings/iommu/msm,iommu-v0.txt | 62
> ++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
>
> diff --git a/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> b/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> new file mode 100644
> index 000..63b4f96
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
> @@ -0,0 +1,62 @@
> +* MSM IOMMU
> +
> +The MSM IOMMU is an implementation compatible with the ARM VMSA short
> +descriptor page tables. It provides address translation for bus masters
> outside
> +of the CPU, each connected to the IOMMU through a port called micro-TLB.
> +
> +Required Properties:
> +
> + - compatible: Must contain "msm,iommu-v0".
SOC specific compatible strings please.
> + - reg: Base address and size of the IOMMU 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.
> + - #iommu-cells: The number of cells needed to specify the stream id. This
> + is always 1.
> + - qcom,ncb: The total number of context banks in the IOMMU.
> + - clocks : List of clocks to be used during SMMU register access. See
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + for information about the format. For each clock specified
> + here, there must be a corresponding entry in clock-names
> + (see below).
> +
> + - clock-names : List of clock names corresponding to the clocks
> specified in
> + the "clocks" property (above). See
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + for more info.
You must define how many clocks, their order and their names.
> +
> +Each bus master connected to an IOMMU must reference the IOMMU in its device
> +node with the following property:
> +
> + - iommus: A reference to the IOMMU in multiple cells. The first cell is a
> + phandle to the IOMMU and the second cell is the stream id.
> + A single master device can be connected to more than one iommu
> + and multiple contexts in each of the iommu. So multiple entries
> + are required to list all the iommus and the stream ids that the
> + master is connected to.
> +
> +Example: mdp iommu and its bus master
> +
> +mdp_port0: iommu@750 {
> + compatible = "msm,iommu-v0";
> + #iommu-cells = <1>;
> + clock-names =
> + "smmu_pclk",
> + "iommu_clk";
> + clocks =
> + <&mmcc SMMU_AHB_CLK>,
> + <&mmcc MDP_AXI_CLK>;
> + reg = <0x0750 0x10>;
> + interrupts =
> + ,
> + ;
> + qcom,ncb = <2>;
> + };
> +
> + mdp: qcom,mdp@510 {
> + compatible = "qcom,mdp";
> + ...
> + iommus = <&mdp_port0 0
> + &mdp_port0 2>;
> + };
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
> Code Aurora Forum, hosted by The Linux Foundation
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH V2] iommu/arm-smmu: clear cache lock bit of ACR
On 03/05/16 14:50, Peng Fan wrote:
According MMU-500r2 TRM, section 3.7.1 Auxiliary Control registers,
You can modify ACTLR only when the ACR.CACHE_LOCK bit is 0.
So before clearing ARM_MMU500_ACTLR_CPRE of each context bank,
need clear CACHE_LOCK bit of ACR register first.
Since CACHE_LOCK bit is only present in MMU-500r2 onwards,
need to check the major number of IDR7.
Signed-off-by: Peng Fan
Cc: Will Deacon
Cc: Robin Murphy
---
V2:
Following Robin's comments, need to check IDR7 before clearing
CACHE_LOCK bit of ACR.
V1:
Patch based on iommu/devel
drivers/iommu/arm-smmu.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index acff332..c7ad23e 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -98,6 +98,9 @@
#define sCR0_BSU_SHIFT14
#define sCR0_BSU_MASK 0x3
+/* Auxiliary Configuration register */
+#define ARM_SMMU_GR0_sACR 0x10
+
/* Identification registers */
#define ARM_SMMU_GR0_ID0 0x20
#define ARM_SMMU_GR0_ID1 0x24
@@ -144,6 +147,9 @@
#define ID2_PTFS_64K (1 << 14)
#define ID2_VMID16(1 << 15)
+#define ID7_MAJOR_SHIFT4
+#define ID7_MAJOR_MASK 0xf
+
/* Global TLB invalidation */
#define ARM_SMMU_GR0_TLBIVMID 0x64
#define ARM_SMMU_GR0_TLBIALLNSNH 0x68
@@ -235,6 +241,8 @@
#define ARM_MMU500_ACTLR_CPRE (1 << 1)
+#define ARM_MMU500_ACR_CACHE_LOCK (1 << 26)
+
#define CB_PAR_F (1 << 0)
#define ATSR_ACTIVE (1 << 0)
@@ -1493,7 +1501,7 @@ static void arm_smmu_device_reset(struct arm_smmu_device
*smmu)
void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
void __iomem *cb_base;
int i = 0;
- u32 reg;
+ u32 reg, major;
/* clear global FSR */
reg = readl_relaxed(ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sGFSR);
@@ -1506,6 +1514,19 @@ static void arm_smmu_device_reset(struct arm_smmu_device
*smmu)
writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_S2CR(i));
}
+ /*
+* Before clearing ARM_MMU500_ACTLR_CPRE, need to
+* clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
+* bit is only present in MMU-500r2 onwards.
+*/
+ reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
+ major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
+ if ((smmu->model == ARM_MMU500) && (major >= 2)) {
+ reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
+ reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
+ writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
+ }
+
I'd have been inclined to make the ID reg read conditional on ARM_MMU500
as well, but this way is marginally more compact, and it's not like
we're in a frequently-used hot path anyway.
Reviewed-by: Robin Murphy
Thanks,
Robin.
/* Make sure all context banks are disabled and clear CB_FSR */
for (i = 0; i < smmu->num_context_banks; ++i) {
cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, i);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH v1 15/18] x86: Enable memory encryption on the APs
On 05/01/2016 05:10 PM, Huang, Kai wrote:
>
>
> On 4/27/2016 10:58 AM, Tom Lendacky wrote:
>> Add support to set the memory encryption enable flag on the APs during
>> realmode initialization. When an AP is started it checks this flag, and
>> if set, enables memory encryption on its core.
>>
>> Signed-off-by: Tom Lendacky
>> ---
>> arch/x86/include/asm/msr-index.h |2 ++
>> arch/x86/include/asm/realmode.h | 12
>> arch/x86/realmode/init.c |4
>> arch/x86/realmode/rm/trampoline_64.S | 14 ++
>> 4 files changed, 32 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/msr-index.h
>> b/arch/x86/include/asm/msr-index.h
>> index 94555b4..b73182b 100644
>> --- a/arch/x86/include/asm/msr-index.h
>> +++ b/arch/x86/include/asm/msr-index.h
>> @@ -349,6 +349,8 @@
>> #define MSR_K8_TOP_MEM10xc001001a
>> #define MSR_K8_TOP_MEM20xc001001d
>> #define MSR_K8_SYSCFG0xc0010010
>> +#define MSR_K8_SYSCFG_MEM_ENCRYPT_BIT23
>> +#define MSR_K8_SYSCFG_MEM_ENCRYPT(1ULL <<
>> MSR_K8_SYSCFG_MEM_ENCRYPT_BIT)
>> #define MSR_K8_INT_PENDING_MSG0xc0010055
>> /* C1E active bits in int pending message */
>> #define K8_INTP_C1E_ACTIVE_MASK0x1800
>> diff --git a/arch/x86/include/asm/realmode.h
>> b/arch/x86/include/asm/realmode.h
>> index 9c6b890..e24d2ec 100644
>> --- a/arch/x86/include/asm/realmode.h
>> +++ b/arch/x86/include/asm/realmode.h
>> @@ -1,6 +1,15 @@
>> #ifndef _ARCH_X86_REALMODE_H
>> #define _ARCH_X86_REALMODE_H
>>
>> +/*
>> + * Flag bit definitions for use with the flags field of the
>> trampoline header
>> + * when configured for X86_64
>> + */
>> +#define TH_FLAGS_MEM_ENCRYPT_BIT0
>> +#define TH_FLAGS_MEM_ENCRYPT(1ULL << TH_FLAGS_MEM_ENCRYPT_BIT)
>
> Would mind change it to a more vendor specific name, such as
> AMD_MEM_ENCRYPT, or SME_MEM_ENCRYPT?
Yup, that can be done.
>
>> +
>> +#ifndef __ASSEMBLY__
>> +
>> #include
>> #include
>>
>> @@ -38,6 +47,7 @@ struct trampoline_header {
>> u64 start;
>> u64 efer;
>> u32 cr4;
>> +u32 flags;
>> #endif
>> };
>>
>> @@ -61,4 +71,6 @@ extern unsigned char secondary_startup_64[];
>> void reserve_real_mode(void);
>> void setup_real_mode(void);
>>
>> +#endif /* __ASSEMBLY__ */
>> +
>> #endif /* _ARCH_X86_REALMODE_H */
>> diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c
>> index 85b145c..657532b 100644
>> --- a/arch/x86/realmode/init.c
>> +++ b/arch/x86/realmode/init.c
>> @@ -84,6 +84,10 @@ void __init setup_real_mode(void)
>> trampoline_cr4_features = &trampoline_header->cr4;
>> *trampoline_cr4_features = __read_cr4();
>>
>> +trampoline_header->flags = 0;
>> +if (sme_me_mask)
>> +trampoline_header->flags |= TH_FLAGS_MEM_ENCRYPT;
>> +
>> trampoline_pgd = (u64 *) __va(real_mode_header->trampoline_pgd);
>> trampoline_pgd[0] = init_level4_pgt[pgd_index(__PAGE_OFFSET)].pgd;
>> trampoline_pgd[511] = init_level4_pgt[511].pgd;
>> diff --git a/arch/x86/realmode/rm/trampoline_64.S
>> b/arch/x86/realmode/rm/trampoline_64.S
>> index dac7b20..8d84167 100644
>> --- a/arch/x86/realmode/rm/trampoline_64.S
>> +++ b/arch/x86/realmode/rm/trampoline_64.S
>> @@ -30,6 +30,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include "realmode.h"
>>
>> .text
>> @@ -109,6 +110,18 @@ ENTRY(startup_32)
>> movl$(X86_CR0_PG | X86_CR0_WP | X86_CR0_PE), %eax
>> movl%eax, %cr0
>>
>> +# Check for and enable memory encryption support
>> +movlpa_tr_flags, %eax
>> +bt$TH_FLAGS_MEM_ENCRYPT_BIT, pa_tr_flags
>
> pa_tr_flags -> %eax ? Otherwise looks the previous line is useless.
Yes, I overlooked that. I'll take care of it.
Thanks,
Tom
>
> Thanks,
> -Kai
>
>> +jnc.Ldone
>> +movl$MSR_K8_SYSCFG, %ecx
>> +rdmsr
>> +bt$MSR_K8_SYSCFG_MEM_ENCRYPT_BIT, %eax
>> +jc.Ldone
>> +bts$MSR_K8_SYSCFG_MEM_ENCRYPT_BIT, %eax
>> +wrmsr
>> +.Ldone:
>> +
>> /*
>> * At this point we're in long mode but in 32bit compatibility mode
>> * with EFER.LME = 1, CS.L = 0, CS.D = 1 (and in turn
>> @@ -147,6 +160,7 @@ GLOBAL(trampoline_header)
>> tr_start:.space8
>> GLOBAL(tr_efer).space8
>> GLOBAL(tr_cr4).space4
>> +GLOBAL(tr_flags).space4
>> END(trampoline_header)
>>
>> #include "trampoline_common.S"
>>
>>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)
On 04/30/2016 01:13 AM, Elliott, Robert (Persistent Memory) wrote: >> -Original Message- >> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- >> ow...@vger.kernel.org] On Behalf Of Tom Lendacky >> Sent: Tuesday, April 26, 2016 5:56 PM >> Subject: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD) >> >> This RFC patch series provides support for AMD's new Secure Memory >> Encryption (SME) feature. >> >> SME can be used to mark individual pages of memory as encrypted through the >> page tables. A page of memory that is marked encrypted will be automatically >> decrypted when read from DRAM and will be automatically encrypted when >> written to DRAM. Details on SME can found in the links below. >> > ... >> ... Certain data must be accounted for >> as having been placed in memory before SME was enabled (EFI, initrd, etc.) >> and accessed accordingly. >> > ... >> x86/efi: Access EFI related tables in the clear >> x86: Access device tree in the clear >> x86: Do not specify encrypted memory for VGA mapping > > If the SME encryption key "is created randomly each time a system is booted," > data on NVDIMMs won't decrypt properly on the next boot. You need to exclude > persistent memory regions (reported in the UEFI memory map as > EfiReservedMemoryType with the NV attribute, or as EfiPersistentMemory). The current plan is for the AMD Secure Processor to securely save the SME encryption key when NVDIMMs are installed on a system. The saved SME key will be restored if an NVDIMM restore event needs to be performed. If there isn't an NVDIMM restore event, then the randomly generated key will be used. Thanks, Tom > > Perhaps the SEV feature will allow key export/import that could work for > NVDIMMs. > > --- > Robert Elliott, HPE Persistent Memory > > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH V2] iommu/arm-smmu: clear cache lock bit of ACR
According MMU-500r2 TRM, section 3.7.1 Auxiliary Control registers,
You can modify ACTLR only when the ACR.CACHE_LOCK bit is 0.
So before clearing ARM_MMU500_ACTLR_CPRE of each context bank,
need clear CACHE_LOCK bit of ACR register first.
Since CACHE_LOCK bit is only present in MMU-500r2 onwards,
need to check the major number of IDR7.
Signed-off-by: Peng Fan
Cc: Will Deacon
Cc: Robin Murphy
---
V2:
Following Robin's comments, need to check IDR7 before clearing
CACHE_LOCK bit of ACR.
V1:
Patch based on iommu/devel
drivers/iommu/arm-smmu.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index acff332..c7ad23e 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -98,6 +98,9 @@
#define sCR0_BSU_SHIFT 14
#define sCR0_BSU_MASK 0x3
+/* Auxiliary Configuration register */
+#define ARM_SMMU_GR0_sACR 0x10
+
/* Identification registers */
#define ARM_SMMU_GR0_ID0 0x20
#define ARM_SMMU_GR0_ID1 0x24
@@ -144,6 +147,9 @@
#define ID2_PTFS_64K (1 << 14)
#define ID2_VMID16 (1 << 15)
+#define ID7_MAJOR_SHIFT4
+#define ID7_MAJOR_MASK 0xf
+
/* Global TLB invalidation */
#define ARM_SMMU_GR0_TLBIVMID 0x64
#define ARM_SMMU_GR0_TLBIALLNSNH 0x68
@@ -235,6 +241,8 @@
#define ARM_MMU500_ACTLR_CPRE (1 << 1)
+#define ARM_MMU500_ACR_CACHE_LOCK (1 << 26)
+
#define CB_PAR_F (1 << 0)
#define ATSR_ACTIVE(1 << 0)
@@ -1493,7 +1501,7 @@ static void arm_smmu_device_reset(struct arm_smmu_device
*smmu)
void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
void __iomem *cb_base;
int i = 0;
- u32 reg;
+ u32 reg, major;
/* clear global FSR */
reg = readl_relaxed(ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sGFSR);
@@ -1506,6 +1514,19 @@ static void arm_smmu_device_reset(struct arm_smmu_device
*smmu)
writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_S2CR(i));
}
+ /*
+* Before clearing ARM_MMU500_ACTLR_CPRE, need to
+* clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
+* bit is only present in MMU-500r2 onwards.
+*/
+ reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
+ major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
+ if ((smmu->model == ARM_MMU500) && (major >= 2)) {
+ reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
+ reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
+ writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
+ }
+
/* Make sure all context banks are disabled and clear CB_FSR */
for (i = 0; i < smmu->num_context_banks; ++i) {
cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, i);
--
2.6.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/arm-smmu: clear cache lock bit of ACR
Hi Robin,
On Tue, May 03, 2016 at 12:15:52PM +0100, Robin Murphy wrote:
>On 03/05/16 11:15, Peng Fan wrote:
>>According MMU-500 TRM, section 3.7.1 Auxiliary Control registers,
>>You can modify ACTLR only when the ACR.CACHE_LOCK bit is 0.
>>
>>So before clearing ARM_MMU500_ACTLR_CPRE of each context bank,
>>need clear CACHE_LOCK bit of ACR register first.
>
>Ah, good catch - I think I misread CACHE_LOCK as resetting to 0, and
>proceeded to forget about it. However, it's only present in MMU-500r2
>onwards, so we'd also want to check IDR7 before touching ACR.
Thanks for comments. I'll add code to check IDR7 and send out V2.
Thanks,
Peng.
>
>Thanks,
>Robin.
>
>>Signed-off-by: Peng Fan
>>Cc: Will Deacon
>>Cc: Robin Murphy
>>---
>>
>>Hi Will,
>>
>> Patch based on iommu/devel branch.
>>
>>
>> drivers/iommu/arm-smmu.c | 15 +++
>> 1 file changed, 15 insertions(+)
>>
>>diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>>index acff332..d094a5a 100644
>>--- a/drivers/iommu/arm-smmu.c
>>+++ b/drivers/iommu/arm-smmu.c
>>@@ -98,6 +98,9 @@
>> #define sCR0_BSU_SHIFT 14
>> #define sCR0_BSU_MASK 0x3
>>
>>+/* Auxiliary Configuration register */
>>+#define ARM_SMMU_GR0_sACR0x10
>>+
>> /* Identification registers */
>> #define ARM_SMMU_GR0_ID00x20
>> #define ARM_SMMU_GR0_ID10x24
>>@@ -235,6 +238,8 @@
>>
>> #define ARM_MMU500_ACTLR_CPRE (1 << 1)
>>
>>+#define ARM_MMU500_ACR_CACHE_LOCK(1 << 26)
>>+
>> #define CB_PAR_F(1 << 0)
>>
>> #define ATSR_ACTIVE (1 << 0)
>>@@ -1506,6 +1511,16 @@ static void arm_smmu_device_reset(struct
>>arm_smmu_device *smmu)
>> writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_S2CR(i));
>> }
>>
>>+ /*
>>+ * Before clearing ARM_MMU500_ACTLR_CPRE, need to
>>+ * clear CACHE_LOCK bit of ACR first.
>>+ */
>>+ if (smmu->model == ARM_MMU500) {
>>+ reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
>>+ reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
>>+ writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
>>+ }
>>+
>> /* Make sure all context banks are disabled and clear CB_FSR */
>> for (i = 0; i < smmu->num_context_banks; ++i) {
>> cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, i);
>>
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v8 6/8] iommu/msi-iommu: iommu_msi_domain
Hi Alex,
On 05/02/2016 10:23 PM, Alex Williamson wrote:
> Hi Eric,
>
> On Mon, 2 May 2016 17:48:13 +0200
> Eric Auger wrote:
>
>> Hi Alex,
>> On 04/29/2016 12:27 AM, Alex Williamson wrote:
>>> On Thu, 28 Apr 2016 08:15:21 +
>>> Eric Auger wrote:
>>>
This function checks whether
- the device belongs to a non default iommu domain
- this iommu domain requires the MSI address to be mapped.
If those conditions are met, the function returns the iommu domain
to be used for mapping the MSI doorbell; else it returns NULL.
Signed-off-by: Eric Auger
---
v7 -> v8:
- renamed iommu_msi_mapping_desc_to_domain to iommu_msi_domain
- the function now takes a struct device *
- use DOMAIN_ATTR_MSI_GEOMETRY attribute
---
drivers/iommu/msi-iommu.c | 17 +
include/linux/msi-iommu.h | 14 ++
2 files changed, 31 insertions(+)
diff --git a/drivers/iommu/msi-iommu.c b/drivers/iommu/msi-iommu.c
index 203e86e..023ff17 100644
--- a/drivers/iommu/msi-iommu.c
+++ b/drivers/iommu/msi-iommu.c
@@ -243,3 +243,20 @@ unlock:
}
}
EXPORT_SYMBOL_GPL(iommu_msi_put_doorbell_iova);
+
+struct iommu_domain *iommu_msi_domain(struct device *dev)
+{
+ struct iommu_domain *d = iommu_get_domain_for_dev(dev);
+ struct iommu_domain_msi_geometry msi_geometry;
+
+ if (!d || (d->type == IOMMU_DOMAIN_DMA))
+ return NULL;
+
+ iommu_domain_get_attr(d, DOMAIN_ATTR_MSI_GEOMETRY, &msi_geometry);
+ if (!msi_geometry.programmable)
>>>
>>> It feels like we're conflating ideas with using the "programmable" flag
>>> in this way. AIUI the IOMMU API consumer is supposed to see the
>>> invalid MSI geometry with the programmable feature set and know to call
>>> iommu_msi_set_aperture(). Looking for the msi_cookie would tell us if
>>> that had been done, but that doesn't tell us if it should have been
>>> done. iommu_msi_msg_pa_to_va() handles this later, if we return
>>> NULL here that function returns success otherwise it goes on to fail if
>>> the iova or msi cookie is not set. So really what we're trying to flag
>>> is that the MSI geometry participates in the IOMMU-MSI API you've
>>> created and we should pick a feature name that says that rather than
>>> something as vague a "programmable". Perhaps simply iommu_msi_api
>>> rather than programmable.
>> Yes I had the same questioning too when I wrote this code. So if my
>> understanding is correct we would have
>> - programmable: tells whether the MSI range is fixed or pogrammable and,
>> - mapping_required (new boolean field): indicating whether MSIs need to
>> be mapped in the IOMMU
>
> Let's say we had a flag "iommu_msi_supported", doesn't that already
> tell us whether the MSI range is programmable and the API to use to do
> it? Can't we figure out if mapping is required based on whether
> iommu_msi_supported is set and aperture_start and aperture_end indicate
> a valid range? It seems like what we want on this code path is to
> simply know whether the IOMMU domain is relevant to the IOMMU MSI API,
> which would be abundantly clear with such a flag.
OK I now get your point. Thanks for the clarification. I renamed
programmable into iommu_msi_supported.
>
>>>
>>> BTW, I don't see that you ever set aperture_start/end once
>>> iommu_msi_set_aperture() has been called. It seems like doing so would
>>> add some consistency to that MSI geometry attribute.
>> Indeed currently I mentionned:
>> /* In case the aperture is programmable, start/end are set to 0 */
>
> Which is confusing, if a user sets an aperture, I would think they'd
> like to see the MSI geometry updated to reflect that.
>
>> If I set start/end in iommu_msi_set_aperture then I think I should also
>> return the actual values in iommu_domain_get_attr. I thought the extra
>> care to handle the possible race between the set_aperture (msi_iommu)
>> and the get_attr (iommu) was maybe not worth the benefits:
>> is_aperture_set is not visible to get_attr so I would be forced to
>> introduce a mutex at iommu_domain level or call an msi-iommu function
>> from iommu implementation. So I preferred to keep start/end as read-only
>> info initialized by the iommu driver.
>
> Seems like a race between iommu_msi_set_aperture() and
> iommu_domain_get_attr() is the caller's problem. We can always define
> that start >= end is invalid and set them in the right order that
> iommu_domain_get_attr() may get different versions of invalid, but it
> will always be invalid or valid. A helper function could tell us if we
> have a valid range rather than using is_aperture_set. Thanks,
Agreed; I added an iommu_domain_msi_aperture_valid helper function.
Thanks!
Eric
>
> Alex
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailm
Re: [PATCH] iommu/arm-smmu: clear cache lock bit of ACR
On 03/05/16 11:15, Peng Fan wrote:
According MMU-500 TRM, section 3.7.1 Auxiliary Control registers,
You can modify ACTLR only when the ACR.CACHE_LOCK bit is 0.
So before clearing ARM_MMU500_ACTLR_CPRE of each context bank,
need clear CACHE_LOCK bit of ACR register first.
Ah, good catch - I think I misread CACHE_LOCK as resetting to 0, and
proceeded to forget about it. However, it's only present in MMU-500r2
onwards, so we'd also want to check IDR7 before touching ACR.
Thanks,
Robin.
Signed-off-by: Peng Fan
Cc: Will Deacon
Cc: Robin Murphy
---
Hi Will,
Patch based on iommu/devel branch.
drivers/iommu/arm-smmu.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index acff332..d094a5a 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -98,6 +98,9 @@
#define sCR0_BSU_SHIFT14
#define sCR0_BSU_MASK 0x3
+/* Auxiliary Configuration register */
+#define ARM_SMMU_GR0_sACR 0x10
+
/* Identification registers */
#define ARM_SMMU_GR0_ID0 0x20
#define ARM_SMMU_GR0_ID1 0x24
@@ -235,6 +238,8 @@
#define ARM_MMU500_ACTLR_CPRE (1 << 1)
+#define ARM_MMU500_ACR_CACHE_LOCK (1 << 26)
+
#define CB_PAR_F (1 << 0)
#define ATSR_ACTIVE (1 << 0)
@@ -1506,6 +1511,16 @@ static void arm_smmu_device_reset(struct arm_smmu_device
*smmu)
writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_S2CR(i));
}
+ /*
+* Before clearing ARM_MMU500_ACTLR_CPRE, need to
+* clear CACHE_LOCK bit of ACR first.
+*/
+ if (smmu->model == ARM_MMU500) {
+ reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
+ reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
+ writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
+ }
+
/* Make sure all context banks are disabled and clear CB_FSR */
for (i = 0; i < smmu->num_context_banks; ++i) {
cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, i);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported
> From: Yongji Xie > Sent: Wednesday, April 27, 2016 8:43 PM > > This patch enables mmapping MSI-X tables if hardware supports > interrupt remapping which can ensure that a given pci device > can only shoot the MSIs assigned for it. > > With MSI-X table mmapped, we also need to expose the > read/write interface which will be used to access MSI-X table. > > Signed-off-by: Yongji Xie A curious question here. Does "allow to mmap MSI-X" essentially mean that KVM guest can directly read/write physical MSI-X structure then? Thanks Kevin ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported
> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com] > Sent: Tuesday, May 03, 2016 2:08 PM > > On 2016/5/3 13:34, Tian, Kevin wrote: > > >> From: Yongji Xie > >> Sent: Wednesday, April 27, 2016 8:43 PM > >> > >> This patch enables mmapping MSI-X tables if hardware supports > >> interrupt remapping which can ensure that a given pci device > >> can only shoot the MSIs assigned for it. > >> > >> With MSI-X table mmapped, we also need to expose the > >> read/write interface which will be used to access MSI-X table. > >> > >> Signed-off-by: Yongji Xie > > A curious question here. Does "allow to mmap MSI-X" essentially > > mean that KVM guest can directly read/write physical MSI-X > > structure then? > > > > Thanks > > Kevin > > > > Here we just allow to mmap MSI-X table in kernel. It doesn't > mean all KVM guest can directly read/write physical MSI-X > structure. This should be decided by QEMU. For PPC64 > platform, we would allow to passthrough the MSI-X table > because we know guest kernel would not write physical > MSI-X structure when enabling MSI. > A bit confused here. If guest kernel doesn't need to write physical MSI-X structure, what's the point of passing through the table then? I think the key whether MSI-X table can be passed through is related to where hypervisor control is deployed. At least for x86: - When irq remapping is not enabled, host/hypervisor needs to control physical interrupt message including vector/dest/etc. directly in MSI-X structure, so we cannot allow a guest to access it; - when irq remapping is enabled, host/hypervisor can control interrupt routing in irq remapping table. However MSI-X also needs to be configured as remappable format. In this manner we also cannot allow direct access from guest. The only sane case to pass through MSI-X structure, is a mechanism similar to irq remapping but w/o need to change original MSI-X format so direct access from guest side is safe. Is it the case in PPC64? Thanks Kevin ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/arm-smmu: clear cache lock bit of ACR
According MMU-500 TRM, section 3.7.1 Auxiliary Control registers,
You can modify ACTLR only when the ACR.CACHE_LOCK bit is 0.
So before clearing ARM_MMU500_ACTLR_CPRE of each context bank,
need clear CACHE_LOCK bit of ACR register first.
Signed-off-by: Peng Fan
Cc: Will Deacon
Cc: Robin Murphy
---
Hi Will,
Patch based on iommu/devel branch.
drivers/iommu/arm-smmu.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index acff332..d094a5a 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -98,6 +98,9 @@
#define sCR0_BSU_SHIFT 14
#define sCR0_BSU_MASK 0x3
+/* Auxiliary Configuration register */
+#define ARM_SMMU_GR0_sACR 0x10
+
/* Identification registers */
#define ARM_SMMU_GR0_ID0 0x20
#define ARM_SMMU_GR0_ID1 0x24
@@ -235,6 +238,8 @@
#define ARM_MMU500_ACTLR_CPRE (1 << 1)
+#define ARM_MMU500_ACR_CACHE_LOCK (1 << 26)
+
#define CB_PAR_F (1 << 0)
#define ATSR_ACTIVE(1 << 0)
@@ -1506,6 +1511,16 @@ static void arm_smmu_device_reset(struct arm_smmu_device
*smmu)
writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_S2CR(i));
}
+ /*
+* Before clearing ARM_MMU500_ACTLR_CPRE, need to
+* clear CACHE_LOCK bit of ACR first.
+*/
+ if (smmu->model == ARM_MMU500) {
+ reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
+ reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
+ writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
+ }
+
/* Make sure all context banks are disabled and clear CB_FSR */
for (i = 0; i < smmu->num_context_banks; ++i) {
cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, i);
--
2.6.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported
On 2016/5/3 14:22, Tian, Kevin wrote: From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com] Sent: Tuesday, May 03, 2016 2:08 PM On 2016/5/3 13:34, Tian, Kevin wrote: From: Yongji Xie Sent: Wednesday, April 27, 2016 8:43 PM This patch enables mmapping MSI-X tables if hardware supports interrupt remapping which can ensure that a given pci device can only shoot the MSIs assigned for it. With MSI-X table mmapped, we also need to expose the read/write interface which will be used to access MSI-X table. Signed-off-by: Yongji Xie A curious question here. Does "allow to mmap MSI-X" essentially mean that KVM guest can directly read/write physical MSI-X structure then? Thanks Kevin Here we just allow to mmap MSI-X table in kernel. It doesn't mean all KVM guest can directly read/write physical MSI-X structure. This should be decided by QEMU. For PPC64 platform, we would allow to passthrough the MSI-X table because we know guest kernel would not write physical MSI-X structure when enabling MSI. A bit confused here. If guest kernel doesn't need to write physical MSI-X structure, what's the point of passing through the table then? We want to allow the MSI-X table because there may be some critical registers in the same page as the MSI-X table. We have to handle the mmio access to these register in QEMU rather than in guest if mmapping MSI-X table is disallowed. I think the key whether MSI-X table can be passed through is related to where hypervisor control is deployed. At least for x86: - When irq remapping is not enabled, host/hypervisor needs to control physical interrupt message including vector/dest/etc. directly in MSI-X structure, so we cannot allow a guest to access it; - when irq remapping is enabled, host/hypervisor can control interrupt routing in irq remapping table. However MSI-X also needs to be configured as remappable format. In this manner we also cannot allow direct access from guest. The only sane case to pass through MSI-X structure, is a mechanism similar to irq remapping but w/o need to change original MSI-X format so direct access from guest side is safe. Is it the case in PPC64? Thanks Kevin Acutually, we are not aimed at accessing MSI-X table from guest. So I think it's safe to passthrough MSI-X table if we can make sure guest kernel would not touch MSI-X table in normal code path such as para-virtualized guest kernel on PPC64. Thanks, Yongji ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
