* [PATCH v2 4/6] ARM: dts: imx6: Add support for phxBOARD-Mira i.MX 6 DualLight/Solo RDK
From: Stefan Riedmueller @ 2017-12-20 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513776567-30182-1-git-send-email-s.riedmueller@phytec.de>
From: Christian Hemp <c.hemp@phytec.de>
Add support for the PHYTEC phyBOARD-Mira Low-Cost Rapid Development Kit
with i.MX 6DualLight/Solo with NAND.
Following interfaces are supported:
- 100 MBit Ethernet
- USB Host
- RS232
- HDMI
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Christ <s.christ@phytec.de>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts | 64 +++++++++++++++++++++++
2 files changed, 65 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b793617..07d99a1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -388,6 +388,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-icore-rqs.dtb \
imx6dl-nit6xlite.dtb \
imx6dl-nitrogen6x.dtb \
+ imx6dl-phytec-mira-rdk-nand.dtb \
imx6dl-phytec-pbab01.dtb \
imx6dl-rex-basic.dtb \
imx6dl-riotboard.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts b/arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts
new file mode 100644
index 0000000..f56c20f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2017 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-phytec-phycore-som.dtsi"
+#include "imx6qdl-phytec-mira.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Mira DualLite/Solo Carrier-Board with NAND";
+ compatible = "phytec,imx6dl-pbac06-nand", "phytec,imx6dl-pbac06",
+ "phytec,imx6qdl-pcm058", "fsl,imx6dl";
+
+ chosen {
+ linux,stdout-path = &uart2;
+ };
+};
+
+ðphy {
+ max-speed = <100>;
+};
+
+&fec {
+ status = "okay";
+};
+
+&gpmi {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbotg {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/6] ARM: dts: imx6: Add support for phyBOARD-Mira i.MX 6Quad/Dual RDK
From: Stefan Riedmueller @ 2017-12-20 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513776567-30182-1-git-send-email-s.riedmueller@phytec.de>
From: Christian Hemp <c.hemp@phytec.de>
Add support for the PHYTEC phyBOARD-Mira Rapid Development Kit with
i.MX 6Quad/Dual with eMMC or NAND.
Following interfaces are supported:
- Gigabit Ethernet
- USB Host
- CAN
- RS232
- PCIe
- LVDS
- HDMI
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Christ <s.christ@phytec.de>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts | 72 ++++++++++++++++++++++++
arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts | 72 ++++++++++++++++++++++++
3 files changed, 146 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts
create mode 100644 arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9..b793617 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -449,6 +449,8 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-nitrogen6_max.dtb \
imx6q-nitrogen6_som2.dtb \
imx6q-novena.dtb \
+ imx6q-phytec-mira-rdk-emmc.dtb \
+ imx6q-phytec-mira-rdk-nand.dtb \
imx6q-phytec-pbab01.dtb \
imx6q-pistachio.dtb \
imx6q-rex-pro.dtb \
diff --git a/arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts b/arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts
new file mode 100644
index 0000000..52000d5
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2017 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-phytec-phycore-som.dtsi"
+#include "imx6qdl-phytec-mira.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Mira Quad Carrier-Board with eMMC";
+ compatible = "phytec,imx6q-pbac06-emmc", "phytec,imx6q-pbac06",
+ "phytec,imx6qdl-pcm058", "fsl,imx6q";
+
+ chosen {
+ linux,stdout-path = &uart2;
+ };
+};
+
+&can1 {
+ status = "okay";
+};
+
+&fec {
+ status = "okay";
+};
+
+&flash {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+&pcie {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbotg {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
+
+&usdhc4 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts b/arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts
new file mode 100644
index 0000000..05f2d14
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2017 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-phytec-phycore-som.dtsi"
+#include "imx6qdl-phytec-mira.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Mira Quad Carrier-Board with NAND";
+ compatible = "phytec,imx6q-pbac06-nand", "phytec,imx6q-pbac06",
+ "phytec,imx6qdl-pcm058", "fsl,imx6q";
+
+ chosen {
+ linux,stdout-path = &uart2;
+ };
+};
+
+&can1 {
+ status = "okay";
+};
+
+&fec {
+ status = "okay";
+};
+
+&flash {
+ status = "okay";
+};
+
+&gpmi {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+&pcie {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbotg {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/6] ARM: dts: imx6: Add initial support for phyBOARD-Mira
From: Stefan Riedmueller @ 2017-12-20 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513776567-30182-1-git-send-email-s.riedmueller@phytec.de>
This patch adds basic support for PHYTEC phyBOARD-Mira as carrier board
for PHYTEC phyCORE-i.MX 6.
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Christ <s.christ@phytec.de>
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi | 390 +++++++++++++++++++++++++++++
1 file changed, 390 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi
new file mode 100644
index 0000000..45d8c0c
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi
@@ -0,0 +1,390 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2017 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+
+/ {
+ aliases {
+ rtc0 = &i2c_rtc;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ power-supply = <®_backlight>;
+ pwms = <&pwm1 0 5000000>;
+ status = "okay";
+ };
+
+ gpio_leds: leds {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpioleds>;
+ status = "disabled";
+
+ compatible = "gpio-leds";
+
+ red {
+ label = "phyboard-mira:red";
+ gpios = <&gpio5 22 GPIO_ACTIVE_HIGH>;
+ };
+
+ green {
+ label = "phyboard-mira:green";
+ gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>;
+ };
+
+ blue {
+ label = "phyboard-mira:blue";
+ gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ };
+ };
+
+ reg_backlight: regulator-backlight {
+ compatible = "regulator-fixed";
+ regulator-name = "backlight_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_en_switch: regulator-en-switch {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_en_switch>;
+ compatible = "regulator-fixed";
+ regulator-name = "Enable Switch";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ enable-active-high;
+ gpio = <&gpio3 4 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ };
+
+ reg_flexcan1: regulator-flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1_en>;
+ compatible = "regulator-fixed";
+ regulator-name = "flexcan1-reg";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ gpio = <&gpio2 20 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_panel: regulator-panel {
+ compatible = "regulator-fixed";
+ regulator-name = "panel-power-supply";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_pcie: regulator-pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie_reg>;
+ compatible = "regulator-fixed";
+ regulator-name = "mPCIe_1V5";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ gpio = <&gpio3 0 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usb_h1_vbus: usb-h1-vbus {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh1_vbus>;
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usbotg_vbus: usbotg-vbus {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg_vbus>;
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ panel {
+ compatible = "auo,g104sn02";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_panel_en>;
+ power-supply = <®_panel>;
+ enable-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>;
+
+ backlight = <&backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ xceiver-supply = <®_flexcan1>;
+ status = "disabled";
+};
+
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmicec>;
+ ddc-i2c-bus = <&i2c2>;
+ status = "disabled";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ clock-frequency = <400000>;
+ status = "disabled";
+
+ stmpe: touchctrl at 44 {
+ compatible = "st,stmpe811";
+ reg = <0x44>;
+ interrupt-parent = <&gpio7>;
+ interrupts = <12 IRQ_TYPE_NONE>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_stmpe>;
+ status = "disabled";
+
+ stmpe_touchscreen {
+ compatible = "st,stmpe-ts";
+ st,sample-time = <4>;
+ st,mod-12b = <1>;
+ st,ref-sel = <0>;
+ st,adc-freq = <1>;
+ st,ave-ctrl = <1>;
+ st,touch-det-delay = <2>;
+ st,settling = <2>;
+ st,fraction-z = <7>;
+ st,i-drive = <1>;
+ };
+ };
+
+ i2c_rtc: rtc at 68 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rtc_int>;
+ compatible = "microcrystal,rv4162";
+ reg = <0x68>;
+ interrupt-parent = <&gpio7>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ clock-frequency = <100000>;
+ status = "disabled";
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel at 0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "disabled";
+
+ port at 4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie>;
+ reset-gpio = <&gpio2 25 GPIO_ACTIVE_LOW>;
+ vpcie-supply = <®_pcie>;
+ status = "disabled";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ uart-has-rtscts;
+ status = "disabled";
+};
+
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ disable-over-current;
+ status = "disabled";
+};
+
+&usbotg {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ vbus-supply = <®_usbotg_vbus>;
+ disable-over-current;
+ status = "disabled";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio6 31 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_panel_en: panelen1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_EB0__GPIO2_IO28 0xb0b1
+ >;
+ };
+
+ pinctrl_en_switch: enswitchgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_DA4__GPIO3_IO04 0xb0b1
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
+ MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
+ >;
+ };
+
+ pinctrl_flexcan1_en: flexcan1engrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_A18__GPIO2_IO20 0xb0b1
+ >;
+ };
+
+ pinctrl_gpioleds: gpioledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT4__GPIO5_IO22 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT5__GPIO5_IO23 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT6__GPIO5_IO24 0x1b0b0
+ >;
+ };
+
+ pinctrl_hdmicec: hdmicecgrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_pcie: pciegrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__GPIO2_IO25 0xb0b1
+ >;
+ };
+
+ pinctrl_pcie_reg: pciereggrp {
+ fsl,pins = <MX6QDL_PAD_EIM_DA0__GPIO3_IO00 0xb0b1>;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_9__PWM1_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_rtc_int: rtcintgrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_RST__GPIO7_IO08 0x1b0b0
+ >;
+ };
+
+ pinctrl_stmpe: stmpegrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D26__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_EB3__UART3_CTS_B 0x1b0b1
+ MX6QDL_PAD_EIM_D23__UART3_RTS_B 0x1b0b1
+ MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbh1_vbus: usbh1vbusgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_A20__GPIO2_IO18 0xb0b1
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
+ >;
+ };
+
+ pinctrl_usbotg_vbus: usbotgvbusgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_A19__GPIO2_IO19 0xb0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x170f9
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100f9
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170f9
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170f9
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170f9
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170f9
+ MX6QDL_PAD_EIM_BCLK__GPIO6_IO31 0xb0b1 /* CD */
+ >;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/6] ARM: dts: imx6: Add initial support for phyCORE-i.MX 6 SOM
From: Stefan Riedmueller @ 2017-12-20 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513776567-30182-1-git-send-email-s.riedmueller@phytec.de>
This patch adds basic support for PHYTEC phyCORE-i.MX 6 SOM with i.MX
6Quad/Dual or i.MX 6DualLight/Solo.
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Christ <s.christ@phytec.de>
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi | 282 ++++++++++++++++++++++
1 file changed, 282 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
new file mode 100644
index 0000000..8501ac6
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
@@ -0,0 +1,282 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2017 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "PHYTEC phyCORE-i.MX 6";
+ compatible = "phytec,imx6qdl-pcm058", "fsl,imx6qdl";
+
+ aliases {
+ rtc1 = &da9062_rtc;
+ rtc2 = &snvs_rtc;
+ };
+
+ /*
+ * Set the minimum memory size here and
+ * let the bootloader set the real size.
+ */
+ memory at 10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x8000000>;
+ };
+
+ gpio_leds_som: somleds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpioleds_som>;
+
+ som_green {
+ label = "phycore:green";
+ gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&ecspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ flash: flash at 0 {
+ compatible = "m25p80";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ status = "disabled";
+ };
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-handle = <ðphy>;
+ phy-mode = "rgmii";
+ phy-supply = <&vdd_eth_io>;
+ phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>;
+ status = "disabled";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy: ethernet-phy at 3 {
+ reg = <3>;
+ txc-skew-ps = <1680>;
+ rxc-skew-ps = <1860>;
+ };
+ };
+};
+
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ nand-on-flash-bbt;
+ status = "disabled";
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ clock-frequency = <400000>;
+ status = "okay";
+
+ eeprom: eeprom at 50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
+
+ pmic0: pmic at 58 {
+ compatible = "dlg,da9062";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ reg = <0x58>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+
+ da9062_rtc: rtc {
+ compatible = "dlg,da9062-rtc";
+ };
+
+ da9062_wdt: watchdog {
+ compatible = "dlg,da9062-watchdog";
+ };
+
+ da9062_reg: regulators {
+ vdd_arm: buck1 {
+ regulator-name = "vdd_arm";
+ regulator-min-microvolt = <730000>;
+ regulator-max-microvolt = <1380000>;
+ regulator-always-on;
+ };
+
+ vdd_soc: buck2 {
+ regulator-name = "vdd_soc";
+ regulator-min-microvolt = <730000>;
+ regulator-max-microvolt = <1380000>;
+ regulator-always-on;
+ };
+
+ vdd_ddr3_1p5: buck3 {
+ regulator-name = "vdd_ddr3";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ };
+
+ vdd_eth_1p2: buck4 {
+ regulator-name = "vdd_eth";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ };
+
+ vdd_snvs: ldo1 {
+ regulator-name = "vdd_snvs";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+
+ vdd_high: ldo2 {
+ regulator-name = "vdd_high";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+
+ vdd_eth_io: ldo3 {
+ regulator-name = "vdd_eth_io";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+
+ vdd_emmc_1p8: ldo4 {
+ regulator-name = "vdd_emmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
+ };
+};
+
+®_arm {
+ vin-supply = <&vdd_arm>;
+};
+
+®_pu {
+ vin-supply = <&vdd_soc>;
+};
+
+®_soc {
+ vin-supply = <&vdd_soc>;
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&usdhc4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc4>;
+ bus-width = <8>;
+ non-removable;
+ vmmc-supply = <&vdd_emmc_1p8>;
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
+ MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
+ MX6QDL_PAD_SD2_DAT1__GPIO1_IO14 0x1b0b0
+ >;
+ };
+
+ pinctrl_gpioleds_som: gpioledssomgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1b0b0
+ >;
+ };
+
+ pinctrl_gpmi_nand: gpminandgrp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CLE__NAND_CLE 0xb0b1
+ MX6QDL_PAD_NANDF_ALE__NAND_ALE 0xb0b1
+ MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0xb0b1
+ MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0xb000
+ MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0xb0b1
+ MX6QDL_PAD_NANDF_CS1__NAND_CE1_B 0xb0b1
+ MX6QDL_PAD_NANDF_CS2__NAND_CE2_B 0xb0b1
+ MX6QDL_PAD_NANDF_CS3__NAND_CE3_B 0xb0b1
+ MX6QDL_PAD_SD4_CMD__NAND_RE_B 0xb0b1
+ MX6QDL_PAD_SD4_CLK__NAND_WE_B 0xb0b1
+ MX6QDL_PAD_NANDF_D0__NAND_DATA00 0xb0b1
+ MX6QDL_PAD_NANDF_D1__NAND_DATA01 0xb0b1
+ MX6QDL_PAD_NANDF_D2__NAND_DATA02 0xb0b1
+ MX6QDL_PAD_NANDF_D3__NAND_DATA03 0xb0b1
+ MX6QDL_PAD_NANDF_D4__NAND_DATA04 0xb0b1
+ MX6QDL_PAD_NANDF_D5__NAND_DATA05 0xb0b1
+ MX6QDL_PAD_NANDF_D6__NAND_DATA06 0xb0b1
+ MX6QDL_PAD_NANDF_D7__NAND_DATA07 0xb0b1
+ MX6QDL_PAD_SD4_DAT0__NAND_DQS 0x00b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
+ MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
+ MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
+ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x1b0b0
+ >;
+ };
+
+ pinctrl_pmic: pmicgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ >;
+ };
+
+ pinctrl_usdhc4: usdhc4grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_CMD__SD4_CMD 0x17059
+ MX6QDL_PAD_SD4_CLK__SD4_CLK 0x10059
+ MX6QDL_PAD_SD4_DAT0__SD4_DATA0 0x17059
+ MX6QDL_PAD_SD4_DAT1__SD4_DATA1 0x17059
+ MX6QDL_PAD_SD4_DAT2__SD4_DATA2 0x17059
+ MX6QDL_PAD_SD4_DAT3__SD4_DATA3 0x17059
+ MX6QDL_PAD_SD4_DAT4__SD4_DATA4 0x17059
+ MX6QDL_PAD_SD4_DAT5__SD4_DATA5 0x17059
+ MX6QDL_PAD_SD4_DAT6__SD4_DATA6 0x17059
+ MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
+ >;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/6] ARM: dts: Add PHYTEC phyCORE-i.MX 6 and phyBOARD-Mira carrier board support
From: Stefan Riedmueller @ 2017-12-20 13:29 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for the PHYTEC phyCORE-i.MX 6 and phyBOARD-Mira.
Following boards are included:
phyBOARD-Mira with phyCORE-i.MX 6 Quad/Dual with:
- i.MX 6Quad/Dual SOC
- NAND or eMMC
- HDMI interface
- LVDS display interface
- Gigabit Ethernet
- USB Host
- CAN
- RS232
- PCIe
This board also contains an LVDS camera interface and parallel display
interface which are not yet supported.
phyBAORD-Mira with phyCORE-i.MX 6 DualLight/Solo with:
- i.MX 6DualLight/Solo
- NAND
- HDMI interface
- 100 MBit/s Ethernet
- USB Host
- RS232
phyBOARD-Mira with phyCORE-i.MX 6 QuadPlus with:
- i.MX 6QuadPlus SOC
- NAND
- HDMI interface
- LVDS display interface
- Gigabit Ethernet
- USB Host
- CAN
- RS232
- PCIe
This board also contains an LVDS camera interface and parallel display
interface which are not yet supported.
The entire series is based on v4.15-rc4.
Changes since v1:
- Removed unnecessary ipu aliases
- Added unit-address to memory node name
- Fixed eeprom compatible to correct vendor name (atmel instead of cat)
- Fixed rtc compatible to correct vendor name (microcrystal instead of mc)
- Changed pcie regulator to be used with vpcie-supply in &pcie node and
removed regulator-always-on
- Changed pcie reset-gpio polarity to GPIO_ACTIVE_LOW
- Replaced fsl,uart-has-rtscts by uart-has-rtscts
- Fixed typos in defconfig patch
Christian Hemp (2):
ARM: dts: imx6: Add support for phyBOARD-Mira i.MX 6Quad/Dual RDK
ARM: dts: imx6: Add support for phxBOARD-Mira i.MX 6 DualLight/Solo
RDK
Enrico Scholz (1):
ARM: dts: imx6: Add support for phyBOARD-Mira with i.MX 6QuadPlus
Stefan Riedmueller (3):
ARM: dts: imx6: Add initial support for phyCORE-i.MX 6 SOM
ARM: dts: imx6: Add initial support for phyBOARD-Mira
ARM: imx_v6_v7_defconfig: Enable Dialog Semiconductor DA9062 driver
arch/arm/boot/dts/Makefile | 4 +
arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts | 64 ++++
arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts | 72 ++++
arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts | 72 ++++
arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi | 390 ++++++++++++++++++++++
arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi | 282 ++++++++++++++++
arch/arm/boot/dts/imx6qp-phytec-mira-rdk-nand.dts | 72 ++++
arch/arm/configs/imx_v6_v7_defconfig | 4 +
8 files changed, 960 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts
create mode 100644 arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts
create mode 100644 arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
create mode 100644 arch/arm/boot/dts/imx6qp-phytec-mira-rdk-nand.dts
--
2.7.4
^ permalink raw reply
* [PATCH 2/2] arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
From: Vladimir Zapolskiy @ 2017-12-20 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513776132-22700-1-git-send-email-vladimir_zapolskiy@mentor.com>
From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
The present change is a bug fix for AVB link iteratively up/down.
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
the RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the present change is also a safety improvement because
it removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi b/arch/arm64/boot/dts/renesas/ulcb.dtsi
index be91016e0b48..3e7a6b94e9f8 100644
--- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -145,7 +145,6 @@
&avb {
pinctrl-0 = <&avb_pins>;
pinctrl-names = "default";
- renesas,no-ether-link;
phy-handle = <&phy0>;
status = "okay";
--
2.8.1
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: renesas: salvator-x: Remove renesas, no-ether-link property
From: Vladimir Zapolskiy @ 2017-12-20 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513776132-22700-1-git-send-email-vladimir_zapolskiy@mentor.com>
From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
The present change is a bug fix for AVB link iteratively up/down.
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
the RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the present change is also a safety improvement because
it removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 4e800e933944..c3095bd575d7 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -255,7 +255,6 @@
&avb {
pinctrl-0 = <&avb_pins>;
pinctrl-names = "default";
- renesas,no-ether-link;
phy-handle = <&phy0>;
status = "okay";
--
2.8.1
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: renesas: Remove renesas, no-ether-link property
From: Vladimir Zapolskiy @ 2017-12-20 13:22 UTC (permalink / raw)
To: linux-arm-kernel
The present change is a bug fix for AVB link iteratively up/down.
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
the RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the change is also a safety improvement because it
removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Note that DTS files for V3M Starter Kit, Draak and Eagle boards
contain the same property, the files are untouched due to unavailable
schematics to verify if the fix applies to these boards as well.
Bogdan Mirea (2):
arm64: dts: renesas: salvator-x: Remove renesas,no-ether-link property
arm64: dts: renesas: ulcb: Remove renesas,no-ether-link property
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 -
arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
2 files changed, 2 deletions(-)
--
2.8.1
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Lukasz Majewski @ 2017-12-20 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaAYLd6ZcBXQP_SfA1dTyyb4kjOpGoW5DUBgH_9pDDtQQ@mail.gmail.com>
Hi Linus,
> On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski <lukma@denx.de>
> wrote:
> >> On Wed Dec 13 08:34:22 2017 Linus Walleij
> >> <linus.walleij@linaro.org> wrote:
> >> > On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski <lukma@denx.de>
> >> > wrote: Out of curiosity: Liebherr is obviously doing heavy-duty
> >> > industrial control systems. Likewise Hartley is doing similar
> >> > business over at Vision Engravings.
> >> >
> >> > Is the situation such that there is a whole bunch of industrial
> >> > systems out there, in active use and needing future upgrades,
> >> > that use the EP93xx?
> >>
> >> That's definitely the case. I'm as well aware of several thousands
> >> of industrial devices which are expected to run 24/7 for the next 5
> >> years at least. And they are updated from time to time.
> >
> > I can agree with this statement.
>
> OK I'm coloring this platform with a highlight for ARM32 maintenance.
>
> >> > Arnd has been nudging me to do DT conversion for EP93xx
> >> > so if there are many active industrial users of these
> >> > I should prioritize it, because these things have 20+ years
> >> > support cycles.
> >>
> >> I'm not sure how important or necessary at all is to change
> >> anything in these legacy platforms.
> >
> > +1
>
> That is an understandable conservative stance.
>
> There is a fine line between "it works, don't touch it" and
> "modernize the ARM32 ecosystem".
There may be a more pragmatic reason. If those boards are deployed
(widely) in the industry - there may be a problem with re-validation of
the SW.
>
> There is a point where supporting old board files will stand in
> the way and cost a lot in maintenance (like moving drivers our
> of arch/arm, or modernizing misc subsystems). Then moving the
> platform over to device tree should be preferred.
With my limited experience - those platforms have more similarities to
x86. Multiplatform may be the goal here....
>
> > I'm using OE to build toolchain (SDK). I can confirm that gcc 7.2
> > works with it.
> >
> > And yes, armv4 support shall be preserved in GCC ....
I should have be more peculiar - this is armv4t (arm920t)
>
> Yes that is the same toochain I use.
>
> Yours,
> Linus Walleij
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171220/7d527241/attachment.sig>
^ permalink raw reply
* [PATCH v3 14/19] KVM: arm/arm64: Move HYP IO VAs to the "idmap" range
From: Steve Capper @ 2017-12-20 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218173926.16911-15-marc.zyngier@arm.com>
Hi Marc,
On Mon, Dec 18, 2017 at 05:39:21PM +0000, Marc Zyngier wrote:
> We so far mapped our HYP IO (which is essencially the GICv2 control
> registers) using the same method as for memory. It recently appeared
> that is a bit unsafe:
>
> we compute the HYP VA using the kern_hyp_va helper, but that helper
> is only designed to deal with kernel VAs coming from the linear map,
> and not from the vmalloc region... This could in turn cause some bad
> aliasing between the two, amplified by the new VA randomisation.
>
> A solution is to come up with our very own basic VA allocator for
> MMIO. Since half of the HYP address space only contains a single
> page (the idmap), we have plenty to borrow from. Let's use the idmap
> as a base, and allocate downwards from it. GICv2 now lives on the
> other side of the great VA barrier.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> virt/kvm/arm/mmu.c | 40 ++++++++++++++++++++++++++++------------
> 1 file changed, 28 insertions(+), 12 deletions(-)
>
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index 6192d45d1e1a..0597c9846f1a 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
[...]
> @@ -721,7 +728,8 @@ int create_hyp_io_mappings(phys_addr_t phys_addr, size_t size,
> void __iomem **kaddr,
> void __iomem **haddr)
> {
> - unsigned long start, end;
> + pgd_t *pgd = hyp_pgd;
> + unsigned long base;
> int ret;
>
> *kaddr = ioremap(phys_addr, size);
> @@ -733,19 +741,26 @@ int create_hyp_io_mappings(phys_addr_t phys_addr, size_t size,
> return 0;
> }
>
> + mutex_lock(&io_map_lock);
> +
> + base = io_map_base - size;
> + base &= ~(size - 1);
> +
Is it worth checking to see if we have "escaped" from our half of the
HYP region?
So something like?
if (base ^ io_map_base & BIT(VA_BITS - 1))
allocationFailed...
> + if (__kvm_cpu_uses_extended_idmap())
> + pgd = boot_hyp_pgd;
>
> - start = kern_hyp_va((unsigned long)*kaddr);
> - end = kern_hyp_va((unsigned long)*kaddr + size);
> - ret = __create_hyp_mappings(hyp_pgd, start, end,
> + ret = __create_hyp_mappings(pgd, base, base + size,
> __phys_to_pfn(phys_addr), PAGE_HYP_DEVICE);
>
> if (ret) {
> iounmap(*kaddr);
> *kaddr = NULL;
> } else {
> - *haddr = (void __iomem *)start;
> + *haddr = (void __iomem *)base;
> + io_map_base = base;
> }
>
> + mutex_unlock(&io_map_lock);
> return ret;
> }
>
> @@ -1826,6 +1841,7 @@ int kvm_mmu_init(void)
> goto out;
> }
>
> + io_map_base = hyp_idmap_start;
> return 0;
> out:
> free_hyp_pgds();
> --
> 2.14.2
>
^ permalink raw reply
* [PATCH v2 3/8] media: v4l2-async: simplify v4l2_async_subdev structure
From: Lad, Prabhakar @ 2017-12-20 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9702fbf0c9dd2f6a657aff0c7fff3ca849d76713.1513682135.git.mchehab@s-opensource.com>
Hi Mauro,
Thanks for the patch.
On Tue, Dec 19, 2017 at 11:18 AM, Mauro Carvalho Chehab
<mchehab@s-opensource.com> wrote:
> The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one
> struct to be filled (struct fwnode_handle). The V4L2_ASYNC_MATCH_DEVNAME
> match criteria requires just a device name.
>
> So, it doesn't make sense to enclose those into structs,
> as the criteria can go directly into the union.
>
> That makes easier to document it, as we don't need to document
> weird senseless structs.
>
> At drivers, this makes even clearer about the match criteria.
>
> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Acked-by: Benoit Parrot <bparrot@ti.com>
> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> drivers/media/platform/am437x/am437x-vpfe.c | 6 +++---
For above:
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Cheers,
--Prabhakar Lad
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Lukasz Majewski @ 2017-12-20 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a22-Q6Ksqh3eeoq-iLcs9PA2kZ12Cjp5ibPUKvU8dhbrw@mail.gmail.com>
Hi Arnd,
> On Wed, Dec 20, 2017 at 1:33 PM, Linus Walleij
> <linus.walleij@linaro.org> wrote:
> > On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski <lukma@denx.de>
> > wrote:
>
> >
> > There is a point where supporting old board files will stand in
> > the way and cost a lot in maintenance (like moving drivers our
> > of arch/arm, or modernizing misc subsystems). Then moving the
> > platform over to device tree should be preferred.
>
> I'm generally more interested in the multiplatform conversion than
> the DT conversion, and I think converting this one to multiplatform
> isn't actually that hard, and doesn't have a significant risk for
> regressions, the main work is to convert the clock handling.
Maybe we need some kind of a schedule (or roadmap)?
>
> Arnd
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171220/c753049a/attachment.sig>
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Arnd Bergmann @ 2017-12-20 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513774853.1538.15.camel@Nokia-N900>
On Wed, Dec 20, 2017 at 2:00 PM, Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
> Hi!
>
> On Wed Dec 20 13:50:28 2017 Arnd Bergmann <arnd@arndb.de> wrote:
>> I'm generally more interested in the multiplatform conversion than
>> the DT conversion, and I think converting this one to multiplatform
>> isn't actually that hard, and doesn't have a significant risk for
>> regressions, the main work is to convert the clock handling.
>
> If it will be still possible to build the binary kernel of the same size after the
> conversion, I'm in for testing, otherwise it will not fit into Flash any more...
I think there is an increase in code size that comes mainly from the
common clock layer itself, plus a few bytes here and there. Obviously
the increase is much bigger if you actually enable multiple platforms.
Here is the size of the uncompressed vmlinux file with the current
clk implementation, compared to a build with a build containing the
common clk code but no clock driver, and the separate clock
implementation we have today:
text data bss dec hex filename
4752655 1036028 128260 5916943 5a490f build/tmp/vmlinux-old-clk
4780174 1040524 128284 5948982 5ac636 build/tmp/vmlinux-common-clk
2491 1700 0 4191 105f build/tmp/arch/arm/mach-ep93xx/clock.o
The difference would come to about 0.7% of the current image size,
I guess around 1% when the other changes are included. Is that within
the margins you have, or is this already critical?
Arnd
^ permalink raw reply
* [PATCH] irqchip/gic-v3-its: Flush GICR caching for a cross node collection move of an irq
From: Marc Zyngier @ 2017-12-20 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKTKpr47HZmoShXvAG5d4DZQORvrMccdaL8-mEWmpEsNMX5_3w@mail.gmail.com>
On 20/12/17 09:34, Ganapatrao Kulkarni wrote:
> Hi Marc,
>
> On Wed, Dec 20, 2017 at 2:56 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On 20/12/17 09:15, Ganapatrao Kulkarni wrote:
>>> When an interrupt is moved, it is possible that an implementation that
>>> supports caching might still have cached data for a previous
>>> (no longer valid) mapping of the interrupt. In particular, in a distributed
>>> GIC implementation like multi-socket SoC platfroms. Hence it is necessary
>>> to flush cached entries after cross node collection migration.
>>>
>>> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
>>> ---
>>> drivers/irqchip/irq-gic-v3-its.c | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>>> index 4039e64..ea849a1 100644
>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>> @@ -1119,6 +1119,12 @@ static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
>>> if (cpu != its_dev->event_map.col_map[id]) {
>>> target_col = &its_dev->its->collections[cpu];
>>> its_send_movi(its_dev, target_col, id);
>>> + /* Issue INV for cross node collection move on
>>> + * multi socket systems.
>>> + */
>>> + if (cpu_to_node(cpu) !=
>>> + cpu_to_node(its_dev->event_map.col_map[id]))
>>> + its_send_inv(its_dev, id);
>>> its_dev->event_map.col_map[id] = cpu;
>>> irq_data_update_effective_affinity(d, cpumask_of(cpu));
>>> }
>>>
>>
>> The MOVI command doesn't have any such requirement (it only mandates
>> synchronization), and doesn't say anything about distributed vs monolithic.
>
> GIC-v3 spec do mention to issue ITS INV command or a write to GICR_INVLPIR.
> pasting below snippet of MOVI command description.
>
> "When an interrupt is moved to a collection, it is possible that an
> implementation that supports speculative caching
> might still have cached data for a previous (no longer valid) mapping
> of the interrupt. Hence, implementations
> must take care to invalidate any data associated with an interrupt
> when it is moved. In particular, in a distributed
> implementation, the ITS must write to the appropriate GICR_* register
> to perform the invalidation in the redistributor."
Doing some documentation archaeology, I found that this wording has been
dropped from the engineering specification in August 2014, and was never
included in the architecture specification. I suggest you start using a
slightly more up-to-date set of documentation...
Now, back to your point: what it says in the bit of (confidential)
document that you quoted is that the *HW* must perform the invalidation
(that's what the words "implementations" and "ITS" refer to), not some
random bits of SW.
If you know of an implementation that suffers from this, please resend a
patch that handles this as a quirk, with a proper erratum number.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v1] mfd: ab8500: introduce DEFINE_SHOW_ATTRIBUTE() macro
From: Lee Jones @ 2017-12-20 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214105121.77015-1-andriy.shevchenko@linux.intel.com>
On Thu, 14 Dec 2017, Andy Shevchenko wrote:
> This macro deduplicates a lot of similar code in the ab8500-debugfs.c module.
> Targeting to be moved to seq_file.h eventually.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/mfd/ab8500-debugfs.c | 406 +++++++------------------------------------
> 1 file changed, 62 insertions(+), 344 deletions(-)
Applied, thanks.
--
Lee Jones
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Alexander Sverdlin @ 2017-12-20 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a22-Q6Ksqh3eeoq-iLcs9PA2kZ12Cjp5ibPUKvU8dhbrw@mail.gmail.com>
Hi!
On Wed Dec 20 13:50:28 2017 Arnd Bergmann <arnd@arndb.de> wrote:
> I'm generally more interested in the multiplatform conversion than
> the DT conversion, and I think converting this one to multiplatform
> isn't actually that hard, and doesn't have a significant risk for
> regressions, the main work is to convert the clock handling.
If it will be still possible to build the binary kernel of the same size after the conversion, I'm in for testing, otherwise it will not fit into Flash any more...
--
Alex.
^ permalink raw reply
* [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc
From: Arnd Bergmann @ 2017-12-20 13:00 UTC (permalink / raw)
To: linux-arm-kernel
gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
meaning that this is expected to be removed at some point in the future,
with gcc-8.0 as the earliest.
When building the kernel, the difference between ARMv4 and ARMv4T
is relatively small because the kernel never runs THUMB instructions
on ARMv4T and does not need any support for interworking.
For any future compiler that does not support -march=armv4, we now
fall back to -march=armv4t as the architecture level selection,
but keep using -march=armv4 by default as long as that is supported
by the compiler.
Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
will go away at the same time as -march=armv4, so this adds a check
to see if the compiler supports them, falling back to no -mtune
option otherwise.
Compiling with -march=armv4t leads the compiler to using 'bx reg'
instructions instead of 'mov pc,reg'. This is not supported on
ARMv4 based CPUs, but the linker can work around this by rewriting
those instructions to the ARMv4 version if we pass --fix-v4bx
to the linker. This should work with binutils-2.15 (released
May 2004) or higher, and we can probably assume that anyone using
gcc-7.x will have a much more recent binutils version as well.
However, in order to still allow users of old toolchains to link
the kernel, we only pass the option to linkers that support it,
based on a $(ld-option ...) call. I'm intentionally passing the
flag to all linker versions here regardless of whether it's needed
or not, so we can more easily spot any regressions if something
goes wrong.
For consistency, I'm passing the --fix-v4bx flag for both the
vmlinux final link and the individual loadable modules.
The module loader code already interprets the R_ARM_V4BX relocations
in loadable modules and converts bx instructions into mov even
when running on ARMv4T or ARMv5 processors. This is now redundant
when we pass --fix-v4bx to the linker for building modules, but
I see no harm in leaving the current implementation and doing both.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Please test by making the -march=armv4t switch unconditional
and see if that results in a working kernel
arch/arm/Makefile | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e83f5161fdd8..33b7eb4502aa 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -19,6 +19,11 @@ LDFLAGS_vmlinux += --be8
KBUILD_LDFLAGS_MODULE += --be8
endif
+ifeq ($(CONFIG_CPU_32v4),y)
+LDFLAGS_vmlinux += $(call ld-option,--fix-v4bx)
+LDFLAGS_MODULE += $(call ld-option,--fix-v4bx)
+endif
+
ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm/kernel/module.lds
endif
@@ -76,7 +81,7 @@ arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,
endif
arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t)
arch-$(CONFIG_CPU_32v4T) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
-arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 -march=armv4
+arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 $(call cc-option,-march=armv4,-march=armv4t)
arch-$(CONFIG_CPU_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3
# Evaluate arch cc-option calls now
@@ -94,8 +99,8 @@ tune-$(CONFIG_CPU_ARM922T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM925T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM926T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_FA526) =-mtune=arm9tdmi
-tune-$(CONFIG_CPU_SA110) =-mtune=strongarm110
-tune-$(CONFIG_CPU_SA1100) =-mtune=strongarm1100
+tune-$(CONFIG_CPU_SA110) =$(call cc-option,-mtune=strongarm110)
+tune-$(CONFIG_CPU_SA1100) =$(call cc-option,-mtune=strongarm1100)
tune-$(CONFIG_CPU_XSCALE) =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
tune-$(CONFIG_CPU_XSC3) =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
tune-$(CONFIG_CPU_FEROCEON) =$(call cc-option,-mtune=marvell-f,-mtune=xscale)
--
2.9.0
^ permalink raw reply related
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Arnd Bergmann @ 2017-12-20 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda8xPuVHpBvX6_Ez+ztn4neVZ+=x=AEWmHJyZgww-1jHg@mail.gmail.com>
On Wed, Dec 20, 2017 at 1:48 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Dec 18, 2017 at 12:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski <lukma@denx.de> wrote:
>>>> It would also be helpful
>>>> to test whether the -march=armv4t/--fix-v4bx workaround produces
>>>> working binaries for you, in that case you could report to the gcc
>>>> developers that the removal of armv4 can continue but that
>>>> the --fix-v4bx option in ld needs to stay around.
>>>
>>> I may ask this issue on OE/Yocto mailing list as well....
>>
>> To clarify, the only affected platforms are those based on either
>> DEC/Intel StrongARM or Faraday FA526, i.e. EBSA-110,
>> FootBridge, RPC, SA1100, Moxart and Gemini.
>
> It's a bit unfortunate since there are users and active contributors to
> these architectures, I think the OE community is being missed out
> just because they "are not Debian". :/
IIRC, OE already uses the --fix-v4bx workaround. I had an older patch
to do the same in the kernel, let me resend it now, so you can try it
and see if that works for you.
Arnd
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Arnd Bergmann @ 2017-12-20 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaAYLd6ZcBXQP_SfA1dTyyb4kjOpGoW5DUBgH_9pDDtQQ@mail.gmail.com>
On Wed, Dec 20, 2017 at 1:33 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski <lukma@denx.de> wrote:
>
> There is a point where supporting old board files will stand in
> the way and cost a lot in maintenance (like moving drivers our
> of arch/arm, or modernizing misc subsystems). Then moving the
> platform over to device tree should be preferred.
I'm generally more interested in the multiplatform conversion than
the DT conversion, and I think converting this one to multiplatform
isn't actually that hard, and doesn't have a significant risk for
regressions, the main work is to convert the clock handling.
Arnd
^ permalink raw reply
* [PATCH 1/9] ARM: enable secure platform-only erratas
From: Dmitry Osipenko @ 2017-12-20 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219232810.GI10595@n2100.armlinux.org.uk>
On 20.12.2017 02:28, Russell King - ARM Linux wrote:
> On Thu, Oct 05, 2017 at 09:16:12PM +0300, Dmitry Osipenko wrote:
>> On 20.07.2017 03:29, Micha? Miros?aw wrote:
>>> Allow secure-only erratas to be used in multiarch kernel.
>>>
>>> Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
>>> ---
>>> arch/arm/Kconfig | 20 ++++++++++++++------
>>> 1 file changed, 14 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index a208bfe367b5..a1eff866550b 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -696,6 +696,14 @@ config ARCH_MULTI_CPU_AUTO
>>>
>>> endmenu
>>>
>>> +config ARCH_ASSUME_SECURE_PLATFORM
>>> + bool "Enable ERRATAs using secure-only registers"
>>> + default !ARCH_MULTIPLATFORM
>>
>> I think default should always be "Yes" and this option shouldn't affect
>> multiplatform kernels. So a multiplatform kernel wouldn't be an option
>> for your device.
>
> No, that changes the current behaviour.
>
> Current behaviour is for the secure-only errata to be disabled when the
> multi-platform option is enabled, because multi-platform kernels have to
> be able to run in the non-secure world. Defaulting this option to "yes"
> means that these errata become visible.
Indeed, I got it inverted.
> I have to wonder why you need this though - your patches seem to be
> targetting a platform that runs in non-secure world, and enabling these
> errata would make the kernel non-bootable on your platform.
Perhaps because Micha? made the Tegra's CPU reset handler hardcoded to either
secure or to non-secure case based on the kernels configuration. I've showed how
we can get rid of that inflexibility in [0], maybe Micha? could pick up the idea
in the next iteration of the patches.
[0] https://marc.info/?l=linux-tegra&m=151371042522835
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Linus Walleij @ 2017-12-20 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a3VJapioU32oBtA2GDmvXiHvz3K=W6BGx+u=Tvb1aDXsg@mail.gmail.com>
On Mon, Dec 18, 2017 at 12:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski <lukma@denx.de> wrote:
>>> On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski <lukma@denx.de>
>>> wrote:
>>> >> >> We also need to think about upholding support in GCC for
>>> >> >> ARMv4(t) for the foreseeable future if there is a big web of
>>> >> >> random deeply embedded systems out there that will need
>>> >> >> updates.
>>> >> >
>>> >> > But we should definitely preserve at least what we have.
>>> >>
>>> >> Plain ARMv4 (and earlier) support in gcc is already marked
>>> >> 'deprecated' and will likely be gone in gcc-8 (it's still there as
>>> >> of last week). ARMv4T is going to be around for a while, and you
>>> >> can even keep building for ARMv4 using "-march=armv4t -marm" when
>>> >> linking with 'ld --fix-v4bx'.
>>> >
>>> > I think that we shall start complaining on the gcc-devel mailing
>>> > list now.
>>> >
>>> > I would be hard to wake up in 2 years time and realise that we don't
>>> > have a modern compiler.
(...)
>>> It would also be helpful
>>> to test whether the -march=armv4t/--fix-v4bx workaround produces
>>> working binaries for you, in that case you could report to the gcc
>>> developers that the removal of armv4 can continue but that
>>> the --fix-v4bx option in ld needs to stay around.
>>
>> I may ask this issue on OE/Yocto mailing list as well....
>
> To clarify, the only affected platforms are those based on either
> DEC/Intel StrongARM or Faraday FA526, i.e. EBSA-110,
> FootBridge, RPC, SA1100, Moxart and Gemini.
It's a bit unfortunate since there are users and active contributors to
these architectures, I think the OE community is being missed out
just because they "are not Debian". :/
Even NetWinder.org is still up and kicking.
Some of it may be nostalgia and platform-hugging with regards to
SA110 and SA1100 systems, I am certainly aware of such tendencies
in myself. And I understand if GCC drops support for old systems
that only have a bunch of elderly gentlemen running it for the fun of it.
What really worries me is if there are widely deployed SA110,
SA1100, FA526 or similar embedded systems using plain ARMv4
and doing regular kernel builds and userspaces for them, in
items with 20+ years support cycles.
With reports in the media about things like nuclear powerplants running
unsupported versions of Windows NT or 95, I want to make sure
that we're not creating a similar situation somewhere for deeply
embedded Linux. Sadly these users mostly seem to come out
of the shadows after-the-fact.
My own experiments with an upgraded Gemini platform are mostly
related to the fact that home routers using this ARMv4 SoC are still
being sold and deployed, using a v2.6 kernel (contributing to the
world of botnets I suppose). The hardware-accelerated gigabit ethernet
on these routers for the home make them still fully usable despite the
ARMv4 core, but securitywise they are a nightmare.
Yours,
Linus Walleij
^ permalink raw reply
* [RFC PATCH 2/2] ASoC: select sysclk clock from mlck clock provider in wm8994 driver
From: Olivier MOYSAN @ 2017-12-20 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219093506.GD8563@sirena.org.uk>
Hello Mark,
On 12/19/2017 10:35 AM, Mark Brown wrote:
> On Fri, Dec 15, 2017 at 03:15:22PM +0000, Olivier MOYSAN wrote:
>
>> You are right. wm8994 allows to select either MCLK for each AIF.
>> From this point of view, the current patch is too limiting.
>> MCLK information in DT allows to enforce MCLK use, but an additionnal
>> information is required to determine AIF MCLK assignment.
>> Available properties in codec DAI node, such as clocks property, cannot
>> help here.
>
>> Maybe a DAPM linked to a control is a better way to select AIF source,
>> When source is not provided by clk_id in wm8994_set_dai_sysclk().
>> In this case, wm8994_set_dai_sysclk() would only have to check
>> if clock source is not already set.
>
>> Please let me know if this option sounds better to you.
>
> What are you trying to accomplish here? You appear to be trying to move
> the system clocking configuration from the machine driver to the CODEC
> which is not how things are supposed to work.
>
As a generic machine, simple or audio graph cards are not able to manage
codec clock muxing.
If we exclude the management of muxing through codec controls,
the remaining solution is to handle it fully through clock framework.
The current patch only supports a limited range of muxing capabilities
of the codec.
To have a full management of the muxing, I think it is necessary to add
a device tree node for each codec interface and to define an aif clock
in these nodes.
Then parent clock assignment of these aif clocks would allow to handle
the muxing.
Please, let me known if is this the right direction for you.
BRs
olivier
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Linus Walleij @ 2017-12-20 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213095257.5cf424fb@jawa>
On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski <lukma@denx.de> wrote:
>> On Wed Dec 13 08:34:22 2017 Linus Walleij <linus.walleij@linaro.org>
>> wrote:
>> > On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski <lukma@denx.de>
>> > wrote: Out of curiosity: Liebherr is obviously doing heavy-duty
>> > industrial control systems. Likewise Hartley is doing similar
>> > business over at Vision Engravings.
>> >
>> > Is the situation such that there is a whole bunch of industrial
>> > systems out there, in active use and needing future upgrades,
>> > that use the EP93xx?
>>
>> That's definitely the case. I'm as well aware of several thousands of
>> industrial devices which are expected to run 24/7 for the next 5
>> years at least. And they are updated from time to time.
>
> I can agree with this statement.
OK I'm coloring this platform with a highlight for ARM32 maintenance.
>> > Arnd has been nudging me to do DT conversion for EP93xx
>> > so if there are many active industrial users of these
>> > I should prioritize it, because these things have 20+ years
>> > support cycles.
>>
>> I'm not sure how important or necessary at all is to change anything
>> in these legacy platforms.
>
> +1
That is an understandable conservative stance.
There is a fine line between "it works, don't touch it" and
"modernize the ARM32 ecosystem".
There is a point where supporting old board files will stand in
the way and cost a lot in maintenance (like moving drivers our
of arch/arm, or modernizing misc subsystems). Then moving the
platform over to device tree should be preferred.
> I'm using OE to build toolchain (SDK). I can confirm that gcc 7.2 works
> with it.
>
> And yes, armv4 support shall be preserved in GCC ....
Yes that is the same toochain I use.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 3/3] staging: vchiq_arm: Cleaning up codestyle warnings
From: Mikhail Shvetsov @ 2017-12-20 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8bfad6214b83ee325888705c9f5a194cb6899caf.1513772223.git.lameli67@gmail.com>
This removes checkpatch.pl warnings:
WARNING: line over 80 characters
Signed-off-by: Mikhail Shvetsov <lameli67@gmail.com>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
index 3c9f97d60019..43c89a08bda9 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
@@ -90,7 +90,8 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
goto failed;
} else if (i > 0) {
vchiq_log_warning(vchiq_core_log_level,
- "%s: videocore initialized after %d retries\n", __func__, i);
+ "%s: videocore initialized after %d retries\n",
+ __func__, i);
}
instance = kzalloc(sizeof(*instance), GFP_KERNEL);
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] staging: vchiq_arm: Fixing code style of comments
From: Mikhail Shvetsov @ 2017-12-20 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8bfad6214b83ee325888705c9f5a194cb6899caf.1513772223.git.lameli67@gmail.com>
This removes checkpatch.pl warnings:
WARNING: Block comments use a trailing */ on a separate line
WARNING: Block comments should align the * on each line
WARNING: Block comments use * on subsequent lines
Signed-off-by: Mikhail Shvetsov <lameli67@gmail.com>
---
.../vc04_services/interface/vchiq_arm/vchiq_kern_lib.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
index 6152596d23ea..3c9f97d60019 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
@@ -75,7 +75,9 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
vchiq_log_trace(vchiq_core_log_level, "%s called", __func__);
/* VideoCore may not be ready due to boot up timing.
- It may never be ready if kernel and firmware are mismatched, so don't block forever. */
+ * It may never be ready if kernel and firmware are mismatched,so don't
+ * block forever.
+ */
for (i = 0; i < VCHIQ_INIT_RETRIES; i++) {
state = vchiq_get_state();
if (state)
@@ -379,8 +381,9 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, void *data,
if ((bulk->data != data) ||
(bulk->size != size)) {
/* This is not a retry of the previous one.
- ** Cancel the signal when the transfer
- ** completes. */
+ * Cancel the signal when the transfer
+ * completes.
+ */
spin_lock(&bulk_waiter_spinlock);
bulk->userdata = NULL;
spin_unlock(&bulk_waiter_spinlock);
@@ -406,7 +409,8 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, void *data,
if (bulk) {
/* Cancel the signal when the transfer
- ** completes. */
+ * completes.
+ */
spin_lock(&bulk_waiter_spinlock);
bulk->userdata = NULL;
spin_unlock(&bulk_waiter_spinlock);
--
2.11.0
^ permalink raw reply related
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