* [PATCH v2 0/6] Add some DT nodes for Mediatek MT2701
From: Erin Lo @ 2017-01-13 8:42 UTC (permalink / raw)
To: linux-arm-kernel
This patch series based on v4.10-rc2, include MT2701 spi/iommu/nand/auxadc/ethernet/thermal controller DT nodes.
Dependent on "Add clock and power domain DT nodes for Mediatek MT2701"[1].
Change in v2:
1. Add spi/auxadc pin setting
2. Add ethernet node and pin setting
3. Add thermal controller node
[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-December/007637.html
Dawei Chien (1):
arm: dts: mt2701: Add thermal device node.
Honghui Zhang (1):
arm: dts: mt2701: Add iommu/smi device node
Leilk Liu (1):
arm: dts: mt2701: Add spi device node
Sean Wang (1):
arm: dts: mt2701: Add ethernet device node.
Xiaolei Li (1):
arm: dts: mt2701: Add nand device node
Zhiyong Tao (1):
arm: dts: mt2701: Add auxadc device node.
arch/arm/boot/dts/mt2701-evb.dts | 94 +++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 189 +++++++++++++++++++++++++++++++++++++++
2 files changed, 283 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH v2 1/6] arm: dts: mt2701: Add spi device node
From: Erin Lo @ 2017-01-13 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484296978-18572-1-git-send-email-erin.lo@mediatek.com>
From: Leilk Liu <leilk.liu@mediatek.com>
Add spi device node for MT2701.
Signed-off-by: Leilk Liu <leilk.liu@mediatek.com>
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
arch/arm/boot/dts/mt2701-evb.dts | 50 ++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 39 +++++++++++++++++++++++++++++++
2 files changed, 89 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index 082ca88..879f1eb 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -24,6 +24,56 @@
};
};
+&pio {
+ spi_pins_a: spi0 at 0 {
+ pins_spi {
+ pinmux = <MT2701_PIN_53_SPI0_CSN__FUNC_SPI0_CS>,
+ <MT2701_PIN_54_SPI0_CK__FUNC_SPI0_CK>,
+ <MT2701_PIN_55_SPI0_MI__FUNC_SPI0_MI>,
+ <MT2701_PIN_56_SPI0_MO__FUNC_SPI0_MO>;
+ bias-disable;
+ };
+ };
+
+ spi_pins_b: spi1 at 0 {
+ pins_spi {
+ pinmux = <MT2701_PIN_7_SPI1_CSN__FUNC_SPI1_CS>,
+ <MT2701_PIN_8_SPI1_MI__FUNC_SPI1_MI>,
+ <MT2701_PIN_9_SPI1_MO__FUNC_SPI1_MO>,
+ <MT2701_PIN_199_SPI1_CLK__FUNC_SPI1_CK>;
+ bias-disable;
+ };
+ };
+
+ spi_pins_c: spi2 at 0 {
+ pins_spi {
+ pinmux = <MT2701_PIN_101_SPI2_CSN__FUNC_SPI2_CS>,
+ <MT2701_PIN_102_SPI2_MI__FUNC_SPI2_MI>,
+ <MT2701_PIN_103_SPI2_MO__FUNC_SPI2_MO>,
+ <MT2701_PIN_104_SPI2_CLK__FUNC_SPI2_CK>;
+ bias-disable;
+ };
+ };
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_a>;
+ status = "disabled";
+};
+
+&spi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_b>;
+ status = "disabled";
+};
+
+&spi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_pins_c>;
+ status = "disabled";
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index bdf8954..eb4c6fd 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -227,6 +227,45 @@
status = "disabled";
};
+ spi0: spi at 1100a000 {
+ compatible = "mediatek,mt2701-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x1100a000 0 0x100>;
+ interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
+ <&topckgen CLK_TOP_SPI0_SEL>,
+ <&pericfg CLK_PERI_SPI0>;
+ clock-names = "parent-clk", "sel-clk", "spi-clk";
+ status = "disabled";
+ };
+
+ spi1: spi at 11016000 {
+ compatible = "mediatek,mt2701-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x11016000 0 0x100>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
+ <&topckgen CLK_TOP_SPI1_SEL>,
+ <&pericfg CLK_PERI_SPI1>;
+ clock-names = "parent-clk", "sel-clk", "spi-clk";
+ status = "disabled";
+ };
+
+ spi2: spi at 11017000 {
+ compatible = "mediatek,mt2701-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x11017000 0 0x1000>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
+ <&topckgen CLK_TOP_SPI2_SEL>,
+ <&pericfg CLK_PERI_SPI2>;
+ clock-names = "parent-clk", "sel-clk", "spi-clk";
+ status = "disabled";
+ };
+
mmsys: syscon at 14000000 {
compatible = "mediatek,mt2701-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/6] arm: dts: mt2701: Add iommu/smi device node
From: Erin Lo @ 2017-01-13 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484296978-18572-1-git-send-email-erin.lo@mediatek.com>
From: Honghui Zhang <honghui.zhang@mediatek.com>
Add the device node of iommu and smi for MT2701.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
arch/arm/boot/dts/mt2701.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index eb4c6fd..87be52c 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -17,6 +17,7 @@
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/mt2701-resets.h>
+#include <dt-bindings/memory/mt2701-larb-port.h>
#include "skeleton64.dtsi"
#include "mt2701-pinfunc.h"
@@ -161,6 +162,16 @@
clock-names = "system-clk", "rtc-clk";
};
+ smi_common: smi at 1000c000 {
+ compatible = "mediatek,mt2701-smi-common";
+ reg = <0 0x1000c000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_SMI>,
+ <&mmsys CLK_MM_SMI_COMMON>,
+ <&infracfg CLK_INFRA_SMI>;
+ clock-names = "apb", "smi", "async";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+ };
+
sysirq: interrupt-controller at 10200100 {
compatible = "mediatek,mt2701-sysirq",
"mediatek,mt6577-sysirq";
@@ -170,6 +181,16 @@
reg = <0 0x10200100 0 0x1c>;
};
+ iommu: mmsys_iommu at 10205000 {
+ compatible = "mediatek,mt2701-m4u";
+ reg = <0 0x10205000 0 0x1000>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_M4U>;
+ clock-names = "bclk";
+ mediatek,larbs = <&larb0 &larb1 &larb2>;
+ #iommu-cells = <1>;
+ };
+
apmixedsys: syscon at 10209000 {
compatible = "mediatek,mt2701-apmixedsys", "syscon";
reg = <0 0x10209000 0 0x1000>;
@@ -272,18 +293,51 @@
#clock-cells = <1>;
};
+ larb0: larb at 14010000 {
+ compatible = "mediatek,mt2701-smi-larb";
+ reg = <0 0x14010000 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ mediatek,larbidx = <0>;
+ clocks = <&mmsys CLK_MM_SMI_LARB0>,
+ <&mmsys CLK_MM_SMI_LARB0>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+ };
+
imgsys: syscon at 15000000 {
compatible = "mediatek,mt2701-imgsys", "syscon";
reg = <0 0x15000000 0 0x1000>;
#clock-cells = <1>;
};
+ larb2: larb at 15001000 {
+ compatible = "mediatek,mt2701-smi-larb";
+ reg = <0 0x15001000 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ mediatek,larbidx = <2>;
+ clocks = <&imgsys CLK_IMG_SMI_COMM>,
+ <&imgsys CLK_IMG_SMI_COMM>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
+ };
+
vdecsys: syscon at 16000000 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x16000000 0 0x1000>;
#clock-cells = <1>;
};
+ larb1: larb at 16010000 {
+ compatible = "mediatek,mt2701-smi-larb";
+ reg = <0 0x16010000 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ mediatek,larbidx = <1>;
+ clocks = <&vdecsys CLK_VDEC_CKGEN>,
+ <&vdecsys CLK_VDEC_LARB>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_VDEC>;
+ };
+
hifsys: syscon at 1a000000 {
compatible = "mediatek,mt2701-hifsys", "syscon";
reg = <0 0x1a000000 0 0x1000>;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/6] arm: dts: mt2701: Add nand device node
From: Erin Lo @ 2017-01-13 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484296978-18572-1-git-send-email-erin.lo@mediatek.com>
From: Xiaolei Li <xiaolei.li@mediatek.com>
Add mt2701 nand device node, include nfi and bch ecc.
Signed-off-by: Xiaolei Li <xiaolei.li@mediatek.com>
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
arch/arm/boot/dts/mt2701.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 87be52c..1182c43 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -261,6 +261,28 @@
status = "disabled";
};
+ nandc: nfi at 1100d000 {
+ compatible = "mediatek,mt2701-nfc";
+ reg = <0 0x1100d000 0 0x1000>;
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_NFI>,
+ <&pericfg CLK_PERI_NFI_PAD>;
+ clock-names = "nfi_clk", "pad_clk";
+ status = "disabled";
+ ecc-engine = <&bch>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ bch: ecc at 1100e000 {
+ compatible = "mediatek,mt2701-ecc";
+ reg = <0 0x1100e000 0 0x1000>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_NFI_ECC>;
+ clock-names = "nfiecc_clk";
+ status = "disabled";
+ };
+
spi1: spi at 11016000 {
compatible = "mediatek,mt2701-spi";
#address-cells = <1>;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 4/6] arm: dts: mt2701: Add auxadc device node.
From: Erin Lo @ 2017-01-13 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484296978-18572-1-git-send-email-erin.lo@mediatek.com>
From: Zhiyong Tao <zhiyong.tao@mediatek.com>
Add auxadc device node for MT2701.
Signed-off-by: Zhiyong Tao <zhiyong.tao@mediatek.com>
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
arch/arm/boot/dts/mt2701-evb.dts | 4 ++++
arch/arm/boot/dts/mt2701.dtsi | 9 +++++++++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index 879f1eb..a483798 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -24,6 +24,10 @@
};
};
+&auxadc {
+ status = "okay";
+};
+
&pio {
spi_pins_a: spi0 at 0 {
pins_spi {
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 1182c43..4f52019 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -208,6 +208,15 @@
<0 0x10216000 0 0x2000>;
};
+ auxadc: adc at 11001000 {
+ compatible = "mediatek,mt2701-auxadc";
+ reg = <0 0x11001000 0 0x1000>;
+ clocks = <&pericfg CLK_PERI_AUXADC>;
+ clock-names = "main";
+ #io-channel-cells = <1>;
+ status = "disabled";
+ };
+
uart0: serial at 11002000 {
compatible = "mediatek,mt2701-uart",
"mediatek,mt6577-uart";
--
1.9.1
^ permalink raw reply related
* [PATCH v2 5/6] arm: dts: mt2701: Add ethernet device node.
From: Erin Lo @ 2017-01-13 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484296978-18572-1-git-send-email-erin.lo@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Add ethernet device node for MT2701.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
arch/arm/boot/dts/mt2701-evb.dts | 40 ++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 22 ++++++++++++++++++++++
2 files changed, 62 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index a483798..40abd3b 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -28,7 +28,47 @@
status = "okay";
};
+ð {
+ mac-address = [00 00 00 00 00 00];
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac1_pins>;
+ gmac1: mac at 1 {
+ compatible = "mediatek,eth-mac";
+ reg = <1>;
+ phy-handle = <&phy5>;
+ };
+
+ mdio-bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy5: ethernet-phy at 5 {
+ reg = <5>;
+ phy-mode = "rgmii-rxid";
+ };
+ };
+};
+
&pio {
+ gmac1_pins: eth at 0 {
+ pins_eth {
+ pinmux = <MT2701_PIN_275_MDC__FUNC_MDC>,
+ <MT2701_PIN_276_MDIO__FUNC_MDIO>,
+ <MT2701_PIN_262_G2_TXEN__FUNC_G2_TXEN>,
+ <MT2701_PIN_263_G2_TXD3__FUNC_G2_TXD3>,
+ <MT2701_PIN_264_G2_TXD2__FUNC_G2_TXD2>,
+ <MT2701_PIN_265_G2_TXD1__FUNC_G2_TXD1>,
+ <MT2701_PIN_266_G2_TXD0__FUNC_G2_TXD0>,
+ <MT2701_PIN_267_G2_TXC__FUNC_G2_TXC>,
+ <MT2701_PIN_268_G2_RXC__FUNC_G2_RXC>,
+ <MT2701_PIN_269_G2_RXD0__FUNC_G2_RXD0>,
+ <MT2701_PIN_270_G2_RXD1__FUNC_G2_RXD1>,
+ <MT2701_PIN_271_G2_RXD2__FUNC_G2_RXD2>,
+ <MT2701_PIN_272_G2_RXD3__FUNC_G2_RXD3>,
+ <MT2701_PIN_274_G2_RXDV__FUNC_G2_RXDV>;
+ };
+ };
+
spi_pins_a: spi0 at 0 {
pins_spi {
pinmux = <MT2701_PIN_53_SPI0_CSN__FUNC_SPI0_CS>,
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 4f52019..3847f70 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -381,6 +381,28 @@
#clock-cells = <1>;
};
+ eth: ethernet at 1b100000 {
+ compatible = "mediatek,mt7623-eth";
+ reg = <0 0x1b100000 0 0x20000>;
+ interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 199 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
+ <&apmixedsys CLK_APMIXED_TRGPLL>,
+ <ðsys CLK_ETHSYS_ESW>,
+ <ðsys CLK_ETHSYS_GP2>,
+ <ðsys CLK_ETHSYS_GP1>;
+ clock-names = "ethif", "trgpll", "esw", "gp2", "gp1";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
+ resets = <&watchdog MT2701_TOPRGU_ETHDMA_RST>;
+ reset-names = "eth";
+ mediatek,ethsys = <ðsys>;
+ mediatek,pctl = <&syscfg_pctl_a>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
bdpsys: syscon at 1c000000 {
compatible = "mediatek,mt2701-bdpsys", "syscon";
reg = <0 0x1c000000 0 0x1000>;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 6/6] arm: dts: mt2701: Add thermal device node.
From: Erin Lo @ 2017-01-13 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484296978-18572-1-git-send-email-erin.lo@mediatek.com>
From: Dawei Chien <dawei.chien@mediatek.com>
Add thermal controller device nodes for MT2701.
Signed-off-by: Dawei Chien <dawei.chien@mediatek.com>
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
arch/arm/boot/dts/mt2701.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 3847f70..c43d5f8 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -89,6 +89,36 @@
clock-output-names = "rtc32k";
};
+ thermal-zones {
+ cpu_thermal: cpu_thermal {
+ polling-delay-passive = <1000>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+
+ thermal-sensors = <&thermal 0>;
+ sustainable-power = <1000>;
+
+ trips {
+ threshold: trip-point at 0 {
+ temperature = <68000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ target: trip-point at 1 {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_crit: cpu_crit at 0 {
+ temperature = <115000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <&gic>;
@@ -270,6 +300,19 @@
status = "disabled";
};
+ thermal: thermal at 1100b000 {
+ #thermal-sensor-cells = <0>;
+ compatible = "mediatek,mt2701-thermal";
+ reg = <0 0x1100b000 0 0x1000>;
+ interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
+ clock-names = "therm", "auxadc";
+ resets = <&pericfg 0x10>;
+ reset-names = "therm";
+ mediatek,auxadc = <&auxadc>;
+ mediatek,apmixedsys = <&apmixedsys>;
+ };
+
nandc: nfi at 1100d000 {
compatible = "mediatek,mt2701-nfc";
reg = <0 0x1100d000 0 0x1000>;
--
1.9.1
^ permalink raw reply related
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-13 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113082903.GA1446@katana>
On Fri, Jan 13, 2017 at 09:29:03AM +0100, Wolfram Sang wrote:
>
> > (But note that this is irrelevant for the patch as the driver doesn't
> > claim to support this kind of transfer.)
>
> Yes, I wanted to mention that, too.
>
> I'd think the series is good to go in?
AFAICT there are some unaddressed comments that Cedrics claimed to fix
before our discussion was dominated by block transfers.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCHv5 3/8] rtc: add STM32 RTC driver
From: Amelie DELAUNAY @ 2017-01-13 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113003840.u6uxt7u4qsit3oqt@piout.net>
Hi Alexandre,
> This didn't apply cleanly, please check rtc-next. I don't think I made any mistake
> as the issue was only in Kconfig. You probably based your patches on 4.9
> instead of 4.10-rc1.
Sorry for this inconvenience. You're right, my patches were based on 4.9 to be tested on stm32f4 family.
No mistake found in your conflict resolution in Kconfig.
I'm going to send a new patch to fix warnings introduced by my driver on rtc-next.
Regards,
Amelie
> -----Original Message-----
> From: Alexandre Belloni [mailto:alexandre.belloni at free-electrons.com]
> Sent: vendredi 13 janvier 2017 01:39
> To: Amelie DELAUNAY <amelie.delaunay@st.com>
> Cc: Alessandro Zummo <a.zummo@towertech.it>; Rob Herring
> <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Maxime
> Coquelin <mcoquelin.stm32@gmail.com>; Alexandre TORGUE
> <alexandre.torgue@st.com>; Russell King <linux@armlinux.org.uk>; rtc-
> linux at googlegroups.com; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Gabriel FERNANDEZ
> <gabriel.fernandez@st.com>
> Subject: Re: [PATCHv5 3/8] rtc: add STM32 RTC driver
>
> On 11/01/2017 at 14:46:43 +0100, Amelie Delaunay wrote :
> > This patch adds support for the STM32 RTC.
> >
> > Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> > ---
> > drivers/rtc/Kconfig | 11 +
> > drivers/rtc/Makefile | 1 +
> > drivers/rtc/rtc-stm32.c | 727
> > ++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 739 insertions(+)
> > create mode 100644 drivers/rtc/rtc-stm32.c
> >
>
> This didn't apply cleanly, please check rtc-next. I don't think I made any mistake
> as the issue was only in Kconfig. You probably based your patches on 4.9
> instead of 4.10-rc1.
>
>
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* arm64: dts: mt8173: add node for thermal calibration
From: Daniel Kurtz @ 2017-01-13 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484286771-35913-1-git-send-email-dawei.chien@mediatek.com>
On Fri, Jan 13, 2017 at 1:52 PM, Dawei Chien <dawei.chien@mediatek.com> wrote:
>
> From: "dawei.chien at mediatek.com" <dawei.chien@mediatek.com>
>
> Add this for supporting thermal calibration by e-fuse data.
>
> Signed-off-by: Dawei Chien <dawei.chien@mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 12e7027..adfac1e 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -401,6 +401,11 @@
> efuse: efuse at 10206000 {
> compatible = "mediatek,mt8173-efuse";
> reg = <0 0x10206000 0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + thermal_calibration: calib at 528 {
> + reg = <0x528 0xc>;
> + };
> };
>
> apmixedsys: clock-controller at 10209000 {
> @@ -574,6 +579,8 @@
> resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
> mediatek,auxadc = <&auxadc>;
> mediatek,apmixedsys = <&apmixedsys>;
> + nvmem-cells = <&thermal_calibration>;
> + nvmem-cell-names = "calibration-data";
> };
>
> nor_flash: spi at 1100d000 {
> --
> 1.9.1
>
^ permalink raw reply
* [RFC 07/13] KVM: arm64: ITS: Change entry_size and indirect bit in BASER
From: Auger Eric @ 2017-01-13 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dc26dc19-313b-375b-0d9b-f4ff411a914f@arm.com>
Hi Marc,
On 12/01/2017 18:05, Marc Zyngier wrote:
> On 12/01/17 15:56, Eric Auger wrote:
>> Change the device table entry_size to 16 bytes instead of 8.
>> We also Store the device and collection device in the its
>> struct.
>>
>> The patch also clears the indirect bit for the device BASER.
>> The indirect bit is set as read-only.
>
> Err... Why? We *really* want to continue supporting indirect tables, as
> this is a massive memory saver for the guest.
>
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>>
>> TODO: investigate support of 2 level tables, ie. enabling
>> Indirect = 1. Support of 2 level tables is implementation
>> defined.
>
> Clearly, that's a regression. What exactly is the issue that decided you
> to disable it?
Well no valuable reason besides I saw it was optional, lack of
time/knowledge and a bit of laziness. I will address this requirement in
my next respin.
For my curiosity why did we choose not allowing the feature for
collections. Is that just because we think their number if going
sufficiently small compared to devices?
Thanks
Eric
>
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH v2 1/2] of: base: add support to find the level of the last cache
From: Tan Xiaojun @ 2017-01-13 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484245772-31511-1-git-send-email-sudeep.holla@arm.com>
On 2017/1/13 2:29, Sudeep Holla wrote:
> It is useful to have helper function just to get the number of cache
> levels for a given logical cpu. We can obtain the same by just checking
> the level at which the last cache is present. This patch adds support
> to find the level of the last cache for a given cpu.
>
> It will be used on ARM64 platform where the device tree provides the
> information for the additional non-architected/transparent/external
> last level caches that are not integrated with the processors.
>
> Suggested-by: Rob Herring <robh+dt@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Tan Xiaojun <tanxiaojun@huawei.com>
> ---
> drivers/of/base.c | 27 +++++++++++++++++++++++++++
> include/linux/of.h | 1 +
> 2 files changed, 28 insertions(+)
>
> v1->v2:
> - Moved to using "cache-level" in the last level cache instead
> of counting through all the nodes as suggested by Rob
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d4bea3c797d6..c1128a077aea 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -25,6 +25,7 @@
> #include <linux/cpu.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/of_graph.h>
> #include <linux/spinlock.h>
> #include <linux/slab.h>
> @@ -2268,6 +2269,32 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
> }
>
> /**
> + * of_find_last_cache_level - Find the level at which the last cache is
> + * present for the given logical cpu
> + *
> + * @cpu: cpu number(logical index) for which the last cache level is needed
> + *
> + * Returns the the level at which the last cache is present. It is exactly
> + * same as the total number of cache levels for the given logical cpu.
> + */
> +int of_find_last_cache_level(unsigned int cpu)
> +{
> + int cache_level = 0;
> + struct device_node *prev = NULL, *np = of_cpu_device_node_get(cpu);
> +
> + while (np) {
> + prev = np;
> + of_node_put(np);
> + np = of_find_next_cache_node(np);
> + }
> +
> + if (prev)
> + of_property_read_u32(prev, "cache-level", &cache_level);
> +
> + return cache_level;
> +}
> +
> +/**
> * of_graph_parse_endpoint() - parse common endpoint node properties
> * @node: pointer to endpoint device_node
> * @endpoint: pointer to the OF endpoint data structure
> diff --git a/include/linux/of.h b/include/linux/of.h
> index d72f01009297..21e6323de0f3 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -280,6 +280,7 @@ extern struct device_node *of_get_child_by_name(const struct device_node *node,
>
> /* cache lookup */
> extern struct device_node *of_find_next_cache_node(const struct device_node *);
> +extern int of_find_last_cache_level(unsigned int cpu);
> extern struct device_node *of_find_node_with_property(
> struct device_node *from, const char *prop_name);
>
> --
> 2.7.4
>
>
> .
>
^ permalink raw reply
* [PATCH v2 2/2] arm64: cacheinfo: add support to override cache levels via device tree
From: Tan Xiaojun @ 2017-01-13 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484245772-31511-2-git-send-email-sudeep.holla@arm.com>
On 2017/1/13 2:29, Sudeep Holla wrote:
> The cache hierarchy can be identified through Cache Level ID(CLIDR)
> architected system register. However in some cases it will provide
> only the number of cache levels that are integrated into the processor
> itself. In other words, it can't provide any information about the
> caches that are external and/or transparent.
>
> Some platforms require to export the information about all such external
> caches to the userspace applications via the sysfs interface.
>
> This patch adds support to override the cache levels using device tree
> to take such external non-architected caches into account.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Tan Xiaojun <tanxiaojun@huawei.com>
> ---
> arch/arm64/kernel/cacheinfo.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
> index 9617301f76b5..3f2250fc391b 100644
> --- a/arch/arm64/kernel/cacheinfo.c
> +++ b/arch/arm64/kernel/cacheinfo.c
> @@ -84,7 +84,7 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
>
> static int __init_cache_level(unsigned int cpu)
> {
> - unsigned int ctype, level, leaves;
> + unsigned int ctype, level, leaves, of_level;
> struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
>
> for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
> @@ -97,6 +97,17 @@ static int __init_cache_level(unsigned int cpu)
> leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
> }
>
> + of_level = of_find_last_cache_level(cpu);
> + if (level < of_level) {
> + /*
> + * some external caches not specified in CLIDR_EL1
> + * the information may be available in the device tree
> + * only unified external caches are considered here
> + */
> + leaves += (of_level - level);
> + level = of_level;
> + }
> +
> this_cpu_ci->num_levels = level;
> this_cpu_ci->num_leaves = leaves;
> return 0;
> --
> 2.7.4
>
>
> .
>
^ permalink raw reply
* [RFC 01/13] KVM: arm/arm64: Add vITS save/restore API documentation
From: Auger Eric @ 2017-01-13 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fe81c1b-9956-d458-b0ef-b7219f1249fe@arm.com>
Hi Marc,
On 12/01/2017 17:52, Marc Zyngier wrote:
> Hi Eric,
>
> On 12/01/17 15:56, Eric Auger wrote:
>> Add description for how to access vITS registers and how to flush/restore
>> vITS tables into/from memory
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> ---
>> Documentation/virtual/kvm/devices/arm-vgic-its.txt | 70 ++++++++++++++++++++++
>> 1 file changed, 70 insertions(+)
>>
>> diff --git a/Documentation/virtual/kvm/devices/arm-vgic-its.txt b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
>> index 6081a5b..bd74613 100644
>> --- a/Documentation/virtual/kvm/devices/arm-vgic-its.txt
>> +++ b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
>> @@ -36,3 +36,73 @@ Groups:
>> -ENXIO: ITS not properly configured as required prior to setting
>> this attribute
>> -ENOMEM: Memory shortage when allocating ITS internal data
>> +
>> + KVM_DEV_ARM_VGIC_GRP_ITS_REGS
>> + Attributes:
>> + The attr field of kvm_device_attr encodes the offset of the
>> + ITS register, relative to the ITS control frame base address
>> + (ITS_base).
>> +
>> + kvm_device_attr.addr points to a __u64 value whatever the width
>> + of the addressed register (32/64 bits).
>> +
>> + Writes to read-only registers are ignored by the kernel except
>> + for a single register, GITS_READR. Normally this register is RO
>> + but it needs to be restored otherwise commands in the queue will
>> + be re-executed after CWRITER setting.
>> +
>> + For other registers, Getting or setting a register has the same
>> + effect as reading/writing the register on real hardware.
>> + Errors:
>> + -ENXIO: Offset does not correspond to any supported register
>> + -EFAULT: Invalid user pointer for attr->addr
>> + -EINVAL: Offset is not 64-bit aligned
>> +
>> + KVM_DEV_ARM_VGIC_GRP_ITS_TABLES
>> + Attributes
>> + The attr field of kvm_device_attr is not used.
>> +
>> + request the flush-save/restore of the ITS tables, namely
>> + the device table, the collection table, all the ITT tables,
>> + the LPI pending tables. On save, the tables are flushed
>> + into guest memory at the location provisionned by the guest
>
> provisioned
>
>> + in GITS_BASER (device and collection tables), on MAPD command
>> + (ITT_addr), GICR_PENDBASERs (pending tables).
>> +
>> + This means the GIC should be restored before the ITS and all
>> + ITS registers but the GITS_CTRL must be restored before
>> + restoring the ITS tables.
>> +
>> + Note the LPI configuration table is read-only for the
>> + in-kernel ITS and its save/restore goes through the standard
>> + RAM save/restore.
>> +
>> + The layout of the tables in guest memory defines an ABI.
>> + The entries are laid out in memory as follows;
>> +
>> + Device Table Entry (DTE) layout: entry size = 16 bytes
>> +
>> + bits: | 63 ... 32 | 31 ... 6 | 5 | 4 ... 0 |
>> + values: | DeviceID | Resv | V | Size |
>> +
>> + bits: | 63 ... 44 | 43 ... 0 |
>> + values: | Resv | ITT_addr |
>
> While I appreciate this layout represents the absolute maximum an ITS
> could implement, I'm a bit concerned about the amount of memory we may
> end-up requiring here. All the ITSs implementations I know of seem to
> get away with 8 bytes per entry. Maybe I'm just too worried.
OK so I would propose a 16b DeviceId and 16b eventid
bits: | 63 ... 48 | 47 ... 4 | 3 ... 0 |
values: | DeviceID | ITT_addr | Size |
I can use the size field as a validity indicator
>
> Also, please mention that ITT_addr is actually ITT_addr[51:8], as we're
> guaranteed to have an ITT that is 256 byte aligned.
sure
>
>> +
>> + Collection Table Entry (CTE) layout: entry size = 8 bytes
>> +
>> + bits: | 63| 62 .. 52 | 51 ... 16 | 15 ... 0 |
>> + values: | V | RES0 | RDBase | ICID |
>> +
>> + Interrupt Translation Table Entry (ITTE) layout: entry size = 16 bytes
>
> The actual name is Interrupt Translation Entry (ITE). I have a patch
> renaming this all over the vgic-its.c file...
ok
>
>> +
>> + bits: | 63 ... 32 | 31 ... 17 | 16 | 15 ... 0 |
>> + values: | DeviceID | RES0 | V | ICID |
>> +
>> + bits: | 63 ... 32 | 31 ... 0 |
>> + values: | pINTID | EventID |
>
> Same concern here. 32bit DevID, EventID and INTID seem a bit over the
> top. But maybe we shouldn't be concerned about memory... ;-)
So I would suggest encoding
16b DeviceId
16b eventid
16b collection ID
16b pINTID
bits: | 63 ... 48 | 47 ... 32 | 31 ... 15 | 15 ... 0 |
values: | DeviceID | pINTID | EventId | ICID |
a null pINTID would meen the ITE is invalid.
Does that make sense or should I instead reduce the number of bits
allocated to collections and keep the pINTID bit number larger?
>
>> +
>> + LPI Pending Table layout:
>> +
>> + As specified in the ARM Generic Interrupt Controller Architecture
>> + Specification GIC Architecture version 3.0 and version 4. The first
>> + 1kB contains only zeros.
>>
>
> You definitely want to relax this. An ITS implementation is allowed (and
> actually encouraged) to maintain a coarse map in the first kB, and use
> this to quickly scan the table, which would be very useful on restore.
Maybe I miss something here. Currently I restore the ITEs before the
pending tables. So considering all the ITEs I know which LPI are defined
and which pending bits need to be restored. Why would I need to use a
coarse map for?
I understand the CPU cannot write the pending tables in our back, spec
says behavior would be unpredictable, right?
Thanks
Eric
>
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCHv4 0/5] Support for Marvell switches with integrated CPUs
From: Chris Packham @ 2017-01-13 9:12 UTC (permalink / raw)
To: linux-arm-kernel
The 98DX3236, 98DX3336 and 98DX4251 are a set of switch ASICs with
integrated CPUs. They CPU block is common within these product lines and
(as far as I can tell/have been told) is based on the Armada XP. There
are a few differences due to the fact they have to squeeze the CPU into
the same package as the switch.
This series is starting to settle down now. The only major change is in
"arm: mvebu: support for SMP on 98DX3336 SoC" the other changes are
generally cosmetic or collecting acks.
Chris Packham (4):
clk: mvebu: support for 98DX3236 SoC
Changes in v2:
- Update devicetree binding documentation for new compatible string
Changes in v3:
- Add 98dx3236 support to mvebu/clk-corediv.c rather than creating a new
driver.
- Document mv98dx3236-corediv-clock binding
Changes in v4:
- None
arm: mvebu: support for SMP on 98DX3336 SoC
Changes in v2:
- Document new enable-method value
- Correct some references from 98DX4521 to 98DX3236
Changes in v3:
- Simplify mv98dx3236_resume_init by using of_io_request_and_map()
Changes in v4:
- integrate changes into platsmp.c instead of new init call
- avoid duplicated code.
- fix error return
- Collect ack from Rob
arm: mvebu: Add device tree for 98DX3236 SoCs
Changes in v2:
- Update devicetree binding documentation to reflect that 98DX3336 and
984251 are supersets of 98DX3236.
- disable crypto block
- disable sdio for 98DX3236, enable for 98DX4251
Changes in v3:
- fix typo 4521 -> 4251
- document prestera bindings
- rework corediv-clock binding
- add label to packet processor node
- add new compatible string for DFX server
Changes in v4:
- Collect ack from Rob
arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards
Kalyan Kinthada (1):
pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
Changes in v2:
- include sdio support for the 98DX4251
Changes in v3:
- None
Changes in v4:
- Correct some discrepencies between binding and driver.
- Collect acks from Rob and Sebastian
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
.../bindings/arm/marvell/98dx3236-resume-ctrl.txt | 18 ++
.../devicetree/bindings/arm/marvell/98dx3236.txt | 23 ++
.../bindings/clock/mvebu-corediv-clock.txt | 1 +
.../devicetree/bindings/clock/mvebu-cpu-clock.txt | 1 +
.../devicetree/bindings/net/marvell,prestera.txt | 50 ++++
.../pinctrl/marvell,armada-98dx3236-pinctrl.txt | 46 ++++
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 254 +++++++++++++++++++++
arch/arm/boot/dts/armada-xp-98dx3336.dtsi | 76 ++++++
arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 90 ++++++++
arch/arm/boot/dts/db-dxbc2.dts | 159 +++++++++++++
arch/arm/boot/dts/db-xc3-24g4xg.dts | 155 +++++++++++++
arch/arm/mach-mvebu/platsmp.c | 86 +++++++
drivers/clk/mvebu/armada-xp.c | 42 ++++
drivers/clk/mvebu/clk-corediv.c | 23 ++
drivers/clk/mvebu/clk-cpu.c | 31 ++-
drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 156 +++++++++++++
17 files changed, 1210 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
create mode 100644 Documentation/devicetree/bindings/net/marvell,prestera.txt
create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
create mode 100644 arch/arm/boot/dts/armada-xp-98dx3236.dtsi
create mode 100644 arch/arm/boot/dts/armada-xp-98dx3336.dtsi
create mode 100644 arch/arm/boot/dts/armada-xp-98dx4251.dtsi
create mode 100644 arch/arm/boot/dts/db-dxbc2.dts
create mode 100644 arch/arm/boot/dts/db-xc3-24g4xg.dts
inter-diff to v3:
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
index d4e6ecdfc853..b5bd23992fdf 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
@@ -28,10 +28,10 @@ mpp13 13 gpio, intr(out), dev(ad15)
mpp14 14 gpio, i2c0(sck)
mpp15 15 gpio, i2c0(sda)
mpp16 16 gpio, dev(oe)
-mpp17 17 gpio, dev(clk)
+mpp17 17 gpio, dev(clkout)
mpp18 18 gpio, uart1(txd)
mpp19 19 gpio, uart1(rxd), dev(rb)
-mpp20 20 gpio, dev(we)
+mpp20 20 gpio, dev(we0)
mpp21 21 gpio, dev(ad0)
mpp22 22 gpio, dev(ad1)
mpp23 23 gpio, dev(ad2)
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 2a2dd8324fb8..6c6497e80a7b 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -7,7 +7,6 @@ obj-$(CONFIG_MACH_MVEBU_ANY) += system-controller.o mvebu-soc-id.o
ifeq ($(CONFIG_MACH_MVEBU_V7),y)
obj-y += cpu-reset.o board-v7.o coherency.o coherency_ll.o pmsu.o pmsu_ll.o
-obj-y += pmsu-98dx3236.o
obj-$(CONFIG_PM) += pm.o pm-board.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o platsmp-a9.o headsmp-a9.o
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 099dabf23461..6b775492cfad 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -27,5 +27,4 @@ void __iomem *mvebu_get_scu_base(void);
int mvebu_pm_suspend_init(void (*board_pm_enter)(void __iomem *sdram_reg,
u32 srcmd));
-void mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr);
#endif
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 3c9ab9a008ad..59be3ca0464f 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -182,12 +182,57 @@ const struct smp_operations armada_xp_smp_ops __initconst = {
#endif
};
+CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
+ &armada_xp_smp_ops);
+
+struct resume_controller {
+ u32 resume_control;
+ u32 resume_boot_addr;
+};
+
+static const struct resume_controller mv98dx3336_resume_controller = {
+ .resume_control = 0x08,
+ .resume_boot_addr = 0x04,
+};
+
+static const struct of_device_id of_mv98dx3236_resume_table[] = {
+ {
+ .compatible = "marvell,98dx3336-resume-ctrl",
+ .data = (void *)&mv98dx3336_resume_controller,
+ },
+ { /* end of list */ },
+};
+
+static int mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
+{
+ const struct of_device_id *match;
+ struct device_node *np;
+ void __iomem *base;
+ struct resume_controller *rc;
+
+ WARN_ON(hw_cpu != 1);
+
+ np = of_find_matching_node_and_match(NULL, of_mv98dx3236_resume_table,
+ &match);
+ if (!np)
+ return -ENODEV;
+
+ base = of_io_request_and_map(np, 0, of_node_full_name(np));
+ rc = (struct resume_controller *)match->data;
+ of_node_put(np);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ writel(0, base + rc->resume_control);
+ writel(virt_to_phys(boot_addr), base + rc->resume_boot_addr);
+
+ return 0;
+}
+
static int mv98dx3236_boot_secondary(unsigned int cpu, struct task_struct *idle)
{
int ret, hw_cpu;
- pr_info("Booting CPU %d\n", cpu);
-
hw_cpu = cpu_logical_map(cpu);
set_secondary_cpu_clock(hw_cpu);
mv98dx3236_resume_set_cpu_boot_addr(hw_cpu,
@@ -212,7 +257,7 @@ static int mv98dx3236_boot_secondary(unsigned int cpu, struct task_struct *idle)
return 0;
}
-struct smp_operations mv98dx3236_smp_ops __initdata = {
+static const struct smp_operations mv98dx3236_smp_ops __initconst = {
.smp_init_cpus = armada_xp_smp_init_cpus,
.smp_prepare_cpus = armada_xp_smp_prepare_cpus,
.smp_boot_secondary = mv98dx3236_boot_secondary,
@@ -223,7 +268,5 @@ struct smp_operations mv98dx3236_smp_ops __initdata = {
#endif
};
-CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
- &armada_xp_smp_ops);
CPU_METHOD_OF_DECLARE(mv98dx3236_smp, "marvell,98dx3236-smp",
&mv98dx3236_smp_ops);
diff --git a/arch/arm/mach-mvebu/pmsu-98dx3236.c b/arch/arm/mach-mvebu/pmsu-98dx3236.c
deleted file mode 100644
index 1052674dd439..000000000000
--- a/arch/arm/mach-mvebu/pmsu-98dx3236.c
+++ /dev/null
@@ -1,52 +0,0 @@
-/**
- * CPU resume support for 98DX3236 internal CPU (a.k.a. MSYS).
- */
-
-#define pr_fmt(fmt) "mv98dx3236-resume: " fmt
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/of_address.h>
-#include <linux/io.h>
-#include "common.h"
-
-static void __iomem *mv98dx3236_resume_base;
-#define MV98DX3236_CPU_RESUME_CTRL_OFFSET 0x08
-#define MV98DX3236_CPU_RESUME_ADDR_OFFSET 0x04
-
-static const struct of_device_id of_mv98dx3236_resume_table[] = {
- {.compatible = "marvell,98dx3336-resume-ctrl",},
- { /* end of list */ },
-};
-
-void mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
-{
- WARN_ON(hw_cpu != 1);
-
- writel(0, mv98dx3236_resume_base + MV98DX3236_CPU_RESUME_CTRL_OFFSET);
- writel(virt_to_phys(boot_addr), mv98dx3236_resume_base +
- MV98DX3236_CPU_RESUME_ADDR_OFFSET);
-}
-
-static int __init mv98dx3236_resume_init(void)
-{
- struct device_node *np;
- void __iomem *base;
-
- np = of_find_matching_node(NULL, of_mv98dx3236_resume_table);
- if (!np)
- return 0;
-
- base = of_io_request_and_map(np, 0, of_node_full_name(np));
- if (IS_ERR(base)) {
- pr_err("unable to map registers\n");
- of_node_put(np);
- return PTR_ERR(mv98dx3236_resume_base);
- }
-
- mv98dx3236_resume_base = base;
- of_node_put(np);
- return 0;
-}
-
-early_initcall(mv98dx3236_resume_init);
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index 554eeae8cd21..9601d662c7f5 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -374,8 +374,8 @@ static struct mvebu_mpp_mode mv98dx3236_mpp_modes[] = {
MPP_VAR_FUNCTION(0x2, "spi0", "miso", V_98DX3236_PLUS),
MPP_VAR_FUNCTION(0x4, "dev", "ad9", V_98DX3236_PLUS)),
MPP_MODE(2,
- MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x2, "spi0", "csk", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "spi0", "sck", V_98DX3236_PLUS),
MPP_VAR_FUNCTION(0x4, "dev", "ad10", V_98DX3236_PLUS)),
MPP_MODE(3,
MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
@@ -390,7 +390,7 @@ static struct mvebu_mpp_mode mv98dx3236_mpp_modes[] = {
MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
MPP_VAR_FUNCTION(0x1, "pex", "rsto", V_98DX3236_PLUS),
MPP_VAR_FUNCTION(0x2, "sd0", "cmd", V_98DX4251),
- MPP_VAR_FUNCTION(0x4, "dev", "bootcs0", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x4, "dev", "bootcs", V_98DX3236_PLUS)),
MPP_MODE(6,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
MPP_VAR_FUNCTION(0x2, "sd0", "clk", V_98DX4251),
@@ -442,7 +442,8 @@ static struct mvebu_mpp_mode mv98dx3236_mpp_modes[] = {
MPP_VAR_FUNCTION(0x3, "uart1", "txd", V_98DX3236_PLUS)),
MPP_MODE(19,
MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
- MPP_VAR_FUNCTION(0x3, "uart1", "rxd", V_98DX3236_PLUS)),
+ MPP_VAR_FUNCTION(0x3, "uart1", "rxd", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "rb", V_98DX3236_PLUS)),
MPP_MODE(20,
MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
MPP_VAR_FUNCTION(0x4, "dev", "we0", V_98DX3236_PLUS)),
@@ -548,7 +549,7 @@ static struct mvebu_mpp_ctrl mv98dx3236_mpp_controls[] = {
};
static struct pinctrl_gpio_range mv98dx3236_mpp_gpio_ranges[] = {
- MPP_GPIO_RANGE(0, 0, 0, 32),
+ MPP_GPIO_RANGE(0, 0, 0, 32),
};
static int armada_xp_pinctrl_suspend(struct platform_device *pdev,
--
2.11.0.24.ge6920cf
^ permalink raw reply related
* [PATCHv4 1/5] clk: mvebu: support for 98DX3236 SoC
From: Chris Packham @ 2017-01-13 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113091222.7132-1-chris.packham@alliedtelesis.co.nz>
The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from
the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz.
The clock gating options are a subset of those on the Armada XP.
The core clock divider is different to the Armada XP also.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
Notes:
Changes in v2:
- Update devicetree binding documentation for new compatible string
Changes in v3:
- Add 98dx3236 support to mvebu/clk-corediv.c rather than creating a new
driver.
- Document mv98dx3236-corediv-clock binding
Changes in v4:
- None
.../bindings/clock/mvebu-corediv-clock.txt | 1 +
.../devicetree/bindings/clock/mvebu-cpu-clock.txt | 1 +
drivers/clk/mvebu/armada-xp.c | 42 ++++++++++++++++++++++
drivers/clk/mvebu/clk-corediv.c | 23 ++++++++++++
drivers/clk/mvebu/clk-cpu.c | 31 ++++++++++++++--
5 files changed, 96 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt
index 520562a7dc2a..c7b4e3a6b2c6 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt
@@ -7,6 +7,7 @@ Required properties:
- compatible : must be "marvell,armada-370-corediv-clock",
"marvell,armada-375-corediv-clock",
"marvell,armada-380-corediv-clock",
+ "marvell,mv98dx3236-corediv-clock",
- reg : must be the register address of Core Divider control register
- #clock-cells : from common clock binding; shall be set to 1
diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
index 99c214660bdc..7f28506eaee7 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
@@ -3,6 +3,7 @@ Device Tree Clock bindings for cpu clock of Marvell EBU platforms
Required properties:
- compatible : shall be one of the following:
"marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
+ "marvell,mv98dx3236-cpu-clock" - cpu clocks for 98DX3236 SoC
- reg : Address and length of the clock complex register set, followed
by address and length of the PMU DFS registers
- #clock-cells : should be set to 1.
diff --git a/drivers/clk/mvebu/armada-xp.c b/drivers/clk/mvebu/armada-xp.c
index b3094315a3c0..0413bf8284e0 100644
--- a/drivers/clk/mvebu/armada-xp.c
+++ b/drivers/clk/mvebu/armada-xp.c
@@ -52,6 +52,12 @@ static u32 __init axp_get_tclk_freq(void __iomem *sar)
return 250000000;
}
+/* MV98DX3236 TCLK frequency is fixed to 200MHz */
+static u32 __init mv98dx3236_get_tclk_freq(void __iomem *sar)
+{
+ return 200000000;
+}
+
static const u32 axp_cpu_freqs[] __initconst = {
1000000000,
1066000000,
@@ -89,6 +95,12 @@ static u32 __init axp_get_cpu_freq(void __iomem *sar)
return cpu_freq;
}
+/* MV98DX3236 CLK frequency is fixed to 800MHz */
+static u32 __init mv98dx3236_get_cpu_freq(void __iomem *sar)
+{
+ return 800000000;
+}
+
static const int axp_nbclk_ratios[32][2] __initconst = {
{0, 1}, {1, 2}, {2, 2}, {2, 2},
{1, 2}, {1, 2}, {1, 1}, {2, 3},
@@ -158,6 +170,14 @@ static const struct coreclk_soc_desc axp_coreclks = {
.num_ratios = ARRAY_SIZE(axp_coreclk_ratios),
};
+static const struct coreclk_soc_desc mv98dx3236_coreclks = {
+ .get_tclk_freq = mv98dx3236_get_tclk_freq,
+ .get_cpu_freq = mv98dx3236_get_cpu_freq,
+ .get_clk_ratio = NULL,
+ .ratios = NULL,
+ .num_ratios = 0,
+};
+
/*
* Clock Gating Control
*/
@@ -195,6 +215,15 @@ static const struct clk_gating_soc_desc axp_gating_desc[] __initconst = {
{ }
};
+static const struct clk_gating_soc_desc mv98dx3236_gating_desc[] __initconst = {
+ { "ge1", NULL, 3, 0 },
+ { "ge0", NULL, 4, 0 },
+ { "pex00", NULL, 5, 0 },
+ { "sdio", NULL, 17, 0 },
+ { "xor0", NULL, 22, 0 },
+ { }
+};
+
static void __init axp_clk_init(struct device_node *np)
{
struct device_node *cgnp =
@@ -206,3 +235,16 @@ static void __init axp_clk_init(struct device_node *np)
mvebu_clk_gating_setup(cgnp, axp_gating_desc);
}
CLK_OF_DECLARE(axp_clk, "marvell,armada-xp-core-clock", axp_clk_init);
+
+static void __init mv98dx3236_clk_init(struct device_node *np)
+{
+ struct device_node *cgnp =
+ of_find_compatible_node(NULL, NULL, "marvell,armada-xp-gating-clock");
+
+ mvebu_coreclk_setup(np, &mv98dx3236_coreclks);
+
+ if (cgnp)
+ mvebu_clk_gating_setup(cgnp, mv98dx3236_gating_desc);
+}
+CLK_OF_DECLARE(mv98dx3236_clk, "marvell,mv98dx3236-core-clock",
+ mv98dx3236_clk_init);
diff --git a/drivers/clk/mvebu/clk-corediv.c b/drivers/clk/mvebu/clk-corediv.c
index d1e5863d3375..8491979f4096 100644
--- a/drivers/clk/mvebu/clk-corediv.c
+++ b/drivers/clk/mvebu/clk-corediv.c
@@ -71,6 +71,10 @@ static const struct clk_corediv_desc mvebu_corediv_desc[] = {
{ .mask = 0x3f, .offset = 8, .fieldbit = 1 }, /* NAND clock */
};
+static const struct clk_corediv_desc mv98dx3236_corediv_desc[] = {
+ { .mask = 0x0f, .offset = 6, .fieldbit = 26 }, /* NAND clock */
+};
+
#define to_corediv_clk(p) container_of(p, struct clk_corediv, hw)
static int clk_corediv_is_enabled(struct clk_hw *hwclk)
@@ -232,6 +236,18 @@ static const struct clk_corediv_soc_desc armada375_corediv_soc = {
.ratio_offset = 0x4,
};
+static const struct clk_corediv_soc_desc mv98dx3236_corediv_soc = {
+ .descs = mv98dx3236_corediv_desc,
+ .ndescs = ARRAY_SIZE(mv98dx3236_corediv_desc),
+ .ops = {
+ .recalc_rate = clk_corediv_recalc_rate,
+ .round_rate = clk_corediv_round_rate,
+ .set_rate = clk_corediv_set_rate,
+ },
+ .ratio_reload = BIT(10),
+ .ratio_offset = 0x8,
+};
+
static void __init
mvebu_corediv_clk_init(struct device_node *node,
const struct clk_corediv_soc_desc *soc_desc)
@@ -313,3 +329,10 @@ static void __init armada380_corediv_clk_init(struct device_node *node)
}
CLK_OF_DECLARE(armada380_corediv_clk, "marvell,armada-380-corediv-clock",
armada380_corediv_clk_init);
+
+static void __init mv98dx3236_corediv_clk_init(struct device_node *node)
+{
+ return mvebu_corediv_clk_init(node, &mv98dx3236_corediv_soc);
+}
+CLK_OF_DECLARE(mv98dx3236_corediv_clk, "marvell,mv98dx3236-corediv-clock",
+ mv98dx3236_corediv_clk_init);
diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
index 5837eb8a212f..3b8f0e14fa01 100644
--- a/drivers/clk/mvebu/clk-cpu.c
+++ b/drivers/clk/mvebu/clk-cpu.c
@@ -165,7 +165,9 @@ static const struct clk_ops cpu_ops = {
.set_rate = clk_cpu_set_rate,
};
-static void __init of_cpu_clk_setup(struct device_node *node)
+/* Add parameter to allow this to support different clock operations. */
+static void __init _of_cpu_clk_setup(struct device_node *node,
+ const struct clk_ops *cpu_clk_ops)
{
struct cpu_clk *cpuclk;
void __iomem *clock_complex_base = of_iomap(node, 0);
@@ -218,7 +220,7 @@ static void __init of_cpu_clk_setup(struct device_node *node)
cpuclk[cpu].hw.init = &init;
init.name = cpuclk[cpu].clk_name;
- init.ops = &cpu_ops;
+ init.ops = cpu_clk_ops;
init.flags = 0;
init.parent_names = &cpuclk[cpu].parent_name;
init.num_parents = 1;
@@ -243,5 +245,30 @@ static void __init of_cpu_clk_setup(struct device_node *node)
iounmap(clock_complex_base);
}
+/* Use this function to call the generic setup with the correct
+ * clock operation
+ */
+static void __init of_cpu_clk_setup(struct device_node *node)
+{
+ _of_cpu_clk_setup(node, &cpu_ops);
+}
+
CLK_OF_DECLARE(armada_xp_cpu_clock, "marvell,armada-xp-cpu-clock",
of_cpu_clk_setup);
+
+/* Define the clock and operations for the mv98dx3236 - it cannot perform
+ * any operations.
+ */
+static const struct clk_ops mv98dx3236_cpu_ops = {
+ .recalc_rate = NULL,
+ .round_rate = NULL,
+ .set_rate = NULL,
+};
+
+static void __init of_mv98dx3236_cpu_clk_setup(struct device_node *node)
+{
+ _of_cpu_clk_setup(node, &mv98dx3236_cpu_ops);
+}
+
+CLK_OF_DECLARE(mv98dx3236_cpu_clock, "marvell,mv98dx3236-cpu-clock",
+ of_mv98dx3236_cpu_clk_setup);
--
2.11.0.24.ge6920cf
^ permalink raw reply related
* [PATCHv4 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Chris Packham @ 2017-01-13 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113091222.7132-1-chris.packham@alliedtelesis.co.nz>
Compared to the armada-xp the 98DX3336 uses different registers to set
the boot address for the secondary CPU so a new enable-method is needed.
This will only work if the machine definition doesn't define an overall
smp_ops because there is not currently a way of overriding this from the
device tree if it is set in the machine definition.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Acked-by: Rob Herring <robh@kernel.org>
---
Notes:
Changes in v2:
- Document new enable-method value
- Correct some references from 98DX4521 to 98DX3236
Changes in v3:
- Simplify mv98dx3236_resume_init by using of_io_request_and_map()
Changes in v4:
- integrate changes into platsmp.c instead of new init call
- avoid duplicated code.
- fix error return
- Collect ack from Rob
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
.../bindings/arm/marvell/98dx3236-resume-ctrl.txt | 18 +++++
arch/arm/mach-mvebu/platsmp.c | 86 ++++++++++++++++++++++
3 files changed, 105 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index a1bcfeed5f24..3c2fd72d0bf9 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -202,6 +202,7 @@ nodes to be present and contain the properties described below.
"marvell,armada-380-smp"
"marvell,armada-390-smp"
"marvell,armada-xp-smp"
+ "marvell,98dx3236-smp"
"mediatek,mt6589-smp"
"mediatek,mt81xx-tz-smp"
"qcom,gcc-msm8660"
diff --git a/Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt b/Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
new file mode 100644
index 000000000000..8082ba872edd
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
@@ -0,0 +1,18 @@
+Resume Control
+--------------
+Available on Marvell SOCs: 98DX3336 and 98DX4251
+
+Required properties:
+
+- compatible: must be "marvell,98dx3336-resume-ctrl"
+
+- reg: Should contain resume control registers location and length
+
+Example:
+
+resume at 20980 {
+ compatible = "marvell,98dx3336-resume-ctrl";
+ reg = <0x20980 0x10>;
+};
+
+
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 46c742d3bd41..59be3ca0464f 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -184,3 +184,89 @@ const struct smp_operations armada_xp_smp_ops __initconst = {
CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
&armada_xp_smp_ops);
+
+struct resume_controller {
+ u32 resume_control;
+ u32 resume_boot_addr;
+};
+
+static const struct resume_controller mv98dx3336_resume_controller = {
+ .resume_control = 0x08,
+ .resume_boot_addr = 0x04,
+};
+
+static const struct of_device_id of_mv98dx3236_resume_table[] = {
+ {
+ .compatible = "marvell,98dx3336-resume-ctrl",
+ .data = (void *)&mv98dx3336_resume_controller,
+ },
+ { /* end of list */ },
+};
+
+static int mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
+{
+ const struct of_device_id *match;
+ struct device_node *np;
+ void __iomem *base;
+ struct resume_controller *rc;
+
+ WARN_ON(hw_cpu != 1);
+
+ np = of_find_matching_node_and_match(NULL, of_mv98dx3236_resume_table,
+ &match);
+ if (!np)
+ return -ENODEV;
+
+ base = of_io_request_and_map(np, 0, of_node_full_name(np));
+ rc = (struct resume_controller *)match->data;
+ of_node_put(np);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ writel(0, base + rc->resume_control);
+ writel(virt_to_phys(boot_addr), base + rc->resume_boot_addr);
+
+ return 0;
+}
+
+static int mv98dx3236_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+ int ret, hw_cpu;
+
+ hw_cpu = cpu_logical_map(cpu);
+ set_secondary_cpu_clock(hw_cpu);
+ mv98dx3236_resume_set_cpu_boot_addr(hw_cpu,
+ armada_xp_secondary_startup);
+
+ /*
+ * This is needed to wake up CPUs in the offline state after
+ * using CPU hotplug.
+ */
+ arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+ /*
+ * This is needed to take secondary CPUs out of reset on the
+ * initial boot.
+ */
+ ret = mvebu_cpu_reset_deassert(hw_cpu);
+ if (ret) {
+ pr_warn("unable to boot CPU: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct smp_operations mv98dx3236_smp_ops __initconst = {
+ .smp_init_cpus = armada_xp_smp_init_cpus,
+ .smp_prepare_cpus = armada_xp_smp_prepare_cpus,
+ .smp_boot_secondary = mv98dx3236_boot_secondary,
+ .smp_secondary_init = armada_xp_secondary_init,
+#ifdef CONFIG_HOTPLUG_CPU
+ .cpu_die = armada_xp_cpu_die,
+ .cpu_kill = armada_xp_cpu_kill,
+#endif
+};
+
+CPU_METHOD_OF_DECLARE(mv98dx3236_smp, "marvell,98dx3236-smp",
+ &mv98dx3236_smp_ops);
--
2.11.0.24.ge6920cf
^ permalink raw reply related
* [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Chris Packham @ 2017-01-13 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113091222.7132-1-chris.packham@alliedtelesis.co.nz>
From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
from Marvell.
Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Notes:
Changes in v2:
- include sdio support for the 98DX4251
Changes in v3:
- None
Changes in v4:
- Correct some discrepencies between binding and driver.
- Collect acks from Rob and Sebastian
.../pinctrl/marvell,armada-98dx3236-pinctrl.txt | 46 ++++++
drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 156 +++++++++++++++++++++
2 files changed, 202 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
new file mode 100644
index 000000000000..b5bd23992fdf
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
@@ -0,0 +1,46 @@
+* Marvell 98dx3236 pinctrl driver for mpp
+
+Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
+part and usage
+
+Required properties:
+- compatible: "marvell,98dx3236-pinctrl" or "marvell,98dx4251-pinctrl"
+- reg: register specifier of MPP registers
+
+This driver supports all 98dx3236, 98dx3336 and 98dx4251 variants
+
+name pins functions
+================================================================================
+mpp0 0 gpio, spi0(mosi), dev(ad8)
+mpp1 1 gpio, spi0(miso), dev(ad9)
+mpp2 2 gpio, spi0(sck), dev(ad10)
+mpp3 3 gpio, spi0(cs0), dev(ad11)
+mpp4 4 gpio, spi0(cs1), smi(mdc), dev(cs0)
+mpp5 5 gpio, pex(rsto), sd0(cmd), dev(bootcs)
+mpp6 6 gpio, sd0(clk), dev(a2)
+mpp7 7 gpio, sd0(d0), dev(ale0)
+mpp8 8 gpio, sd0(d1), dev(ale1)
+mpp9 9 gpio, sd0(d2), dev(ready0)
+mpp10 10 gpio, sd0(d3), dev(ad12)
+mpp11 11 gpio, uart1(rxd), uart0(cts), dev(ad13)
+mpp12 12 gpio, uart1(txd), uart0(rts), dev(ad14)
+mpp13 13 gpio, intr(out), dev(ad15)
+mpp14 14 gpio, i2c0(sck)
+mpp15 15 gpio, i2c0(sda)
+mpp16 16 gpio, dev(oe)
+mpp17 17 gpio, dev(clkout)
+mpp18 18 gpio, uart1(txd)
+mpp19 19 gpio, uart1(rxd), dev(rb)
+mpp20 20 gpio, dev(we0)
+mpp21 21 gpio, dev(ad0)
+mpp22 22 gpio, dev(ad1)
+mpp23 23 gpio, dev(ad2)
+mpp24 24 gpio, dev(ad3)
+mpp25 25 gpio, dev(ad4)
+mpp26 26 gpio, dev(ad5)
+mpp27 27 gpio, dev(ad6)
+mpp28 28 gpio, dev(ad7)
+mpp29 29 gpio, dev(a0)
+mpp30 30 gpio, dev(a1)
+mpp31 31 gpio, slv_smi(mdc), smi(mdc), dev(we1)
+mpp32 32 gpio, slv_smi(mdio), smi(mdio), dev(cs1)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index e4ea71a9d985..9601d662c7f5 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -49,6 +49,10 @@ enum armada_xp_variant {
V_MV78460 = BIT(2),
V_MV78230_PLUS = (V_MV78230 | V_MV78260 | V_MV78460),
V_MV78260_PLUS = (V_MV78260 | V_MV78460),
+ V_98DX3236 = BIT(3),
+ V_98DX3336 = BIT(4),
+ V_98DX4251 = BIT(5),
+ V_98DX3236_PLUS = (V_98DX3236 | V_98DX3336 | V_98DX4251),
};
static struct mvebu_mpp_mode armada_xp_mpp_modes[] = {
@@ -360,6 +364,131 @@ static struct mvebu_mpp_mode armada_xp_mpp_modes[] = {
MPP_VAR_FUNCTION(0x1, "dev", "ad31", V_MV78260_PLUS)),
};
+static struct mvebu_mpp_mode mv98dx3236_mpp_modes[] = {
+ MPP_MODE(0,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "spi0", "mosi", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad8", V_98DX3236_PLUS)),
+ MPP_MODE(1,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "spi0", "miso", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad9", V_98DX3236_PLUS)),
+ MPP_MODE(2,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "spi0", "sck", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad10", V_98DX3236_PLUS)),
+ MPP_MODE(3,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "spi0", "cs0", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad11", V_98DX3236_PLUS)),
+ MPP_MODE(4,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "spi0", "cs1", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x3, "smi", "mdc", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "cs0", V_98DX3236_PLUS)),
+ MPP_MODE(5,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "pex", "rsto", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "sd0", "cmd", V_98DX4251),
+ MPP_VAR_FUNCTION(0x4, "dev", "bootcs", V_98DX3236_PLUS)),
+ MPP_MODE(6,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "sd0", "clk", V_98DX4251),
+ MPP_VAR_FUNCTION(0x4, "dev", "a2", V_98DX3236_PLUS)),
+ MPP_MODE(7,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "sd0", "d0", V_98DX4251),
+ MPP_VAR_FUNCTION(0x4, "dev", "ale0", V_98DX3236_PLUS)),
+ MPP_MODE(8,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "sd0", "d1", V_98DX4251),
+ MPP_VAR_FUNCTION(0x4, "dev", "ale1", V_98DX3236_PLUS)),
+ MPP_MODE(9,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "sd0", "d2", V_98DX4251),
+ MPP_VAR_FUNCTION(0x4, "dev", "ready0", V_98DX3236_PLUS)),
+ MPP_MODE(10,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "sd0", "d3", V_98DX4251),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad12", V_98DX3236_PLUS)),
+ MPP_MODE(11,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "uart1", "rxd", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x3, "uart0", "cts", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad13", V_98DX3236_PLUS)),
+ MPP_MODE(12,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x2, "uart1", "txd", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x3, "uart0", "rts", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad14", V_98DX3236_PLUS)),
+ MPP_MODE(13,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "intr", "out", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "ad15", V_98DX3236_PLUS)),
+ MPP_MODE(14,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "i2c0", "sck", V_98DX3236_PLUS)),
+ MPP_MODE(15,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "i2c0", "sda", V_98DX3236_PLUS)),
+ MPP_MODE(16,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "oe", V_98DX3236_PLUS)),
+ MPP_MODE(17,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "clkout", V_98DX3236_PLUS)),
+ MPP_MODE(18,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x3, "uart1", "txd", V_98DX3236_PLUS)),
+ MPP_MODE(19,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x3, "uart1", "rxd", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "rb", V_98DX3236_PLUS)),
+ MPP_MODE(20,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "we0", V_98DX3236_PLUS)),
+ MPP_MODE(21,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "dev", "ad0", V_98DX3236_PLUS)),
+ MPP_MODE(22,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "dev", "ad1", V_98DX3236_PLUS)),
+ MPP_MODE(23,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "dev", "ad2", V_98DX3236_PLUS)),
+ MPP_MODE(24,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "dev", "ad3", V_98DX3236_PLUS)),
+ MPP_MODE(25,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "dev", "ad4", V_98DX3236_PLUS)),
+ MPP_MODE(26,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "dev", "ad5", V_98DX3236_PLUS)),
+ MPP_MODE(27,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "dev", "ad6", V_98DX3236_PLUS)),
+ MPP_MODE(28,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "dev", "ad7", V_98DX3236_PLUS)),
+ MPP_MODE(29,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "dev", "a0", V_98DX3236_PLUS)),
+ MPP_MODE(30,
+ MPP_VAR_FUNCTION(0x0, "gpo", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "dev", "a1", V_98DX3236_PLUS)),
+ MPP_MODE(31,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "slv_smi", "mdc", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x3, "smi", "mdc", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "we1", V_98DX3236_PLUS)),
+ MPP_MODE(32,
+ MPP_VAR_FUNCTION(0x0, "gpio", NULL, V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x1, "slv_smi", "mdio", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x3, "smi", "mdio", V_98DX3236_PLUS),
+ MPP_VAR_FUNCTION(0x4, "dev", "cs1", V_98DX3236_PLUS)),
+};
+
static struct mvebu_pinctrl_soc_info armada_xp_pinctrl_info;
static const struct of_device_id armada_xp_pinctrl_of_match[] = {
@@ -375,6 +504,14 @@ static const struct of_device_id armada_xp_pinctrl_of_match[] = {
.compatible = "marvell,mv78460-pinctrl",
.data = (void *) V_MV78460,
},
+ {
+ .compatible = "marvell,98dx3236-pinctrl",
+ .data = (void *) V_98DX3236,
+ },
+ {
+ .compatible = "marvell,98dx4251-pinctrl",
+ .data = (void *) V_98DX4251,
+ },
{ },
};
@@ -407,6 +544,14 @@ static struct pinctrl_gpio_range mv78460_mpp_gpio_ranges[] = {
MPP_GPIO_RANGE(2, 64, 64, 3),
};
+static struct mvebu_mpp_ctrl mv98dx3236_mpp_controls[] = {
+ MPP_FUNC_CTRL(0, 32, NULL, armada_xp_mpp_ctrl),
+};
+
+static struct pinctrl_gpio_range mv98dx3236_mpp_gpio_ranges[] = {
+ MPP_GPIO_RANGE(0, 0, 0, 32),
+};
+
static int armada_xp_pinctrl_suspend(struct platform_device *pdev,
pm_message_t state)
{
@@ -488,6 +633,17 @@ static int armada_xp_pinctrl_probe(struct platform_device *pdev)
soc->gpioranges = mv78460_mpp_gpio_ranges;
soc->ngpioranges = ARRAY_SIZE(mv78460_mpp_gpio_ranges);
break;
+ case V_98DX3236:
+ case V_98DX3336:
+ case V_98DX4251:
+ /* fall-through */
+ soc->controls = mv98dx3236_mpp_controls;
+ soc->ncontrols = ARRAY_SIZE(mv98dx3236_mpp_controls);
+ soc->modes = mv98dx3236_mpp_modes;
+ soc->nmodes = mv98dx3236_mpp_controls[0].npins;
+ soc->gpioranges = mv98dx3236_mpp_gpio_ranges;
+ soc->ngpioranges = ARRAY_SIZE(mv98dx3236_mpp_gpio_ranges);
+ break;
}
nregs = DIV_ROUND_UP(soc->nmodes, MVEBU_MPPS_PER_REG);
--
2.11.0.24.ge6920cf
^ permalink raw reply related
* [RFC PATCH v4 0/5] ARM: Fix dma_alloc_coherent() and friends for NOMMU
From: Vladimir Murzin @ 2017-01-13 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a428278-fe0f-ca1f-2b6a-96fdbb363db4@arm.com>
On 12/01/17 18:07, Robin Murphy wrote:
> On 12/01/17 17:15, Vladimir Murzin wrote:
>> On 12/01/17 17:04, Robin Murphy wrote:
>>> On 12/01/17 16:52, Vladimir Murzin wrote:
>>>> On 12/01/17 10:55, Benjamin Gaignard wrote:
>>>>> 2017-01-12 11:35 GMT+01:00 Benjamin Gaignard <benjamin.gaignard@linaro.org>:
>>>>>> 2017-01-11 15:34 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>>>>>> On 11/01/17 13:17, Benjamin Gaignard wrote:
>>>>>>>> 2017-01-10 15:18 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> It seem that addition of cache support for M-class cpus uncovered
>>>>>>>>> latent bug in DMA usage. NOMMU memory model has been treated as being
>>>>>>>>> always consistent; however, for R/M classes of cpu memory can be
>>>>>>>>> covered by MPU which in turn might configure RAM as Normal
>>>>>>>>> i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
>>>>>>>>> friends, since data can stuck in caches now or be buffered.
>>>>>>>>>
>>>>>>>>> This patch set is trying to address the issue by providing region of
>>>>>>>>> memory suitable for consistent DMA operations. It is supposed that
>>>>>>>>> such region is marked by MPU as non-cacheable. Robin suggested to
>>>>>>>>> advertise such memory as reserved shared-dma-pool, rather then using
>>>>>>>>> homebrew command line option, and extend dma-coherent to provide
>>>>>>>>> default DMA area in the similar way as it is done for CMA (PATCH
>>>>>>>>> 2/5). It allows us to offload all bookkeeping on generic coherent DMA
>>>>>>>>> framework, and it is seems that it might be reused by other
>>>>>>>>> architectures like c6x and blackfin.
>>>>>>>>>
>>>>>>>>> Dedicated DMA region is required for cases other than:
>>>>>>>>> - MMU/MPU is off
>>>>>>>>> - cpu is v7m w/o cache support
>>>>>>>>> - device is coherent
>>>>>>>>>
>>>>>>>>> In case one of the above conditions is true dma operations are forced
>>>>>>>>> to be coherent and wired with dma_noop_ops.
>>>>>>>>>
>>>>>>>>> To make life easier NOMMU dma operations are kept in separate
>>>>>>>>> compilation unit.
>>>>>>>>>
>>>>>>>>> Since the issue was reported in the same time as Benjamin sent his
>>>>>>>>> patch [1] to allow mmap for NOMMU, his case is also addressed in this
>>>>>>>>> series (PATCH 1/5 and PATCH 3/5).
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> I have tested this v4 on my setup (stm32f4, no cache, no MPU) and unfortunately
>>>>>>>> it doesn't work with my drm/kms driver.
>>>>>>>
>>>>>>> I guess the same is for fbmem, but would be better to have confirmation since
>>>>>>> amba-clcd I use has not been ported to drm/kms (yet), so I can't test.
>>>>>>>
>>>>>>>> I haven't any errors but nothing is displayed unlike what I have when
>>>>>>>> using current dma-mapping
>>>>>>>> code.
>>>>>>>> I guess the issue is coming from dma-noop where __get_free_pages() is
>>>>>>>> used instead of alloc_pages()
>>>>>>>> in dma-mapping.
>>>>>>>
>>>>>>> Unless I've missed something bellow is a call stack for both
>>>>>>>
>>>>>>> #1
>>>>>>> __alloc_simple_buffer
>>>>>>> __dma_alloc_buffer
>>>>>>> alloc_pages
>>>>>>> split_page
>>>>>>> __dma_clear_buffer
>>>>>>> memset
>>>>>>> page_address
>>>>>>>
>>>>>>> #2
>>>>>>> __get_free_pages
>>>>>>> alloc_pages
>>>>>>> page_address
>>>>>>>
>>>>>>> So the difference is that nommu case in dma-mapping.c memzeros memory, handles
>>>>>>> DMA_ATTR_NO_KERNEL_MAPPING and does optimisation of memory usage.
>>>>>>>
>>>>>>> Is something from above critical for your driver?
>>>>>>
>>>>>> I have removed all the diff (split_page, __dma_clear_buffer, memset)
>>>>>> from #1 and it is still working.
>>>>>> DMA_ATTR_NO_KERNEL_MAPPING flag is not set when allocating the buffer.
>>>>>>
>>>>>> I have investigated more and found that dma-noop doesn't take care of
>>>>>> "dma-ranges" property which is set in DT.
>>>>>> I believed that is the root cause of my problem with your patches.
>>>>>
>>>>> After testing changing virt_to_phys to virt_to_dma in dma-noop.c fix the issue
>>>>> modetest and fbdemo are now still functional.
>>>>>
>>>>
>>>> Thanks for narrowing it down! I did not noticed that stm32f4 remap its memory,
>>>> so dma-ranges property is in use.
>>>>
>>>> It looks like virt_to_dma is ARM specific, so I probably have to discard idea
>>>> of reusing dma-noop-ops and switch logic into dma-mapping-nommu.c based on
>>>> is_device_dma_coherent(dev) check.
>>>
>>> dma_pfn_offset is a member of struct device, so it should be OK for
>>> dma_noop_ops to also make reference to it (and assume it's zero if not
>>> explicitly set).
>>>
>>>> Meanwhile, I'm quite puzzled on how such memory remaping should work together
>>>> with reserved memory. It seem it doesn't account dma-ranges while reserving
>>>> memory (it is too early) nor while allocating/mapping/etc.
>>>
>>> The reserved memory is described in terms of CPU physical addresses, so
>>> a device offset shouldn't matter from that perspective. It only comes
>>> into play at the point you generate the dma_addr_t to hand off to the
>>> device - only then do you need to transform the CPU physical address of
>>> the allocated/mapped page into the device's view of that page (i.e.
>>> subtract the offset).
>>
>> Thanks for explanation! So dma-coherent.c should be modified, right? I see
>> that some architectures provide phys_to_dma/dma_to_phys helpers primary for
>> swiotlb, is it safe to reuse them given that default implementation is
>> provided? Nothing under Documentation explains how they supposed to be used,
>> sorry if asking stupid question.
>
> Those are essentially SWIOTLB-specific, so can't be universally relied
> upon. I think something like this ought to suffice:
Yup, but what about dma-coherent.c? Currently it has
int dma_alloc_from_coherent(struct device *dev, ssize_t size,
dma_addr_t *dma_handle, void **ret)
{
...
*dma_handle = mem->device_base + (pageno << PAGE_SHIFT);
*ret = mem->virt_base + (pageno << PAGE_SHIFT);
...
}
In case reserved memory is described in terms of CPU phys addresses, would not
we need to take into account dma_pfn_offset? What I'm missing?
Thanks
Vladimir
>
> ---8<---
> diff --git a/lib/dma-noop.c b/lib/dma-noop.c
> index 3d766e78fbe2..fbb1b37750d5 100644
> --- a/lib/dma-noop.c
> +++ b/lib/dma-noop.c
> @@ -8,6 +8,11 @@
> #include <linux/dma-mapping.h>
> #include <linux/scatterlist.h>
>
> +static dma_addr_t dma_noop_dev_offset(struct device *dev)
> +{
> + return (dma_addr_t)dev->dma_pfn_offset << PAGE_SHIFT;
> +}
> +
> static void *dma_noop_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t gfp,
> unsigned long attrs)
> @@ -16,7 +21,7 @@ static void *dma_noop_alloc(struct device *dev, size_t
> size,
>
> ret = (void *)__get_free_pages(gfp, get_order(size));
> if (ret)
> - *dma_handle = virt_to_phys(ret);
> + *dma_handle = virt_to_phys(ret) - dma_noop_dev_offset(dev);
> return ret;
> }
>
> @@ -32,7 +37,7 @@ static dma_addr_t dma_noop_map_page(struct device
> *dev, struct page *page,
> enum dma_data_direction dir,
> unsigned long attrs)
> {
> - return page_to_phys(page) + offset;
> + return page_to_phys(page) + offset - dma_noop_dev_offset(dev);
> }
>
> static int dma_noop_map_sg(struct device *dev, struct scatterlist *sgl,
> int nents,
> @@ -47,7 +52,8 @@ static int dma_noop_map_sg(struct device *dev, struct
> scatterlist *sgl, int nent
>
> BUG_ON(!sg_page(sg));
> va = sg_virt(sg);
> - sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va);
> + sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va) -
> + dma_noop_dev_offset(dev);
> sg_dma_len(sg) = sg->length;
> }
> --->8---
>
> intentionally whitespace-damaged by copy-pasting off my terminal to
> emphasise how utterly untested it is ;)
>
> Robin.
>
^ permalink raw reply
* [PATCHv4 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs
From: Chris Packham @ 2017-01-13 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113091222.7132-1-chris.packham@alliedtelesis.co.nz>
The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
with integrated CPUs. They are similar to the Armada XP SoCs but have
different I/O interfaces.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Acked-by: Rob Herring <robh@kernel.org>
---
Notes:
Changes in v2:
- Update devicetree binding documentation to reflect that 98DX3336 and
984251 are supersets of 98DX3236.
- disable crypto block
- disable sdio for 98DX3236, enable for 98DX4251
Changes in v3:
- fix typo 4521 -> 4251
- document prestera bindings
- rework corediv-clock binding
- add label to packet processor node
- add new compatible string for DFX server
Changes in v4:
- Collect ack from Rob
.../devicetree/bindings/arm/marvell/98dx3236.txt | 23 ++
.../devicetree/bindings/net/marvell,prestera.txt | 50 ++++
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 254 +++++++++++++++++++++
arch/arm/boot/dts/armada-xp-98dx3336.dtsi | 76 ++++++
arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 90 ++++++++
5 files changed, 493 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
create mode 100644 Documentation/devicetree/bindings/net/marvell,prestera.txt
create mode 100644 arch/arm/boot/dts/armada-xp-98dx3236.dtsi
create mode 100644 arch/arm/boot/dts/armada-xp-98dx3336.dtsi
create mode 100644 arch/arm/boot/dts/armada-xp-98dx4251.dtsi
diff --git a/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
new file mode 100644
index 000000000000..64e8c73fc5ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
@@ -0,0 +1,23 @@
+Marvell 98DX3236, 98DX3336 and 98DX4251 Platforms Device Tree Bindings
+----------------------------------------------------------------------
+
+Boards with a SoC of the Marvell 98DX3236, 98DX3336 and 98DX4251 families
+shall have the following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armadaxp-98dx3236"
+
+In addition, boards using the Marvell 98DX3336 SoC shall have the
+following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armadaxp-98dx3336"
+
+In addition, boards using the Marvell 98DX4251 SoC shall have the
+following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armadaxp-98dx4251"
diff --git a/Documentation/devicetree/bindings/net/marvell,prestera.txt b/Documentation/devicetree/bindings/net/marvell,prestera.txt
new file mode 100644
index 000000000000..5fbab29718e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell,prestera.txt
@@ -0,0 +1,50 @@
+Marvell Prestera Switch Chip bindings
+-------------------------------------
+
+Required properties:
+- compatible: one of the following
+ "marvell,prestera-98dx3236",
+ "marvell,prestera-98dx3336",
+ "marvell,prestera-98dx4251",
+- reg: address and length of the register set for the device.
+- interrupts: interrupt for the device
+
+Optional properties:
+- dfx: phandle reference to the "DFX Server" node
+
+Example:
+
+switch {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 MBUS_ID(0x03, 0x00) 0 0x100000>;
+
+ packet-processor at 0 {
+ compatible = "marvell,prestera-98dx3236";
+ reg = <0 0x4000000>;
+ interrupts = <33>, <34>, <35>;
+ dfx = <&dfx>;
+ };
+};
+
+DFX Server bindings
+-------------------
+
+Required properties:
+- compatible: must be "marvell,dfx-server"
+- reg: address and length of the register set for the device.
+
+Example:
+
+dfx-registers {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>;
+
+ dfx: dfx at 0 {
+ compatible = "marvell,dfx-server";
+ reg = <0 0x100000>;
+ };
+};
diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
new file mode 100644
index 000000000000..4b7b2fe3b682
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
@@ -0,0 +1,254 @@
+/*
+ * Device Tree Include file for Marvell 98dx3236 family SoC
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Contains definitions specific to the 98dx3236 SoC that are not
+ * common to all Armada XP SoCs.
+ */
+
+#include "armada-xp.dtsi"
+
+/ {
+ model = "Marvell 98DX3236 SoC";
+ compatible = "marvell,armadaxp-98dx3236", "marvell,armadaxp", "marvell,armada-370-xp";
+
+ aliases {
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ gpio2 = &gpio2;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-method = "marvell,98dx3236-smp";
+
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "marvell,sheeva-v7";
+ reg = <0>;
+ clocks = <&cpuclk 0>;
+ clock-latency = <1000000>;
+ };
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+ MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000
+ MBUS_ID(0x03, 0x00) 0 0 0xa8000000 0x4000000
+ MBUS_ID(0x08, 0x00) 0 0 0xac000000 0x100000>;
+
+ /*
+ * 98DX3236 has 1 x1 PCIe unit Gen2.0: One unit can be
+ */
+ pcie-controller {
+ compatible = "marvell,armada-xp-pcie";
+ status = "disabled";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ msi-parent = <&mpic>;
+ bus-range = <0x00 0xff>;
+
+ ranges =
+ <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */
+ 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+ 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
+ 0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */>;
+
+ pcie at 1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+ reg = <0x0800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+ 0x81000000 0 0 0x81000000 0x1 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 58>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 5>;
+ status = "disabled";
+ };
+ };
+
+ internal-regs {
+ coreclk: mvebu-sar at 18230 {
+ compatible = "marvell,mv98dx3236-core-clock";
+ };
+
+ cpuclk: clock-complex at 18700 {
+ compatible = "marvell,mv98dx3236-cpu-clock";
+ };
+
+ corediv-clock at 18740 {
+ status = "disabled";
+ };
+
+ xor at 60900 {
+ status = "disabled";
+ };
+
+ crypto at 90000 {
+ status = "disabled";
+ };
+
+ xor at f0900 {
+ status = "disabled";
+ };
+
+ xor at f0800 {
+ compatible = "marvell,orion-xor";
+ reg = <0xf0800 0x100
+ 0xf0a00 0x100>;
+ clocks = <&gateclk 22>;
+ status = "okay";
+
+ xor10 {
+ interrupts = <51>;
+ dmacap,memcpy;
+ dmacap,xor;
+ };
+ xor11 {
+ interrupts = <52>;
+ dmacap,memcpy;
+ dmacap,xor;
+ dmacap,memset;
+ };
+ };
+
+ gpio0: gpio at 18100 {
+ compatible = "marvell,orion-gpio";
+ reg = <0x18100 0x40>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <82>, <83>, <84>, <85>;
+ };
+
+ /* does not exist */
+ gpio1: gpio at 18140 {
+ compatible = "marvell,orion-gpio";
+ reg = <0x18140 0x40>;
+ status = "disabled";
+ };
+
+ gpio2: gpio at 18180 { /* rework some properties */
+ compatible = "marvell,orion-gpio";
+ reg = <0x18180 0x40>;
+ ngpios = <1>; /* only gpio #32 */
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <87>;
+ };
+
+ nand: nand at d0000 {
+ clocks = <&dfx_coredivclk 0>;
+ };
+ };
+
+ dfx-registers {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>;
+
+ dfx_coredivclk: corediv-clock at f8268 {
+ compatible = "marvell,mv98dx3236-corediv-clock";
+ reg = <0xf8268 0xc>;
+ #clock-cells = <1>;
+ clocks = <&mainpll>;
+ clock-output-names = "nand";
+ };
+
+ dfx: dfx at 0 {
+ compatible = "marvell,dfx-server";
+ reg = <0 0x100000>;
+ };
+ };
+
+ switch {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 MBUS_ID(0x03, 0x00) 0 0x100000>;
+
+ pp0: packet-processor at 0 {
+ compatible = "marvell,prestera-98dx3236";
+ reg = <0 0x4000000>;
+ interrupts = <33>, <34>, <35>;
+ dfx = <&dfx>;
+ };
+ };
+ };
+};
+
+&pinctrl {
+ compatible = "marvell,98dx3236-pinctrl";
+
+ spi0_pins: spi0-pins {
+ marvell,pins = "mpp0", "mpp1",
+ "mpp2", "mpp3";
+ marvell,function = "spi0";
+ };
+};
+
+&sdio {
+ status = "disabled";
+};
+
+&crypto_sram0 {
+ status = "disabled";
+};
+
+&crypto_sram1 {
+ status = "disabled";
+};
diff --git a/arch/arm/boot/dts/armada-xp-98dx3336.dtsi b/arch/arm/boot/dts/armada-xp-98dx3336.dtsi
new file mode 100644
index 000000000000..a9b0f47f8df9
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-98dx3336.dtsi
@@ -0,0 +1,76 @@
+/*
+ * Device Tree Include file for Marvell 98dx3336 family SoC
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Contains definitions specific to the 98dx3336 SoC that are not
+ * common to all Armada XP SoCs.
+ */
+
+#include "armada-xp-98dx3236.dtsi"
+
+/ {
+ model = "Marvell 98DX3336 SoC";
+ compatible = "marvell,armadaxp-98dx3336", "marvell,armadaxp-98dx3236", "marvell,armadaxp", "marvell,armada-370-xp";
+
+ cpus {
+ cpu at 1 {
+ device_type = "cpu";
+ compatible = "marvell,sheeva-v7";
+ reg = <1>;
+ clocks = <&cpuclk 1>;
+ clock-latency = <1000000>;
+ };
+ };
+
+ soc {
+ internal-regs {
+ resume at 20980 {
+ compatible = "marvell,98dx3336-resume-ctrl";
+ reg = <0x20980 0x10>;
+ };
+ };
+ };
+};
+
+&pp0 {
+ compatible = "marvell,prestera-98dx3336";
+};
diff --git a/arch/arm/boot/dts/armada-xp-98dx4251.dtsi b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
new file mode 100644
index 000000000000..446e6e65ec59
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
@@ -0,0 +1,90 @@
+/*
+ * Device Tree Include file for Marvell 98dx4521 family SoC
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Contains definitions specific to the 98dx4521 SoC that are not
+ * common to all Armada XP SoCs.
+ */
+
+#include "armada-xp-98dx3236.dtsi"
+
+/ {
+ model = "Marvell 98DX4251 SoC";
+ compatible = "marvell,armadaxp-98dx4521", "marvell,armadaxp-98dx3236", "marvell,armadaxp", "marvell,armada-370-xp";
+
+ cpus {
+ cpu at 1 {
+ device_type = "cpu";
+ compatible = "marvell,sheeva-v7";
+ reg = <1>;
+ clocks = <&cpuclk 1>;
+ clock-latency = <1000000>;
+ };
+ };
+
+ soc {
+ internal-regs {
+ resume at 20980 {
+ compatible = "marvell,98dx3336-resume-ctrl";
+ reg = <0x20980 0x10>;
+ };
+ };
+ };
+};
+
+&sdio {
+ status = "okay";
+};
+
+&pinctrl {
+ compatible = "marvell,98dx4251-pinctrl";
+
+ sdio_pins: sdio-pins {
+ marvell,pins = "mpp5", "mpp6", "mpp7",
+ "mpp8", "mpp9", "mpp10";
+ marvell,function = "sd0";
+ };
+};
+
+&pp0 {
+ compatible = "marvell,prestera-98dx4251";
+};
--
2.11.0.24.ge6920cf
^ permalink raw reply related
* [PATCHv4 5/5] arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards
From: Chris Packham @ 2017-01-13 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113091222.7132-1-chris.packham@alliedtelesis.co.nz>
These boards are Marvell's evaluation boards for the 98DX4251 and
98DX3336 SoCs.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
arch/arm/boot/dts/db-dxbc2.dts | 159 ++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/db-xc3-24g4xg.dts | 155 +++++++++++++++++++++++++++++++++++
2 files changed, 314 insertions(+)
create mode 100644 arch/arm/boot/dts/db-dxbc2.dts
create mode 100644 arch/arm/boot/dts/db-xc3-24g4xg.dts
diff --git a/arch/arm/boot/dts/db-dxbc2.dts b/arch/arm/boot/dts/db-dxbc2.dts
new file mode 100644
index 000000000000..f56786cea5f8
--- /dev/null
+++ b/arch/arm/boot/dts/db-dxbc2.dts
@@ -0,0 +1,159 @@
+/*
+ * Device Tree file for DB-DXBC2 board
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ *
+ * Based on armada-xp-db.dts
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Note: this Device Tree assumes that the bootloader has remapped the
+ * internal registers to 0xf1000000 (instead of the default
+ * 0xd0000000). The 0xf1000000 is the default used by the recent,
+ * DT-capable, U-Boot bootloaders provided by Marvell. Some earlier
+ * boards were delivered with an older version of the bootloader that
+ * left internal registers mapped at 0xd0000000. If you are in this
+ * situation, you should either update your bootloader (preferred
+ * solution) or the below Device Tree should be adjusted.
+ */
+
+/dts-v1/;
+#include "armada-xp-98dx4251.dtsi"
+
+/ {
+ model = "Marvell Bobcat2 Evaluation Board";
+ compatible = "marvell,db-dxbc2", "marvell,armadaxp-98dx4251", "marvell,armadaxp", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x00000000 0 0x20000000>; /* 512 MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+ MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000
+ MBUS_ID(0x03, 0x00) 0 0 0xa8000000 0x4000000
+ MBUS_ID(0x08, 0x00) 0 0 0xac000000 0x100000>;
+
+ devbus-bootcs {
+ status = "okay";
+
+ /* Device Bus parameters are required */
+
+ /* Read parameters */
+ devbus,bus-width = <16>;
+ devbus,turn-off-ps = <60000>;
+ devbus,badr-skew-ps = <0>;
+ devbus,acc-first-ps = <124000>;
+ devbus,acc-next-ps = <248000>;
+ devbus,rd-setup-ps = <0>;
+ devbus,rd-hold-ps = <0>;
+
+ /* Write parameters */
+ devbus,sync-enable = <0>;
+ devbus,wr-high-ps = <60000>;
+ devbus,wr-low-ps = <60000>;
+ devbus,ale-wr-ps = <60000>;
+ };
+
+ internal-regs {
+ serial at 12000 {
+ status = "okay";
+ };
+ serial at 12100 {
+ status = "okay";
+ };
+
+ i2c at 11000 {
+ clock-frequency = <100000>;
+ status = "okay";
+ };
+
+ mvsdio at d4000 {
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ /* No CD or WP GPIOs */
+ broken-cd;
+ };
+
+ nand at d0000 {
+ status = "okay";
+ num-cs = <1>;
+ marvell,nand-keep-config;
+ marvell,nand-enable-arbiter;
+ nand-on-flash-bbt;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ };
+ };
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ spi-flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "m25p64";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <20000000>;
+ m25p,fast-read;
+
+ partition at u-boot {
+ reg = <0x00000000 0x00100000>;
+ label = "u-boot";
+ };
+ partition at u-boot-env {
+ reg = <0x00100000 0x00040000>;
+ label = "u-boot-env";
+ };
+ partition at unused {
+ reg = <0x00140000 0x00ec0000>;
+ label = "unused";
+ };
+
+ };
+};
diff --git a/arch/arm/boot/dts/db-xc3-24g4xg.dts b/arch/arm/boot/dts/db-xc3-24g4xg.dts
new file mode 100644
index 000000000000..5eb89ffb9a7d
--- /dev/null
+++ b/arch/arm/boot/dts/db-xc3-24g4xg.dts
@@ -0,0 +1,155 @@
+/*
+ * Device Tree file for DB-XC3-24G4XG board
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ *
+ * Based on armada-xp-db.dts
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Note: this Device Tree assumes that the bootloader has remapped the
+ * internal registers to 0xf1000000 (instead of the default
+ * 0xd0000000). The 0xf1000000 is the default used by the recent,
+ * DT-capable, U-Boot bootloaders provided by Marvell. Some earlier
+ * boards were delivered with an older version of the bootloader that
+ * left internal registers mapped at 0xd0000000. If you are in this
+ * situation, you should either update your bootloader (preferred
+ * solution) or the below Device Tree should be adjusted.
+ */
+
+/dts-v1/;
+#include "armada-xp-98dx3336.dtsi"
+
+/ {
+ model = "DB-XC3-24G4XG";
+ compatible = "marvell,db-xc3-24g4xg", "marvell,armadaxp-98dx3336", "marvell,armadaxp", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x00000000 0 0x40000000>; /* 1 GB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+ MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000
+ MBUS_ID(0x03, 0x00) 0 0 0xa8000000 0x4000000
+ MBUS_ID(0x08, 0x00) 0 0 0xac000000 0x100000>;
+
+ devbus-bootcs {
+ status = "okay";
+
+ /* Device Bus parameters are required */
+
+ /* Read parameters */
+ devbus,bus-width = <16>;
+ devbus,turn-off-ps = <60000>;
+ devbus,badr-skew-ps = <0>;
+ devbus,acc-first-ps = <124000>;
+ devbus,acc-next-ps = <248000>;
+ devbus,rd-setup-ps = <0>;
+ devbus,rd-hold-ps = <0>;
+
+ /* Write parameters */
+ devbus,sync-enable = <0>;
+ devbus,wr-high-ps = <60000>;
+ devbus,wr-low-ps = <60000>;
+ devbus,ale-wr-ps = <60000>;
+ };
+
+ internal-regs {
+ serial at 12000 {
+ status = "okay";
+ };
+ serial at 12100 {
+ status = "okay";
+ };
+
+ i2c at 11000 {
+ clock-frequency = <100000>;
+ status = "okay";
+ };
+
+ mvsdio at d4000 {
+ status = "disabled";
+ };
+
+ nand at d0000 {
+ status = "okay";
+ num-cs = <1>;
+ marvell,nand-keep-config;
+ marvell,nand-enable-arbiter;
+ nand-on-flash-bbt;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ };
+ };
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ spi-flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "m25p64";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <20000000>;
+ m25p,fast-read;
+
+ partition at u-boot {
+ reg = <0x00000000 0x00100000>;
+ label = "u-boot";
+ };
+ partition at u-boot-env {
+ reg = <0x00100000 0x00040000>;
+ label = "u-boot-env";
+ };
+ partition at unused {
+ reg = <0x00140000 0x00ec0000>;
+ label = "unused";
+ };
+
+ };
+};
--
2.11.0.24.ge6920cf
^ permalink raw reply related
* [PATCH v29 9/9] Documentation: dt: chosen properties for arm64 kdump
From: AKASHI Takahiro @ 2017-01-13 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112153944.GB12249@leverpostej>
On Thu, Jan 12, 2017 at 03:39:45PM +0000, Mark Rutland wrote:
> Hi,
>
> On Wed, Dec 28, 2016 at 01:37:34PM +0900, AKASHI Takahiro wrote:
> > From: James Morse <james.morse@arm.com>
> >
> > Add documentation for
> > linux,crashkernel-base and crashkernel-size,
> > linux,usable-memory-range
> > linux,elfcorehdr
> > used by arm64 kdump to decribe the kdump reserved area, and
> > the elfcorehdr's location within it.
> >
> > Signed-off-by: James Morse <james.morse@arm.com>
> > [takahiro.akashi at linaro.org: added "linux,crashkernel-base" and "-size" ]
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > Cc: devicetree at vger.kernel.org
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > ---
> > Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++
> > 1 file changed, 50 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
> > index 6ae9d82d4c37..7b115165e9ec 100644
> > --- a/Documentation/devicetree/bindings/chosen.txt
> > +++ b/Documentation/devicetree/bindings/chosen.txt
> > @@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, and only needed on
> > book3e) by some versions of kexec-tools to tell the new kernel that it
> > is being booted by kexec, as the booting environment may differ (e.g.
> > a different secondary CPU release mechanism)
> > +
> > +linux,crashkernel-base
> > +linux,crashkernel-size
> > +----------------------
> > +
> > +These properties (currently used on PowerPC and arm64) indicates
> > +the base address and the size, respectively, of the reserved memory
> > +range for crash dump kernel.
>
> From this description, it's not clear to me what the (expected)
> consumers of this property are, nor what is expected to provide it.
>
> In previous rounds of review, I had assumed that this was used to
> describe a preference to the first kernel as to what region of memory
> should be used for a subsequent kdump kernel. Looking around, I'm not
> sure if I was correct in that assessment.
>
> I see that arch/powerpc seems to consume this property to configure
> crashk_res, but it also rewrites it based on crashk_res, presumably for
> the benefit of userspace. It's not clear to me how on powerpc the kdump
> kernel knows its memory range -- is more DT modification done in the
> kernel and/or userspace?
I don't believe that powerpc will rewrite the property any way.
As far as I know from *the source code*, powerpc kernel retrieves
the memory range for crash dump kernel from a kernel command line, i.e.
crashkernel=, and then exposes it through DT to userspace (assuming
kexec-tools).
> I disagree with modifying this property to expose it to userspace. For
Apart from the context of discussions, is this a shared consensus?
> arm64 we should either ensure that /proc/iomem is consistently usable
> (and have userspace consistently use it), or we should expose a new file
> specifically to expose this information.
The thing that I had in my mind when adding this property is that
/proc/iomem would be obsolete in the future, then we should have
an alternative in hand.
> Further, I do not think we need this property. It makes more sense to me
> for the preference of a a region to be described to the *first* kernel
> using the command line consistently.
>
> So I think we should drop this property, and not use it on arm64. Please
> document this as powerpc only.
OK, but if we drop the property from arm64 code, we have no reason
to leave its description in this patch.
(In fact, there are a few more (undocumented) properties that only ppc
uses for kdump.)
> > +e.g.
> > +
> > +/ {
> > + chosen {
> > + linux,crashkernel-base = <0x9 0xf0000000>;
> > + linux,crashkernel-size = <0x0 0x10000000>;
> > + };
> > +};
>
> > +
> > +linux,usable-memory-range
> > +-------------------------
> > +
> > +This property (currently used only on arm64) holds the memory range,
> > +the base address and the size, which can be used as system ram on
> > +the *current* kernel. Note that, if this property is present, any memory
> > +regions under "memory" nodes in DT blob or ones marked as "conventional
> > +memory" in EFI memory map should be ignored.
>
> Could you please replace this with:
>
> This property (arm64 only) holds a base address and size, describing a
> limited region in which memory may be considered available for use by
> the kernel. Memory outside of this range is not available for use.
>
> This property describes a limitation: memory within this range is only
> valid when also described through another mechanism that the kernel
> would otherwise use to determine available memory (e.g. memory nodes
> or the EFI memory map). Valid memory may be sparse within the range.
Sure.
Thanks,
-Takahiro AKASHI
> To clarify why we need this, given by above comments w.r.r. the
> linux,crashkernel-* properties:
>
> * It preserves all the original memory map information (e.g. memory
> nodes and/or EFI memory map)
>
> * It works consistently, regardless of how the kdump kernel would
> otherwise determine which memory to use (memory nodes, EFI, etc).
>
> * It will be simply and reliable for an in-kernel purgatory to insert,
> if we need a kexec_file_load()-based kdump (e.g. without requiring
> memory map rewrites, and avoiding clashes with command line
> parameters). For a first kernel, this is not as big a concern.
>
> > +linux,elfcorehdr
> > +----------------
> > +
> > +This property (currently used only on arm64) holds the memory range,
> > +the address and the size, of the elf core header which mainly describes
> > +the panicked kernel's memory layout as PT_LOAD segments of elf format.
> > +e.g.
> > +
> > +/ {
> > + chosen {
> > + linux,elfcorehdr = <0x9 0xfffff000 0x0 0x800>;
> > + };
> > +};
>
> This property looks fine to me.
>
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH v3] arm64: mm: Fix NOMAP page initialization
From: Will Deacon @ 2017-01-13 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112185825.GE5020@rric.localdomain>
On Thu, Jan 12, 2017 at 07:58:25PM +0100, Robert Richter wrote:
> On 12.01.17 16:05:36, Will Deacon wrote:
> > On Mon, Jan 09, 2017 at 12:53:20PM +0100, Robert Richter wrote:
>
> > > Kernel compile times (3 runs each):
> > >
> > > pfn_valid_within():
> > >
> > > real 6m4.088s
> > > user 372m57.607s
> > > sys 16m55.158s
> > >
> > > real 6m1.532s
> > > user 372m48.453s
> > > sys 16m50.370s
> > >
> > > real 6m4.061s
> > > user 373m18.753s
> > > sys 16m57.027s
> >
> > Did you reboot the machine between each build here, or only when changing
> > kernel? If the latter, do you see variations in kernel build time by simply
> > rebooting the same Image?
>
> I built it in a loop on the shell, so no reboots between builds. Note
> that I was building the kernel in /dev/shm to not access harddisks. I
> think build times should be comparable then since there is no fs
> caching.
I guess I'm really asking what the standard deviation is if you *do* reboot
between builds, using the same kernel. It's hard to tell whether the numbers
are due to the patches, or just because of noise incurred by the way things
happen to initialise.
Will
^ permalink raw reply
* [RFC 07/13] KVM: arm64: ITS: Change entry_size and indirect bit in BASER
From: Marc Zyngier @ 2017-01-13 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <89752a29-d533-1f4c-9e9b-93e8bd0556b3@redhat.com>
On 13/01/17 08:57, Auger Eric wrote:
> Hi Marc,
>
> On 12/01/2017 18:05, Marc Zyngier wrote:
>> On 12/01/17 15:56, Eric Auger wrote:
>>> Change the device table entry_size to 16 bytes instead of 8.
>>> We also Store the device and collection device in the its
>>> struct.
>>>
>>> The patch also clears the indirect bit for the device BASER.
>>> The indirect bit is set as read-only.
>>
>> Err... Why? We *really* want to continue supporting indirect tables, as
>> this is a massive memory saver for the guest.
>>
>>>
>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>>
>>> ---
>>>
>>> TODO: investigate support of 2 level tables, ie. enabling
>>> Indirect = 1. Support of 2 level tables is implementation
>>> defined.
>>
>> Clearly, that's a regression. What exactly is the issue that decided you
>> to disable it?
> Well no valuable reason besides I saw it was optional, lack of
> time/knowledge and a bit of laziness. I will address this requirement in
> my next respin.
Ah, I was worried about something much more fundamental! ;-)
> For my curiosity why did we choose not allowing the feature for
> collections. Is that just because we think their number if going
> sufficiently small compared to devices?
Collections are usually a much smaller number (directly related to the
number of CPUs in the system), and can be kept very compact. Devices, on
the other hand, can be extremely sparse (to the point where a guest can
fail to allocate enough memory to cover the required range).
TBH, we could allow it for collections as well. It is just not that useful.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Will Deacon @ 2017-01-13 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112232931-mutt-send-email-mst@kernel.org>
On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 11, 2017 at 10:01:39AM +0000, Will Deacon wrote:
> > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote:
> > > > From: Will Deacon <will.deacon@arm.com>
> > > >
> > > > Booting Linux on an ARM fastmodel containing an SMMU emulation results
> > > > in an unexpected I/O page fault from the legacy virtio-blk PCI device:
> > > >
> > > > [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > > > [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > > > [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > > > [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
> > > > [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > > > [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > > > [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > > > [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > > > [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
> > > > [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > > >
> > > > <system hangs failing to read partition table>
> > > >
> > > > This is because the virtio-blk is behind an SMMU, so we have consequently
> > > > swizzled its DMA ops and configured the SMMU to translate accesses. This
> > > > then requires the vring code to use the DMA API to establish translations,
> > > > otherwise all transactions will result in fatal faults and termination.
> > > >
> > > > Given that ARM-based systems only see an SMMU if one is really present
> > > > (the topology is all described by firmware tables such as device-tree or
> > > > IORT), then we can safely use the DMA API for all virtio devices.
> > > >
> > > > Cc: Andy Lutomirski <luto@kernel.org>
> > > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > >
> > > I'd like to better understand then need for this one.
> > > Can't the device in question just set VIRTIO_F_IOMMU_PLATFORM ?
> > >
> > > I'd rather we avoided need for more hacks and just
> > > have everyone switch to that.
> >
> > There are a couple of problems with VIRTIO_F_IOMMU_PLATFORM:
> >
> > 1. It doesn't exist for legacy devices, which are all we have on the
> > platform in question.
> >
> > 2. It's not documented in the virtio sp^H^HSTOP PRESS. I see you applied
> > my patch ;). Thanks.
> >
> > In which case, for non-legacy devices we should definitely be using
> > VIRTIO_F_IOMMU_PLATFORM, but since this platform hasn't yet moved to the
> > world of flying cars, could we unconditionally set the DMA ops on ARM
> > for legacy devices? The alternative is disabling the SMMU altogether,
> > but that's less than ideal because there are non-virtio devices on the
> > same PCI bus.
> >
>
> I'd rather people didn't use SMMU with legacy devices.
I'm afraid we've been doing that for two years and the model already
exists in a mature state, being actively used for development and
validation by ARM and our partners. One of the big things its used for
is to develop SMMU and GIC (our interrupt controller) code with PCI, so
dropping the SMMU from the picture isn't an option.
> Can't you guys just code up the virtio 1 layout in QEMU?
> I took a look and it's not a big deal now that two other
> transports converted, except mmio code in QEMU doesn't
> use linux header to it's a bit messy.
> I'll send a patch to clean that up.
If the model ever changes in this area (which isn't planned atm), the
right thing to do would be to move to modern virtio. However, we're stuck
with what we have for the forseeable future and it works just fine if we
use the DMA API. If we don't use it, Linux no longer boots because it
installs the SMMU-backed DMA ops for the virtio devices and everything
faults.
I really don't understand why this is controversial.
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