* [PATCH 7/7] ARM: dtsi: sun8i-a33: add CPU thermal throttling
From: Quentin Schulz @ 2016-12-20 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220102709.9504-1-quentin.schulz@free-electrons.com>
This adds CPU thermal throttling for the Allwinner A33. It uses the
thermal sensor present in the SoC's GPADC.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
arch/arm/boot/dts/sun8i-a33.dtsi | 47 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 1fcae81..735ebea 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -43,6 +43,7 @@
*/
#include "sun8i-a23-a33.dtsi"
+#include <dt-bindings/thermal/thermal.h>
/ {
cpu0_opp_table: opp_table0 {
@@ -79,6 +80,9 @@
clocks = <&ccu CLK_CPUX>;
clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ cooling-min-level = <0>;
+ cooling-max-level = <3>;
+ #cooling-cells = <2>;
};
cpu at 2 {
@@ -100,6 +104,49 @@
status = "disabled";
};
+ thermal-zones {
+ cpu_thermal {
+ /* milliseconds */
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&rtp>;
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ map1 {
+ trip = <&cpu_alert1>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ cpu_alert0: cpu_alert0 {
+ /* milliCelsius */
+ temperature = <75000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_alert1: cpu_alert1 {
+ /* milliCelsius */
+ temperature = <90000>;
+ hysteresis = <2000>;
+ type = "hot";
+ };
+
+ cpu_crit: cpu_crit {
+ /* milliCelsius */
+ temperature = <110000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
+
memory {
reg = <0x40000000 0x80000000>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH renesas/devel 0/4] ARM, arm64: dts: Use R-Car fallback bindings for msiof nodes
From: Simon Horman @ 2016-12-20 10:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this short series makes use of newly added R-Car fallback bindings in msiof
nodes of the DTs for SoCs where the drivers in question are already used.
This should have no run-time effect at this time as the current driver
implementations use the same initialisation sequences for SoC-specific and
R-Car fallback bindings for all the cases covered by this patch-set.
Based on renesas-devel-20161212-v4.9
Simon Horman (4):
arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for msiof nodes
ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for msiof nodes
ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for msiof nodes
ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes
arch/arm/boot/dts/r8a7790.dtsi | 12 ++++++++----
arch/arm/boot/dts/r8a7791.dtsi | 9 ++++++---
arch/arm/boot/dts/r8a7792.dtsi | 6 ++++--
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 12 ++++++++----
4 files changed, 26 insertions(+), 13 deletions(-)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH renesas/devel 1/4] arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for msiof nodes
From: Simon Horman @ 2016-12-20 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482229959-25584-1-git-send-email-horms+renesas@verge.net.au>
Use recently added R-Car Gen 3 fallback binding for msiof 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>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 7bf0f2f6c224..936c9c48f0db 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -435,7 +435,8 @@
};
msiof0: spi at e6e90000 {
- compatible = "renesas,msiof-r8a7796";
+ compatible = "renesas,msiof-r8a7796",
+ "renesas,rcar-gen3-msiof";
reg = <0 0xe6e90000 0 0x0064>;
interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 211>;
@@ -449,7 +450,8 @@
};
msiof1: spi at e6ea0000 {
- compatible = "renesas,msiof-r8a7796";
+ compatible = "renesas,msiof-r8a7796",
+ "renesas,rcar-gen3-msiof";
reg = <0 0xe6ea0000 0 0x0064>;
interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 210>;
@@ -463,7 +465,8 @@
};
msiof2: spi at e6c00000 {
- compatible = "renesas,msiof-r8a7796";
+ compatible = "renesas,msiof-r8a7796",
+ "renesas,rcar-gen3-msiof";
reg = <0 0xe6c00000 0 0x0064>;
interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 209>;
@@ -476,7 +479,8 @@
};
msiof3: spi at e6c10000 {
- compatible = "renesas,msiof-r8a7796";
+ compatible = "renesas,msiof-r8a7796",
+ "renesas,rcar-gen3-msiof";
reg = <0 0xe6c10000 0 0x0064>;
interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 208>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH renesas/devel 2/4] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for msiof nodes
From: Simon Horman @ 2016-12-20 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482229959-25584-1-git-send-email-horms+renesas@verge.net.au>
Use recently added R-Car Gen 2 fallback binding for msiof nodes in
DT for r8a7791 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7791 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7791.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 93f446db6a21..ba5748dc5171 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1518,7 +1518,8 @@
};
msiof0: spi at e6e20000 {
- compatible = "renesas,msiof-r8a7791";
+ compatible = "renesas,msiof-r8a7791",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e20000 0 0x0064>;
interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7791_CLK_MSIOF0>;
@@ -1532,7 +1533,8 @@
};
msiof1: spi at e6e10000 {
- compatible = "renesas,msiof-r8a7791";
+ compatible = "renesas,msiof-r8a7791",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e10000 0 0x0064>;
interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7791_CLK_MSIOF1>;
@@ -1546,7 +1548,8 @@
};
msiof2: spi at e6e00000 {
- compatible = "renesas,msiof-r8a7791";
+ compatible = "renesas,msiof-r8a7791",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e00000 0 0x0064>;
interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7791_CLK_MSIOF2>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH renesas/devel 3/4] ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for msiof nodes
From: Simon Horman @ 2016-12-20 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482229959-25584-1-git-send-email-horms+renesas@verge.net.au>
Use recently added R-Car Gen 2 fallback binding for msiof nodes in
DT for r8a7792 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7792 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7792.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index c5e834073cb3..a43eb857ba80 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -585,7 +585,8 @@
};
msiof0: spi at e6e20000 {
- compatible = "renesas,msiof-r8a7792";
+ compatible = "renesas,msiof-r8a7792",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e20000 0 0x0064>;
interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7792_CLK_MSIOF0>;
@@ -599,7 +600,8 @@
};
msiof1: spi at e6e10000 {
- compatible = "renesas,msiof-r8a7792";
+ compatible = "renesas,msiof-r8a7792",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e10000 0 0x0064>;
interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7792_CLK_MSIOF1>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH renesas/devel 4/4] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes
From: Simon Horman @ 2016-12-20 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482229959-25584-1-git-send-email-horms+renesas@verge.net.au>
Use recently added R-Car Gen 2 fallback binding for msiof nodes in
DT for r8a7790 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7790.dtsi | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index b7ed7466308b..63648f1a2e19 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1504,7 +1504,8 @@
};
msiof0: spi at e6e20000 {
- compatible = "renesas,msiof-r8a7790";
+ compatible = "renesas,msiof-r8a7790",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e20000 0 0x0064>;
interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7790_CLK_MSIOF0>;
@@ -1518,7 +1519,8 @@
};
msiof1: spi at e6e10000 {
- compatible = "renesas,msiof-r8a7790";
+ compatible = "renesas,msiof-r8a7790",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e10000 0 0x0064>;
interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7790_CLK_MSIOF1>;
@@ -1532,7 +1534,8 @@
};
msiof2: spi at e6e00000 {
- compatible = "renesas,msiof-r8a7790";
+ compatible = "renesas,msiof-r8a7790",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e00000 0 0x0064>;
interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7790_CLK_MSIOF2>;
@@ -1546,7 +1549,8 @@
};
msiof3: spi at e6c90000 {
- compatible = "renesas,msiof-r8a7790";
+ compatible = "renesas,msiof-r8a7790",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6c90000 0 0x0064>;
interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7790_CLK_MSIOF3>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [linux-sunxi][PATCH 0/3] Enable SPDIF on the Mele I7
From: codekipper at gmail.com @ 2016-12-20 10:40 UTC (permalink / raw)
To: linux-arm-kernel
From: Marcus Cooper <codekipper@gmail.com>
Hi All,
here is the patch set required to enable SPDIF on the Mele I7 which is
a A31 based TV-box. To get this working a fix has to be applied to the
clock driver and this will be pushed seperately.
For now the dtsi changes can be applied and when the clk change is
merged then we can finialise this push by applying the I7 patch.
BR,
CK
Marcus Cooper (3):
ARM: dts: sun6i: Add SPDIF TX pin to the A31
ARM: dts: sun6i: Add the SPDIF block to the A31
ARM: dts: sun6i: Add SPDIF to the Mele I7
arch/arm/boot/dts/sun6i-a31-i7.dts | 24 ++++++++++++++++++++++++
arch/arm/boot/dts/sun6i-a31.dtsi | 19 +++++++++++++++++++
2 files changed, 43 insertions(+)
--
2.11.0
^ permalink raw reply
* [linux-sunxi][PATCH 1/3] ARM: dts: sun6i: Add SPDIF TX pin to the A31
From: codekipper at gmail.com @ 2016-12-20 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220104038.22532-1-codekipper@gmail.com>
From: Marcus Cooper <codekipper@gmail.com>
Add the SPDIF TX pin to the A31 dtsi.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 20a0331ddfb5..7370ba6c9993 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -586,6 +586,11 @@
bias-pull-up;
};
+ spdif_pins_a: spdif at 0 {
+ pins = "PH28";
+ function = "spdif";
+ };
+
uart0_pins_a: uart0 at 0 {
pins = "PH20", "PH21";
function = "uart0";
--
2.11.0
^ permalink raw reply related
* [linux-sunxi][PATCH 2/3] ARM: dts: sun6i: Add the SPDIF block to the A31
From: codekipper at gmail.com @ 2016-12-20 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220104038.22532-1-codekipper@gmail.com>
From: Marcus Cooper <codekipper@gmail.com>
Add the SPDIF transceiver controller block to the A31 dtsi.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 7370ba6c9993..559c53efa7e6 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -613,6 +613,20 @@
reg = <0x01c20ca0 0x20>;
};
+ spdif: spdif at 01c21000 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun6i-a31-spdif";
+ reg = <0x01c21000 0x400>;
+ interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_APB1_SPDIF>, <&ccu CLK_SPDIF>;
+ resets = <&ccu RST_APB1_SPDIF>;
+ clock-names = "apb", "spdif";
+ dmas = <&dma 2>, <&dma 2>;
+ dma-names = "rx", "tx";
+ spdif-out = "disabled";
+ status = "disabled";
+ };
+
lradc: lradc at 01c22800 {
compatible = "allwinner,sun4i-a10-lradc-keys";
reg = <0x01c22800 0x100>;
--
2.11.0
^ permalink raw reply related
* [linux-sunxi][PATCH 3/3] ARM: dts: sun6i: Add SPDIF to the Mele I7
From: codekipper at gmail.com @ 2016-12-20 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220104038.22532-1-codekipper@gmail.com>
From: Marcus Cooper <codekipper@gmail.com>
Enable the S/PDIF transmitter that is present on the Mele I7.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
arch/arm/boot/dts/sun6i-a31-i7.dts | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-i7.dts b/arch/arm/boot/dts/sun6i-a31-i7.dts
index a2193309a199..2bc57d2dcd80 100644
--- a/arch/arm/boot/dts/sun6i-a31-i7.dts
+++ b/arch/arm/boot/dts/sun6i-a31-i7.dts
@@ -69,6 +69,23 @@
gpios = <&pio 7 13 GPIO_ACTIVE_HIGH>;
};
};
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "On-board SPDIF";
+ simple-audio-card,cpu {
+ sound-dai = <&spdif>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&spdif_out>;
+ };
+ };
+
+ spdif_out: spdif-out {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ };
};
&codec {
@@ -138,6 +155,13 @@
status = "okay";
};
+&spdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spdif_pins_a>;
+ spdif-out = "okay";
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.11.0
^ permalink raw reply related
* [PATCH renesas/devel 1/4] arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for msiof nodes
From: Geert Uytterhoeven @ 2016-12-20 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482229959-25584-2-git-send-email-horms+renesas@verge.net.au>
On Tue, Dec 20, 2016 at 11:32 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 3 fallback binding for msiof 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@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 2/4] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for msiof nodes
From: Geert Uytterhoeven @ 2016-12-20 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482229959-25584-3-git-send-email-horms+renesas@verge.net.au>
On Tue, Dec 20, 2016 at 11:32 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for msiof nodes in
> DT for r8a7791 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7791 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 1/4] arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for msiof nodes
From: Geert Uytterhoeven @ 2016-12-20 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXpN9x5YH0tiSRxme0yySS1NpaF41_DaePzuWd+3QD=AQ@mail.gmail.com>
On Tue, Dec 20, 2016 at 11:42 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Dec 20, 2016 at 11:32 AM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
>> Use recently added R-Car Gen 3 fallback binding for msiof 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@linux-m68k.org>
and
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [linux-sunxi][PATCH] clk: sunxi-ng: A31: Fix spdif clock register
From: codekipper at gmail.com @ 2016-12-20 10:44 UTC (permalink / raw)
To: linux-arm-kernel
From: Marcus Cooper <codekipper@gmail.com>
As the SPDIF was rarely documented on the earlier Allwinner SoCs
it was assumed that it had a similar clock register to the one
described in the H3 User Manual.
However this is not the case and it looks to shares the same setup
as the I2S clock registers.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index fc75a335a7ce..4c9a920ff4ab 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -468,8 +468,8 @@ static SUNXI_CCU_MUX_WITH_GATE(daudio0_clk, "daudio0", daudio_parents,
static SUNXI_CCU_MUX_WITH_GATE(daudio1_clk, "daudio1", daudio_parents,
0x0b4, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
-static SUNXI_CCU_M_WITH_GATE(spdif_clk, "spdif", "pll-audio",
- 0x0c0, 0, 4, BIT(31), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_MUX_WITH_GATE(spdif_clk, "spdif", daudio_parents,
+ 0x0c0, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(usb_phy0_clk, "usb-phy0", "osc24M",
0x0cc, BIT(8), 0);
--
2.11.0
^ permalink raw reply related
* [PATCH renesas/devel 3/4] ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for msiof nodes
From: Geert Uytterhoeven @ 2016-12-20 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482229959-25584-4-git-send-email-horms+renesas@verge.net.au>
On Tue, Dec 20, 2016 at 11:32 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for msiof nodes in
> DT for r8a7792 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7792 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 4/4] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes
From: Geert Uytterhoeven @ 2016-12-20 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482229959-25584-5-git-send-email-horms+renesas@verge.net.au>
On Tue, Dec 20, 2016 at 11:32 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for msiof nodes in
> DT for r8a7790 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7790 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 1/5] clk: samsung: exynos5433: Set NoC (Network On Chip) clocks as critical
From: Sylwester Nawrocki @ 2016-12-20 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58521D0F.5040704@samsung.com>
On 12/15/2016 05:33 AM, Chanwoo Choi wrote:
> Could you please review this patch?
Chanwoo, the patch looks good to me, I'm going to queue it after
v4.10-rc1 is released.
--
Thanks,
Sylwester
^ permalink raw reply
* [PATCH v2 renesas/devel 00/13] ARM, arm64: dts: Use R-Car fallback bindings for i2c/iic nodes
From: Simon Horman @ 2016-12-20 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481629559-14187-1-git-send-email-horms+renesas@verge.net.au>
On Tue, Dec 13, 2016 at 12:45:46PM +0100, Simon Horman wrote:
> Hi,
>
> this short series makes use of newly added R-Car fallback bindings in i2c
> and iic nodes of the DTs for SoCs where the drivers in question are already
> used.
>
> This should have no run-time effect at this time as the current driver
> implementations use the same initialisation squeuences for SoC-specific and
> R-Car fallback bindings for all the cases covered by this patch-set.
>
> Based on renesas-devel-20161212-v4.9
I have queued these up for v4.11.
^ permalink raw reply
* [PATCH resend] arm64: dts: r8a7796: salvator-x: Update memory node to 4 GiB map
From: Simon Horman @ 2016-12-20 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481815889-15583-1-git-send-email-geert+renesas@glider.be>
On Thu, Dec 15, 2016 at 04:31:29PM +0100, Geert Uytterhoeven wrote:
> 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>
> ---
> Simon, please apply!
>
> U-Boot already adds the second memory region to the "reg" property of
> the first memory node in DT, so this patch is actually a no-op.
> IMHO it doesn't make much sense to keep on pretending we don't have
> enabled memory outside the 32-bit address space.
Hi Geert,
I agree with the reasoning above and have queued up this patch for v4.11.
It is a shame that u-boot has enabled this for us as it would have
been nice to retain control of that occuring. But alas it was not to be so.
^ permalink raw reply
* [PATCH renesas/devel 0/4] ARM, arm64: dts: Use R-Car fallback bindings for msiof nodes
From: Simon Horman @ 2016-12-20 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482229959-25584-1-git-send-email-horms+renesas@verge.net.au>
On Tue, Dec 20, 2016 at 11:32:35AM +0100, Simon Horman wrote:
> Hi,
>
> this short series makes use of newly added R-Car fallback bindings in msiof
> nodes of the DTs for SoCs where the drivers in question are already used.
>
> This should have no run-time effect at this time as the current driver
> implementations use the same initialisation sequences for SoC-specific and
> R-Car fallback bindings for all the cases covered by this patch-set.
>
> Based on renesas-devel-20161212-v4.9
>
> Simon Horman (4):
> arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for msiof nodes
> ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for msiof nodes
> ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for msiof nodes
> ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes
I have queued these up with Geert's Acks.
^ permalink raw reply
* [PATCH renesas/devel 1/4] arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for msiof nodes
From: Simon Horman @ 2016-12-20 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdV50sQtV_Rk5Kw=dyJ=rzX3_Fq=WThjhaFU+GPbzXNhbg@mail.gmail.com>
On Tue, Dec 20, 2016 at 11:44:14AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 20, 2016 at 11:42 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Tue, Dec 20, 2016 at 11:32 AM, Simon Horman
> > <horms+renesas@verge.net.au> wrote:
> >> Use recently added R-Car Gen 3 fallback binding for msiof 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@linux-m68k.org>
>
> and
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
I have taken the liberty of only adding your second tag.
^ permalink raw reply
* [PATCH v3] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168
From: Geetha sowjanya @ 2016-12-20 11:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
This patch implements Cavium ThunderX erratum 28168.
PCI requires stores complete in order. Due to erratum #28168
PCI-inbound MSI-X store to the interrupt controller are delivered
to the interrupt controller before older PCI-inbound memory stores
are committed.
Doing a sync on SMMU will make sure all prior data transfers are
completed before invoking ISR.
changes from v2:
- added entry in Documentation/arm64/silicon-errata.txt
- moved registration of the preflow_handler into
msi_domain_ops.msi_finish() handler.
- create linux/arm.smmu.h to expose smmu API.
Signed-off-by: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 12 ++++++++
arch/arm64/include/asm/cpucaps.h | 3 +-
arch/arm64/kernel/cpu_errata.c | 16 +++++++++++
drivers/iommu/arm-smmu.c | 22 +++++++++++++++
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 48 +++++++++++++++++++++++++++++++-
include/linux/arm-smmu.h | 8 ++++++
7 files changed, 108 insertions(+), 2 deletions(-)
create mode 100644 include/linux/arm-smmu.h
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 405da11..1311f90 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -61,5 +61,6 @@ stable kernels.
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
| Cavium | ThunderX SMMUv2 | #27704 | N/A |
+| Cavium | ThunderX PCI | #28168 | CAVIUM_ERRATUM_28168 |
| | | | |
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 969ef88..cb647f4 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -474,6 +474,18 @@ config CAVIUM_ERRATUM_27456
If unsure, say Y.
+config CAVIUM_ERRATUM_28168
+ bool "Cavium erratum 28168: Make sure DMA data transfer is done before MSIX"
+ depends on ARM64 && ARM_SMMU
+ default y
+ select IRQ_PREFLOW_FASTEOI
+ help
+ Due to erratum #28168 PCI-inbound MSI-X store to the interrupt
+ controller are delivered to the interrupt controller before older
+ PCI-inbound memory stores are committed. Doing a sync on SMMU
+ will make sure all prior data transfers are done before invoking ISR.
+
+ If unsure, say Y.
endmenu
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 87b4465..6975a01 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -34,7 +34,8 @@
#define ARM64_HAS_32BIT_EL0 13
#define ARM64_HYP_OFFSET_LOW 14
#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
+#define ARM64_WORKAROUND_CAVIUM_28168 16
-#define ARM64_NCAPS 16
+#define ARM64_NCAPS 17
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index b75e917..fac6d74 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -123,6 +123,22 @@ static int cpu_enable_trap_ctr_access(void *__unused)
MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x00),
},
#endif
+#ifdef CONFIG_CAVIUM_ERRATUM_28168
+ {
+ /* Cavium ThunderX, T88 pass 1.x - 2.1 */
+ .desc = "Cavium erratum 28168",
+ .capability = ARM64_WORKAROUND_CAVIUM_28168,
+ MIDR_RANGE(MIDR_THUNDERX, 0x00,
+ (1 << MIDR_VARIANT_SHIFT) | 1),
+ },
+ {
+ /* Cavium ThunderX, T81 pass 1.0 */
+ .desc = "Cavium erratum 28168",
+ .capability = ARM64_WORKAROUND_CAVIUM_28168,
+ MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x00),
+ },
+#endif
+
{
.desc = "Mismatched cache line size",
.capability = ARM64_MISMATCHED_CACHE_LINE_SIZE,
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 06167da..451b393 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -49,6 +49,8 @@
#include <linux/spinlock.h>
#include <linux/amba/bus.h>
+#include <linux/arm-smmu.h>
+
#include "io-pgtable.h"
@@ -577,6 +579,26 @@ static void __arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
}
}
+#ifdef CONFIG_CAVIUM_ERRATUM_28168
+/*
+ * Cavium ThunderX erratum 28168
+ *
+ * Due to erratum #28168 PCI-inbound MSI-X store to the interrupt
+ * controller are delivered to the interrupt controller before older
+ * PCI-inbound memory stores are committed. Doing a sync on SMMU
+ * will make sure all prior data transfers are completed before
+ * invoking ISR.
+ *
+ */
+void dev_smmu_tlb_sync(struct device *dev)
+{
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+ struct arm_smmu_device *smmu = fwspec_smmu(fwspec);
+
+ if (smmu)
+ __arm_smmu_tlb_sync(smmu);
+}
+#endif
static void arm_smmu_tlb_sync(void *cookie)
{
struct arm_smmu_domain *smmu_domain = cookie;
diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index aee1c60..36ce696 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -20,6 +20,7 @@
#include <linux/of.h>
#include <linux/of_irq.h>
#include <linux/of_pci.h>
+#include <linux/arm-smmu.h>
static void its_mask_msi_irq(struct irq_data *d)
{
@@ -86,11 +87,53 @@ static int its_pci_msi_prepare(struct irq_domain *domain, struct device *dev,
/* ITS specific DeviceID, as the core ITS ignores dev. */
info->scratchpad[0].ul = pci_msi_domain_get_msi_rid(domain, pdev);
-
+ info->scratchpad[1].ptr = &pdev->dev;
return msi_info->ops->msi_prepare(domain->parent,
dev, dev_alias.count, info);
}
+#ifdef CONFIG_CAVIUM_ERRATUM_28168
+#define THUNDER_PME_DEVICE_ID 0xA100
+
+static void cavium_irq_preflow_handler(struct irq_data *data)
+{
+ struct pci_dev *pdev;
+
+ pdev = msi_desc_to_pci_dev(irq_data_get_msi_desc(data));
+ dev_smmu_tlb_sync(&pdev->dev);
+}
+static void cavium_its_pci_msi_finish(msi_alloc_info_t *info, int ret)
+{
+ struct device *dev = info->scratchpad[1].ptr;
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct device *parent_dev;
+ struct msi_desc *desc;
+
+ if (ret)
+ return;
+
+ if (pci_pcie_type(pdev) != PCI_EXP_TYPE_ROOT_PORT) {
+ for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
+ pdev = to_pci_dev(parent_dev);
+ if (pci_pcie_type(pdev) != PCI_EXP_TYPE_ROOT_PORT)
+ continue;
+
+ if (pdev->device == THUNDER_PME_DEVICE_ID)
+ for_each_pci_msi_entry(desc, to_pci_dev(dev))
+ __irq_set_preflow_handler(desc->irq, cavium_irq_preflow_handler);
+ break;
+ }
+ }
+}
+#else
+static void cavium_irq_preflow_handler(struct irq_data *data)
+{
+}
+static void cavium_its_pci_msi_finish(msi_alloc_info_t *info, int ret)
+{
+}
+#endif
+
static struct msi_domain_ops its_pci_msi_ops = {
.msi_prepare = its_pci_msi_prepare,
};
@@ -118,6 +161,9 @@ static int __init its_pci_msi_init_one(struct fwnode_handle *handle,
return -ENXIO;
}
+ if (cpus_have_cap(ARM64_WORKAROUND_CAVIUM_28168))
+ its_pci_msi_ops.msi_finish = cavium_its_pci_msi_finish;
+
if (!pci_msi_create_irq_domain(handle, &its_pci_msi_domain_info,
parent)) {
pr_err("%s: Unable to create PCI domain\n", name);
diff --git a/include/linux/arm-smmu.h b/include/linux/arm-smmu.h
new file mode 100644
index 0000000..d3f5dff
--- /dev/null
+++ b/include/linux/arm-smmu.h
@@ -0,0 +1,8 @@
+#ifndef _ARM_SMMU_H
+#define _ARM_SMMU_H
+
+#include<linux/pci.h>
+
+extern void dev_smmu_tlb_sync(struct device *dev);
+
+#endif /* _ARM_SMMU_H */
--
1.9.1
^ permalink raw reply related
* [linux-sunxi] Problems to Allwinner H3's eFUSE/SID
From: Bernhard Nortmann @ 2016-12-20 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <136061482160932@web34j.yandex.ru>
Hi all!
This is rather interesting stuff. Actually it's possible to find partial
documentation for this method (of reading SID/efuse values) even for older
SoCs. There's an early version of the A20 User Manual (Revision 1.0 -
Feb. 18, 2013) available on the net, where chapter 1.18 describes the
registers involved. This section seems to have been removed in later
editions. (Search for the file A20_UM-V1.020130322.pdf)
The U-Boot code that Allwinner published also has source files for various
SoCs that contain corresponding implementations of `sid_program_key()` and
`sid_read_key()` (in efuse.c),
see https://github.com/allwinner-zh/bootloader/search?q=sid_read_key.
Regards, B. Nortmann
Am 19.12.2016 um 16:22 schrieb Icenowy Zheng:
> Hi everyone,
>
> Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
> controller of H3 (incl. H2+).
>
> See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>
> Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
> directly access 0x01c14200.
>
> From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
> the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
> legacy kernel).
>
> According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
> byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
> 0x58 is H3D (currently not known SoC) )
>
> However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
> with 0x02004620, which do not match this rule.
>
> The readout by devmem2 is satisfying this rule: their first word is
> 0x02c00081, matches H3.
>
> Then I found the SID-reading code from BSP U-Boot[2], which is based on
> register operations. With this kind of code (I wrote one prototype in
> userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
> my Orange Pi One. ("02004620 74358720 5027048e 3c0000c3" with sunxi-fel sid)
> And, after accessing to the SID by registers, the value of *0x01c14200 become
> also "02c00081".
>
> With direct access to 0x01c14200 after boot with mainline kernel, I got also
> "02004620".
>
> Then I altered the program to do the register operations with sunxi-fel, the
> result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>
> Summary:
>
> +-----------------------------------------------+----------------+
> | Read situation | The first word |
> +-----------------------------------------------+----------------+
> | Direct read by sunxi-fel | 02004620 |
> | Direct read in mainline /dev/mem | 02004620 |
> | Direct read in legacy /dev/mem | 02c00081 |
> | Register access in FEL | 02c00081 |
> | Register access in mainline | 02c00081 |
> | Direct read after register access in FEL | 02c00081 |
> | Direct read after register access in mainline | 02c00081 |
> +-----------------------------------------------+----------------+
>
> According to some facts:
> - The register based access to SID is weird: it needs ~5 register
> operations per word of SID.
> - Reading via register access will change the value when reading by accessing
> 0x01c14200.
> - In the u-boot code[2] there's some functions which read out the SID by
> registers and then abandoned the value.
> - This mismatch do not exist on A64.
>
> I think that: Allwinner designed a "cache" to the SID to make the simplify the
> code to read it, and it automatically loaded the cache when booting; however,
> when doing first cache on H3, some byte shifts occured, and the value become
> wrong. A manual read on H3 can make the cache right again. This is a silicon
> bug, and fixed in A64.
>
> This raises a problem: currently many systems has used the misread SID value to
> generated lots of MAC addresses, and workaround this SID bug will change them.
>
> However, if this bug is not workarounded, the sun8i-ths driver won't work well
> (as some calibartion value lies in eFUSE). I think some early user of this
> driver has already experienced bad readout value.
> (The calibration value differs on my opi1 and KotCzarny's opipc)
>
> And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
> think sunxi-fel must have the workaround)
>
> Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
> at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>
> Furthermore, A83T may also have this problem, testers are welcome!
>
> [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
> [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>
> Experiments:
> - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
> A SID readout shell script via FEL with register access.
> - https://31.135.195.151:20281/d/efuse/
> A SID readout program via /dev/mem with register access by KotCzarny.
> (with statically compiled binary)
>
> Regards,
> Icenowy
>
^ permalink raw reply
* [PATCH v3] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168
From: Marc Zyngier @ 2016-12-20 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482231993-27571-1-git-send-email-gakula@caviumnetworks.com>
Geetha,
On 20/12/16 11:06, Geetha sowjanya wrote:
> From: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
>
> This patch implements Cavium ThunderX erratum 28168.
>
> PCI requires stores complete in order. Due to erratum #28168
> PCI-inbound MSI-X store to the interrupt controller are delivered
> to the interrupt controller before older PCI-inbound memory stores
> are committed.
> Doing a sync on SMMU will make sure all prior data transfers are
> completed before invoking ISR.
>
> changes from v2:
> - added entry in Documentation/arm64/silicon-errata.txt
> - moved registration of the preflow_handler into
> msi_domain_ops.msi_finish() handler.
> - create linux/arm.smmu.h to expose smmu API.
>
> Signed-off-by: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
Where is your SoB? This is a requirement if you're picking a patch from
someone else.
> ---
> Documentation/arm64/silicon-errata.txt | 1 +
> arch/arm64/Kconfig | 12 ++++++++
> arch/arm64/include/asm/cpucaps.h | 3 +-
> arch/arm64/kernel/cpu_errata.c | 16 +++++++++++
> drivers/iommu/arm-smmu.c | 22 +++++++++++++++
> drivers/irqchip/irq-gic-v3-its-pci-msi.c | 48 +++++++++++++++++++++++++++++++-
> include/linux/arm-smmu.h | 8 ++++++
> 7 files changed, 108 insertions(+), 2 deletions(-)
> create mode 100644 include/linux/arm-smmu.h
>
> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
> index 405da11..1311f90 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -61,5 +61,6 @@ stable kernels.
> | Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
> +| Cavium | ThunderX PCI | #28168 | CAVIUM_ERRATUM_28168 |
> | | | | |
> | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 969ef88..cb647f4 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -474,6 +474,18 @@ config CAVIUM_ERRATUM_27456
>
> If unsure, say Y.
>
> +config CAVIUM_ERRATUM_28168
> + bool "Cavium erratum 28168: Make sure DMA data transfer is done before MSIX"
> + depends on ARM64 && ARM_SMMU
> + default y
> + select IRQ_PREFLOW_FASTEOI
> + help
> + Due to erratum #28168 PCI-inbound MSI-X store to the interrupt
> + controller are delivered to the interrupt controller before older
> + PCI-inbound memory stores are committed. Doing a sync on SMMU
> + will make sure all prior data transfers are done before invoking ISR.
> +
> + If unsure, say Y.
> endmenu
>
>
> diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> index 87b4465..6975a01 100644
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@ -34,7 +34,8 @@
> #define ARM64_HAS_32BIT_EL0 13
> #define ARM64_HYP_OFFSET_LOW 14
> #define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
> +#define ARM64_WORKAROUND_CAVIUM_28168 16
>
> -#define ARM64_NCAPS 16
> +#define ARM64_NCAPS 17
>
> #endif /* __ASM_CPUCAPS_H */
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index b75e917..fac6d74 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -123,6 +123,22 @@ static int cpu_enable_trap_ctr_access(void *__unused)
> MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x00),
> },
> #endif
> +#ifdef CONFIG_CAVIUM_ERRATUM_28168
> + {
> + /* Cavium ThunderX, T88 pass 1.x - 2.1 */
> + .desc = "Cavium erratum 28168",
> + .capability = ARM64_WORKAROUND_CAVIUM_28168,
> + MIDR_RANGE(MIDR_THUNDERX, 0x00,
> + (1 << MIDR_VARIANT_SHIFT) | 1),
> + },
> + {
> + /* Cavium ThunderX, T81 pass 1.0 */
> + .desc = "Cavium erratum 28168",
> + .capability = ARM64_WORKAROUND_CAVIUM_28168,
> + MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x00),
> + },
> +#endif
> +
> {
> .desc = "Mismatched cache line size",
> .capability = ARM64_MISMATCHED_CACHE_LINE_SIZE,
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 06167da..451b393 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -49,6 +49,8 @@
> #include <linux/spinlock.h>
>
> #include <linux/amba/bus.h>
> +#include <linux/arm-smmu.h>
> +
>
> #include "io-pgtable.h"
>
> @@ -577,6 +579,26 @@ static void __arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
> }
> }
>
> +#ifdef CONFIG_CAVIUM_ERRATUM_28168
> +/*
> + * Cavium ThunderX erratum 28168
> + *
> + * Due to erratum #28168 PCI-inbound MSI-X store to the interrupt
> + * controller are delivered to the interrupt controller before older
> + * PCI-inbound memory stores are committed. Doing a sync on SMMU
> + * will make sure all prior data transfers are completed before
> + * invoking ISR.
> + *
> + */
> +void dev_smmu_tlb_sync(struct device *dev)
> +{
> + struct iommu_fwspec *fwspec = dev->iommu_fwspec;
> + struct arm_smmu_device *smmu = fwspec_smmu(fwspec);
> +
> + if (smmu)
> + __arm_smmu_tlb_sync(smmu);
> +}
> +#endif
I'll let Robin and Will comment on this, but it strikes be as rather odd
that nothing will happen if the SMMU is in bypass or simply compiled
out. So this workaround is at best incomplete.
> static void arm_smmu_tlb_sync(void *cookie)
> {
> struct arm_smmu_domain *smmu_domain = cookie;
> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> index aee1c60..36ce696 100644
> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> @@ -20,6 +20,7 @@
> #include <linux/of.h>
> #include <linux/of_irq.h>
> #include <linux/of_pci.h>
> +#include <linux/arm-smmu.h>
>
> static void its_mask_msi_irq(struct irq_data *d)
> {
> @@ -86,11 +87,53 @@ static int its_pci_msi_prepare(struct irq_domain *domain, struct device *dev,
>
> /* ITS specific DeviceID, as the core ITS ignores dev. */
> info->scratchpad[0].ul = pci_msi_domain_get_msi_rid(domain, pdev);
> -
> + info->scratchpad[1].ptr = &pdev->dev;
> return msi_info->ops->msi_prepare(domain->parent,
> dev, dev_alias.count, info);
> }
>
> +#ifdef CONFIG_CAVIUM_ERRATUM_28168
> +#define THUNDER_PME_DEVICE_ID 0xA100
> +
> +static void cavium_irq_preflow_handler(struct irq_data *data)
> +{
> + struct pci_dev *pdev;
> +
> + pdev = msi_desc_to_pci_dev(irq_data_get_msi_desc(data));
> + dev_smmu_tlb_sync(&pdev->dev);
> +}
Missing space between the two functions.
> +static void cavium_its_pci_msi_finish(msi_alloc_info_t *info, int ret)
> +{
> + struct device *dev = info->scratchpad[1].ptr;
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct device *parent_dev;
> + struct msi_desc *desc;
> +
> + if (ret)
> + return;
> +
> + if (pci_pcie_type(pdev) != PCI_EXP_TYPE_ROOT_PORT) {
> + for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
> + pdev = to_pci_dev(parent_dev);
> + if (pci_pcie_type(pdev) != PCI_EXP_TYPE_ROOT_PORT)
> + continue;
> +
> + if (pdev->device == THUNDER_PME_DEVICE_ID)
> + for_each_pci_msi_entry(desc, to_pci_dev(dev))
> + __irq_set_preflow_handler(desc->irq, cavium_irq_preflow_handler);
So only the PME device is affected? Why can't you simply use INTx for it
(there is already some provision for that in the PME driver
("pcie_pme=nomsi").
If your PME device doesn't implement legacy interrupt, can't you do
something in the PME interrupt handler instead? Like reading from the
end-point or something similar?
> + break;
> + }
> + }
> +}
> +#else
> +static void cavium_irq_preflow_handler(struct irq_data *data)
> +{
> +}
Why is this defined? It is just going to generate a warning if
CONFIG_CAVIUM_ERRATUM_28168 is not defined...
> +static void cavium_its_pci_msi_finish(msi_alloc_info_t *info, int ret)
> +{
> +}
You might as well have
#define cavium_its_pci_msi_finish NULL
> +#endif
> +
> static struct msi_domain_ops its_pci_msi_ops = {
> .msi_prepare = its_pci_msi_prepare,
> };
> @@ -118,6 +161,9 @@ static int __init its_pci_msi_init_one(struct fwnode_handle *handle,
> return -ENXIO;
> }
>
> + if (cpus_have_cap(ARM64_WORKAROUND_CAVIUM_28168))
> + its_pci_msi_ops.msi_finish = cavium_its_pci_msi_finish;
> +
> if (!pci_msi_create_irq_domain(handle, &its_pci_msi_domain_info,
> parent)) {
> pr_err("%s: Unable to create PCI domain\n", name);
> diff --git a/include/linux/arm-smmu.h b/include/linux/arm-smmu.h
> new file mode 100644
> index 0000000..d3f5dff
> --- /dev/null
> +++ b/include/linux/arm-smmu.h
> @@ -0,0 +1,8 @@
> +#ifndef _ARM_SMMU_H
> +#define _ARM_SMMU_H
> +
> +#include<linux/pci.h>
> +
> +extern void dev_smmu_tlb_sync(struct device *dev);
> +
> +#endif /* _ARM_SMMU_H */
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168
From: Will Deacon @ 2016-12-20 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd950765-8c1f-14d5-2be8-efa76f2d6b6b@arm.com>
On Tue, Dec 20, 2016 at 11:52:58AM +0000, Marc Zyngier wrote:
> On 20/12/16 11:06, Geetha sowjanya wrote:
> > From: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
> > +#ifdef CONFIG_CAVIUM_ERRATUM_28168
> > +/*
> > + * Cavium ThunderX erratum 28168
> > + *
> > + * Due to erratum #28168 PCI-inbound MSI-X store to the interrupt
> > + * controller are delivered to the interrupt controller before older
> > + * PCI-inbound memory stores are committed. Doing a sync on SMMU
> > + * will make sure all prior data transfers are completed before
> > + * invoking ISR.
> > + *
> > + */
> > +void dev_smmu_tlb_sync(struct device *dev)
> > +{
> > + struct iommu_fwspec *fwspec = dev->iommu_fwspec;
> > + struct arm_smmu_device *smmu = fwspec_smmu(fwspec);
> > +
> > + if (smmu)
> > + __arm_smmu_tlb_sync(smmu);
> > +}
> > +#endif
>
> I'll let Robin and Will comment on this, but it strikes be as rather odd
> that nothing will happen if the SMMU is in bypass or simply compiled
> out. So this workaround is at best incomplete.
Agreed. Unless the SMMU is the cause of the issue, relying on it to
implement the workaround is fragile and unnecessarily introduces a linkage
between SMMU driver internals and the interrupt handling code.
Not a fan.
Will
^ 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