* [PATCH 03/20] ARM: dts: imx6qdl-hummingboard2: rename microsom include
From: Russell King @ 2017-12-11 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211165631.GW10595@n2100.armlinux.org.uk>
Rename microsom include to imx6qdl-sr-som.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 72226ccf3e34..2dfd8f5887fc 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -38,7 +38,7 @@
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include "imx6qdl-microsom.dtsi"
+#include "imx6qdl-sr-som.dtsi"
/ {
chosen {
--
2.7.4
^ permalink raw reply related
* [PATCH 02/20] ARM: dts: imx6*-hummingboard2: remove ar8035 include
From: Russell King @ 2017-12-11 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211165631.GW10595@n2100.armlinux.org.uk>
Remove the AR8035 include, the file is now gone.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 0e3c57b99904..72226ccf3e34 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -39,7 +39,6 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
#include "imx6qdl-microsom.dtsi"
-#include "imx6qdl-microsom-ar8035.dtsi"
/ {
chosen {
--
2.7.4
^ permalink raw reply related
* [PATCH 01/20] ARM: dts: imx6qdl: add HummingBoard2 boards
From: Russell King @ 2017-12-11 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211165631.GW10595@n2100.armlinux.org.uk>
From: Jon Nettleton <jon@solid-run.com>
This adds support for the Hummingboard Gate and Edge devices from
SolidRun.
Signed-off-by: Jon Nettleton <jon@solid-run.com>
Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-hummingboard2.dts | 50 +++
arch/arm/boot/dts/imx6q-hummingboard2.dts | 58 +++
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 541 +++++++++++++++++++++++++++
4 files changed, 651 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-hummingboard2.dts
create mode 100644 arch/arm/boot/dts/imx6q-hummingboard2.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b5ba7ad6ae30..a757e2dd60c4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -388,6 +388,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-hummingboard.dtb \
imx6dl-hummingboard-emmc-som-v15.dtb \
imx6dl-hummingboard-som-v15.dtb \
+ imx6dl-hummingboard2.dtb \
imx6dl-icore.dtb \
imx6dl-icore-rqs.dtb \
imx6dl-nit6xlite.dtb \
@@ -447,6 +448,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-hummingboard.dtb \
imx6q-hummingboard-emmc-som-v15.dtb \
imx6q-hummingboard-som-v15.dtb \
+ imx6q-hummingboard2.dtb \
imx6q-icore.dtb \
imx6q-icore-ofcap10.dtb \
imx6q-icore-ofcap12.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-hummingboard2.dts b/arch/arm/boot/dts/imx6dl-hummingboard2.dts
new file mode 100644
index 000000000000..207ce329534a
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-hummingboard2.dts
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2015 Rabeeh Khoury <rabeeh@solid-run.com>
+ * Based on dt work by Russell King
+ *
+ * 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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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 "AS IS", 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.
+ */
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-hummingboard2.dtsi"
+
+/ {
+ model = "SolidRun HummingBoard2 Solo/DualLite";
+ compatible = "solidrun,hummingboard2/dl", "fsl,imx6dl";
+};
diff --git a/arch/arm/boot/dts/imx6q-hummingboard2.dts b/arch/arm/boot/dts/imx6q-hummingboard2.dts
new file mode 100644
index 000000000000..b850111ddf34
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-hummingboard2.dts
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2015 Rabeeh Khoury <rabeeh@solid-run.com>
+ * Based on dt work by Russell King
+ *
+ * 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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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 "AS IS", 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.
+ */
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-hummingboard2.dtsi"
+
+/ {
+ model = "SolidRun HummingBoard2 Dual/Quad";
+ compatible = "solidrun,hummingboard2/q", "fsl,imx6q";
+};
+
+&sata {
+ status = "okay";
+ fsl,transmit-level-mV = <1104>;
+ fsl,transmit-boost-mdB = <0>;
+ fsl,transmit-atten-16ths = <9>;
+ fsl,no-spread-spectrum;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
new file mode 100644
index 000000000000..0e3c57b99904
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -0,0 +1,541 @@
+/*
+ * Copyright (C) 2015 Rabeeh Khoury <rabeeh@solid-run.com>
+ *
+ * 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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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 "AS IS", 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.
+ */
+#include "imx6qdl-microsom.dtsi"
+#include "imx6qdl-microsom-ar8035.dtsi"
+
+/ {
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ ir_recv: ir-receiver {
+ compatible = "gpio-ir-receiver";
+ gpios = <&gpio7 9 1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_gpio7_9>;
+ linux,rc-map-name = "rc-rc6-mce";
+ };
+
+ usdhc2_pwrseq: usdhc2-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio4 30 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_usbh1_vbus: regulator-usb-h1-vbus {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio1 0 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_usbh1_vbus>;
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reg_usbotg_vbus: regulator-usb-otg-vbus {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio3 22 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_usbotg_vbus>;
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reg_usbh2_vbus: regulator-usb-h2-vbus {
+ compatible = "regulator-gpio";
+ enable-active-high;
+ enable-gpio = <&gpio2 13 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_usbh2_vbus>;
+ regulator-name = "usb_h2_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ };
+
+ reg_usbh3_vbus: regulator-usb-h3-vbus {
+ compatible = "regulator-gpio";
+ enable-active-high;
+ enable-gpio = <&gpio7 10 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_usbh3_vbus>;
+ regulator-name = "usb_h3_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ };
+
+ sound-sgtl5000 {
+ audio-codec = <&sgtl5000>;
+ audio-routing =
+ "MIC_IN", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "Headphone Jack", "HP_OUT";
+ compatible = "fsl,imx-audio-sgtl5000";
+ model = "On-board Codec";
+ mux-ext-port = <5>;
+ mux-int-port = <1>;
+ ssi-controller = <&ssi1>;
+ };
+};
+
+&audmux {
+ status = "okay";
+};
+
+&ecspi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_ecspi2>;
+ cs-gpios = <&gpio2 26 0>;
+ status = "okay";
+};
+
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_hdmi>;
+ ddc-i2c-bus = <&i2c2>;
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_i2c1>;
+ status = "okay";
+
+ pcf8523: rtc at 68 {
+ compatible = "nxp,pcf8523";
+ reg = <0x68>;
+ nxp,12p5_pf;
+ };
+
+ sgtl5000: codec at 0a {
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ compatible = "fsl,sgtl5000";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_sgtl5000>;
+ reg = <0x0a>;
+ VDDA-supply = <®_3p3v>;
+ VDDIO-supply = <®_3p3v>;
+ };
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_i2c2>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_i2c3>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ hummingboard2 {
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /*
+ * 36 pin headers GPIO description. The pins
+ * numbering as following -
+ *
+ * 3.2v 5v 74 75
+ * 73 72 71 70
+ * 69 68 67 66
+ *
+ * 77 78 79 76
+ * 65 64 61 60
+ * 53 52 51 50
+ * 49 48 166 132
+ * 95 94 90 91
+ * GND 54 24 204
+ *
+ * The GPIO numbers can be extracted using
+ * signal name from below.
+ * Example -
+ * MX6QDL_PAD_EIM_DA10__GPIO3_IO10 is
+ * GPIO(3,10) which is (3-1)*32+10 = gpio 74
+ *
+ * i.e. The mapping of GPIO(X,Y) to Linux gpio
+ * number is : gpio number = (X-1) * 32 + Y
+ */
+ /* DI1_PIN15 */
+ MX6QDL_PAD_EIM_DA10__GPIO3_IO10 0x400130b1
+ /* DI1_PIN02 */
+ MX6QDL_PAD_EIM_DA11__GPIO3_IO11 0x400130b1
+ /* DISP1_DATA00 */
+ MX6QDL_PAD_EIM_DA9__GPIO3_IO09 0x400130b1
+ /* DISP1_DATA01 */
+ MX6QDL_PAD_EIM_DA8__GPIO3_IO08 0x400130b1
+ /* DISP1_DATA02 */
+ MX6QDL_PAD_EIM_DA7__GPIO3_IO07 0x400130b1
+ /* DISP1_DATA03 */
+ MX6QDL_PAD_EIM_DA6__GPIO3_IO06 0x400130b1
+ /* DISP1_DATA04 */
+ MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x400130b1
+ /* DISP1_DATA05 */
+ MX6QDL_PAD_EIM_DA4__GPIO3_IO04 0x400130b1
+ /* DISP1_DATA06 */
+ MX6QDL_PAD_EIM_DA3__GPIO3_IO03 0x400130b1
+ /* DISP1_DATA07 */
+ MX6QDL_PAD_EIM_DA2__GPIO3_IO02 0x400130b1
+ /* DI1_D0_CS */
+ MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x400130b1
+ /* DI1_D1_CS */
+ MX6QDL_PAD_EIM_DA14__GPIO3_IO14 0x400130b1
+ /* DI1_PIN01 */
+ MX6QDL_PAD_EIM_DA15__GPIO3_IO15 0x400130b1
+ /* DI1_PIN03 */
+ MX6QDL_PAD_EIM_DA12__GPIO3_IO12 0x400130b1
+ /* DISP1_DATA08 */
+ MX6QDL_PAD_EIM_DA1__GPIO3_IO01 0x400130b1
+ /* DISP1_DATA09 */
+ MX6QDL_PAD_EIM_DA0__GPIO3_IO00 0x400130b1
+ /* DISP1_DATA10 */
+ MX6QDL_PAD_EIM_EB1__GPIO2_IO29 0x400130b1
+ /* DISP1_DATA11 */
+ MX6QDL_PAD_EIM_EB0__GPIO2_IO28 0x400130b1
+ /* DISP1_DATA12 */
+ MX6QDL_PAD_EIM_A17__GPIO2_IO21 0x400130b1
+ /* DISP1_DATA13 */
+ MX6QDL_PAD_EIM_A18__GPIO2_IO20 0x400130b1
+ /* DISP1_DATA14 */
+ MX6QDL_PAD_EIM_A19__GPIO2_IO19 0x400130b1
+ /* DISP1_DATA15 */
+ MX6QDL_PAD_EIM_A20__GPIO2_IO18 0x400130b1
+ /* DISP1_DATA16 */
+ MX6QDL_PAD_EIM_A21__GPIO2_IO17 0x400130b1
+ /* DISP1_DATA17 */
+ MX6QDL_PAD_EIM_A22__GPIO2_IO16 0x400130b1
+ /* DISP1_DATA18 */
+ MX6QDL_PAD_EIM_A23__GPIO6_IO06 0x400130b1
+ /* DISP1_DATA19 */
+ MX6QDL_PAD_EIM_A24__GPIO5_IO04 0x400130b1
+ /* DISP1_DATA20 */
+ MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x400130b1
+ /* DISP1_DATA21 */
+ MX6QDL_PAD_EIM_D30__GPIO3_IO30 0x400130b1
+ /* DISP1_DATA22 */
+ MX6QDL_PAD_EIM_D26__GPIO3_IO26 0x400130b1
+ /* DISP1_DATA23 */
+ MX6QDL_PAD_EIM_D27__GPIO3_IO27 0x400130b1
+ /* DI1_DISP_CLK */
+ MX6QDL_PAD_EIM_A16__GPIO2_IO22 0x400130b1
+ /* SPDIF_IN */
+ MX6QDL_PAD_ENET_RX_ER__GPIO1_IO24 0x400130b1
+ /* SPDIF_OUT */
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x400130b1
+
+ /* MikroBUS GPIO pin number 10 */
+ MX6QDL_PAD_EIM_LBA__GPIO2_IO27 0x400130b1
+ >;
+ };
+
+ pinctrl_hummingboard2_ecspi2: hummingboard2-ecspi2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
+ MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
+ MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
+ MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x000b1 /* CS */
+ >;
+ };
+
+ pinctrl_hummingboard2_gpio7_9: hummingboard2-gpio7_9 {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_CMD__GPIO7_IO09 0x80000000
+ >;
+ };
+
+ pinctrl_hummingboard2_hdmi: hummingboard2-hdmi {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+ >;
+ };
+
+ pinctrl_hummingboard2_i2c1: hummingboard2-i2c1 {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_hummingboard2_i2c2: hummingboard2-i2c2 {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_hummingboard2_i2c3: hummingboard2-i2c3 {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D17__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_hummingboard2_mipi: hummingboard2_mipi {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x4001b8b1
+ MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x4001b8b1
+ MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x130b0
+ >;
+ };
+
+ pinctrl_hummingboard2_pcie_reset: hummingboard2-pcie-reset {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT3__GPIO2_IO11 0x1b0b1
+ >;
+ };
+
+ pinctrl_hummingboard2_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__PWM1_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_hummingboard2_sgtl5000: hummingboard2-sgtl5000 {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x130b0
+ MX6QDL_PAD_KEY_COL0__AUD5_TXC 0x130b0
+ MX6QDL_PAD_KEY_ROW0__AUD5_TXD 0x110b0
+ MX6QDL_PAD_KEY_COL1__AUD5_TXFS 0x130b0
+ MX6QDL_PAD_GPIO_5__CCM_CLKO1 0x130b0
+ >;
+ };
+
+ pinctrl_hummingboard2_usbh1_vbus: hummingboard2-usbh1-vbus {
+ fsl,pins = <MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0>;
+ };
+
+ pinctrl_hummingboard2_usbh2_vbus: hummingboard2-usbh2-vbus {
+ fsl,pins = <MX6QDL_PAD_SD4_DAT5__GPIO2_IO13 0x1b0b0>;
+ };
+
+ pinctrl_hummingboard2_usbh3_vbus: hummingboard2-usbh3-vbus {
+ fsl,pins = <MX6QDL_PAD_SD4_CLK__GPIO7_IO10 0x1b0b0>;
+ };
+
+ pinctrl_hummingboard2_usbotg_id: hummingboard2-usbotg-id {
+ /*
+ * Similar to pinctrl_usbotg_2, but we want it
+ * pulled down for a fixed host connection.
+ */
+ fsl,pins = <MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x13059>;
+ };
+
+ pinctrl_hummingboard2_usbotg_vbus: hummingboard2-usbotg-vbus {
+ fsl,pins = <MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0>;
+ };
+
+ pinctrl_hummingboard2_usdhc2_aux: hummingboard2-usdhc2-aux {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x13071
+ MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x1b071
+ MX6QDL_PAD_DISP0_DAT9__GPIO4_IO30 0x1b0b0
+ >;
+ };
+
+ pinctrl_hummingboard2_usdhc2: hummingboard2-usdhc2 {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x13059
+ >;
+ };
+
+ pinctrl_hummingboard2_usdhc2_100mhz: hummingboard2-usdhc2-100mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170b9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100b9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170b9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x130b9
+ >;
+ };
+
+ pinctrl_hummingboard2_usdhc2_200mhz: hummingboard2-usdhc2-200mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170f9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100f9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170f9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170f9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170f9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x130f9
+ >;
+ };
+
+ pinctrl_hummingboard2_usdhc3: hummingboard2-usdhc3 {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
+ >;
+ };
+
+ pinctrl_hummingboard2_uart3: hummingboard2-uart3 {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D25__UART3_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D24__UART3_RX_DATA 0x40013000
+ >;
+ };
+ };
+};
+
+&ldb {
+ status = "disabled";
+
+ lvds-channel at 0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <18>;
+ };
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_pcie_reset>;
+ reset-gpio = <&gpio2 11 0>;
+ status = "okay";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_pwm1>;
+ status = "okay";
+};
+
+&pwm3 {
+ status = "disabled";
+};
+
+&pwm4 {
+ status = "disabled";
+};
+
+&ssi1 {
+ status = "okay";
+};
+
+&usbh1 {
+ disable-over-current;
+ vbus-supply = <®_usbh1_vbus>;
+ status = "okay";
+};
+
+&usbotg {
+ disable-over-current;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_usbotg_id>;
+ vbus-supply = <®_usbotg_vbus>;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <
+ &pinctrl_hummingboard2_usdhc2_aux
+ &pinctrl_hummingboard2_usdhc2
+ >;
+ pinctrl-1 = <
+ &pinctrl_hummingboard2_usdhc2_aux
+ &pinctrl_hummingboard2_usdhc2_100mhz
+ >;
+ pinctrl-2 = <
+ &pinctrl_hummingboard2_usdhc2_aux
+ &pinctrl_hummingboard2_usdhc2_200mhz
+ >;
+ mmc-pwrseq = <&usdhc2_pwrseq>;
+ cd-gpios = <&gpio1 4 0>;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &pinctrl_hummingboard2_usdhc3
+ >;
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_3p3v>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_uart3>;
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/3] arm64: allwinner: a64: bananapi-m64: add usb otg
From: Jagan Teki @ 2017-12-11 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513011400-4120-1-git-send-email-jagan@amarulasolutions.com>
Add usb otg support for bananapi-m64 board,
- USB-ID connected with PH9
- USB-DRVVBUS controlled by N_VBUSEN pin from PMIC
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v3:
- Move the position of reg_drivevbus as per binding documentation.
Changes for v2:
- add drvvbus regulator
- add N_VBUSEN pin
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 4a8d3f8..a23c113 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -66,6 +66,10 @@
};
};
+&ehci0 {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
@@ -136,6 +140,10 @@
status = "okay";
};
+&ohci0 {
+ status = "okay";
+};
+
&ohci1 {
status = "okay";
};
@@ -148,6 +156,7 @@
reg = <0x3a3>;
interrupt-parent = <&r_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
};
};
@@ -247,6 +256,11 @@
regulator-name = "vcc-rtc";
};
+®_drivevbus {
+ regulator-name = "usb0-vbus";
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
@@ -259,6 +273,13 @@
status = "okay";
};
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
&usbphy {
+ usb0_id_det-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
+ usb0_vbus-supply = <®_drivevbus>;
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] arm64: allwinner: axp803: Add drivevbus regulator
From: Jagan Teki @ 2017-12-11 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513011400-4120-1-git-send-email-jagan@amarulasolutions.com>
Add reg_drivevbus regualtor for boards which are using
external regulator to drive the OTG VBus through N_VBUSEN
PMIC pin.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v3:
- none
arch/arm64/boot/dts/allwinner/axp803.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi b/arch/arm64/boot/dts/allwinner/axp803.dtsi
index ff8af52..e5eae8b 100644
--- a/arch/arm64/boot/dts/allwinner/axp803.dtsi
+++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
@@ -146,5 +146,10 @@
regulator-max-microvolt = <3000000>;
regulator-name = "rtc-ldo";
};
+
+ reg_drivevbus: drivevbus {
+ regulator-name = "drivevbus";
+ status = "disabled";
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/3] regulator: axp20x: add drivevbus support for axp803
From: Jagan Teki @ 2017-12-11 16:56 UTC (permalink / raw)
To: linux-arm-kernel
Like axp221, axp223, axp813 the axp803 is also supporting external
regulator to drive the OTG VBus through N_VBUSEN PMIC pin.
Add support for it.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes for v3:
- Update drivevbus in table of regulators
Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
drivers/regulator/axp20x-regulator.c | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 9455503..d1762f3 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -43,7 +43,7 @@ Optional properties:
regulator to drive the OTG VBus, rather then
as an input pin which signals whether the
board is driving OTG VBus or not.
- (axp221 / axp223 / axp813 only)
+ (axp221 / axp223 / axp803/ axp813 only)
- x-powers,master-mode: Boolean (axp806 only). Set this when the PMIC is
wired for master mode. The default is slave mode.
@@ -132,6 +132,7 @@ FLDO2 : LDO : fldoin-supply : shared supply
LDO_IO0 : LDO : ips-supply : GPIO 0
LDO_IO1 : LDO : ips-supply : GPIO 1
RTC_LDO : LDO : ips-supply : always on
+DRIVEVBUS : Enable output : drivevbus-supply : external regulator
AXP806 regulators, type, and corresponding input supply names:
diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 181622b..91b8ff8 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -721,6 +721,8 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
case AXP803_ID:
regulators = axp803_regulators;
nregulators = AXP803_REG_ID_MAX;
+ drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
+ "x-powers,drive-vbus-en");
break;
case AXP806_ID:
regulators = axp806_regulators;
--
2.7.4
^ permalink raw reply related
* [PATCH 00/20] Add Hummingboard 2 support
From: Russell King - ARM Linux @ 2017-12-11 16:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series adds the long awaited Hummingboard 2 support to the
mainline kernel.
While I could squash the patch set down, I've not done this because
this is the result of several different people over the course of
the last couple of years, and I believe it's not right to lose the
detail of their contributions.
This builds upon the previous set of changes for the Hummingboard,
which re-organised the way we deal with the uSOM and baseboards.
arch/arm/boot/dts/Makefile | 6 +
.../boot/dts/imx6dl-hummingboard2-emmc-som-v15.dts | 55 +++
arch/arm/boot/dts/imx6dl-hummingboard2-som-v15.dts | 54 +++
arch/arm/boot/dts/imx6dl-hummingboard2.dts | 53 ++
.../boot/dts/imx6q-hummingboard2-emmc-som-v15.dts | 63 +++
arch/arm/boot/dts/imx6q-hummingboard2-som-v15.dts | 62 +++
arch/arm/boot/dts/imx6q-hummingboard2.dts | 61 +++
arch/arm/boot/dts/imx6qdl-hummingboard2-emmc.dtsi | 72 +++
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 540 +++++++++++++++++++++
9 files changed, 966 insertions(+)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v6 3/3] clk: at91: pmc: Support backup for programmable clocks
From: Romain Izard @ 2017-12-11 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211165535.5126-1-romain.izard.pro@gmail.com>
When an AT91 programmable clock is declared in the device tree, register
it into the Power Management Controller driver. On entering suspend mode,
the driver saves and restores the Programmable Clock registers to support
the backup mode for these clocks.
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
Changes in v2:
* register PCKs on clock startup
Changes in v3:
* improve comments on hanling 0 in pmc_register_id and pmc_register_pck
* declare local variables earlier for checkpatch
Changes in v6:
* Use the correct author email address
drivers/clk/at91/clk-programmable.c | 2 ++
drivers/clk/at91/pmc.c | 35 +++++++++++++++++++++++++++++++++++
drivers/clk/at91/pmc.h | 2 ++
3 files changed, 39 insertions(+)
diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
index 85a449cf61e3..0e6aab1252fc 100644
--- a/drivers/clk/at91/clk-programmable.c
+++ b/drivers/clk/at91/clk-programmable.c
@@ -204,6 +204,8 @@ at91_clk_register_programmable(struct regmap *regmap,
if (ret) {
kfree(prog);
hw = ERR_PTR(ret);
+ } else {
+ pmc_register_pck(id);
}
return hw;
diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
index 07dc2861ad3f..1fa27f4ea538 100644
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -22,6 +22,7 @@
#include "pmc.h"
#define PMC_MAX_IDS 128
+#define PMC_MAX_PCKS 8
int of_at91_get_clk_range(struct device_node *np, const char *propname,
struct clk_range *range)
@@ -50,6 +51,7 @@ EXPORT_SYMBOL_GPL(of_at91_get_clk_range);
static struct regmap *pmcreg;
static u8 registered_ids[PMC_MAX_IDS];
+static u8 registered_pcks[PMC_MAX_PCKS];
static struct
{
@@ -66,8 +68,13 @@ static struct
u32 pcr[PMC_MAX_IDS];
u32 audio_pll0;
u32 audio_pll1;
+ u32 pckr[PMC_MAX_PCKS];
} pmc_cache;
+/*
+ * As Peripheral ID 0 is invalid on AT91 chips, the identifier is stored
+ * without alteration in the table, and 0 is for unused clocks.
+ */
void pmc_register_id(u8 id)
{
int i;
@@ -82,9 +89,28 @@ void pmc_register_id(u8 id)
}
}
+/*
+ * As Programmable Clock 0 is valid on AT91 chips, there is an offset
+ * of 1 between the stored value and the real clock ID.
+ */
+void pmc_register_pck(u8 pck)
+{
+ int i;
+
+ for (i = 0; i < PMC_MAX_PCKS; i++) {
+ if (registered_pcks[i] == 0) {
+ registered_pcks[i] = pck + 1;
+ break;
+ }
+ if (registered_pcks[i] == (pck + 1))
+ break;
+ }
+}
+
static int pmc_suspend(void)
{
int i;
+ u8 num;
regmap_read(pmcreg, AT91_PMC_SCSR, &pmc_cache.scsr);
regmap_read(pmcreg, AT91_PMC_PCSR, &pmc_cache.pcsr0);
@@ -103,6 +129,10 @@ static int pmc_suspend(void)
regmap_read(pmcreg, AT91_PMC_PCR,
&pmc_cache.pcr[registered_ids[i]]);
}
+ for (i = 0; registered_pcks[i]; i++) {
+ num = registered_pcks[i] - 1;
+ regmap_read(pmcreg, AT91_PMC_PCKR(num), &pmc_cache.pckr[num]);
+ }
return 0;
}
@@ -119,6 +149,7 @@ static bool pmc_ready(unsigned int mask)
static void pmc_resume(void)
{
int i;
+ u8 num;
u32 tmp;
u32 mask = AT91_PMC_MCKRDY | AT91_PMC_LOCKA;
@@ -143,6 +174,10 @@ static void pmc_resume(void)
pmc_cache.pcr[registered_ids[i]] |
AT91_PMC_PCR_CMD);
}
+ for (i = 0; registered_pcks[i]; i++) {
+ num = registered_pcks[i] - 1;
+ regmap_write(pmcreg, AT91_PMC_PCKR(num), pmc_cache.pckr[num]);
+ }
if (pmc_cache.uckr & AT91_PMC_UPLLEN)
mask |= AT91_PMC_LOCKU;
diff --git a/drivers/clk/at91/pmc.h b/drivers/clk/at91/pmc.h
index 858e8ef7e8db..d22b1fa9ecdc 100644
--- a/drivers/clk/at91/pmc.h
+++ b/drivers/clk/at91/pmc.h
@@ -31,8 +31,10 @@ int of_at91_get_clk_range(struct device_node *np, const char *propname,
#ifdef CONFIG_PM
void pmc_register_id(u8 id);
+void pmc_register_pck(u8 pck);
#else
static inline void pmc_register_id(u8 id) {}
+static inline void pmc_register_pck(u8 pck) {}
#endif
#endif /* __PMC_H_ */
--
2.14.1
^ permalink raw reply related
* [PATCH v6 2/3] clk: at91: pmc: Save SCSR during suspend
From: Romain Izard @ 2017-12-11 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211165535.5126-1-romain.izard.pro@gmail.com>
The contents of the System Clock Status Register (SCSR) needs to be
restored into the System Clock Enable Register (SCER).
As the bootloader will restore some clocks by itself, the issue can be
missed as only the USB controller, the LCD controller, the Image Sensor
controller and the programmable clocks will be impacted.
Fix the obvious typo in the suspend/resume code, as the IMR register
does not need to be saved twice.
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
drivers/clk/at91/pmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
index 5c2b26de303e..07dc2861ad3f 100644
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -86,7 +86,7 @@ static int pmc_suspend(void)
{
int i;
- regmap_read(pmcreg, AT91_PMC_IMR, &pmc_cache.scsr);
+ regmap_read(pmcreg, AT91_PMC_SCSR, &pmc_cache.scsr);
regmap_read(pmcreg, AT91_PMC_PCSR, &pmc_cache.pcsr0);
regmap_read(pmcreg, AT91_CKGR_UCKR, &pmc_cache.uckr);
regmap_read(pmcreg, AT91_CKGR_MOR, &pmc_cache.mor);
@@ -129,7 +129,7 @@ static void pmc_resume(void)
if (pmc_cache.pllar != tmp)
pr_warn("PLLAR was not configured properly by the firmware\n");
- regmap_write(pmcreg, AT91_PMC_IMR, pmc_cache.scsr);
+ regmap_write(pmcreg, AT91_PMC_SCER, pmc_cache.scsr);
regmap_write(pmcreg, AT91_PMC_PCER, pmc_cache.pcsr0);
regmap_write(pmcreg, AT91_CKGR_UCKR, pmc_cache.uckr);
regmap_write(pmcreg, AT91_CKGR_MOR, pmc_cache.mor);
--
2.14.1
^ permalink raw reply related
* [PATCH v6 1/3] clk: at91: pmc: Wait for clocks when resuming
From: Romain Izard @ 2017-12-11 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211165535.5126-1-romain.izard.pro@gmail.com>
Wait for the syncronization of all clocks when resuming, not only the
UPLL clock. Do not use regmap_read_poll_timeout, as it will call BUG()
when interrupts are masked, which is the case in here.
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
drivers/clk/at91/pmc.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
index 775af473fe11..5c2b26de303e 100644
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -107,10 +107,20 @@ static int pmc_suspend(void)
return 0;
}
+static bool pmc_ready(unsigned int mask)
+{
+ unsigned int status;
+
+ regmap_read(pmcreg, AT91_PMC_SR, &status);
+
+ return ((status & mask) == mask) ? 1 : 0;
+}
+
static void pmc_resume(void)
{
- int i, ret = 0;
+ int i;
u32 tmp;
+ u32 mask = AT91_PMC_MCKRDY | AT91_PMC_LOCKA;
regmap_read(pmcreg, AT91_PMC_MCKR, &tmp);
if (pmc_cache.mckr != tmp)
@@ -134,13 +144,11 @@ static void pmc_resume(void)
AT91_PMC_PCR_CMD);
}
- if (pmc_cache.uckr & AT91_PMC_UPLLEN) {
- ret = regmap_read_poll_timeout(pmcreg, AT91_PMC_SR, tmp,
- !(tmp & AT91_PMC_LOCKU),
- 10, 5000);
- if (ret)
- pr_crit("USB PLL didn't lock when resuming\n");
- }
+ if (pmc_cache.uckr & AT91_PMC_UPLLEN)
+ mask |= AT91_PMC_LOCKU;
+
+ while (!pmc_ready(mask))
+ cpu_relax();
}
static struct syscore_ops pmc_syscore_ops = {
--
2.14.1
^ permalink raw reply related
* [PATCH v6 0/3] Clock patches for SAMA5D2 backup mode
From: Romain Izard @ 2017-12-11 16:55 UTC (permalink / raw)
To: linux-arm-kernel
While the core of the backup mode for SAMA5D2 has been integrated in
v4.13, it is far from complete. Individual controllers in the chip have
drivers that do not support the reset of the registers during suspend,
and they need to be adapted to handle it.
The first patch uses the clock wakeup code from the prototype backup
mode instead of the version integrated in the mainline, as the mainline
version is not stable. During a test loop with two-second backup
suspend, the mainline version will hang in less than one day, whereas
the proposed version has been running the same test for more than a
month without hanging.
Changes in v2:
* drop the IIO patch duplicating existing code
* determine the number of programmable clocks to save dynamically
* declare a required local variable in the tty/serial patch
Changes in v3:
* drop dev_printk changes for PMECC
* rework the resume code for PMECC
* improve comments on PMC clock handling
Changes in v4:
* fix a bug in the PMECC resume code
Changes in v5:
* drop all patches already taken
* split the patch series by subsystem
Changes in v6:
* rebase on v4.15-rc3
Romain Izard (3):
clk: at91: pmc: Wait for clocks when resuming
clk: at91: pmc: Save SCSR during suspend
clk: at91: pmc: Support backup for programmable clocks
drivers/clk/at91/clk-programmable.c | 2 ++
drivers/clk/at91/pmc.c | 63 +++++++++++++++++++++++++++++++------
drivers/clk/at91/pmc.h | 2 ++
3 files changed, 57 insertions(+), 10 deletions(-)
--
2.14.1
^ permalink raw reply
* [PATCH 02/12] mtd: nand: add reworked Marvell NAND controller driver
From: Miquel RAYNAL @ 2017-12-11 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAEAJfC89bRugBsK8jrK=6fdq76yzjThA74UCAhAaVuonLLNvg@mail.gmail.com>
On Mon, 11 Dec 2017 13:27:30 -0300
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:
> On 7 December 2017 at 17:18, Miquel Raynal
> <miquel.raynal@free-electrons.com> wrote:
> > Add marvell_nand driver which aims at replacing the existing
> > pxa3xx_nand driver.
> >
> > The new driver intends to be easier to understand and follows the
> > brand new NAND framework rules by implementing hooks for every
> > pattern the controller might support and referencing them inside a
> > parser object that will be given to the core at each ->exec_op()
> > call.
> >
> > Raw accessors are implemented, useful to test/debug
> > memory/filesystem corruptions. Userspace binaries contained in the
> > mtd-utils package may now be used and their output trusted.
> >
> > Timings may not be kept from the bootloader anymore, the timings
> > used for instance in U-Boot were not optimal and it supposed to
> > have NAND support (and initialized) in the bootloader.
> >
> > Thanks to the improved timings, implementation of ONFI mode 5
> > support (with EDO managed by adding a delay on data sampling),
> > merging the commands together and optimizing writes in the command
> > registers, the new driver may achieve faster throughputs in both
> > directions. Measurements show an improvement of about +23% read
> > throughput and +24% write throughput. These measurements have been
> > done with an Armada-385-DB-AP (4kiB NAND pages forced in 4-bit
> > strength BCH ECC correction) using the userspace tool 'flash_speed'
> > from the MTD test suite.
> >
> > Besides these important topics, the new driver addresses several
> > unsolved known issues in the old driver which:
> > - did not work with ECC soft neither with ECC none ;
> > - relied on naked read/write (which is unchanged) while the NFCv1
> > embedded in the pxa3xx platforms do not implement it, so several
> > NAND commands did not actually ever work without any notice (like
> > reading the ONFI PARAM_PAGE or SET/GET_FEATURES) ;
> > - wrote the OOB data correctly, but was not able to read it
> > correctly past the first OOB data chunk ;
> > - did not displayed ECC bytes ;
> > - used device tree bindings that did not allow more than one NAND
> > chip, and did not allow to choose the correct chip select if not
> > incrementing from 0. Plus, the Ready/Busy line used had to be 0.
> >
> > Old device tree bindings are still supported but deprecated. A more
> > hierarchical view has to be used to keep the controller and the NAND
> > chip structures clearly separated both inside the device tree and
> > also in the driver code.
> >
>
> So, is this driver fully compatible with the current pxa3xx-nand
> driver?
It should be!
>
> Have you tested with U-Boot's driver (based on the pxa3xx-nand)?
>
> I recally some subtle issues with the fact that U-Boot and Linux had
> to agree about the BBT format.
I kept the pxa3xx_nand driver BBT format.
This is something I mistakenly omitted from the commit message:
There are 5 supported layouts in the driver (the same as withing the
pxa3xx_nand driver):
1/ Page: 512B, strength 1b/512B (hamming)
2/ Page: 2kiB, strength 4b/2kiB (hamming)
3/ page: 2kiB, strength 16b/2kiB (BCH)
4/ page: 4kiB, strength 16b/2kiB (BCH)
5/ page: 4kiB, strength 32b/2kiB (BCH)
Layout 2 has been tested with CM_X300 compulab module (PXA SoC) with
and without DMA.
Layout 4 has been tested with an Armada 385 db, an Armada 7040 DB and
an Armada 8040 DB.
Layout 5 has been tested with an Armada 398 db.
Layout 1 has been tested with the Armada 385 db with some hacks.
Layout 3 has been tested with the Armada 385 db with some other hacks,
that is why I am concerned about the other thread on the MTD mailing
list "wait timeout when scanning for BB" where a 2kiB page with
16b/2048B strength is in use.
Regards,
Miqu?l
^ permalink raw reply
* [PATCH] ARM: dts: dra7: Add missing hdmi audio DMA channel information
From: Tony Lindgren @ 2017-12-11 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171108125323.7070-1-peter.ujfalusi@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [171108 04:54]:
> The audio DMA request for hdmi is crossbar 76 and we use sDMA
> to handle the data transfer.
Applying into omap-for-v4.16/dt thanks.
Tony
^ permalink raw reply
* [GIT PULL] OMAP2+: clkctrl fixes/enhancements for OMAP SoCs for 4.16 merge
From: Tony Lindgren @ 2017-12-11 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <26d92d81-5922-1755-e59c-964e09a7f3c2@ti.com>
* Tero Kristo <t-kristo@ti.com> [171205 05:05]:
> Hi Tony,
>
> This pull contains the series posted here [1], it has only been rebased on
> top of 4.15-rc1. Can be applied separately from the clkctrl driver series.
> The part missing after this is the DTS series, which I will post later this
> week (I don't think I have time to post them today, but they are available
> also under branch 4.15-rc1-clkctrl-dts in my public repo.)
Thanks pulling into omap-for-v4.16/soc.
Regards,
Tony
> [1] http://www.spinics.net/lists/linux-omap/msg139902.html
>
> ===
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> https://github.com/t-kristo/linux-pm.git 4.15-rc1-clkctrl-mach-omap2
>
> for you to fetch changes up to 71d50393ab0186b40860d31468a1b701c97339f6:
>
> ARM: DM816x: hwmod_data: fix clockdomain name for sata hwmod (2017-12-04
> 11:35:21 +0200)
>
> ----------------------------------------------------------------
> Tero Kristo (7):
> ARM: OMAP2+: CM: add support for getting phys address for a clkctrl
> register
> ARM: OMAP4: CMINST: add support for translating clkctrl addresses
> ARM: OMAP2+: hwmod: fix clkctrl address translation logic
> ARM: OMAP2+: clockdomain: remove the obsolete clkdm_xlate_address API
> ARM: AM33xx: CM: add support for getting physical address for a
> register
> ARM: OMAP2+: hwmod: calculate physical register address on am33xx
> ARM: DM816x: hwmod_data: fix clockdomain name for sata hwmod
>
> arch/arm/mach-omap2/clockdomain.c | 8 ----
> arch/arm/mach-omap2/clockdomain.h | 2 -
> arch/arm/mach-omap2/cm.h | 3 ++
> arch/arm/mach-omap2/cm33xx.c | 6 +++
> arch/arm/mach-omap2/cm_common.c | 10 ++++
> arch/arm/mach-omap2/cminst44xx.c | 10 ++--
> arch/arm/mach-omap2/omap_hwmod.c | 73
> +++++++++++++++---------------
> arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 2 +-
> 8 files changed, 59 insertions(+), 55 deletions(-)
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
^ permalink raw reply
* [PATCH 0/2] ARM: OMAP2+: CM: make some structures, function arguments and pointers as const
From: Tony Lindgren @ 2017-12-11 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1509974140-10860-1-git-send-email-bhumirks@gmail.com>
* Bhumika Goyal <bhumirks@gmail.com> [171106 05:17]:
> Make some pointers and function arguments as const. After this change,
> make the structures of type cm_ll_data as const.
Thanks applying both in to omap-for-v4.16/soc.
Regards,
Tony
^ permalink raw reply
* [PATCH v3 07/12] dt-bindings: Document the Rockchip MIPI RX D-PHY bindings
From: Laurent Pinchart @ 2017-12-11 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206111939.1153-8-jacob-chen@iotwrt.com>
Hello Jacob,
Thank you for the patch.
On Wednesday, 6 December 2017 13:19:34 EET Jacob Chen wrote:
> From: Jacob Chen <jacob2.chen@rock-chips.com>
>
> Add DT bindings documentation for Rockchip MIPI D-PHY RX
>
> Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
> ---
> .../bindings/media/rockchip-mipi-dphy.txt | 71 +++++++++++++++++++
> 1 file changed, 71 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
>
> diff --git a/Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
> b/Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt new file
> mode 100644
> index 000000000000..cef9450db051
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
> @@ -0,0 +1,71 @@
> +Rockchip SoC MIPI RX D-PHY
> +-------------------------------------------------------------
> +
> +Required properties:
> +
> +- compatible: value should be one of the following
> + "rockchip,rk3288-mipi-dphy";
> + "rockchip,rk3399-mipi-dphy";
> +- rockchip,grf: GRF regs.
> +- bus-width : maximum number of data lanes supported (SoC specific);
Bus width isn't a standard property, should this be rockchip,data-lanes or
rockchip,#data-lanes ?
> +- clocks : list of clock specifiers, corresponding to entries in
> + clock-names property;
> +- clock-names: required clock name.
> +
> +The device node should contain two 'port' child node, according to the
s/child node/child nodes/
> bindings
> +defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
> +The first port should be connected to sensor nodes, and the second port
> should be
> +connected to isp node. The following are properties specific to those
> nodes.
> +
> +endpoint node
> +-------------
> +
> +- data-lanes : (required) an array specifying active physical MIPI-CSI2
> + data input lanes and their mapping to logical lanes; the
> + array's content is unused, only its length is meaningful;
I assume this means that the D-PHY can't reroute lanes. I would mention that
explicitly, and require that the data-lanes values start at one at are
consecutive instead of ignoring them.
> +Device node example
> +-------------------
> +
> + mipi_dphy_rx0: mipi-dphy-rx0 {
> + compatible = "rockchip,rk3399-mipi-dphy";
> + clocks = <&cru SCLK_MIPIDPHY_REF>,
> + <&cru SCLK_DPHY_RX0_CFG>,
> + <&cru PCLK_VIO_GRF>;
> + clock-names = "dphy-ref", "dphy-cfg", "grf";
> + power-domains = <&power RK3399_PD_VIO>;
> + bus-width = <4>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mipi_in_wcam: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&wcam_out>;
> + data-lanes = <1 2>;
> + };
> + mipi_in_ucam: endpoint at 1 {
> + reg = <1>;
> + remote-endpoint = <&ucam_out>;
> + data-lanes = <1>;
> + };
What do those two camera correspond to ? Can they be active at the same time,
or do they use the same data lanes ? If they use the same data lanes, how does
this work, is there a multiplexer on the board ?
> + };
> +
> + port at 1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dphy_rx0_out: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&isp0_mipi_in>;
> + };
> + };
> + };
> + };
> \ No newline at end of file
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] rcutorture: Add basic ARM64 support to run scripts
From: Paul E. McKenney @ 2017-12-11 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512728023-37977-1-git-send-email-lianglihao@huawei.com>
On Fri, Dec 08, 2017 at 06:13:43PM +0800, lianglihao at huawei.com wrote:
> From: Lihao Liang <lianglihao@huawei.com>
>
> This commit adds support of the qemu command qemu-system-aarch64
> to rcutorture. Use the following command to run:
>
> ./kvm.sh --qemu-cmd qemu-system-aarch64
>
> Signed-off-by: Lihao Liang <lianglihao@huawei.com>
Nice!!! Getting ARM support for rcutorture has been on my todo list
for some time!
A few questions and comments below.
Feedback from ARM experts also welcome!
Thanx, Paul
> ---
>
> The max CPUs supported by qemu machine 'virt' is 8 so the value of
> CONFIG_NR_CPUS in some test configuration files needs to be adjusted.
>
> tools/testing/selftests/rcutorture/bin/functions.sh | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
> index 07a1377..5ffe4fe 100644
> --- a/tools/testing/selftests/rcutorture/bin/functions.sh
> +++ b/tools/testing/selftests/rcutorture/bin/functions.sh
> @@ -136,6 +136,9 @@ identify_boot_image () {
> qemu-system-x86_64|qemu-system-i386)
> echo arch/x86/boot/bzImage
> ;;
> + qemu-system-aarch64)
> + echo arch/arm64/boot/Image
> + ;;
> *)
> echo vmlinux
> ;;
Is it possible to automatically select ARM based on the kernel binary?
See the identify_qemu function for how this is done for i386, x86_64,
and PowerPC. Can an "elif" be added for ARM?
> @@ -185,7 +188,14 @@ identify_qemu_append () {
> then
> echo root=/dev/sda
> else
> - echo console=ttyS0
> + case "$1" in
> + qemu-system-aarch64)
> + echo console=ttyAMA0
> + ;;
> + *)
> + echo console=ttyS0
> + ;;
> + esac
> fi
> }
This approach is going to result in very ugly nesting if support is
added for additional CPU families. How about something like this?
identify_qemu_append () {
local console=ttyS0
case "$1" in
qemu-system-x86_64|qemu-system-i386)
echo noapic selinux=0 initcall_debug debug
;;
qemu-system-aarch64)
console=ttyAMA0
;;
esac
if test -n "$TORTURE_QEMU_INTERACTIVE"
then
echo root=/dev/sda
else
echo console=$console
fi
}
> @@ -197,6 +207,9 @@ identify_qemu_args () {
> case "$1" in
> qemu-system-x86_64|qemu-system-i386)
> ;;
> + qemu-system-aarch64)
> + echo -M virt -cpu host
> + ;;
> qemu-system-ppc64)
> echo -enable-kvm -M pseries -nodefaults
> echo -device spapr-vscsi
> @@ -257,6 +270,9 @@ specify_qemu_cpus () {
> qemu-system-x86_64|qemu-system-i386)
How about the following instead, eliminating the need for an additional
case?
qemu-system-x86_64|qemu-system-i386!qemu-system-aarch64)
> echo $2 -smp $3
> ;;
> + qemu-system-aarch64)
> + echo $2 -smp $3
> + ;;
> qemu-system-ppc64)
> nt="`lscpu | grep '^NUMA node0' | sed -e 's/^[^,]*,\([0-9]*\),.*$/\1/'`"
> echo $2 -smp cores=`expr \( $3 + $nt - 1 \) / $nt`,threads=$nt
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 00/36] Optimize KVM/ARM for VHE systems
From: Yury Norov @ 2017-12-11 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211153458.GK910@cbox>
On Mon, Dec 11, 2017 at 04:34:58PM +0100, Christoffer Dall wrote:
> Hi Yury,
>
> On Mon, Dec 11, 2017 at 05:43:23PM +0300, Yury Norov wrote:
> >
> > On Thu, Dec 07, 2017 at 06:05:54PM +0100, Christoffer Dall wrote:
> > > This series redesigns parts of KVM/ARM to optimize the performance on
> > > VHE systems. The general approach is to try to do as little work as
> > > possible when transitioning between the VM and the hypervisor. This has
> > > the benefit of lower latency when waiting for interrupts and delivering
> > > virtual interrupts, and reduces the overhead of emulating behavior and
> > > I/O in the host kernel.
> > >
> > > Patches 01 through 04 are not VHE specific, but rework parts of KVM/ARM
> > > that can be generally improved. We then add infrastructure to move more
> > > logic into vcpu_load and vcpu_put, we improve handling of VFP and debug
> > > registers.
> > >
> > > We then introduce a new world-switch function for VHE systems, which we
> > > can tweak and optimize for VHE systems. To do that, we rework a lot of
> > > the system register save/restore handling and emulation code that may
> > > need access to system registers, so that we can defer as many system
> > > register save/restore operations to vcpu_load and vcpu_put, and move
> > > this logic out of the VHE world switch function.
> > >
> > > We then optimize the configuration of traps. On non-VHE systems, both
> > > the host and VM kernels run in EL1, but because the host kernel should
> > > have full access to the underlying hardware, but the VM kernel should
> > > not, we essentially make the host kernel more privileged than the VM
> > > kernel despite them both running at the same privilege level by enabling
> > > VE traps when entering the VM and disabling those traps when exiting the
> > > VM. On VHE systems, the host kernel runs in EL2 and has full access to
> > > the hardware (as much as allowed by secure side software), and is
> > > unaffected by the trap configuration. That means we can configure the
> > > traps for VMs running in EL1 once, and don't have to switch them on and
> > > off for every entry/exit to/from the VM.
> > >
> > > Finally, we improve our VGIC handling by moving all save/restore logic
> > > out of the VHE world-switch, and we make it possible to truly only
> > > evaluate if the AP list is empty and not do *any* VGIC work if that is
> > > the case, and only do the minimal amount of work required in the course
> > > of the VGIC processing when we have virtual interrupts in flight.
> > >
> > > The patches are based on v4.15-rc1 plus the fixes sent for v4.15-rc3
> > > [1], the level-triggered mapped interrupts support series [2], and the
> > > first five patches of James' SDEI series [3], a single SVE patch that
> > > moves the CPU ID reg trap setup out of the world-switch path, and v3 of
> > > my vcpu load/put series [4].
> > >
> > > I've given the patches a fair amount of testing on Thunder-X, Mustang,
> > > Seattle, and TC2 (32-bit) for non-VHE testing, and tested VHE
> > > functionality on the Foundation model, running both 64-bit VMs and
> > > 32-bit VMs side-by-side and using both GICv3-on-GICv3 and
> > > GICv2-on-GICv3.
> > >
> > > The patches are also available in the vhe-optimize-v2 branch on my
> > > kernel.org repository [5].
> > >
> > > Changes since v1:
> > > - Rebased on v4.15-rc1 and newer versions of other dependencies,
> > > including the vcpu load/put approach taken for KVM.
> > > - Addressed review comments from v1 (detailed changelogs are in the
> > > individual patches).
> > >
> > > Thanks,
> > > -Christoffer
> > >
> > > [1]: git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm kvm-arm-fixes-for-v4.15-1
> > > [2]: git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git level-mapped-v6
> > > [3]: git://linux-arm.org/linux-jm.git sdei/v5/base
> > > [4]: git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git vcpu-load-put-v3
> > > [5]: git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git vhe-optimize-v2
> >
> > I just submitted the benchmark I used to test your v1 and v2 series':
> > https://lkml.org/lkml/2017/12/11/364
> >
> > On ThunderX2, 112 online CPUs test results for v1 are like this:
> >
> > Host, v4.14:
> > Dry-run: 0 1
> > Self-IPI: 9 18
> > Normal IPI: 81 110
> > Broadcast IPI: 0 2106
> >
> > Guest, v4.14:
> > Dry-run: 0 1
> > Self-IPI: 10 18
> > Normal IPI: 305 525
> > Broadcast IPI: 0 9729
> >
> > Guest, v4.14 + VHE:
> > Dry-run: 0 1
> > Self-IPI: 9 18
> > Normal IPI: 176 343
> > Broadcast IPI: 0 9885
> >
> > And for v2.
> >
> > Host, v4.15:
> > Dry-run: 0 1
> > Self-IPI: 9 18
> > Normal IPI: 79 108
> > Broadcast IPI: 0 2102
> >
> > Guest, v4.15-rc:
> > Dry-run: 0 1
> > Self-IPI: 9 18
> > Normal IPI: 291 526
> > Broadcast IPI: 0 10439
> >
> > Guest, v4.15-rc + VHE:
> > Dry-run: 0 2
> > Self-IPI: 14 28
> > Normal IPI: 370 569
> > Broadcast IPI: 0 11688
> >
> > All times are normalized to v1 host dry-run time. Smaller - better.
> >
>
> Thanks for running this.
>
> > Results for v1 and v2 may vary because kernel version is changed.
> > What makes us worry is slowing down the "Normal IPI" test observed in
> > v2 series.
>
> I'm wondering if this is not simply variability in your measurements.
> How many times have you run this? The 100,000 iterations for each run
> is not a lot if you consider the cost of migrating threads.
I ran it more than 100 times, maybe more than 200. Variablity exists,
but ~5% at max, much less than observed changes. I can run 1M iterations
version to handle this concern.
> Is this workload pinned to a single CPU?
No. We are interested in test close to real usecases, so I didn't pin
the test. Inside, sending IPI and waiting for acknowledge is pinned
using {get,put}_cpu(). Tomorrow I'll run test pinned to some CPU. Are
you OK with 'taskset -c 111 insmod ipi_benchmark.ko'?
> Is the system otherwise idle (both host and guest)?
Yes, this machine is in my exclusive usage, and I don't run something
heavy in background. And this is newly installed Ubuntu.
> If you run this during boot or during kernel module load, the results
> may be skewed by that.
Hmm... I do it at module load, but there are many tests that measure
performance like this... Anyway, I'll check that.
> Power management can greatly influence results as well.
That's true. I'll check this also. But as you see, all host numbers,
and guest dry-run and self-ipi numbers are stable, except v2 test...
> Just so I'm sure we're reading these reults the same way, your "+ VHE"
> notation means the VHE optimization series, but both the before and
> after picture runs with VHE enabled, right?
Yes.
> Are you using the same guest kernel version and config for both your v1
> and v2 results, and for both the before and after versions?
I rebased v1 on 4.14. For v2 I ran make olddefconfig, the rest is same
as on your branches. I used same kernel image for host and guest, ie
4.14 host + 4.14 guest for v1, and 4.15-rc host and guest for v2. I
also tested host with and without this series - no difference for both
versions.
> I can't easily come up with a scneario that explains the slowdown on the
> normal IPI test, beyond some unfortunate bug introduced in v2.
>
> >
> > Nevertheless, if you find test relevant, for v1 and v2,
> > Tested-by: Yury Norov <ynorov@caviumnetworks.com>
>
> Thanks,
> -Christoffer
^ permalink raw reply
* [PATCH] IPI performance benchmark
From: Christian Borntraeger @ 2017-12-11 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211145557.mooeknrcdfw53qpz@yury-thinkpad>
On 12/11/2017 03:55 PM, Yury Norov wrote:
> On Mon, Dec 11, 2017 at 03:35:02PM +0100, Christian Borntraeger wrote:
>>
>>
>> On 12/11/2017 03:16 PM, Yury Norov wrote:
>>> This benchmark sends many IPIs in different modes and measures
>>> time for IPI delivery (first column), and total time, ie including
>>> time to acknowledge the receive by sender (second column).
>>>
>>> The scenarios are:
>>> Dry-run: do everything except actually sending IPI. Useful
>>> to estimate system overhead.
>>> Self-IPI: Send IPI to self CPU.
>>> Normal IPI: Send IPI to some other CPU.
>>> Broadcast IPI: Send broadcast IPI to all online CPUs.
>>>
>>> For virtualized guests, sending and reveiving IPIs causes guest exit.
>>> I used this test to measure performance impact on KVM subsystem of
>>> Christoffer Dall's series "Optimize KVM/ARM for VHE systems".
>>>
>>> https://www.spinics.net/lists/kvm/msg156755.html
>>>
>>> Test machine is ThunderX2, 112 online CPUs. Below the results normalized
>>> to host dry-run time. Smaller - better.
>>>
>>> Host, v4.14:
>>> Dry-run: 0 1
>>> Self-IPI: 9 18
>>> Normal IPI: 81 110
>>> Broadcast IPI: 0 2106
>>>
>>> Guest, v4.14:
>>> Dry-run: 0 1
>>> Self-IPI: 10 18
>>> Normal IPI: 305 525
>>> Broadcast IPI: 0 9729
>>>
>>> Guest, v4.14 + VHE:
>>> Dry-run: 0 1
>>> Self-IPI: 9 18
>>> Normal IPI: 176 343
>>> Broadcast IPI: 0 9885
[...]
>>> +static int __init init_bench_ipi(void)
>>> +{
>>> + ktime_t ipi, total;
>>> + int ret;
>>> +
>>> + ret = bench_ipi(NTIMES, DRY_RUN, &ipi, &total);
>>> + if (ret)
>>> + pr_err("Dry-run FAILED: %d\n", ret);
>>> + else
>>> + pr_err("Dry-run: %18llu, %18llu ns\n", ipi, total);
>>
>> you do not use NTIMES here to calculate the average value. Is that intended?
>
> I think, it's more visually to represent all results in number of dry-run
> times, like I did in patch description. So on kernel side I expose raw data
> and calculate final values after finishing tests.
I think it is highly confusing that the output from the patch description does not
match the output from the real module. So can you make that match at least?
>
> If you think that average values are preferable, I can do that in v2.
The raw numbers a propably fine, but then you might want to print the number of
loop iterations in the output.
If we want to do something fancy, we could do a combination of a smaller inner
loop doing the test, then an outer loops redoing the inner loop and then you
can do some min/max/average calculation. Not s
^ permalink raw reply
* [PATCH 13/13] arc: do not use __print_symbol()
From: Vineet Gupta @ 2017-12-11 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-14-sergey.senozhatsky@gmail.com>
On 12/11/2017 04:53 AM, Sergey Senozhatsky wrote:
> __print_symbol() uses extra stack space to sprintf() symbol
> information and then to feed that buffer to printk()
>
> char buffer[KSYM_SYMBOL_LEN];
>
> sprint_symbol(buffer, address);
> printk(fmt, buffer);
>
> Replace __print_symbol() with a direct printk("%pS") call.
>
> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Cc: Vineet Gupta <vgupta@synopsys.com>
Applied to arc for-curr
Thx,
-Vineet
> ---
> arch/arc/kernel/stacktrace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
> index 74315f302971..bf40e06f3fb8 100644
> --- a/arch/arc/kernel/stacktrace.c
> +++ b/arch/arc/kernel/stacktrace.c
> @@ -163,7 +163,7 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs *regs,
> */
> static int __print_sym(unsigned int address, void *unused)
> {
> - __print_symbol(" %s\n", address);
> + printk(" %pS\n", (void *)address);
> return 0;
> }
>
^ permalink raw reply
* [PATCH 00/13] replace print_symbol() with printk()-s
From: Joe Perches @ 2017-12-11 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211125025.2270-1-sergey.senozhatsky@gmail.com>
On Mon, 2017-12-11 at 21:50 +0900, Sergey Senozhatsky wrote:
> print_symbol
Yay.
Just about exactly 5 years earlier...
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137121.html
^ permalink raw reply
* [PATCH net v3] net: phy: meson-gxl: detect LPA corruption
From: David Miller @ 2017-12-11 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208110811.30789-1-jbrunet@baylibre.com>
From: Jerome Brunet <jbrunet@baylibre.com>
Date: Fri, 8 Dec 2017 12:08:11 +0100
> I suppose this patch probably seems a bit hacky, especially the part
> about the link partner acknowledge. I'm trying to figure out if the
> value in MII_LPA makes sense but I don't have such a deep knowledge
> of the ethernet spec.
Yeah it's not the prettiest thing in the world, but if this is what you
need to check to detect this situation then there isn't much else you
can do.
Applied, thanks.
^ permalink raw reply
* [PATCH] arm64: defconfig: enable CONFIG_UNIPHIER_EFUSE
From: Masahiro Yamada @ 2017-12-11 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512005215-6323-1-git-send-email-hayashibara.keiji@socionext.com>
FW: Arnd and Olof,
This patch looks trivial enough.
The reason for not-apply is
probably because this patch was sent to Catalin and Will
without Arnd and Olof even CC'ed.
Arnd, Olof,
Please consider to apply it.
This one:
https://patchwork.kernel.org/patch/10084055/
Thanks.
2017-11-30 10:26 GMT+09:00 Keiji Hayashibara <hayashibara.keiji@socionext.com>:
> Enable the efuse driver for UniPhier SoC
>
> Signed-off-by: Keiji Hayashibara <hayashibara.keiji@socionext.com>
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 6356c6d..41e1b56 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -558,6 +558,7 @@ CONFIG_PHY_XGENE=y
> CONFIG_PHY_TEGRA_XUSB=y
> CONFIG_QCOM_L2_PMU=y
> CONFIG_QCOM_L3_PMU=y
> +CONFIG_UNIPHIER_EFUSE=y
> CONFIG_TEE=y
> CONFIG_OPTEE=y
> CONFIG_ARM_SCPI_PROTOCOL=y
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH] arm: dts: uniphier: add efuse node for UniPhier 32bit SoC
From: Masahiro Yamada @ 2017-12-11 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512375130-16860-1-git-send-email-hayashibara.keiji@socionext.com>
2017-12-04 17:12 GMT+09:00 Keiji Hayashibara <hayashibara.keiji@socionext.com>:
> Add efuse node for UniPhier LD4, Pro4, sLD8, Pro5 and PXs2.
> This efuse node is included in soc-glue.
>
> Signed-off-by: Keiji Hayashibara <hayashibara.keiji@socionext.com>
> ---
> arch/arm/boot/dts/uniphier-ld4.dtsi | 18 ++++++++++++++++++
> arch/arm/boot/dts/uniphier-pro4.dtsi | 23 +++++++++++++++++++++++
> arch/arm/boot/dts/uniphier-pro5.dtsi | 33 +++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/uniphier-pxs2.dtsi | 18 ++++++++++++++++++
> arch/arm/boot/dts/uniphier-sld8.dtsi | 18 ++++++++++++++++++
> 5 files changed, 110 insertions(+)
Applied to linux-uniphier,
but please reconsider To: list next time.
This patch was addressed to Rob and Mark,
but they do not pick up platform DT patches.
You do not need to get Rob's Ack for a patch like this.
Binding is a contract between operation system and DT.
The binding for this
(Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt)
was approved by Rob and merged in the mainline.
Given that this patch follows the binding correctly,
it should be safe.
Thanks.
> diff --git a/arch/arm/boot/dts/uniphier-ld4.dtsi b/arch/arm/boot/dts/uniphier-ld4.dtsi
> index 01fc3e1..6883f3b 100644
> --- a/arch/arm/boot/dts/uniphier-ld4.dtsi
> +++ b/arch/arm/boot/dts/uniphier-ld4.dtsi
> @@ -273,6 +273,24 @@
> };
> };
>
> + soc-glue at 5f900000 {
> + compatible = "socionext,uniphier-ld4-soc-glue-debug",
> + "simple-mfd";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x5f900000 0x2000>;
> +
> + efuse at 100 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x100 0x28>;
> + };
> +
> + efuse at 130 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x130 0x8>;
> + };
> + };
> +
> timer at 60000200 {
> compatible = "arm,cortex-a9-global-timer";
> reg = <0x60000200 0x20>;
> diff --git a/arch/arm/boot/dts/uniphier-pro4.dtsi b/arch/arm/boot/dts/uniphier-pro4.dtsi
> index 7955c3a..150726b 100644
> --- a/arch/arm/boot/dts/uniphier-pro4.dtsi
> +++ b/arch/arm/boot/dts/uniphier-pro4.dtsi
> @@ -294,6 +294,29 @@
> };
> };
>
> + soc-glue at 5f900000 {
> + compatible = "socionext,uniphier-pro4-soc-glue-debug",
> + "simple-mfd";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x5f900000 0x2000>;
> +
> + efuse at 100 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x100 0x28>;
> + };
> +
> + efuse at 130 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x130 0x8>;
> + };
> +
> + efuse at 200 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x200 0x14>;
> + };
> + };
> +
> aidet: aidet at 5fc20000 {
> compatible = "socionext,uniphier-pro4-aidet";
> reg = <0x5fc20000 0x200>;
> diff --git a/arch/arm/boot/dts/uniphier-pro5.dtsi b/arch/arm/boot/dts/uniphier-pro5.dtsi
> index 6589b8a..f291dd6 100644
> --- a/arch/arm/boot/dts/uniphier-pro5.dtsi
> +++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
> @@ -355,6 +355,39 @@
> };
> };
>
> + soc-glue at 5f900000 {
> + compatible = "socionext,uniphier-pro5-soc-glue-debug",
> + "simple-mfd";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x5f900000 0x2000>;
> +
> + efuse at 100 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x100 0x28>;
> + };
> +
> + efuse at 130 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x130 0x8>;
> + };
> +
> + efuse at 200 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x200 0x28>;
> + };
> +
> + efuse at 300 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x300 0x14>;
> + };
> +
> + efuse at 400 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x400 0x8>;
> + };
> + };
> +
> aidet: aidet at 5fc20000 {
> compatible = "socionext,uniphier-pro5-aidet";
> reg = <0x5fc20000 0x200>;
> diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> index d82d6d8..8e54e87 100644
> --- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
> +++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> @@ -375,6 +375,24 @@
> };
> };
>
> + soc-glue at 5f900000 {
> + compatible = "socionext,uniphier-pxs2-soc-glue-debug",
> + "simple-mfd";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x5f900000 0x2000>;
> +
> + efuse at 100 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x100 0x28>;
> + };
> +
> + efuse at 200 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x200 0x58>;
> + };
> + };
> +
> aidet: aidet at 5fc20000 {
> compatible = "socionext,uniphier-pxs2-aidet";
> reg = <0x5fc20000 0x200>;
> diff --git a/arch/arm/boot/dts/uniphier-sld8.dtsi b/arch/arm/boot/dts/uniphier-sld8.dtsi
> index 7188536..afafe7c 100644
> --- a/arch/arm/boot/dts/uniphier-sld8.dtsi
> +++ b/arch/arm/boot/dts/uniphier-sld8.dtsi
> @@ -277,6 +277,24 @@
> };
> };
>
> + soc-glue at 5f900000 {
> + compatible = "socionext,uniphier-sld8-soc-glue-debug",
> + "simple-mfd";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x5f900000 0x2000>;
> +
> + efuse at 100 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x100 0x28>;
> + };
> +
> + efuse at 200 {
> + compatible = "socionext,uniphier-efuse";
> + reg = <0x200 0x14>;
> + };
> + };
> +
> timer at 60000200 {
> compatible = "arm,cortex-a9-global-timer";
> reg = <0x60000200 0x20>;
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [RESEND PATCH V2] arm64: fault: avoid send SIGBUS two times
From: Dongjiu Geng @ 2017-12-11 16:05 UTC (permalink / raw)
To: linux-arm-kernel
do_sea() calls arm64_notify_die() which will always signal
user-space. It also returns whether APEI claimed the external
abort as a RAS notification. If it returns failure do_mem_abort()
will signal user-space too.
do_mem_abort() wants to know if we handled the error, we always
call arm64_notify_die() so can always return success.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
---
1. Address James's comments to update the commit messages
2. Address James's comments to not change the si_code for SIGBUS
---
arch/arm64/mm/fault.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index b64958b..38b9f3e 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -610,7 +610,6 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
{
struct siginfo info;
const struct fault_info *inf;
- int ret = 0;
inf = esr_to_fault_info(esr);
pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
@@ -625,7 +624,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
if (interrupts_enabled(regs))
nmi_enter();
- ret = ghes_notify_sea();
+ ghes_notify_sea();
if (interrupts_enabled(regs))
nmi_exit();
@@ -640,7 +639,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
info.si_addr = (void __user *)addr;
arm64_notify_die("", regs, &info, esr);
- return ret;
+ return 0;
}
static const struct fault_info fault_info[] = {
--
2.10.1
^ 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