* [PATCH 14/16] arm64: dts: r8a7796: salvator-x: Enable EthernetAVB
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>
[geert: Add pinctrl]
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 | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index 38bde9de3250..c7f40f8f3169 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -18,6 +18,7 @@
aliases {
serial0 = &scif2;
+ ethernet0 = &avb;
};
chosen {
@@ -107,6 +108,11 @@
pinctrl-0 = <&scif_clk_pins>;
pinctrl-names = "default";
+ avb_pins: avb {
+ groups = "avb_mdc";
+ function = "avb";
+ };
+
scif2_pins: scif2 {
groups = "scif2_data_a";
function = "scif2";
@@ -158,6 +164,32 @@
};
};
+&avb {
+ pinctrl-0 = <&avb_pins>;
+ pinctrl-names = "default";
+ renesas,no-ether-link;
+ phy-handle = <&phy0>;
+ status = "okay";
+
+ phy0: ethernet-phy at 0 {
+ rxc-skew-ps = <900>;
+ rxdv-skew-ps = <0>;
+ rxd0-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd3-skew-ps = <0>;
+ txc-skew-ps = <900>;
+ txen-skew-ps = <0>;
+ txd0-skew-ps = <0>;
+ txd1-skew-ps = <0>;
+ txd2-skew-ps = <0>;
+ txd3-skew-ps = <0>;
+ reg = <0>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
&extal_clk {
clock-frequency = <16666666>;
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.11
From: Simon Horman @ 2017-01-06 11:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these Renesas ARM64 based SoC DT updates for v4.11.
This is based on v4.10-rc2 as v4.10-rc1 does not compile using
the defconfig.
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-dt-for-v4.11
for you to fetch changes up to b2b9443beee5017ebdb3f2be9ef472c73d260481:
arm64: dts: r8a7795: Add PWM support (2017-01-04 10:00:44 +0100)
----------------------------------------------------------------
Renesas ARM64 Based SoC DT Updates for v4.11
* Add PWM, and sound MIX and CTU support to r8a7795 SoC
* Add CAN, CAN FD and all MSIOF nodes to r8a7796 SoC
* Use Gen 3 fallback binding for i2c, msiof, PCIE and USB2 phy
* Enable Ethernet and 4 GiB memory on r8a7796/salvator-x board
* Add r8a7796/salvator-x board part number to bindings
----------------------------------------------------------------
Chris Paterson (3):
arm64: dts: r8a7796: Add CAN external clock support
arm64: dts: r8a7796: Add CAN support
arm64: dts: r8a7796: Add CAN FD support
Geert Uytterhoeven (2):
arm64: dts: r8a7796: Add all MSIOF nodes
arm64: renesas: r8a7796/salvator-x: Add board part number to DT bindings
Kuninori Morimoto (2):
arm64: dts: r8a7795: add sound CTU support
arm64: dts: r8a7795: add sound MIX support
Laurent Pinchart (3):
arm64: dts: renesas: r8a7796: Add EthernetAVB instance
arm64: dts: r8a7796: salvator-x: Enable EthernetAVB
arm64: dts: r8a7795: Add PWM support
Simon Horman (5):
arm64: dts: r8a7795: Use renesas,rcar-gen3-usb2-phy fallback binding
arm64: dts: r8a7795: Use Gen 3 fallback compat string for PCIE
arm64: dts: r8a7795: Use R-Car Gen 3 fallback binding for i2c nodes
arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for i2c nodes
arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for msiof nodes
Takeshi Kihara (1):
arm64: dts: r8a7796: salvator-x: Update memory node to 4 GiB map
Documentation/devicetree/bindings/arm/shmobile.txt | 2 +-
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 2 +
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 119 ++++++++++++--
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 37 +++++
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 183 ++++++++++++++++++++-
5 files changed, 323 insertions(+), 20 deletions(-)
^ permalink raw reply
* [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
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