* [PATCH 13/16] arm64: dts: renesas: r8a7796: Add EthernetAVB instance
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 43 ++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 26a0506e3013..d4beb15b076a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -428,6 +428,49 @@
};
};
+ avb: ethernet at e6800000 {
+ compatible = "renesas,etheravb-r8a7796",
+ "renesas,etheravb-rcar-gen3";
+ reg = <0 0xe6800000 0 0x800>, <0 0xe6a00000 0 0x10000>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14", "ch15",
+ "ch16", "ch17", "ch18", "ch19",
+ "ch20", "ch21", "ch22", "ch23",
+ "ch24";
+ clocks = <&cpg CPG_MOD 812>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ phy-mode = "rgmii-id";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
scif2: serial at e6e88000 {
compatible = "renesas,scif-r8a7796",
"renesas,rcar-gen3-scif", "renesas,scif";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 12/16] arm64: dts: r8a7796: salvator-x: Update memory node to 4 GiB map
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
This patch updates memory region:
- After changes, the new map of the Salvator-X board on R8A7796 SoC
Bank0: 2GiB RAM : 0x000048000000 -> 0x000bfffffff
Bank1: 2GiB RAM : 0x000600000000 -> 0x0067fffffff
- Before changes, the old map looked like this:
Bank0: 2GiB RAM : 0x000048000000 -> 0x000bfffffff
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Correct size of old map]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index f35e96ca7d60..38bde9de3250 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -31,6 +31,11 @@
reg = <0x0 0x48000000 0x0 0x78000000>;
};
+ memory at 600000000 {
+ device_type = "memory";
+ reg = <0x6 0x00000000 0x0 0x80000000>;
+ };
+
reg_1p8v: regulator0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 11/16] arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for i2c nodes
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
Use recently added R-Car Gen 3 fallback binding for i2c nodes in
DT for r8a7796 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7796 and the
fallback binding for R-Car Gen 3.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index a37bb5eb062c..26a0506e3013 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -269,7 +269,8 @@
i2c0: i2c at e6500000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe6500000 0 0x40>;
interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 931>;
@@ -284,7 +285,8 @@
i2c1: i2c at e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 930>;
@@ -299,7 +301,8 @@
i2c2: i2c at e6510000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe6510000 0 0x40>;
interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 929>;
@@ -314,7 +317,8 @@
i2c3: i2c at e66d0000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe66d0000 0 0x40>;
interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 928>;
@@ -328,7 +332,8 @@
i2c4: i2c at e66d8000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe66d8000 0 0x40>;
interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 927>;
@@ -342,7 +347,8 @@
i2c5: i2c at e66e0000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe66e0000 0 0x40>;
interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 919>;
@@ -356,7 +362,8 @@
i2c6: i2c at e66e8000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe66e8000 0 0x40>;
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 918>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 10/16] arm64: dts: r8a7795: Use R-Car Gen 3 fallback binding for i2c nodes
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
Use recently added R-Car Gen 3 fallback binding for i2c nodes in
DT for r8a7795 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7795 and the
fallback binding for R-Car Gen 3.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 91a797b18c11..3fe7e0af5989 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -792,7 +792,8 @@
i2c0: i2c at e6500000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe6500000 0 0x40>;
interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 931>;
@@ -806,7 +807,8 @@
i2c1: i2c at e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 930>;
@@ -820,7 +822,8 @@
i2c2: i2c at e6510000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe6510000 0 0x40>;
interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 929>;
@@ -834,7 +837,8 @@
i2c3: i2c at e66d0000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe66d0000 0 0x40>;
interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 928>;
@@ -848,7 +852,8 @@
i2c4: i2c at e66d8000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe66d8000 0 0x40>;
interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 927>;
@@ -862,7 +867,8 @@
i2c5: i2c at e66e0000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe66e0000 0 0x40>;
interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 919>;
@@ -876,7 +882,8 @@
i2c6: i2c at e66e8000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+ "renesas,rcar-gen3-i2c";
reg = <0 0xe66e8000 0 0x40>;
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 918>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 09/16] arm64: dts: r8a7795: Use Gen 3 fallback compat string for PCIE
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
Use recently added en 3 fallback compat string for PCIE
in r8a7795 DT.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 7e21491c6510..91a797b18c11 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1279,7 +1279,8 @@
};
pciec0: pcie at fe000000 {
- compatible = "renesas,pcie-r8a7795";
+ compatible = "renesas,pcie-r8a7795",
+ "renesas,pcie-rcar-gen3";
reg = <0 0xfe000000 0 0x80000>;
#address-cells = <3>;
#size-cells = <2>;
@@ -1304,7 +1305,8 @@
};
pciec1: pcie at ee800000 {
- compatible = "renesas,pcie-r8a7795";
+ compatible = "renesas,pcie-r8a7795",
+ "renesas,pcie-rcar-gen3";
reg = <0 0xee800000 0 0x80000>;
#address-cells = <3>;
#size-cells = <2>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 08/16] arm64: dts: r8a7795: add sound MIX support
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
This patch adds MIX (= Mixer) support.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 1 +
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 82a269a4f10d..7a8986edcdc0 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -413,6 +413,7 @@
<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+ <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
<&audio_clk_a>, <&cs2000>,
<&audio_clk_c>,
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index e09f5b7b874a..7e21491c6510 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -920,6 +920,7 @@
<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+ <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
<&audio_clk_a>, <&audio_clk_b>,
<&audio_clk_c>,
@@ -931,6 +932,7 @@
"src.9", "src.8", "src.7", "src.6",
"src.5", "src.4", "src.3", "src.2",
"src.1", "src.0",
+ "mix.1", "mix.0",
"ctu.1", "ctu.0",
"dvc.0", "dvc.1",
"clk_a", "clk_b", "clk_c", "clk_i";
@@ -948,6 +950,11 @@
};
};
+ rcar_sound,mix {
+ mix0: mix-0 { };
+ mix1: mix-1 { };
+ };
+
rcar_sound,ctu {
ctu00: ctu-0 { };
ctu01: ctu-1 { };
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 07/16] arm64: dts: r8a7795: add sound CTU support
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
This patch adds CTU (= Channel Transfer Unit) support which is needed
to sound mixing.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 1 +
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 13 +++++++++++++
2 files changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index bcaf4008d32d..82a269a4f10d 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -412,6 +412,7 @@
<&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+ <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
<&audio_clk_a>, <&cs2000>,
<&audio_clk_c>,
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 2c076c21d7fa..e09f5b7b874a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -919,6 +919,7 @@
<&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+ <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
<&audio_clk_a>, <&audio_clk_b>,
<&audio_clk_c>,
@@ -930,6 +931,7 @@
"src.9", "src.8", "src.7", "src.6",
"src.5", "src.4", "src.3", "src.2",
"src.1", "src.0",
+ "ctu.1", "ctu.0",
"dvc.0", "dvc.1",
"clk_a", "clk_b", "clk_c", "clk_i";
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
@@ -946,6 +948,17 @@
};
};
+ rcar_sound,ctu {
+ ctu00: ctu-0 { };
+ ctu01: ctu-1 { };
+ ctu02: ctu-2 { };
+ ctu03: ctu-3 { };
+ ctu10: ctu-4 { };
+ ctu11: ctu-5 { };
+ ctu12: ctu-6 { };
+ ctu13: ctu-7 { };
+ };
+
rcar_sound,src {
src0: src-0 {
interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 06/16] arm64: dts: r8a7795: Use renesas, rcar-gen3-usb2-phy fallback binding
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
A fallback binding for the Renesas R-Car Gen3 for USB2.0 PHY driver was
added by commit cde7bc367f09 ("phy: rcar-gen3-usb2: add fallback binding").
This patch makes use of this binding in the DT for the r8a7795 SoC.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index bbf594bce930..2c076c21d7fa 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1146,7 +1146,8 @@
};
usb2_phy0: usb-phy at ee080200 {
- compatible = "renesas,usb2-phy-r8a7795";
+ compatible = "renesas,usb2-phy-r8a7795",
+ "renesas,rcar-gen3-usb2-phy";
reg = <0 0xee080200 0 0x700>;
interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 703>;
@@ -1156,7 +1157,8 @@
};
usb2_phy1: usb-phy at ee0a0200 {
- compatible = "renesas,usb2-phy-r8a7795";
+ compatible = "renesas,usb2-phy-r8a7795",
+ "renesas,rcar-gen3-usb2-phy";
reg = <0 0xee0a0200 0 0x700>;
clocks = <&cpg CPG_MOD 702>;
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
@@ -1165,7 +1167,8 @@
};
usb2_phy2: usb-phy at ee0c0200 {
- compatible = "renesas,usb2-phy-r8a7795";
+ compatible = "renesas,usb2-phy-r8a7795",
+ "renesas,rcar-gen3-usb2-phy";
reg = <0 0xee0c0200 0 0x700>;
clocks = <&cpg CPG_MOD 701>;
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 05/16] arm64: renesas: r8a7796/salvator-x: Add board part number to DT bindings
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 253bf9b86690..c9502634316d 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -75,7 +75,7 @@ Boards:
compatible = "renesas,rskrza1", "renesas,r7s72100"
- Salvator-X (RTP0RC7795SIPB0010S)
compatible = "renesas,salvator-x", "renesas,r8a7795";
- - Salvator-X
+ - Salvator-X (RTP0RC7796SIPB0011S)
compatible = "renesas,salvator-x", "renesas,r8a7796";
- SILK (RTP0RC7794LCB00011S)
compatible = "renesas,silk", "renesas,r8a7794"
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 04/16] arm64: dts: r8a7796: Add CAN FD support
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
From: Chris Paterson <chris.paterson2@renesas.com>
Adds CAN FD controller node for r8a7796.
Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index a97ef2e7202c..a37bb5eb062c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -397,6 +397,30 @@
status = "disabled";
};
+ canfd: can at e66c0000 {
+ compatible = "renesas,r8a7796-canfd",
+ "renesas,rcar-gen3-canfd";
+ reg = <0 0xe66c0000 0 0x8000>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 914>,
+ <&cpg CPG_CORE R8A7796_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "fck", "canfd", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7796_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
+
+ channel0 {
+ status = "disabled";
+ };
+
+ channel1 {
+ status = "disabled";
+ };
+ };
+
scif2: serial at e6e88000 {
compatible = "renesas,scif-r8a7796",
"renesas,rcar-gen3-scif", "renesas,scif";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 03/16] arm64: dts: r8a7796: Add CAN support
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
From: Chris Paterson <chris.paterson2@renesas.com>
Adds CAN controller nodes for r8a7796.
Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index c0f9ced8df7e..a97ef2e7202c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -367,6 +367,36 @@
status = "disabled";
};
+ can0: can at e6c30000 {
+ compatible = "renesas,can-r8a7796",
+ "renesas,rcar-gen3-can";
+ reg = <0 0xe6c30000 0 0x1000>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 916>,
+ <&cpg CPG_CORE R8A7796_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7796_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ can1: can at e6c38000 {
+ compatible = "renesas,can-r8a7796",
+ "renesas,rcar-gen3-can";
+ reg = <0 0xe6c38000 0 0x1000>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 915>,
+ <&cpg CPG_CORE R8A7796_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7796_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
scif2: serial at e6e88000 {
compatible = "renesas,scif-r8a7796",
"renesas,rcar-gen3-scif", "renesas,scif";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 02/16] arm64: dts: r8a7796: Add CAN external clock support
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
From: Chris Paterson <chris.paterson2@renesas.com>
Adds external CAN clock node for r8a7796. This clock can be used as
fCAN clock of CAN and CAN FD controller.
Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 4bf8e14956fe..c0f9ced8df7e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -69,6 +69,13 @@
clock-frequency = <0>;
};
+ /* External CAN clock - to be overridden by boards that provide it */
+ can_clk: can {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
/* External SCIF clock - to be overridden by boards that provide it */
scif_clk: scif {
compatible = "fixed-clock";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 01/16] arm64: dts: r8a7796: Add all MSIOF nodes
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1483700694.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add the device nodes for all MSIOF SPI controllers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 54 ++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 28ba59a00cd8..4bf8e14956fe 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -373,6 +373,60 @@
status = "disabled";
};
+ msiof0: spi at e6e90000 {
+ compatible = "renesas,msiof-r8a7796";
+ reg = <0 0xe6e90000 0 0x0064>;
+ interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 211>;
+ dmas = <&dmac1 0x41>, <&dmac1 0x40>,
+ <&dmac2 0x41>, <&dmac2 0x40>;
+ dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ msiof1: spi at e6ea0000 {
+ compatible = "renesas,msiof-r8a7796";
+ reg = <0 0xe6ea0000 0 0x0064>;
+ interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 210>;
+ dmas = <&dmac1 0x43>, <&dmac1 0x42>,
+ <&dmac2 0x43>, <&dmac2 0x42>;
+ dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ msiof2: spi at e6c00000 {
+ compatible = "renesas,msiof-r8a7796";
+ reg = <0 0xe6c00000 0 0x0064>;
+ interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 209>;
+ dmas = <&dmac0 0x45>, <&dmac0 0x44>;
+ dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ msiof3: spi at e6c10000 {
+ compatible = "renesas,msiof-r8a7796";
+ reg = <0 0xe6c10000 0 0x0064>;
+ interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 208>;
+ dmas = <&dmac0 0x47>, <&dmac0 0x46>;
+ dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
dmac0: dma-controller at e6700000 {
compatible = "renesas,dmac-r8a7796",
"renesas,rcar-dmac";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [QUESTION] Early Write Acknowledge for PCIe configuration space
From: John Garry @ 2017-01-06 11:15 UTC (permalink / raw)
To: linux-arm-kernel
[apologies if this has been queried before]
Hi ARM guys,
I have a question about the device memory attributes we assign for PCIe
config space for arm64. Currently we use ioremap to map in the config
space; this uses nGnRE, which means we enable Early Write Acknowledge.
The ARMv8 ARM states that "ARM recommend that No Early Write Acknowledge
Hint is used for PCIe configuration writes".
I understand a problem with using E is in that configuration write is a
non-post operation, which means the RP requires to get the completion
ack from the EP The problem here is if CPU writes data to ECAM by E,
complete will go back to CPU directly, and maybe at this point the write
has not reached the EP.
I believe that this may cause ordering issues in PCI read/write. In
practice we use non-relaxed readl/writel to access config space, which
include the synchronization barriers, which, *as I understand*, even if
for full system domain, may be negated by the E attribute for PCIe.
So a question: why is the recommendation in the ARMv8 ARM ignored?
Thanks in advance,
John
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Arnd Bergmann @ 2017-01-06 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9d5e32d3-000c-2f95-7ea8-c64d53ab6b56@cogentembedded.com>
On Wednesday, January 4, 2017 6:29:39 PM CET Nikita Yushchenko wrote:
> > Just a guess, but if the inbound translation windows in the host
> > bridge are wider than 32-bit, the reason for setting up a single
> > 32-bit window is probably because that is what the parent bus supports.
>
> Well anyway applying patch similar to your's will fix pcie-rcar + nvme
> case - thus I don't object :) But it can break other cases ...
>
> But why do you hook at set_dma_mask() and overwrite mask inside, instead
> of hooking at dma_supported() and rejecting unsupported mask?
>
> I think later is better, because it lets drivers to handle unsupported
> high-dma case, like documented in DMA-API_HOWTO.
I think the behavior I put in there is required for swiotlb to make
sense, otherwise you would rely on the driver to handle dma_set_mask()
failure gracefully with its own bounce buffers (as network and
scsi drivers do but others don't).
Having swiotlb or iommu enabled should result in dma_set_mask() always
succeeding unless the mask is too small to cover the swiotlb
bounce buffer area or the iommu virtual address space. This behavior
is particularly important in case the bus address space is narrower
than 32-bit, as we have to guarantee that the fallback to 32-bit
DMA always succeeds. There are also a lot of drivers that try to
set a 64-bit mask but don't implement bounce buffers for streaming
mappings if that fails, and swiotlb is what we use to make those
drivers work.
And yes, the API is a horrible mess.
Arnd
^ permalink raw reply
* [PATCH V8 1/9] iommu: add IOMMU_PRIV attribute
From: Joerg Roedel @ 2017-01-06 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483362764-11990-2-git-send-email-sricharan@codeaurora.org>
On Mon, Jan 02, 2017 at 06:42:36PM +0530, Sricharan R wrote:
> From: Mitchel Humpherys <mitchelh@codeaurora.org>
>
> Add the IOMMU_PRIV attribute, which is used to indicate privileged
> mappings.
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Tested-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
> Acked-by: Will Deacon <will.deacon@arm.com>
> ---
> include/linux/iommu.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 0ff5111..8c15ada 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -31,6 +31,7 @@
> #define IOMMU_CACHE (1 << 2) /* DMA cache coherency */
> #define IOMMU_NOEXEC (1 << 3)
> #define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
> +#define IOMMU_PRIV (1 << 5) /* privileged */
Since this is a new generic global flag, can you please add a more
verbose comment telling what a 'privileged' mapping is about in the
iommu-case? We should have a clear defined semantic for this flag or we
might end up with different meanings for it with different
iommu-hardware.
Joerg
^ permalink raw reply
* [PATCH v6 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Joerg Roedel @ 2017-01-06 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483643086-2883-1-git-send-email-eric.auger@redhat.com>
On Thu, Jan 05, 2017 at 07:04:28PM +0000, Eric Auger wrote:
> iommu/dma: Allow MSI-only cookies
> iommu: Rename iommu_dm_regions into iommu_resv_regions
> iommu: Add a new type field in iommu_resv_region
> iommu: iommu_alloc_resv_region
> iommu: Only map direct mapped regions
> iommu: iommu_get_group_resv_regions
> iommu: Implement reserved_regions iommu-group sysfs file
> iommu/vt-d: Implement reserved region get/put callbacks
> iommu/amd: Declare MSI and HT regions as reserved IOVA regions
> iommu/arm-smmu: Implement reserved region get/put callbacks
> iommu/arm-smmu-v3: Implement reserved region get/put callbacks
The iommu changes look mostly good to me. I posted a few comments to
individual patches.
Joerg
^ permalink raw reply
* [PATCH v6 08/18] iommu/vt-d: Implement reserved region get/put callbacks
From: Joerg Roedel @ 2017-01-06 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483643086-2883-9-git-send-email-eric.auger@redhat.com>
On Thu, Jan 05, 2017 at 07:04:36PM +0000, Eric Auger wrote:
> +static void intel_iommu_get_resv_regions(struct device *device,
> + struct list_head *head)
> +{
> + struct iommu_resv_region *reg;
> +
> + reg = iommu_alloc_resv_region(IOAPIC_RANGE_START,
> + IOAPIC_RANGE_END - IOAPIC_RANGE_START + 1,
> + 0, IOMMU_RESV_NOMAP);
> + if (!reg)
> + return;
> + list_add_tail(®->list, head);
> +}
That is different from what AMD does, can you also report the RMRR
regions for the device here (as direct-map regions)?
Joerg
^ permalink raw reply
* [PATCH v6 07/18] iommu: Implement reserved_regions iommu-group sysfs file
From: Joerg Roedel @ 2017-01-06 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483643086-2883-8-git-send-email-eric.auger@redhat.com>
On Thu, Jan 05, 2017 at 07:04:35PM +0000, Eric Auger wrote:
> + list_for_each_entry_safe(region, next, &group_resv_regions, list) {
> + str += sprintf(str, "0x%016llx 0x%016llx\n",
> + (long long int)region->start,
> + (long long int)(region->start +
> + region->length - 1));
> + kfree(region);
> + }
I think it also makes sense to report the type of the reserved region.
Joerg
^ permalink raw reply
* [PATCH v6 01/18] iommu/dma: Allow MSI-only cookies
From: Joerg Roedel @ 2017-01-06 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483643086-2883-2-git-send-email-eric.auger@redhat.com>
On Thu, Jan 05, 2017 at 07:04:29PM +0000, Eric Auger wrote:
> struct iommu_dma_cookie {
> - struct iova_domain iovad;
> - struct list_head msi_page_list;
> - spinlock_t msi_lock;
> + union {
> + struct iova_domain iovad;
> + dma_addr_t msi_iova;
> + };
> + struct list_head msi_page_list;
> + spinlock_t msi_lock;
> + enum iommu_dma_cookie_type type;
Please move the type to the beginning of the struct and add a comment
how the type relates to the union.
Joerg
^ permalink raw reply
* [RFC PATCH 4/7] KVM: arm/arm64: Check that system supports split eoi/deactivate
From: Christoffer Dall @ 2017-01-06 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3f788da-4cae-76ee-d186-ad44fcf3a318@arm.com>
On Fri, Jan 06, 2017 at 10:24:04AM +0000, Marc Zyngier wrote:
> On 06/01/17 10:02, Christoffer Dall wrote:
> > On Thu, Jan 05, 2017 at 05:40:58PM +0000, Marc Zyngier wrote:
> >> On 10/12/16 20:47, Christoffer Dall wrote:
> >>> Some systems without proper firmware and/or hardware description data
> >>> don't support the split EOI and deactivate operation and therefore
> >>> don't provide an irq_set_vcpu_affinity implementation. On such
> >>> systems, we cannot leave the physical interrupt active after the timer
> >>> handler on the host has run, so we cannot support KVM with the timer
> >>> changes we about to introduce.
> >>>
> >>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> >>> ---
> >>> virt/kvm/arm/arch_timer.c | 30 ++++++++++++++++++++++++++++++
> >>> 1 file changed, 30 insertions(+)
> >>>
> >>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> >>> index c7c3bfd..f27a086 100644
> >>> --- a/virt/kvm/arm/arch_timer.c
> >>> +++ b/virt/kvm/arm/arch_timer.c
> >>> @@ -418,6 +418,31 @@ static int kvm_timer_dying_cpu(unsigned int cpu)
> >>> return 0;
> >>> }
> >>>
> >>> +static bool has_split_eoi_deactivate_support(void)
> >>> +{
> >>> + struct irq_desc *desc;
> >>> + struct irq_data *data;
> >>> + struct irq_chip *chip;
> >>> +
> >>> + /*
> >>> + * Check if split EOI and deactivate is supported on this machine.
> >>> + */
> >>> + desc = irq_to_desc(host_vtimer_irq);
> >>> + if (!desc) {
> >>> + kvm_err("kvm_arch_timer: no host_vtimer_irq descriptor\n");
> >>> + return false;
> >>> + }
> >>> +
> >>> + data = irq_desc_get_irq_data(desc);
> >>> + chip = irq_data_get_irq_chip(data);
> >>> + if (!chip || !chip->irq_set_vcpu_affinity) {
> >>> + kvm_err("kvm_arch_timer: no split EOI/deactivate; abort\n");
> >>> + return false;
> >>> + }
> >>> +
> >>> + return true;
> >>> +}
> >>
> >> That feels really involved. How about reporting that we don't have a
> >> usable VGIC altogether from the GIC driver?
> >>
> >
> > You mean not booting the kernel at all, or establish some communication
> > from the GIC driver to KVM, telling KVM if it's usable for
> > virtualization or not?
>
> We already query the vgic configuration by calling gic_get_kvm_info() at
> boot time. My suggestion is to make it return NULL if the GIC can't
> support split EOI/deactivate, and fallback to the "no-vgic" mode, if
> ever implemented.
>
That sounds good to me.
Thanks,
-Christoffer
^ permalink raw reply
* [RFC PATCH 1/7] arm64: Use physical counter for in-kernel reads
From: Christoffer Dall @ 2017-01-06 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <89b4c1c1-3c6a-b7a1-cbcb-93a64812ebff@arm.com>
On Fri, Jan 06, 2017 at 10:38:49AM +0000, Marc Zyngier wrote:
> On 06/01/17 10:00, Christoffer Dall wrote:
> > Hi Marc,
> >
> > On Thu, Jan 05, 2017 at 06:11:14PM +0000, Marc Zyngier wrote:
> >> [adding the arm64 maintainers, plus Mark as arch timer maintainer]
> >
> > Right, sorry, I should have done that already.
> >
> >>
> >> On 10/12/16 20:47, Christoffer Dall wrote:
> >>> Using the physical counter allows KVM to retain the offset between the
> >>> virtual and physical counter as long as it is actively running a VCPU.
> >>>
> >>> As soon as a VCPU is released, another thread is scheduled or we start
> >>> running userspace applications, we reset the offset to 0, so that VDSO
> >>> operations can still read the virtual counter and get the same view of
> >>> time as the kernel.
> >>>
> >>> This opens up potential improvements for KVM performance.
> >>>
> >>> VHE kernels or kernels using the virtual timer are unaffected by this.
> >>>
> >>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> >>> ---
> >>> arch/arm64/include/asm/arch_timer.h | 6 ++++--
> >>> drivers/clocksource/arm_arch_timer.c | 2 +-
> >>> 2 files changed, 5 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> >>> index eaa5bbe..cec2549 100644
> >>> --- a/arch/arm64/include/asm/arch_timer.h
> >>> +++ b/arch/arm64/include/asm/arch_timer.h
> >>> @@ -139,11 +139,13 @@ static inline void arch_timer_set_cntkctl(u32 cntkctl)
> >>>
> >>> static inline u64 arch_counter_get_cntpct(void)
> >>> {
> >>> + u64 cval;
> >>> /*
> >>> * AArch64 kernel and user space mandate the use of CNTVCT.
> >>> */
> >>> - BUG();
> >>> - return 0;
> >>> + isb();
> >>> + asm volatile("mrs %0, cntpct_el0" : "=r" (cval));
> >>> + return cval;
> >>> }
> >>>
> >>> static inline u64 arch_counter_get_cntvct(void)
> >>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> >>> index 73c487d..a5b0789 100644
> >>> --- a/drivers/clocksource/arm_arch_timer.c
> >>> +++ b/drivers/clocksource/arm_arch_timer.c
> >>> @@ -597,7 +597,7 @@ static void __init arch_counter_register(unsigned type)
> >>>
> >>> /* Register the CP15 based counter if we have one */
> >>> if (type & ARCH_CP15_TIMER) {
> >>> - if (IS_ENABLED(CONFIG_ARM64) || arch_timer_uses_ppi == VIRT_PPI)
> >>> + if (arch_timer_uses_ppi == VIRT_PPI || is_kernel_in_hyp_mode())
> >>
> >> Why do we have this is_kernel_in_hyp_mode clause? I can't think of any
> >> reason for a VHE kernel to use the virtual counter at all...
> >>
> >
> > Good question. I think I just didn't want to change behavior from the
> > existing functionality mre than necessary.
> >
> > Note that on a VHE kernel this will be the EL2 virtual counter, not the
> > EL1 virtual counter, due to the register redirection. Are the virtual
> > and physical EL2 counters always equivalent on a VHE system?
>
> Yes, they are. CNTVOFF_EL2 is ignored in that case, and you get an extra
> interrupt for the new EL2 virtual timer as well.
>
ok, in that case I suppose I can just check for arch_timer_uses_ppi ==
VIRT_PPI and be done with it.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v2 2/4] linux/const.h: move UL() macro to include/linux/const.h
From: David Howells @ 2017-01-06 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483582810-7046-3-git-send-email-yamada.masahiro@socionext.com>
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> diff --git a/include/uapi/linux/const.h b/include/uapi/linux/const.h
> index c872bfd..76fb0f9 100644
> --- a/include/uapi/linux/const.h
> +++ b/include/uapi/linux/const.h
> @@ -1,7 +1,7 @@
> /* const.h: Macros for dealing with constants. */
>
> -#ifndef _LINUX_CONST_H
> -#define _LINUX_CONST_H
> +#ifndef _UAPI_LINUX_CONST_H
> +#define _UAPI_LINUX_CONST_H
You need to be very careful doing this. Some userspace stuff depends on the
guard macro names on the kernel header files.
> /* Some constant macros are used in both assembler and
> * C code. Therefore we cannot annotate them always with
> @@ -21,7 +21,10 @@
> #define _AT(T,X) ((T)(X))
> #endif
>
> +#define _UL(x) (_AC(x, UL))
> +#define _ULL(x) (_AC(x, ULL))
How likely is this to collide with existing userspace code somewhere? It
looks like the sort of thing that could collide with a C library.
David
^ permalink raw reply
* [PATCH V6 05/10] acpi: apei: handle SEA notification type for ARMv8
From: James Morse @ 2017-01-06 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8b7fa162-0d44-025f-758d-d61cfa75c787@codeaurora.org>
Hi Tyler,
On 05/01/17 22:31, Baicar, Tyler wrote:
> On 12/20/2016 8:29 AM, James Morse wrote:
>> On 07/12/16 21:48, Tyler Baicar wrote:
>>> ARM APEI extension proposal added SEA (Synchrounous External
>>> Abort) notification type for ARMv8.
>>> Add a new GHES error source handling function for SEA. If an error
>>> source's notification type is SEA, then this function can be registered
>>> into the SEA exception handler. That way GHES will parse and report
>>> SEA exceptions when they occur.
>>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>>> index 2acbc60..66ab3fd 100644
>>> --- a/drivers/acpi/apei/ghes.c
>>> +++ b/drivers/acpi/apei/ghes.c
>>> @@ -767,6 +771,62 @@ static struct notifier_block ghes_notifier_sci = {
>>> .notifier_call = ghes_notify_sci,
>>> };
>>> +#ifdef CONFIG_HAVE_ACPI_APEI_SEA
>>> +static LIST_HEAD(ghes_sea);
>>> +
>>> +static int ghes_notify_sea(struct notifier_block *this,
>>> + unsigned long event, void *data)
>>> +{
>>> + struct ghes *ghes;
>>> + int ret = NOTIFY_DONE;
>>> +
>>> + rcu_read_lock();
>>> + list_for_each_entry_rcu(ghes, &ghes_sea, list) {
>>> + if (!ghes_proc(ghes))
>>> + ret = NOTIFY_OK;
>>> + }
>>> + rcu_read_unlock();
>>> +
>>> + return ret;
>>> +}
>> What stops this from being re-entrant?
>>
>> ghes_copy_tofrom_phs() takes the ghes_ioremap_lock_irq spinlock, but there is
>> nothing to stop a subsequent instruction fetch or memory access causing another
>> (maybe different) Synchronous External Abort which deadlocks trying to take the
>> same lock.
>>
>> ghes_notify_sea() looks to be based on ghes_notify_sci(), which (if I've found
>> the right part of the ACPI spec) is a level-low interrupt. spin_lock_irqsave()
>> would mask interrupts so there is no risk of a different notification firing on
>> the same CPU, (it looks like they are almost all ultimately an irq).
>>
>> NMI is the odd one out because its not maskable like this, but ghes_notify_nmi()
>> has:
>>> if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
>>> return ret;
>> To ensure there is only ever one thread poking around in this code.
>>
>> What happens if a system describes two GHES sources, one using an irq the other
>> SEA? The SEA error can interrupt the irq error while its holding the above lock.
>> I guess this is also why all the NMI code in that file is separate.
> Let me see if I'm following you right :)
> I should use spin_lock_irqsave() in ghes_notify_sea() to avoid ghes_notify_sci()
> from
> interrupting this process and potentially causing the deadlock?
This way round you are already safe: The CPU masks interrupts when it takes the
exception, they should still be masked by the time we get in here...
The other way round is a lot more fun!
What happens if APEI is processing some error record that was notified via an
interrupt, and then takes the Synchronous External Abort, and ends up back in
this code? Masking interrupts doesn't stop the external-abort, and trying to
take the ghes_ioremap_lock_irq will deadlock.
What happens if we interrupt printk() holding all its locks is another thing I
haven't worked out yet.
> This race condition does seem valid. We are using the same acknowledgment for
> all our
> HEST table entries, so our firmware will not populate more than one entry at a
> time. That
> gets us around this race condition.
Ah, so your firmware will wait for the interrupt-signalled error to be finished
before it triggers the Synchronous External Abort. I think this would still be a
linux bug if the firmware didn't do this.
x86 could have done the same with NMI notifications, but we have all this 'if
(in_nmi)' to allow interrupts-masked GHES handling to be interrupted.
What do you think to re-using the 'if (in_nmi)' code for SEA? We can argue that
SEA is NMI-like in that it can't be masked, and it interrupts code that had
interrupts masked. It 'should' be as simple as putting 'HAVE_NMI' in arm64's
Kconfig, and wrapping the atomic notifier call with nmi_enter()/nmi_exit() from
linux/hardirq.h. (...famous last words...)
This probably answers my printk() questions too, but I need to look into it some
more.
Thanks,
James
^ permalink raw reply
* [RFC PATCH 1/7] arm64: Use physical counter for in-kernel reads
From: Marc Zyngier @ 2017-01-06 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106100049.GB21089@cbox>
On 06/01/17 10:00, Christoffer Dall wrote:
> Hi Marc,
>
> On Thu, Jan 05, 2017 at 06:11:14PM +0000, Marc Zyngier wrote:
>> [adding the arm64 maintainers, plus Mark as arch timer maintainer]
>
> Right, sorry, I should have done that already.
>
>>
>> On 10/12/16 20:47, Christoffer Dall wrote:
>>> Using the physical counter allows KVM to retain the offset between the
>>> virtual and physical counter as long as it is actively running a VCPU.
>>>
>>> As soon as a VCPU is released, another thread is scheduled or we start
>>> running userspace applications, we reset the offset to 0, so that VDSO
>>> operations can still read the virtual counter and get the same view of
>>> time as the kernel.
>>>
>>> This opens up potential improvements for KVM performance.
>>>
>>> VHE kernels or kernels using the virtual timer are unaffected by this.
>>>
>>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>>> ---
>>> arch/arm64/include/asm/arch_timer.h | 6 ++++--
>>> drivers/clocksource/arm_arch_timer.c | 2 +-
>>> 2 files changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
>>> index eaa5bbe..cec2549 100644
>>> --- a/arch/arm64/include/asm/arch_timer.h
>>> +++ b/arch/arm64/include/asm/arch_timer.h
>>> @@ -139,11 +139,13 @@ static inline void arch_timer_set_cntkctl(u32 cntkctl)
>>>
>>> static inline u64 arch_counter_get_cntpct(void)
>>> {
>>> + u64 cval;
>>> /*
>>> * AArch64 kernel and user space mandate the use of CNTVCT.
>>> */
>>> - BUG();
>>> - return 0;
>>> + isb();
>>> + asm volatile("mrs %0, cntpct_el0" : "=r" (cval));
>>> + return cval;
>>> }
>>>
>>> static inline u64 arch_counter_get_cntvct(void)
>>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>>> index 73c487d..a5b0789 100644
>>> --- a/drivers/clocksource/arm_arch_timer.c
>>> +++ b/drivers/clocksource/arm_arch_timer.c
>>> @@ -597,7 +597,7 @@ static void __init arch_counter_register(unsigned type)
>>>
>>> /* Register the CP15 based counter if we have one */
>>> if (type & ARCH_CP15_TIMER) {
>>> - if (IS_ENABLED(CONFIG_ARM64) || arch_timer_uses_ppi == VIRT_PPI)
>>> + if (arch_timer_uses_ppi == VIRT_PPI || is_kernel_in_hyp_mode())
>>
>> Why do we have this is_kernel_in_hyp_mode clause? I can't think of any
>> reason for a VHE kernel to use the virtual counter at all...
>>
>
> Good question. I think I just didn't want to change behavior from the
> existing functionality mre than necessary.
>
> Note that on a VHE kernel this will be the EL2 virtual counter, not the
> EL1 virtual counter, due to the register redirection. Are the virtual
> and physical EL2 counters always equivalent on a VHE system?
Yes, they are. CNTVOFF_EL2 is ignored in that case, and you get an extra
interrupt for the new EL2 virtual timer as well.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox