* [PATCH 07/10] ARM: dts: imx6ul: phycore: Add eMMC at usdhc2
From: Stefan Riedmueller @ 2019-07-09 7:19 UTC (permalink / raw)
To: shawnguo, s.hauer, robh+dt, mark.rutland
Cc: devicetree, martyn.welch, linux-kernel, linux-imx, kernel,
festevam, linux-arm-kernel
In-Reply-To: <1562656767-273566-1-git-send-email-s.riedmueller@phytec.de>
The phyCORE-i.MX 6UL/ULL now can have eMMC instead of the NAND flash
memory. Add the eMMC node and disable it by default so it can be enabled
in case it is populated.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi
index de6ffbb0183c..09a313daedb8 100644
--- a/arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi
+++ b/arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi
@@ -90,6 +90,15 @@
status = "okay";
};
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ status = "disabled";
+};
+
&iomuxc {
pinctrl_enet1: enet1grp {
fsl,pins = <
@@ -145,4 +154,19 @@
>;
};
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x170f9
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x100f9
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x170f9
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x170f9
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x170f9
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170f9
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x170f9
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x170f9
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x170f9
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x170f9
+ >;
+ };
+
};
--
2.7.4
^ permalink raw reply related
* [PATCH 08/10] ARM: dts: imx6ul: segin: Move ECSPI interface to board include file
From: Stefan Riedmueller @ 2019-07-09 7:19 UTC (permalink / raw)
To: shawnguo, s.hauer, robh+dt, mark.rutland
Cc: devicetree, martyn.welch, linux-kernel, linux-imx, kernel,
festevam, linux-arm-kernel
In-Reply-To: <1562656767-273566-1-git-send-email-s.riedmueller@phytec.de>
The ECSPI interface is available on the expansion connector of every
PHYTEC phyBOARD-Segin. Move its definition to the board include file
for better reuse.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
arch/arm/boot/dts/imx6ul-phytec-segin-ff-rdk-nand.dts | 14 --------------
arch/arm/boot/dts/imx6ul-phytec-segin.dtsi | 16 ++++++++++++++++
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/imx6ul-phytec-segin-ff-rdk-nand.dts b/arch/arm/boot/dts/imx6ul-phytec-segin-ff-rdk-nand.dts
index c6ef13685a7c..32d90c67a6f2 100644
--- a/arch/arm/boot/dts/imx6ul-phytec-segin-ff-rdk-nand.dts
+++ b/arch/arm/boot/dts/imx6ul-phytec-segin-ff-rdk-nand.dts
@@ -28,9 +28,6 @@
};
&ecspi3 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_ecspi3>;
- cs-gpios = <&gpio1 20 GPIO_ACTIVE_HIGH>;
status = "okay";
};
@@ -93,14 +90,3 @@
&usdhc1 {
status = "okay";
};
-
-&iomuxc {
- pinctrl_ecspi3: ecspi3grp {
- fsl,pins = <
- MX6UL_PAD_UART2_RTS_B__ECSPI3_MISO 0x10b0
- MX6UL_PAD_UART2_CTS_B__ECSPI3_MOSI 0x10b0
- MX6UL_PAD_UART2_RX_DATA__ECSPI3_SCLK 0x10b0
- MX6UL_PAD_UART2_TX_DATA__GPIO1_IO20 0x10b0
- >;
- };
-};
diff --git a/arch/arm/boot/dts/imx6ul-phytec-segin.dtsi b/arch/arm/boot/dts/imx6ul-phytec-segin.dtsi
index 7cd24ec40c36..8d5f8dc6ad58 100644
--- a/arch/arm/boot/dts/imx6ul-phytec-segin.dtsi
+++ b/arch/arm/boot/dts/imx6ul-phytec-segin.dtsi
@@ -103,6 +103,13 @@
assigned-clock-rates = <786432000>;
};
+&ecspi3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ cs-gpios = <&gpio1 20 GPIO_ACTIVE_HIGH>;
+ status = "disabled";
+};
+
&fec2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet2>;
@@ -225,6 +232,15 @@
>;
};
+ pinctrl_ecspi3: ecspi3grp {
+ fsl,pins = <
+ MX6UL_PAD_UART2_RTS_B__ECSPI3_MISO 0x10b0
+ MX6UL_PAD_UART2_CTS_B__ECSPI3_MOSI 0x10b0
+ MX6UL_PAD_UART2_RX_DATA__ECSPI3_SCLK 0x10b0
+ MX6UL_PAD_UART2_TX_DATA__GPIO1_IO20 0x10b0
+ >;
+ };
+
pinctrl_enet2: enet2grp {
fsl,pins = <
MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0
--
2.7.4
^ permalink raw reply related
* [PATCH 09/10] ARM: dts: imx6ul: segin: Move machine include to dts files
From: Stefan Riedmueller @ 2019-07-09 7:19 UTC (permalink / raw)
To: shawnguo, s.hauer, robh+dt, mark.rutland
Cc: devicetree, martyn.welch, linux-kernel, linux-imx, kernel,
festevam, linux-arm-kernel
In-Reply-To: <1562656767-273566-1-git-send-email-s.riedmueller@phytec.de>
Move the imx6ul.dtsi include to the dts files so it is easier to reuse
the SOM dtsi for e.g. an i.MX 6ULL SOM.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi | 1 -
arch/arm/boot/dts/imx6ul-phytec-segin-ff-rdk-nand.dts | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi
index 09a313daedb8..92bf91674056 100644
--- a/arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi
+++ b/arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi
@@ -7,7 +7,6 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/pwm/pwm.h>
-#include "imx6ul.dtsi"
/ {
model = "PHYTEC phyCORE-i.MX6 UltraLite";
diff --git a/arch/arm/boot/dts/imx6ul-phytec-segin-ff-rdk-nand.dts b/arch/arm/boot/dts/imx6ul-phytec-segin-ff-rdk-nand.dts
index 32d90c67a6f2..699dfcbf9a60 100644
--- a/arch/arm/boot/dts/imx6ul-phytec-segin-ff-rdk-nand.dts
+++ b/arch/arm/boot/dts/imx6ul-phytec-segin-ff-rdk-nand.dts
@@ -5,6 +5,7 @@
*/
/dts-v1/;
+#include "imx6ul.dtsi"
#include "imx6ul-phytec-phycore-som.dtsi"
#include "imx6ul-phytec-segin.dtsi"
#include "imx6ul-phytec-segin-peb-eval-01.dtsi"
--
2.7.4
^ permalink raw reply related
* [PATCH 10/10] ARM: dts: imx6ull: Add support for PHYTEC phyBOARD-Segin with i.MX 6ULL
From: Stefan Riedmueller @ 2019-07-09 7:19 UTC (permalink / raw)
To: shawnguo, s.hauer, robh+dt, mark.rutland
Cc: devicetree, martyn.welch, linux-kernel, linux-imx, kernel,
festevam, linux-arm-kernel
In-Reply-To: <1562656767-273566-1-git-send-email-s.riedmueller@phytec.de>
In addition to the PHYTEC phyCORE-i.MX 6UL the PHYTEC phyBOARD-Segin is
also available with the PHYTEC phyCORE-i.MX 6ULL. So this adds support
for this SOM and its baseboards.
It comes in a full featured option with either NAND flash or eMMC and in
a low cost option only available with NAND flash.
The hardware specs are:
- Full featured with NAND or eMMC:
* i.MX 6ULL Y2
* 512MB DDR3 memory
* 512MB NAND flash or 4GB/8GB eMMC
* Dual 10/100 Ethernet
* USB Host and USB OTG
* RS232
* MicroSD external storage
* Audio, RS232, I2C, SPI, CAN headers
* Further I/O options via A/V and Expansion headers
- Low cost with NAND:
* i.MX 6ULL Y0
* 256MB DDR3 memory
* 128MB NAND flash
* Single 10/100 Ethernet
* USB OTG
* RS232
* MicroSD external storage
* I2C
* Further I/O options via Expansion headers
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
arch/arm/boot/dts/Makefile | 3 +
arch/arm/boot/dts/imx6ull-phytec-phycore-som.dtsi | 24 ++++++
.../boot/dts/imx6ull-phytec-segin-ff-rdk-emmc.dts | 93 ++++++++++++++++++++++
.../boot/dts/imx6ull-phytec-segin-ff-rdk-nand.dts | 93 ++++++++++++++++++++++
.../boot/dts/imx6ull-phytec-segin-lc-rdk-nand.dts | 45 +++++++++++
.../boot/dts/imx6ull-phytec-segin-peb-eval-01.dtsi | 19 +++++
arch/arm/boot/dts/imx6ull-phytec-segin.dtsi | 38 +++++++++
7 files changed, 315 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ull-phytec-phycore-som.dtsi
create mode 100644 arch/arm/boot/dts/imx6ull-phytec-segin-ff-rdk-emmc.dts
create mode 100644 arch/arm/boot/dts/imx6ull-phytec-segin-ff-rdk-nand.dts
create mode 100644 arch/arm/boot/dts/imx6ull-phytec-segin-lc-rdk-nand.dts
create mode 100644 arch/arm/boot/dts/imx6ull-phytec-segin-peb-eval-01.dtsi
create mode 100644 arch/arm/boot/dts/imx6ull-phytec-segin.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 668b57c8cc57..16efd11cf20f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -580,6 +580,9 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ull-14x14-evk.dtb \
imx6ull-colibri-eval-v3.dtb \
imx6ull-colibri-wifi-eval-v3.dtb \
+ imx6ull-phytec-segin-ff-rdk-nand.dtb \
+ imx6ull-phytec-segin-ff-rdk-emmc.dtb \
+ imx6ull-phytec-segin-lc-rdk-nand.dtb \
imx6ulz-14x14-evk.dtb
dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-cl-som-imx7.dtb \
diff --git a/arch/arm/boot/dts/imx6ull-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx6ull-phytec-phycore-som.dtsi
new file mode 100644
index 000000000000..56cd16e5a77f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-phytec-phycore-som.dtsi
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 PHYTEC Messtechnik GmbH
+ * Author: Stefan Riedmueller <s.riedmueller@phytec.de>
+ */
+
+#include "imx6ul-phytec-phycore-som.dtsi"
+
+/ {
+ model = "PHYTEC phyCORE-i.MX6 ULL";
+ compatible = "phytec,imx6ull-pcl063", "fsl,imx6ull";
+};
+
+&iomuxc {
+ /delete-node/ gpioledssomgrp;
+};
+
+&iomuxc_snvs {
+ pinctrl_gpioleds_som: gpioledssomgrp {
+ fsl,pins = <
+ MX6ULL_PAD_SNVS_TAMPER4__GPIO5_IO04 0x0b0b0
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6ull-phytec-segin-ff-rdk-emmc.dts b/arch/arm/boot/dts/imx6ull-phytec-segin-ff-rdk-emmc.dts
new file mode 100644
index 000000000000..9648d4ecaf58
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-phytec-segin-ff-rdk-emmc.dts
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 PHYTEC Messtechnik GmbH
+ * Author: Stefan Riedmueller <s.riedmueller@phytec.de>
+ */
+
+/dts-v1/;
+#include "imx6ull.dtsi"
+#include "imx6ull-phytec-phycore-som.dtsi"
+#include "imx6ull-phytec-segin.dtsi"
+#include "imx6ull-phytec-segin-peb-eval-01.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Segin i.MX6 ULL Full Featured with eMMC";
+ compatible = "phytec,imx6ull-pbacd10-emmc", "phytec,imx6ull-pbacd10",
+ "phytec,imx6ull-pcl063","fsl,imx6ull";
+};
+
+&adc1 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&tlv320 {
+ status = "okay";
+};
+
+&ecspi3 {
+ status = "okay";
+};
+
+ðphy1 {
+ status = "okay";
+};
+
+ðphy2 {
+ status = "okay";
+};
+
+&fec1 {
+ status = "okay";
+};
+
+&fec2 {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+®_can1_en {
+ status = "okay";
+};
+
+®_sound_1v8 {
+ status = "okay";
+};
+
+®_sound_3v3 {
+ status = "okay";
+};
+
+&sai2 {
+ status = "okay";
+};
+
+&sound {
+ status = "okay";
+};
+
+&uart5 {
+ status = "okay";
+};
+
+&usbotg1 {
+ status = "okay";
+};
+
+&usbotg2 {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
+
+&usdhc2 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6ull-phytec-segin-ff-rdk-nand.dts b/arch/arm/boot/dts/imx6ull-phytec-segin-ff-rdk-nand.dts
new file mode 100644
index 000000000000..656baf846453
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-phytec-segin-ff-rdk-nand.dts
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 PHYTEC Messtechnik GmbH
+ * Author: Stefan Riedmueller <s.riedmueller@phytec.de>
+ */
+
+/dts-v1/;
+#include "imx6ull.dtsi"
+#include "imx6ull-phytec-phycore-som.dtsi"
+#include "imx6ull-phytec-segin.dtsi"
+#include "imx6ull-phytec-segin-peb-eval-01.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Segin i.MX6 ULL Full Featured with NAND";
+ compatible = "phytec,imx6ull-pbacd10-nand", "phytec,imx6ull-pbacd10",
+ "phytec,imx6ull-pcl063", "fsl,imx6ull";
+};
+
+&adc1 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&tlv320 {
+ status = "okay";
+};
+
+&ecspi3 {
+ status = "okay";
+};
+
+ðphy1 {
+ status = "okay";
+};
+
+ðphy2 {
+ status = "okay";
+};
+
+&fec1 {
+ status = "okay";
+};
+
+&fec2 {
+ status = "okay";
+};
+
+&gpmi {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+®_can1_en {
+ status = "okay";
+};
+
+®_sound_1v8 {
+ status = "okay";
+};
+
+®_sound_3v3 {
+ status = "okay";
+};
+
+&sai2 {
+ status = "okay";
+};
+
+&sound {
+ status = "okay";
+};
+
+&uart5 {
+ status = "okay";
+};
+
+&usbotg1 {
+ status = "okay";
+};
+
+&usbotg2 {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6ull-phytec-segin-lc-rdk-nand.dts b/arch/arm/boot/dts/imx6ull-phytec-segin-lc-rdk-nand.dts
new file mode 100644
index 000000000000..e168494e0a6d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-phytec-segin-lc-rdk-nand.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 PHYTEC Messtechnik GmbH
+ * Author: Stefan Riedmueller <s.riedmueller@phytec.de>
+ */
+
+/dts-v1/;
+#include "imx6ull.dtsi"
+#include "imx6ull-phytec-phycore-som.dtsi"
+#include "imx6ull-phytec-segin.dtsi"
+#include "imx6ull-phytec-segin-peb-eval-01.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Segin i.MX6 ULL Low Cost with NAND";
+ compatible = "phytec,imx6ull-pbacd10-nand", "phytec,imx6ull-pbacd10",
+ "phytec,imx6ull-pcl063", "fsl,imx6ull";
+};
+
+&adc1 {
+ status = "okay";
+};
+
+ðphy1 {
+ status = "okay";
+};
+
+&fec1 {
+ status = "okay";
+};
+
+&gpmi {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+&usbotg1 {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6ull-phytec-segin-peb-eval-01.dtsi b/arch/arm/boot/dts/imx6ull-phytec-segin-peb-eval-01.dtsi
new file mode 100644
index 000000000000..ff08d95a1aa2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-phytec-segin-peb-eval-01.dtsi
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 PHYTEC Messtechnik GmbH
+ * Author: Stefan Riedmueller <s.riedmueller@phytec.de>
+ */
+
+#include "imx6ul-phytec-segin-peb-eval-01.dtsi"
+
+&iomuxc {
+ /delete-node/ gpio_keysgrp;
+};
+
+&iomuxc_snvs {
+ pinctrl_gpio_keys: gpio_keysgrp {
+ fsl,pins = <
+ MX6ULL_PAD_SNVS_TAMPER0__GPIO5_IO00 0x79
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6ull-phytec-segin.dtsi b/arch/arm/boot/dts/imx6ull-phytec-segin.dtsi
new file mode 100644
index 000000000000..c1595fc785f7
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-phytec-segin.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 PHYTEC Messtechnik GmbH
+ * Author: Stefan Riedmueller <s.riedmueller@phytec.de>
+ */
+
+#include "imx6ul-phytec-segin.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Segin i.MX6 ULL";
+ compatible = "phytec,imx6ull-pbacd-10", "phytec,imx6ull-pcl063","fsl,imx6ull";
+};
+
+&iomuxc {
+ /delete-node/ flexcan1engrp;
+ /delete-node/ rtcintgrp;
+ /delete-node/ stmpegrp;
+};
+
+&iomuxc_snvs {
+ princtrl_flexcan1_en: flexcan1engrp {
+ fsl,pins = <
+ MX6ULL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x17059
+ >;
+ };
+
+ pinctrl_rtc_int: rtcintgrp {
+ fsl,pins = <
+ MX6ULL_PAD_SNVS_TAMPER1__GPIO5_IO01 0x17059
+ >;
+ };
+
+ pinctrl_stmpe: stmpegrp {
+ fsl,pins = <
+ MX6ULL_PAD_SNVS_TAMPER3__GPIO5_IO03 0x17059
+ >;
+ };
+};
--
2.7.4
^ permalink raw reply related
* RE: [PATCH v9 5/6] usb:cdns3 Add Cadence USB3 DRD Driver
From: Felipe Balbi @ 2019-07-09 7:22 UTC (permalink / raw)
To: Pawel Laszczak, devicetree@vger.kernel.org
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
hdegoede@redhat.com, heikki.krogerus@linux.intel.com,
robh+dt@kernel.org, rogerq@ti.com, linux-kernel@vger.kernel.org,
jbergsagel@ti.com, nsekhar@ti.com, nm@ti.com, Suresh Punnoose,
peter.chen@nxp.com, Jayshri Dajiram Pawar, Rahul Kumar
In-Reply-To: <BYAPR07MB47092C1E19FD36FB336A55C2DDF10@BYAPR07MB4709.namprd07.prod.outlook.com>
Hi,
Pawel Laszczak <pawell@cadence.com> writes:
>>>>> IRQF_ONESHOT can be used only in threaded handled.
>>>>> "
>>>>> * IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler finished.
>>>>> * Used by threaded interrupts which need to keep the
>>>>> * irq line disabled until the threaded handler has been run.
>>>>> "
>>>>
>>>>so?
>>>
>>> I don't understand why If I don't have threaded handler why I need IRQF_ONESHOT.
>>> Why interrupt cannot be reenabled after hardirq handler finished ?
>>> I do not use threaded handler so this flag seem unnecessary.
>>
>>Unless this has changed over the years, it was a requirement from IRQ susbystem.
>>
>> /*
>> * Drivers are often written to work w/o knowledge about the
>> * underlying irq chip implementation, so a request for a
>> * threaded irq without a primary hard irq context handler
>> * requires the ONESHOT flag to be set. Some irq chips like
>> * MSI based interrupts are per se one shot safe. Check the
>> * chip flags, so we can avoid the unmask dance at the end of
>> * the threaded handler for those.
>> */
>> if (desc->irq_data.chip->flags & IRQCHIP_ONESHOT_SAFE)
>> new->flags &= ~IRQF_ONESHOT;
>
> From description I understand that it should be set when driver uses only
> threaded handler without hard irq handler.
> eg.
>
> ret = devm_request_threaded_irq(dev, data->usb_id_irq,
> NULL, int3496_thread_isr,
> IRQF_SHARED | IRQF_ONESHOT |
> IRQF_TRIGGER_RISING |
> IRQF_TRIGGER_FALLING,
> dev_name(dev), data);
>
> It make sense, we don't have hard irq handler so we can't clear source of interrupt.
> If we clear it immediately in interrupt controller then the same interrupt could
> be raised again, because it was not cleared e.g in controller register.
You are correct. Big mistake on my side. Apologies.
--
balbi
^ permalink raw reply
* [PATCH v13 0/5] Add support for mt8183 SCP.
From: Pi-Hsun Shih @ 2019-07-09 7:25 UTC (permalink / raw)
Cc: Pi-Hsun Shih,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Erin Lo, moderated list:ARM/Mediatek SoC support, open list,
moderated list:ARM/Mediatek SoC support,
open list:REMOTE PROCESSOR REMOTEPROC SUBSYSTEM, Nicolas Boichat
Add support for controlling and communicating with mt8183's system
control processor (SCP), using the remoteproc & rpmsg framework.
And also add a cros_ec driver for CrOS EC host command over rpmsg.
The overall structure of the series is:
* remoteproc/mtk_scp.c: Control the start / stop of SCP (Patch 2, 3).
* remoteproc/mtk_scp_ipi.c: Communicates to SCP using inter-processor
interrupt (IPI) and shared memory (Patch 2, 3).
* rpmsg/mtk_rpmsg.c: Wrapper to wrap the IPI communication into a rpmsg
device. Supports name service for SCP firmware to
announce channels (Patch 4).
* add scp dts node to mt8183 platform (Patch 5).
Changes from v12:
- Initialize cache before firmware load, to avoid problem while loading
large firmware.
- Disable watchdog before stopping SCP, to avoid extra warning message.
- Fix new warnings by checkpatch.
Changes from v11:
- Fixed a bug that mtk_rpmsg_endpoint is not properly cleaned up if
rproc_boot fails.
- Add missing documentation in comment.
Changes from v10:
- Drop applied cros_ec_rpmsg patches.
- Add clock reset before loading SCP firmware.
- Fix some type mismatch warnings when printing debug messages.
Changes from v9:
- Remove reserve-memory-vpu_share node.
- Remove change to cros_ec_commands.h (That is already in
https://lore.kernel.org/lkml/20190518063949.GY4319@dell/T/)
Changes from v8:
- Rebased onto https://patchwork.kernel.org/cover/10962385/.
- Drop merged cros_ec_rpmsg patch, and add scp dts node patch.
- Add more reserved memory region.
Changes from v7:
- Rebase onto https://lore.kernel.org/patchwork/patch/1059196/.
- Fix clock enable/disable timing for SCP driver.
- Add more SCP IPI ID.
Changes from v6:
- Decouple mtk_rpmsg from mtk_scp.
- Change data of EC response to be aligned to 4 bytes.
Changes from v5:
- Add device tree binding document for cros_ec_rpmsg.
- Better document in comments for cros_ec_rpmsg.
- Remove dependency on CONFIG_ in binding tree document.
Changes from v4:
- Merge patch 6 (Load ELF firmware) into patch 2, so the driver loads
ELF firmware by default, and no longer accept plain binary.
- rpmsg_device listed in device tree (as a child of the SCP node) would
have it's device tree node mapped to the rpmsg_device, so the rpmsg
driver can use the properties on device tree.
Changes from v3:
- Make writing to SCP SRAM aligned.
- Add a new patch (Patch 6) to load ELF instead of bin firmware.
- Add host event support for EC driver.
- Fix some bugs found in testing (missing spin_lock_init,
rproc_subdev_unprepare to rproc_subdev_stop).
- Fix some coding style issue found by checkpatch.pl.
Changes from v2:
- Fold patch 3 into patch 2 in v2.
- Move IPI id around to support cross-testing for old and new firmware.
- Finish more TODO items.
Changes from v1:
- Extract functions and rename variables in mtk_scp.c.
- Do cleanup properly in mtk_rpmsg.c, which also removes the problem of
short-lived work items.
- Code format fix based on feedback for cros_ec_rpmsg.c.
- Extract feature detection for SCP into separate patch (Patch 6).
Eddie Huang (1):
arm64: dts: mt8183: add scp node
Erin Lo (3):
dt-bindings: Add a binding for Mediatek SCP
remoteproc/mediatek: add SCP support for mt8183
remoteproc: mt8183: add reserved memory manager API
Pi-Hsun Shih (1):
rpmsg: add rpmsg support for mt8183 SCP.
.../bindings/remoteproc/mtk,scp.txt | 36 +
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 11 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 12 +
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/mtk_common.h | 82 +++
drivers/remoteproc/mtk_scp.c | 689 ++++++++++++++++++
drivers/remoteproc/mtk_scp_ipi.c | 163 +++++
drivers/rpmsg/Kconfig | 9 +
drivers/rpmsg/Makefile | 1 +
drivers/rpmsg/mtk_rpmsg.c | 414 +++++++++++
include/linux/platform_data/mtk_scp.h | 167 +++++
include/linux/rpmsg/mtk_rpmsg.h | 38 +
13 files changed, 1633 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
create mode 100644 drivers/remoteproc/mtk_common.h
create mode 100644 drivers/remoteproc/mtk_scp.c
create mode 100644 drivers/remoteproc/mtk_scp_ipi.c
create mode 100644 drivers/rpmsg/mtk_rpmsg.c
create mode 100644 include/linux/platform_data/mtk_scp.h
create mode 100644 include/linux/rpmsg/mtk_rpmsg.h
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply
* [PATCH v13 1/5] dt-bindings: Add a binding for Mediatek SCP
From: Pi-Hsun Shih @ 2019-07-09 7:25 UTC (permalink / raw)
Cc: Pi-Hsun Shih, Erin Lo, Rob Herring, Ohad Ben-Cohen,
Bjorn Andersson, Rob Herring, Mark Rutland, Matthias Brugger,
open list:REMOTE PROCESSOR REMOTEPROC SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, open list
In-Reply-To: <20190709072547.217957-1-pihsun@chromium.org>
From: Erin Lo <erin.lo@mediatek.com>
Add a DT binding documentation of SCP for the
MT8183 SoC from Mediatek.
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes from v12, v11, v10, v9, v8, v7, v6:
- No change.
Changes from v5:
- Remove dependency on CONFIG_RPMSG_MTK_SCP.
Changes from v4:
- Add detail of more properties.
- Document the usage of mtk,rpmsg-name in subnode from the new design.
Changes from v3:
- No change.
Changes from v2:
- No change. I realized that for this patch series, there's no need to
add anything under the mt8183-scp node (neither the mt8183-rpmsg or
the cros-ec-rpmsg) for them to work, since mt8183-rpmsg is added
directly as a rproc_subdev by code, and cros-ec-rpmsg is dynamically
created by SCP name service.
Changes from v1:
- No change.
---
.../bindings/remoteproc/mtk,scp.txt | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
new file mode 100644
index 000000000000..3ba668bab14b
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
@@ -0,0 +1,36 @@
+Mediatek SCP Bindings
+----------------------------------------
+
+This binding provides support for ARM Cortex M4 Co-processor found on some
+Mediatek SoCs.
+
+Required properties:
+- compatible Should be "mediatek,mt8183-scp"
+- reg Should contain the address ranges for the two memory
+ regions, SRAM and CFG.
+- reg-names Contains the corresponding names for the two memory
+ regions. These should be named "sram" & "cfg".
+- clocks Clock for co-processor (See: ../clock/clock-bindings.txt)
+- clock-names Contains the corresponding name for the clock. This
+ should be named "main".
+
+Subnodes
+--------
+
+Subnodes of the SCP represent rpmsg devices. The names of the devices are not
+important. The properties of these nodes are defined by the individual bindings
+for the rpmsg devices - but must contain the following property:
+
+- mtk,rpmsg-name Contains the name for the rpmsg device. Used to match
+ the subnode to rpmsg device announced by SCP.
+
+Example:
+
+ scp: scp@10500000 {
+ compatible = "mediatek,mt8183-scp";
+ reg = <0 0x10500000 0 0x80000>,
+ <0 0x105c0000 0 0x5000>;
+ reg-names = "sram", "cfg";
+ clocks = <&infracfg CLK_INFRA_SCPSYS>;
+ clock-names = "main";
+ };
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v13 5/5] arm64: dts: mt8183: add scp node
From: Pi-Hsun Shih @ 2019-07-09 7:25 UTC (permalink / raw)
Cc: Pi-Hsun Shih, Eddie Huang, Erin Lo, Rob Herring, Mark Rutland,
Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, open list
In-Reply-To: <20190709072547.217957-1-pihsun@chromium.org>
From: Eddie Huang <eddie.huang@mediatek.com>
Add scp node to mt8183 and mt8183-evb
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Signed-off-by: Eddie Huang <eddie.huang@mediatek.com>
---
Changes from v12, v11, v10:
- No change.
Changes from v9:
- Remove extra reserve-memory-vpu_share node.
Changes from v8:
- New patch.
---
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 11 +++++++++++
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 12 ++++++++++++
2 files changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index d8e555cbb5d3..e46e34ce3159 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -24,6 +24,17 @@
chosen {
stdout-path = "serial0:921600n8";
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ scp_mem_reserved: scp_mem_region {
+ compatible = "shared-dma-pool";
+ reg = <0 0x50000000 0 0x2900000>;
+ no-map;
+ };
+ };
};
&auxadc {
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index c2749c4631bc..133146b52904 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -254,6 +254,18 @@
clock-names = "spi", "wrap";
};
+ scp: scp@10500000 {
+ compatible = "mediatek,mt8183-scp";
+ reg = <0 0x10500000 0 0x80000>,
+ <0 0x105c0000 0 0x5000>;
+ reg-names = "sram", "cfg";
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&infracfg CLK_INFRA_SCPSYS>;
+ clock-names = "main";
+ memory-region = <&scp_mem_reserved>;
+ status = "disabled";
+ };
+
auxadc: auxadc@11001000 {
compatible = "mediatek,mt8183-auxadc",
"mediatek,mt8173-auxadc";
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* Re: [PATCH v3 6/6] interconnect: Add OPP table support for interconnects
From: Vincent Guittot @ 2019-07-09 7:25 UTC (permalink / raw)
To: Saravana Kannan
Cc: Georgi Djakov, Rob Herring, Mark Rutland, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rafael J. Wysocki, Sweeney, Sean,
daidavid1, Rajendra Nayak, sibis, Bjorn Andersson, Evan Green,
Android Kernel Team, open list:THERMAL,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel
In-Reply-To: <CAGETcx912kpi9DejPCoWMUF5AMm4=o1C0C45zwMfUy6aX_jcYg@mail.gmail.com>
On Sun, 7 Jul 2019 at 23:48, Saravana Kannan <saravanak@google.com> wrote:
>
> On Thu, Jul 4, 2019 at 12:12 AM Vincent Guittot
> <vincent.guittot@linaro.org> wrote:
> >
> > On Wed, 3 Jul 2019 at 23:33, Saravana Kannan <saravanak@google.com> wrote:
> > >
> > > On Tue, Jul 2, 2019 at 11:45 PM Vincent Guittot
> > > <vincent.guittot@linaro.org> wrote:
> > > >
> > > > On Wed, 3 Jul 2019 at 03:10, Saravana Kannan <saravanak@google.com> wrote:
> > > > >
> > > > > Interconnect paths can have different performance points. Now that OPP
> > > > > framework supports bandwidth OPP tables, add OPP table support for
> > > > > interconnects.
> > > > >
> > > > > Devices can use the interconnect-opp-table DT property to specify OPP
> > > > > tables for interconnect paths. And the driver can obtain the OPP table for
> > > > > an interconnect path by calling icc_get_opp_table().
> > > >
> > > > The opp table of a path must come from the aggregation of OPP tables
> > > > of the interconnect providers.
> > >
> > > The aggregation of OPP tables of the providers is certainly the
> > > superset of what a path can achieve, but to say that OPPs for
> > > interconnect path should match that superset is an oversimplification
> > > of the reality in hardware.
> > >
> > > There are lots of reasons an interconnect path might not want to use
> > > all the available bandwidth options across all the interconnects in
> > > the route.
> > >
> > > 1. That particular path might not have been validated or verified
> > > during the HW design process for some of the frequencies/bandwidth
> > > combinations of the providers.
> >
> > All these constraint are provider's constraints and not consumer's one
> >
> > The consumer asks for a bandwidth according to its needs and then the
> > providers select the optimal bandwidth of each interconnect after
> > aggregating all the request and according to what OPP have been
> > validated
>
> Not really. The screening can be a consumer specific issue. The
> consumer IP itself might have some issue with using too low of a
> bandwidth or bandwidth that's not within some range. It should not be
How can an IP ask for not enough bandwidth ?
It asks the needed bandwidth based on its requirements
> the provider's job to take into account all the IP that might be
> connected to the interconnects. If the interconnect HW itself didn't
That's not what I'm saying. The provider knows which bandwidth the
interconnect can provide as it is the ones which configures it. So if
the interconnect has a finite number of bandwidth point based probably
on the possible clock frequency and others config of the interconnect,
it selects the best final config after aggregating the request of the
consumer.
> change, the provider driver shouldn't need to change. By your
> definition, a provider driver will have to account for all the
> possible bus masters that might be connected to it across all SoCs.
you didn't catch my point
> That's not good design nor is it scalable.
>
> > >
> > > 2. Similarly during parts screening in the factory, some of the
> > > combinations might not have been screened and can't be guaranteed
> > > to work.
> >
> > As above, it's the provider's job to select the final bandwidth
> > according to its constraint
>
> Same reply as above.
>
> > >
> > > 3. Only a certain set of bandwidth levels might make sense to use from
> > > a power/performance balance given the device using it. For example:
> > > - The big CPU might not want to use some of the lower bandwidths
> > > but the little CPU might want to.
> > > - The big CPU might not want to use some intermediate bandwidth
> > > points if they don't save a lot of power compared to a higher
> > > bandwidth levels, but the little CPU might want to.
> > > - The little CPU might never want to use the higher set of
> > > bandwidth levels since they won't be power efficient for the use
> > > cases that might run on it.
> >
> > These example are quite vague about the reasons why little might never
> > want to use higher bandwidth.
>
> How is it vague? I just said because of power/performance balance.
>
> > But then, if little doesn't ask high bandwidth it will not use them.
>
> If you are running a heuristics based algorithm to pick bandwidth,
> this is how it'll know NOT to use some of the bandwidth levels.
so you want to set a bandwidth according to the cpu frequency which is
what has been proposed in other thread
>
> > >
> > > 4. It might not make sense from a system level power perspective.
> > > Let's take an example of a path S (source) -> A -> B -> C -> D
> > > (destination).
> > > - A supports only 2, 5, 7 and 10 GB/s. B supports 1, 2 ... 10 GB/s.
> > > C supports 5 and 10 GB/s
> > > - If you combine and list the superset of bandwidth levels
> > > supported in that path, that'd be 1, 2, 3, ... 10 GB/s.
> > > - Which set of bandwidth levels make sense will depend on the
> > > hardware characteristics of the interconnects.
> > > - If B is the biggest power sink, then you might want to use all 10
> > > levels.
> > > - If A is the biggest power sink, then you might want to use all 2,
> > > 5 and 10 GB/s of the levels.
> > > - If C is the biggest power sink then you might only want to use 5
> > > and 10 GB/s
> > > - The more hops and paths you get the more convoluted this gets.
> > >
> > > 5. The design of the interconnects themselves might have an impact on
> > > which bandwidth levels are used.
> > > - For example, the FIFO depth between two specific interconnects
> > > might affect the valid bandwidth levels for a specific path.
> > > - Say S1 -> A -> B -> D1, S2 -> C -> B -> D1 and S2 -> C -> D2 are
> > > three paths.
> > > - If C <-> B FIFO depth is small, then there might be a requirement
> > > that C and B be closely performance matched to avoid system level
> > > congestion due to back pressure.
> > > - So S2 -> D1 path can't use all the bandwidth levels supported by
> > > C-B combination.
> > > - But S2 -> D2 can use all the bandwidth levels supported by C.
> > > - And S1 -> D1 can use all the levels supported by A-B combination.
> > >
> >
> > All the examples above makes sense but have to be handle by the
> > provider not the consumer. The consumer asks for a bandwidth according
> > to its constraints. Then the provider which is the driver that manages
> > the interconnect IP, should manage all this hardware and platform
> > specific stuff related to the interconnect IP in order to set the
> > optimal bandwidth that fit both consumer constraint and platform
> > specific configuration.
>
> Sure, but the provider itself can have interconnect properties to
> indicate which other interconnects it's tied to. And the provider will
> still need the interconnect-opp-table to denote which bandwidth levels
> are sensible to use with each of its connections.
>
> So in some instances the interconnect-opp-table covers the needs of
> purely consumers and in some instances purely providers. But in either
> case, it's still needed to describe the hardware properly.
>
> -Saravana
>
> > > These are just some of the reasons I could recollect in a few minutes.
> > > These are all real world cases I had to deal with in the past several
> > > years of dealing with scaling interconnects. I'm sure vendors and SoCs
> > > I'm not familiar with have other good reasons I'm not aware of.
> > >
> > > Trying to figure this all out by aggregating OPP tables of
> > > interconnect providers just isn't feasible nor is it efficient. The
> > > OPP tables for an interconnect path is describing the valid BW levels
> > > supported by that path and verified in hardware and makes a lot of
> > > sense to capture it clearly in DT.
> > >
> > > > So such kind of OPP table should be at
> > > > provider level but not at path level.
> > >
> > > They can also use it if they want to, but they'll probably want to use
> > > a frequency OPP table.
> > >
> > >
> > > -Saravana
> > >
> > > >
> > > > >
> > > > > Signed-off-by: Saravana Kannan <saravanak@google.com>
> > > > > ---
> > > > > drivers/interconnect/core.c | 27 ++++++++++++++++++++++++++-
> > > > > include/linux/interconnect.h | 7 +++++++
> > > > > 2 files changed, 33 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> > > > > index 871eb4bc4efc..881bac80bc1e 100644
> > > > > --- a/drivers/interconnect/core.c
> > > > > +++ b/drivers/interconnect/core.c
> > > > > @@ -47,6 +47,7 @@ struct icc_req {
> > > > > */
> > > > > struct icc_path {
> > > > > size_t num_nodes;
> > > > > + struct opp_table *opp_table;
> > > > > struct icc_req reqs[];
> > > > > };
> > > > >
> > > > > @@ -313,7 +314,7 @@ struct icc_path *of_icc_get(struct device *dev, const char *name)
> > > > > {
> > > > > struct icc_path *path = ERR_PTR(-EPROBE_DEFER);
> > > > > struct icc_node *src_node, *dst_node;
> > > > > - struct device_node *np = NULL;
> > > > > + struct device_node *np = NULL, *opp_node;
> > > > > struct of_phandle_args src_args, dst_args;
> > > > > int idx = 0;
> > > > > int ret;
> > > > > @@ -381,10 +382,34 @@ struct icc_path *of_icc_get(struct device *dev, const char *name)
> > > > > dev_err(dev, "%s: invalid path=%ld\n", __func__, PTR_ERR(path));
> > > > > mutex_unlock(&icc_lock);
> > > > >
> > > > > + opp_node = of_parse_phandle(np, "interconnect-opp-table", idx);
> > > > > + if (opp_node) {
> > > > > + path->opp_table = dev_pm_opp_of_find_table_from_node(opp_node);
> > > > > + of_node_put(opp_node);
> > > > > + }
> > > > > +
> > > > > +
> > > > > return path;
> > > > > }
> > > > > EXPORT_SYMBOL_GPL(of_icc_get);
> > > > >
> > > > > +/**
> > > > > + * icc_get_opp_table() - Get the OPP table that corresponds to a path
> > > > > + * @path: reference to the path returned by icc_get()
> > > > > + *
> > > > > + * This function will return the OPP table that corresponds to a path handle.
> > > > > + * If the interconnect API is disabled, NULL is returned and the consumer
> > > > > + * drivers will still build. Drivers are free to handle this specifically, but
> > > > > + * they don't have to.
> > > > > + *
> > > > > + * Return: opp_table pointer on success. NULL is returned when the API is
> > > > > + * disabled or the OPP table is missing.
> > > > > + */
> > > > > +struct opp_table *icc_get_opp_table(struct icc_path *path)
> > > > > +{
> > > > > + return path->opp_table;
> > > > > +}
> > > > > +
> > > > > /**
> > > > > * icc_set_bw() - set bandwidth constraints on an interconnect path
> > > > > * @path: reference to the path returned by icc_get()
> > > > > diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
> > > > > index dc25864755ba..0c0bc55f0e89 100644
> > > > > --- a/include/linux/interconnect.h
> > > > > +++ b/include/linux/interconnect.h
> > > > > @@ -9,6 +9,7 @@
> > > > >
> > > > > #include <linux/mutex.h>
> > > > > #include <linux/types.h>
> > > > > +#include <linux/pm_opp.h>
> > > > >
> > > > > /* macros for converting to icc units */
> > > > > #define Bps_to_icc(x) ((x) / 1000)
> > > > > @@ -28,6 +29,7 @@ struct device;
> > > > > struct icc_path *icc_get(struct device *dev, const int src_id,
> > > > > const int dst_id);
> > > > > struct icc_path *of_icc_get(struct device *dev, const char *name);
> > > > > +struct opp_table *icc_get_opp_table(struct icc_path *path);
> > > > > void icc_put(struct icc_path *path);
> > > > > int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw);
> > > > >
> > > > > @@ -49,6 +51,11 @@ static inline void icc_put(struct icc_path *path)
> > > > > {
> > > > > }
> > > > >
> > > > > +static inline struct opp_table *icc_get_opp_table(struct icc_path *path)
> > > > > +{
> > > > > + return NULL;
> > > > > +}
> > > > > +
> > > > > static inline int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw)
> > > > > {
> > > > > return 0;
> > > > > --
> > > > > 2.22.0.410.gd8fdbe21b5-goog
> > > > >
> >
> > --
> > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
> >
^ permalink raw reply
* RE: [PATCH v9 5/6] usb:cdns3 Add Cadence USB3 DRD Driver
From: Pawel Laszczak @ 2019-07-09 7:29 UTC (permalink / raw)
To: Felipe Balbi, devicetree@vger.kernel.org
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
hdegoede@redhat.com, heikki.krogerus@linux.intel.com,
robh+dt@kernel.org, rogerq@ti.com, linux-kernel@vger.kernel.org,
jbergsagel@ti.com, nsekhar@ti.com, nm@ti.com, Suresh Punnoose,
peter.chen@nxp.com, Jayshri Dajiram Pawar, Rahul Kumar
In-Reply-To: <87muhn65a7.fsf@linux.intel.com>
>
>
>Hi,
>
>Pawel Laszczak <pawell@cadence.com> writes:
>>>>>> IRQF_ONESHOT can be used only in threaded handled.
>>>>>> "
>>>>>> * IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler finished.
>>>>>> * Used by threaded interrupts which need to keep the
>>>>>> * irq line disabled until the threaded handler has been run.
>>>>>> "
>>>>>
>>>>>so?
>>>>
>>>> I don't understand why If I don't have threaded handler why I need IRQF_ONESHOT.
>>>> Why interrupt cannot be reenabled after hardirq handler finished ?
>>>> I do not use threaded handler so this flag seem unnecessary.
>>>
>>>Unless this has changed over the years, it was a requirement from IRQ susbystem.
>>>
>>> /*
>>> * Drivers are often written to work w/o knowledge about the
>>> * underlying irq chip implementation, so a request for a
>>> * threaded irq without a primary hard irq context handler
>>> * requires the ONESHOT flag to be set. Some irq chips like
>>> * MSI based interrupts are per se one shot safe. Check the
>>> * chip flags, so we can avoid the unmask dance at the end of
>>> * the threaded handler for those.
>>> */
>>> if (desc->irq_data.chip->flags & IRQCHIP_ONESHOT_SAFE)
>>> new->flags &= ~IRQF_ONESHOT;
>>
>> From description I understand that it should be set when driver uses only
>> threaded handler without hard irq handler.
>> eg.
>>
>> ret = devm_request_threaded_irq(dev, data->usb_id_irq,
>> NULL, int3496_thread_isr,
>> IRQF_SHARED | IRQF_ONESHOT |
>> IRQF_TRIGGER_RISING |
>> IRQF_TRIGGER_FALLING,
>> dev_name(dev), data);
>>
>> It make sense, we don't have hard irq handler so we can't clear source of interrupt.
>> If we clear it immediately in interrupt controller then the same interrupt could
>> be raised again, because it was not cleared e.g in controller register.
>
>You are correct. Big mistake on my side. Apologies.
All right, you're welcome. I learn a lot of during such discussions :).
>--
>balbi
^ permalink raw reply
* Re: [PATCH 1/3] opp: of: Support multiple suspend OPPs defined in DT
From: Viresh Kumar @ 2019-07-09 7:51 UTC (permalink / raw)
To: Anson.Huang
Cc: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
vireshk, nm, sboyd, leonard.crestez, aisheng.dong, daniel.baluta,
ping.bai, l.stach, abel.vesa, ccaione, angus, andrew.smirnov, agx,
devicetree, linux-arm-kernel, linux-kernel, linux-pm, Linux-imx
In-Reply-To: <20190709071056.26361-1-Anson.Huang@nxp.com>
On 09-07-19, 15:10, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> With property "opp-supported-hw" introduced, the OPP table
> in DT could be a large OPP table and ONLY a subset of OPPs
> are available, based on the version of the hardware running
> on. That introduces restriction of using "opp-suspend"
> property to define the suspend OPP, as we are NOT sure if the
> OPP containing "opp-suspend" property is available for the
> hardware running on, and the of opp core does NOT allow multiple
> suspend OPPs defined in DT OPP table.
>
> To eliminate this restrition, make of opp core allow multiple
> suspend OPPs defined in DT, and pick the OPP with highest rate
> and with "opp-suspend" property present to be suspend OPP, it
> can speed up the suspend/resume process.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> drivers/opp/of.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
Please update the DT bindings first.
FWIW, all three patches look fine otherwise.
--
viresh
^ permalink raw reply
* Re: [PATCH v2 1/1] ARM: dts: colibri: introduce dts with UHS-I support enabled
From: Stefan Agner @ 2019-07-09 7:52 UTC (permalink / raw)
To: Igor Opaniuk
Cc: devicetree, linux-kernel, linux-arm-kernel, robh+dt, mark.rutland,
shawnguo, s.hauer, kernel, festevam, linux-imx, marcel,
marcel.ziswiler
In-Reply-To: <20190514143826.7331-1-igor.opaniuk@toradex.com>
On 2019-05-14 16:38, Igor Opaniuk wrote:
> Introduce DTS for Colibri iMX6S/DL V1.1x re-design, where UHS-I support was
> added. Provide proper configuration for VGEN3, which allows that rail to
> be automatically switched to 1.8 volts for proper UHS-I operation mode.
>
> Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com>
> ---
>
> v2:
> - rework hierarchy of dts files, and a separate dtsi for Colibri
> iMX6S/DL V1.1x re-design, where UHS-I was added
> - add comments about vgen3 power rail
> - fix other minor issues, addressing Marcel's comments.
>
> arch/arm/boot/dts/Makefile | 1 +
> .../boot/dts/imx6dl-colibri-v1.1-eval-v3.dts | 220 +++++
> arch/arm/boot/dts/imx6qdl-colibri-v1.1.dtsi | 852 ++++++++++++++++++
> 3 files changed, 1073 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-colibri-v1.1-eval-v3.dts
> create mode 100644 arch/arm/boot/dts/imx6qdl-colibri-v1.1.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index dab2914fa293..dc4ea05c8e2a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -401,6 +401,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6dl-aristainetos2_4.dtb \
> imx6dl-aristainetos2_7.dtb \
> imx6dl-colibri-eval-v3.dtb \
> + imx6dl-colibri-v1.1-eval-v3.dtb \
> imx6dl-cubox-i.dtb \
> imx6dl-cubox-i-emmc-som-v15.dtb \
> imx6dl-cubox-i-som-v15.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-colibri-v1.1-eval-v3.dts
> b/arch/arm/boot/dts/imx6dl-colibri-v1.1-eval-v3.dts
> new file mode 100644
> index 000000000000..8ed7a528e7c7
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-colibri-v1.1-eval-v3.dts
> @@ -0,0 +1,220 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Copyright 2019 Toradex AG
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-colibri-v1.1.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S V1.1 on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri_imx6dl-eval-v3", "toradex,colibri_imx6dl",
> + "fsl,imx6dl";
I would also change compatible here so someone could detect the new
version, e.g.
"toradex,colibri_imx6dl-v1.1-eval-v3", "toradex,colibri_imx6dl-v1.1",
I guess if the module is considered backward compatible, we should keep
the old compatible strings as well, like we did on Apalis T30, see
arch/arm/boot/dts/tegra30-apalis-v1.1-eval.dts.
The module level model/compatible get overwritten anyway, I think we
could drop those.
--
Stefan
> +
> + /* Will be filled by the bootloader */
> + memory@10000000 {
> + device_type = "memory";
> + reg = <0x10000000 0>;
> + };
> +
> + aliases {
> + i2c0 = &i2c2;
> + i2c1 = &i2c3;
> + };
> +
> + aliases {
> + rtc0 = &rtc_i2c;
> + rtc1 = &snvs_rtc;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + /* Fixed crystal dedicated to mcp251x */
> + clk16m: clock-16m {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <16000000>;
> + clock-output-names = "clk16m";
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + wakeup {
> + label = "Wake-Up";
> + gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>; /* SODIMM 45 */
> + linux,code = <KEY_WAKEUP>;
> + debounce-interval = <10>;
> + wakeup-source;
> + };
> + };
> +
> + lcd_display: disp0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "bgr666";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ipu1_lcdif>;
> + status = "okay";
> +
> + port@0 {
> + reg = <0>;
> +
> + lcd_display_in: endpoint {
> + remote-endpoint = <&ipu1_di0_disp0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + lcd_display_out: endpoint {
> + remote-endpoint = <&lcd_panel_in>;
> + };
> + };
> + };
> +
> + panel: panel {
> + /*
> + * edt,et057090dhu: EDT 5.7" LCD TFT
> + * edt,et070080dh6: EDT 7.0" LCD TFT
> + */
> + compatible = "edt,et057090dhu";
> + backlight = <&backlight>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <&lcd_display_out>;
> + };
> + };
> + };
> +};
> +
> +&backlight {
> + brightness-levels = <0 127 191 223 239 247 251 255>;
> + default-brightness-level = <1>;
> + status = "okay";
> +};
> +
> +/* Colibri SSP */
> +&ecspi4 {
> + status = "okay";
> +
> + mcp251x0: mcp251x@0 {
> + compatible = "microchip,mcp2515";
> + reg = <0>;
> + clocks = <&clk16m>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <27 0x2>;
> + spi-max-frequency = <10000000>;
> + status = "okay";
> + };
> +};
> +
> +&hdmi {
> + status = "okay";
> +};
> +
> +/*
> + * Colibri I2C: I2C3_SDA/SCL on SODIMM 194/196 (e.g. RTC on carrier board)
> + */
> +&i2c3 {
> + status = "okay";
> +
> + /* M41T0M6 real time clock on carrier board */
> + rtc_i2c: rtc@68 {
> + compatible = "st,m41t0";
> + reg = <0x68>;
> + };
> +};
> +
> +&ipu1_di0_disp0 {
> + remote-endpoint = <&lcd_display_in>;
> +};
> +
> +&pwm1 {
> + status = "okay";
> +};
> +
> +&pwm2 {
> + status = "okay";
> +};
> +
> +&pwm3 {
> + status = "okay";
> +};
> +
> +&pwm4 {
> + status = "okay";
> +};
> +
> +®_usb_host_vbus {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&uart3 {
> + status = "okay";
> +};
> +
> +&usbh1 {
> + vbus-supply = <®_usb_host_vbus>;
> + status = "okay";
> +};
> +
> +&usbotg {
> + status = "okay";
> +};
> +
> +/* Colibri MMC */
> +&usdhc1 {
> + status = "okay";
> +};
> +
> +&weim {
> + status = "okay";
> +
> + /* weim memory map: 32MB on CS0, CS1, CS2 and CS3 */
> + ranges = <0 0 0x08000000 0x02000000
> + 1 0 0x0a000000 0x02000000
> + 2 0 0x0c000000 0x02000000
> + 3 0 0x0e000000 0x02000000>;
> +
> + /* SRAM on Colibri nEXT_CS0 */
> + sram@0,0 {
> + compatible = "cypress,cy7c1019dv33-10zsxi, mtd-ram";
> + reg = <0 0 0x00010000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + bank-width = <2>;
> + fsl,weim-cs-timing = <0x00010081 0x00000000 0x04000000
> + 0x00000000 0x04000040 0x00000000>;
> + };
> +
> + /* SRAM on Colibri nEXT_CS1 */
> + sram@1,0 {
> + compatible = "cypress,cy7c1019dv33-10zsxi, mtd-ram";
> + reg = <1 0 0x00010000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + bank-width = <2>;
> + fsl,weim-cs-timing = <0x00010081 0x00000000 0x04000000
> + 0x00000000 0x04000040 0x00000000>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/imx6qdl-colibri-v1.1.dtsi
> b/arch/arm/boot/dts/imx6qdl-colibri-v1.1.dtsi
> new file mode 100644
> index 000000000000..e40819f05c81
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-colibri-v1.1.dtsi
> @@ -0,0 +1,852 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Copyright 2019 Toradex AG
> + */
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S V1.1 Module";
> + compatible = "toradex,colibri_imx6dl", "fsl,imx6dl";
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_bl_on>;
> + pwms = <&pwm3 0 5000000>;
> + enable-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* Colibri BL_ON */
> + status = "disabled";
> + };
> +
> + reg_module_3v3: regulator-module-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "+V3.3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + reg_module_3v3_audio: regulator-module-3v3-audio {
> + compatible = "regulator-fixed";
> + regulator-name = "+V3.3_AUDIO";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + reg_usb_host_vbus: regulator-usb-host-vbus {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_regulator_usbh_pwr>;
> + regulator-name = "usb_host_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpio3 31 GPIO_ACTIVE_HIGH>; /* USBH_PEN */
> + status = "disabled";
> + };
> +
> + sound {
> + compatible = "fsl,imx-audio-sgtl5000";
> + model = "imx6dl-colibri-sgtl5000";
> + ssi-controller = <&ssi1>;
> + audio-codec = <&codec>;
> + audio-routing =
> + "Headphone Jack", "HP_OUT",
> + "LINE_IN", "Line In Jack",
> + "MIC_IN", "Mic Jack",
> + "Mic Jack", "Mic Bias";
> + mux-int-port = <1>;
> + mux-ext-port = <5>;
> + };
> +
> + /* Optional S/PDIF in on SODIMM 88 and out on SODIMM 90, 137 or 168 */
> + sound_spdif: sound-spdif {
> + compatible = "fsl,imx-audio-spdif";
> + model = "imx-spdif";
> + spdif-controller = <&spdif>;
> + spdif-in;
> + spdif-out;
> + status = "disabled";
> + };
> +};
> +
> +&audmux {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_audmux &pinctrl_mic_gnd>;
> + status = "okay";
> +};
> +
> +/* Optional on SODIMM 55/63 */
> +&can1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan1>;
> + status = "disabled";
> +};
> +
> +/* Optional on SODIMM 178/188 */
> +&can2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan2>;
> + status = "disabled";
> +};
> +
> +/* Colibri SSP */
> +&ecspi4 {
> + cs-gpios = <&gpio5 2 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ecspi4>;
> + status = "disabled";
> +};
> +
> +&fec {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet>;
> + phy-mode = "rmii";
> + status = "okay";
> +};
> +
> +&hdmi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hdmi_ddc>;
> + status = "disabled";
> +};
> +
> +/*
> + * PWR_I2C: power I2C to audio codec, PMIC, temperature sensor and
> + * touch screen controller
> + */
> +&i2c2 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c2>;
> + status = "okay";
> +
> + pmic: pfuze100@8 {
> + compatible = "fsl,pfuze100";
> + reg = <0x08>;
> +
> + regulators {
> + sw1a_reg: sw1ab {
> + regulator-min-microvolt = <300000>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw1c_reg: sw1c {
> + regulator-min-microvolt = <300000>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw3a_reg: sw3a {
> + regulator-min-microvolt = <400000>;
> + regulator-max-microvolt = <1975000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + swbst_reg: swbst {
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5150000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + snvs_reg: vsnvs {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vref_reg: vrefddr {
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + /* vgen1: unused */
> +
> + vgen2_reg: vgen2 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1550000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + /*
> + * +V3.3_1.8_SD1 coming off VGEN3 and supplying
> + * the i.MX 6 NVCC_SD1.
> + */
> + vgen3_reg: vgen3 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + };
> +
> + vgen4_reg: vgen4 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vgen5_reg: vgen5 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vgen6_reg: vgen6 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> + };
> + };
> +
> + codec: sgtl5000@a {
> + compatible = "fsl,sgtl5000";
> + reg = <0x0a>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + VDDA-supply = <®_module_3v3_audio>;
> + VDDIO-supply = <®_module_3v3>;
> + VDDD-supply = <&vgen4_reg>;
> + lrclk-strength = <3>;
> + };
> +
> + /* STMPE811 touch screen controller */
> + stmpe811@41 {
> + compatible = "st,stmpe811";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_touch_int>;
> + reg = <0x41>;
> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-parent = <&gpio6>;
> + interrupt-controller;
> + id = <0>;
> + blocks = <0x5>;
> + irq-trigger = <0x1>;
> + /* 3.25 MHz ADC clock speed */
> + st,adc-freq = <1>;
> + /* 12-bit ADC */
> + st,mod-12b = <1>;
> + /* internal ADC reference */
> + st,ref-sel = <0>;
> + /* ADC conversion time: 80 clocks */
> + st,sample-time = <4>;
> +
> + stmpe_touchscreen {
> + compatible = "st,stmpe-ts";
> + /* 8 sample average control */
> + st,ave-ctrl = <3>;
> + /* 7 length fractional part in z */
> + st,fraction-z = <7>;
> + /*
> + * 50 mA typical 80 mA max touchscreen drivers
> + * current limit value
> + */
> + st,i-drive = <1>;
> + /* 1 ms panel driver settling time */
> + st,settling = <3>;
> + /* 5 ms touch detect interrupt delay */
> + st,touch-det-delay = <5>;
> + };
> +
> + stmpe_adc {
> + compatible = "st,stmpe-adc";
> + /* forbid to use ADC channels 3-0 (touch) */
> + st,norequest-mask = <0x0F>;
> + };
> + };
> +};
> +
> +/*
> + * I2C3_SDA/SCL on SODIMM 194/196 (e.g. RTC on carrier board)
> + */
> +&i2c3 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default", "recovery";
> + pinctrl-0 = <&pinctrl_i2c3>;
> + pinctrl-1 = <&pinctrl_i2c3_recovery>;
> + scl-gpios = <&gpio1 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + sda-gpios = <&gpio1 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + status = "disabled";
> +};
> +
> +/* Colibri PWM<B> */
> +&pwm1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm1>;
> + status = "disabled";
> +};
> +
> +/* Colibri PWM<D> */
> +&pwm2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm2>;
> + status = "disabled";
> +};
> +
> +/* Colibri PWM<A> */
> +&pwm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm3>;
> + status = "disabled";
> +};
> +
> +/* Colibri PWM<C> */
> +&pwm4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm4>;
> + status = "disabled";
> +};
> +
> +/* Optional S/PDIF out on SODIMM 137 */
> +&spdif {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spdif>;
> + status = "disabled";
> +};
> +
> +&ssi1 {
> + status = "okay";
> +};
> +
> +/* Colibri UART_A */
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1_dte &pinctrl_uart1_ctrl>;
> + fsl,dte-mode;
> + uart-has-rtscts;
> + status = "disabled";
> +};
> +
> +/* Colibri UART_B */
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart2_dte>;
> + fsl,dte-mode;
> + uart-has-rtscts;
> + status = "disabled";
> +};
> +
> +/* Colibri UART_C */
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart3_dte>;
> + fsl,dte-mode;
> + status = "disabled";
> +};
> +
> +&usbotg {
> + pinctrl-names = "default";
> + disable-over-current;
> + dr_mode = "peripheral";
> + status = "disabled";
> +};
> +
> +/* Colibri MMC */
> +&usdhc1 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc1 &pinctrl_mmc_cd>;
> + pinctrl-1 = <&pinctrl_usdhc1_100mhz &pinctrl_mmc_cd>;
> + pinctrl-2 = <&pinctrl_usdhc1_200mhz &pinctrl_mmc_cd>;
> + vmmc-supply = <®_module_3v3>;
> + vqmmc-supply = <&vgen3_reg>;
> + bus-width = <4>;
> + cd-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; /* MMCD */
> + disable-wp;
> + enable-sdio-wakeup;
> + keep-power-in-suspend;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + status = "disabled";
> +};
> +
> +/* eMMC */
> +&usdhc3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc3>;
> + vqmmc-supply = <®_module_3v3>;
> + bus-width = <8>;
> + no-1-8-v;
> + non-removable;
> + status = "okay";
> +};
> +
> +&weim {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_weim_sram &pinctrl_weim_cs0
> + &pinctrl_weim_cs1 &pinctrl_weim_cs2
> + &pinctrl_weim_rdnwr &pinctrl_weim_npwe>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + status = "disabled";
> +};
> +
> +&iomuxc {
> + pinctrl_audmux: audmuxgrp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL0__AUD5_TXC 0x130b0
> + MX6QDL_PAD_KEY_ROW0__AUD5_TXD 0x130b0
> + MX6QDL_PAD_KEY_COL1__AUD5_TXFS 0x130b0
> + MX6QDL_PAD_KEY_ROW1__AUD5_RXD 0x130b0
> + /* SGTL5000 sys_mclk */
> + MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x000b0
> + >;
> + };
> +
> + pinctrl_cam_mclk: cammclkgrp {
> + fsl,pins = <
> + /* Parallel Camera CAM sys_mclk */
> + MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x00b0
> + >;
> + };
> +
> + pinctrl_ecspi4: ecspi4grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D22__ECSPI4_MISO 0x100b1
> + MX6QDL_PAD_EIM_D28__ECSPI4_MOSI 0x100b1
> + MX6QDL_PAD_EIM_D21__ECSPI4_SCLK 0x100b1
> + /* SPI CS */
> + MX6QDL_PAD_EIM_A25__GPIO5_IO02 0x000b1
> + >;
> + };
> +
> + pinctrl_enet: enetgrp {
> + fsl,pins = <
> + MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
> + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
> + MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
> + MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x1b0b0
> + MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
> + MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
> + MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
> + MX6QDL_PAD_GPIO_16__ENET_REF_CLK ((1<<30) | 0x1b0b0)
> + >;
> + };
> +
> + pinctrl_flexcan1: flexcan1grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
> + MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
> + >;
> + };
> +
> + pinctrl_flexcan2: flexcan2grp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x1b0b0
> + MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b0b0
> + >;
> + };
> +
> + pinctrl_gpio_bl_on: gpioblon {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D26__GPIO3_IO26 0x1b0b0
> + >;
> + };
> +
> + pinctrl_gpio_keys: gpiokeys {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_A16__GPIO2_IO22 0x130b0
> + >;
> + };
> +
> + pinctrl_hdmi_ddc: hdmiddcgrp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL3__HDMI_TX_DDC_SCL 0x4001b8b1
> + MX6QDL_PAD_KEY_ROW3__HDMI_TX_DDC_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_i2c2: i2c2grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_EB2__I2C2_SCL 0x4001b8b1
> + MX6QDL_PAD_EIM_D16__I2C2_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_i2c3: i2c3grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_3__I2C3_SCL 0x4001b8b1
> + MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_i2c3_recovery: i2c3recoverygrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_3__GPIO1_IO03 0x4001b8b1
> + MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_ipu1_csi0: ipu1csi0grp { /* Parallel Camera */
> + fsl,pins = <
> + MX6QDL_PAD_EIM_A17__IPU1_CSI1_DATA12 0xb0b1
> + MX6QDL_PAD_EIM_A18__IPU1_CSI1_DATA13 0xb0b1
> + MX6QDL_PAD_EIM_A19__IPU1_CSI1_DATA14 0xb0b1
> + MX6QDL_PAD_EIM_A20__IPU1_CSI1_DATA15 0xb0b1
> + MX6QDL_PAD_EIM_A21__IPU1_CSI1_DATA16 0xb0b1
> + MX6QDL_PAD_EIM_A22__IPU1_CSI1_DATA17 0xb0b1
> + MX6QDL_PAD_EIM_A23__IPU1_CSI1_DATA18 0xb0b1
> + MX6QDL_PAD_EIM_A24__IPU1_CSI1_DATA19 0xb0b1
> + MX6QDL_PAD_EIM_D17__IPU1_CSI1_PIXCLK 0xb0b1
> + MX6QDL_PAD_EIM_EB3__IPU1_CSI1_HSYNC 0xb0b1
> + MX6QDL_PAD_EIM_D29__IPU1_CSI1_VSYNC 0xb0b1
> + /* Disable PWM pins on camera interface */
> + MX6QDL_PAD_SD4_DAT1__GPIO2_IO09 0x40
> + MX6QDL_PAD_GPIO_1__GPIO1_IO01 0x40
> + >;
> + };
> +
> + pinctrl_ipu1_lcdif: ipu1lcdifgrp {
> + fsl,pins = <
> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0xa1
> + MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0xa1
> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0xa1
> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0xa1
> + MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0xa1
> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0xa1
> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0xa1
> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0xa1
> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0xa1
> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0xa1
> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0xa1
> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0xa1
> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0xa1
> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0xa1
> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0xa1
> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0xa1
> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0xa1
> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0xa1
> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0xa1
> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0xa1
> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0xa1
> + MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0xa1
> + >;
> + };
> +
> + pinctrl_mic_gnd: gpiomicgnd {
> + fsl,pins = <
> + /* Controls Mic GND, PU or '1' pull Mic GND to GND */
> + MX6QDL_PAD_RGMII_TD1__GPIO6_IO21 0x1b0b0
> + >;
> + };
> +
> + pinctrl_mmc_cd: gpiommccd {
> + fsl,pins = <
> + MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x1b0b1
> + >;
> + };
> +
> + pinctrl_pwm1: pwm1grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_9__PWM1_OUT 0x1b0b1
> + >;
> + };
> +
> + pinctrl_pwm2: pwm2grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_1__PWM2_OUT 0x1b0b1
> + MX6QDL_PAD_EIM_A21__GPIO2_IO17 0x00040
> + >;
> + };
> +
> + pinctrl_pwm3: pwm3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
> + MX6QDL_PAD_EIM_A22__GPIO2_IO16 0x00040
> + >;
> + };
> +
> + pinctrl_pwm4: pwm4grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT2__PWM4_OUT 0x1b0b1
> + >;
> + };
> +
> + pinctrl_regulator_usbh_pwr: gpioregusbhpwrgrp {
> + fsl,pins = <
> + /* USBH_EN */
> + MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x0f058
> + >;
> + };
> +
> + pinctrl_spdif: spdifgrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_17__SPDIF_OUT 0x1b0b0
> + >;
> + };
> +
> + pinctrl_touch_int: gpiotouchintgrp {
> + fsl,pins = <
> + /* STMPE811 interrupt */
> + MX6QDL_PAD_RGMII_TD0__GPIO6_IO20 0x1b0b0
> + >;
> + };
> +
> + pinctrl_uart1_dce: uart1dcegrp {
> + fsl,pins = <
> + MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
> + MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
> + >;
> + };
> +
> + /* DTE mode */
> + pinctrl_uart1_dte: uart1dtegrp {
> + fsl,pins = <
> + MX6QDL_PAD_CSI0_DAT10__UART1_RX_DATA 0x1b0b1
> + MX6QDL_PAD_CSI0_DAT11__UART1_TX_DATA 0x1b0b1
> + MX6QDL_PAD_EIM_D19__UART1_RTS_B 0x1b0b1
> + MX6QDL_PAD_EIM_D20__UART1_CTS_B 0x1b0b1
> + >;
> + };
> +
> + /* Additional DTR, DSR, DCD */
> + pinctrl_uart1_ctrl: uart1ctrlgrp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D23__UART1_DCD_B 0x1b0b0
> + MX6QDL_PAD_EIM_D24__UART1_DTR_B 0x1b0b0
> + MX6QDL_PAD_EIM_D25__UART1_DSR_B 0x1b0b0
> + >;
> + };
> +
> + pinctrl_uart2_dte: uart2dtegrp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_DAT4__UART2_TX_DATA 0x1b0b1
> + MX6QDL_PAD_SD4_DAT7__UART2_RX_DATA 0x1b0b1
> + MX6QDL_PAD_SD4_DAT6__UART2_RTS_B 0x1b0b1
> + MX6QDL_PAD_SD4_DAT5__UART2_CTS_B 0x1b0b1
> + >;
> + };
> +
> + pinctrl_uart3_dte: uart3dtegrp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_CLK__UART3_TX_DATA 0x1b0b1
> + MX6QDL_PAD_SD4_CMD__UART3_RX_DATA 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usbc_det: usbcdetgrp {
> + fsl,pins = <
> + /* USBC_DET */
> + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
> + /* USBC_DET_EN */
> + MX6QDL_PAD_RGMII_TX_CTL__GPIO6_IO26 0x0f058
> + /* USBC_DET_OVERWRITE */
> + MX6QDL_PAD_RGMII_RXC__GPIO6_IO30 0x0f058
> + >;
> + };
> +
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071
> + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071
> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071
> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071
> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071
> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071
> + >;
> + };
> +
> + pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x170b1
> + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100b1
> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170b1
> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170b1
> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170b1
> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170b1
> + >;
> + };
> +
> + pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_CMD__SD1_CMD 0x170f1
> + MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100f1
> + MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170f1
> + MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170f1
> + MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170f1
> + MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170f1
> + >;
> + };
> +
> + pinctrl_usdhc3: usdhc3grp {
> + 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
> + /* eMMC reset */
> + MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
> + >;
> + };
> +
> + pinctrl_weim_cs0: weimcs0grp {
> + fsl,pins = <
> + /* nEXT_CS0 */
> + MX6QDL_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
> + >;
> + };
> +
> + pinctrl_weim_cs1: weimcs1grp {
> + fsl,pins = <
> + /* nEXT_CS1 */
> + MX6QDL_PAD_EIM_CS1__EIM_CS1_B 0xb0b1
> + >;
> + };
> +
> + pinctrl_weim_cs2: weimcs2grp {
> + fsl,pins = <
> + /* nEXT_CS2 */
> + MX6QDL_PAD_SD2_DAT1__EIM_CS2_B 0xb0b1
> + >;
> + };
> +
> + pinctrl_weim_sram: weimsramgrp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_OE__EIM_OE_B 0xb0b1
> + MX6QDL_PAD_EIM_RW__EIM_RW 0xb0b1
> + /* Data */
> + MX6QDL_PAD_CSI0_DATA_EN__EIM_DATA00 0x1b0b0
> + MX6QDL_PAD_CSI0_VSYNC__EIM_DATA01 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT4__EIM_DATA02 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT5__EIM_DATA03 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT6__EIM_DATA04 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT7__EIM_DATA05 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT8__EIM_DATA06 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT9__EIM_DATA07 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT12__EIM_DATA08 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT13__EIM_DATA09 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT14__EIM_DATA10 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT15__EIM_DATA11 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT16__EIM_DATA12 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT17__EIM_DATA13 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT18__EIM_DATA14 0x1b0b0
> + MX6QDL_PAD_CSI0_DAT19__EIM_DATA15 0x1b0b0
> + /* Address */
> + MX6QDL_PAD_EIM_DA15__EIM_AD15 0xb0b1
> + MX6QDL_PAD_EIM_DA14__EIM_AD14 0xb0b1
> + MX6QDL_PAD_EIM_DA13__EIM_AD13 0xb0b1
> + MX6QDL_PAD_EIM_DA12__EIM_AD12 0xb0b1
> + MX6QDL_PAD_EIM_DA11__EIM_AD11 0xb0b1
> + MX6QDL_PAD_EIM_DA10__EIM_AD10 0xb0b1
> + MX6QDL_PAD_EIM_DA9__EIM_AD09 0xb0b1
> + MX6QDL_PAD_EIM_DA8__EIM_AD08 0xb0b1
> + MX6QDL_PAD_EIM_DA7__EIM_AD07 0xb0b1
> + MX6QDL_PAD_EIM_DA6__EIM_AD06 0xb0b1
> + MX6QDL_PAD_EIM_DA5__EIM_AD05 0xb0b1
> + MX6QDL_PAD_EIM_DA4__EIM_AD04 0xb0b1
> + MX6QDL_PAD_EIM_DA3__EIM_AD03 0xb0b1
> + MX6QDL_PAD_EIM_DA2__EIM_AD02 0xb0b1
> + MX6QDL_PAD_EIM_DA1__EIM_AD01 0xb0b1
> + MX6QDL_PAD_EIM_DA0__EIM_AD00 0xb0b1
> + >;
> + };
> +
> + pinctrl_weim_rdnwr: weimrdnwr {
> + fsl,pins = <
> + MX6QDL_PAD_SD2_CLK__GPIO1_IO10 0x0040
> + MX6QDL_PAD_RGMII_TD3__GPIO6_IO23 0x130b0
> + >;
> + };
> +
> + pinctrl_weim_npwe: weimnpwe {
> + fsl,pins = <
> + MX6QDL_PAD_SD2_DAT3__GPIO1_IO12 0x0040
> + MX6QDL_PAD_RGMII_TD2__GPIO6_IO22 0x130b0
> + >;
> + };
> +
> + /* ADDRESS[16:18] [25] used as GPIO */
> + pinctrl_weim_gpio_1: weimgpio-1 {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x1b0b0
> + MX6QDL_PAD_KEY_ROW2__GPIO4_IO11 0x1b0b0
> + MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT23__GPIO5_IO17 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT22__GPIO5_IO16 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT21__GPIO5_IO15 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT20__GPIO5_IO14 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x1b0b0
> + MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
> + >;
> + };
> +
> + /* ADDRESS[19:24] used as GPIO */
> + pinctrl_weim_gpio_2: weimgpio-2 {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_ROW2__GPIO4_IO11 0x1b0b0
> + MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT23__GPIO5_IO17 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT22__GPIO5_IO16 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT21__GPIO5_IO15 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT20__GPIO5_IO14 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x1b0b0
> + MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x1b0b0
> + MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
> + >;
> + };
> +
> + /* DATA[16:31] used as GPIO */
> + pinctrl_weim_gpio_3: weimgpio-3 {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_LBA__GPIO2_IO27 0x1b0b0
> + MX6QDL_PAD_EIM_BCLK__GPIO6_IO31 0x1b0b0
> + MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x1b0b0
> + MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x1b0b0
> + MX6QDL_PAD_NANDF_RB0__GPIO6_IO10 0x1b0b0
> + MX6QDL_PAD_NANDF_ALE__GPIO6_IO08 0x1b0b0
> + MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09 0x1b0b0
> + MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x1b0b0
> + MX6QDL_PAD_NANDF_CLE__GPIO6_IO07 0x1b0b0
> + MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x1b0b0
> + MX6QDL_PAD_CSI0_MCLK__GPIO5_IO19 0x1b0b0
> + MX6QDL_PAD_CSI0_PIXCLK__GPIO5_IO18 0x1b0b0
> + MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1b0b0
> + MX6QDL_PAD_GPIO_5__GPIO1_IO05 0x1b0b0
> + MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
> + >;
> + };
> +
> + /* DQM[0:3] used as GPIO */
> + pinctrl_weim_gpio_4: weimgpio-4 {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_EB0__GPIO2_IO28 0x1b0b0
> + MX6QDL_PAD_EIM_EB1__GPIO2_IO29 0x1b0b0
> + MX6QDL_PAD_SD2_DAT2__GPIO1_IO13 0x1b0b0
> + MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b0
> + >;
> + };
> +
> + /* RDY used as GPIO */
> + pinctrl_weim_gpio_5: weimgpio-5 {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_WAIT__GPIO5_IO00 0x1b0b0
> + >;
> + };
> +
> + /* ADDRESS[16] DATA[30] used as GPIO */
> + pinctrl_weim_gpio_6: weimgpio-6 {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x1b0b0
> + MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x1b0b0
> + >;
> + };
> +};
^ permalink raw reply
* RE: [PATCH 1/3] opp: of: Support multiple suspend OPPs defined in DT
From: Anson Huang @ 2019-07-09 7:54 UTC (permalink / raw)
To: Viresh Kumar
Cc: robh+dt@kernel.org, mark.rutland@arm.com, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
vireshk@kernel.org, nm@ti.com, sboyd@kernel.org, Leonard Crestez,
Aisheng Dong, Daniel Baluta, Jacky Bai, l.stach@pengutronix.de,
Abel Vesa, ccaione@baylibre.com, angus@akkea.ca,
andrew.smirnov@gmail.com, agx
In-Reply-To: <20190709075119.rg6ktsg7nwdadsmd@vireshk-i7>
Hi, Viresh
> On 09-07-19, 15:10, Anson.Huang@nxp.com wrote:
> > From: Anson Huang <Anson.Huang@nxp.com>
> >
> > With property "opp-supported-hw" introduced, the OPP table in DT could
> > be a large OPP table and ONLY a subset of OPPs are available, based on
> > the version of the hardware running on. That introduces restriction of
> > using "opp-suspend"
> > property to define the suspend OPP, as we are NOT sure if the OPP
> > containing "opp-suspend" property is available for the hardware
> > running on, and the of opp core does NOT allow multiple suspend OPPs
> > defined in DT OPP table.
> >
> > To eliminate this restrition, make of opp core allow multiple suspend
> > OPPs defined in DT, and pick the OPP with highest rate and with
> > "opp-suspend" property present to be suspend OPP, it can speed up the
> > suspend/resume process.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > drivers/opp/of.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
>
> Please update the DT bindings first.
OK, will send a V2 containing DT binding changes.
>
> FWIW, all three patches look fine otherwise.
Thank you!
Anson.
^ permalink raw reply
* RE: [PATCH] usb: dwc3: Enable the USB snooping
From: Ran Wang @ 2019-07-09 7:55 UTC (permalink / raw)
To: Felipe Balbi
Cc: Greg Kroah-Hartman, open list:DESIGNWARE USB3 DRD IP DRIVER,
open list, Rob Herring, devicetree@vger.kernel.org, Leo Li
In-Reply-To: <87v9wvsex3.fsf@linux.intel.com>
Hi Felipe,
On Monday, June 24, 2019 13:58, Felipe Balbi wrote:
>
> Hi,
>
> Ran Wang <ran.wang_1@nxp.com> writes:
> >> >> > >> >> > /* Global Debug Queue/FIFO Space Available Register */
> >> >> > >> >> > #define DWC3_GDBGFIFOSPACE_NUM(n) ((n) & 0x1f)
> >> >> > >> >> > #define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0)
> >> >> > >> >> > @@ -859,6 +867,7 @@ struct dwc3_scratchpad_array {
> >> >> > >> >> > * 3 - Reserved
> >> >> > >> >> > * @imod_interval: set the interrupt moderation interval in
> 250ns
> >> >> > >> >> > * increments or 0 to disable.
> >> >> > >> >> > + * @dma_coherent: set if enable dma-coherent.
> >> >> > >> >>
> >> >> > >> >> you're not enabling dma coherency, you're enabling cache
> snooping.
> >> >> > >> >> And this property should describe that. Also, keep in mind
> >> >> > >> >> that different devices may want different cache types for
> >> >> > >> >> each of those fields, so your property would have to be a
> >> >> > >> >> lot more complex. Something
> >> >> > like:
> >> >> > >> >>
> >> >> > >> >> snps,cache-type = <foobar "cacheable">, <baz "cacheable">, ...
> >> >> > >> >>
> >> >> > >> >> Then driver would have to parse this properly to setup GSBUSCFG0.
> >> >> > >
> >> >> > > According to the DesignWare Cores SuperSpeed USB 3.0
> >> >> > > Controller Databook (v2.60a), it has described Type Bit
> >> >> > > Assignments for all supported
> >> >> > master bus type:
> >> >> > > AHB, AXI3, AXI4 and Native. I found the bit definition are
> >> >> > > different among
> >> >> > them.
> >> >> > > So, for the example you gave above, feel a little bit confused.
> >> >> > > Did you mean:
> >> >> > > snps,cache-type = <DATA_RD "write allocate">, <DESC_RD
> >> >> > > "cacheable">, <DATA_WR "bufferable">, <DESC_WR "read
> >> >> > > allocate">
> >> >> >
> >> >> > yeah, something like that.
> >> >>
> >> >> I think DATA_RD should be a macro, right? So, where I can put its define?
> >> >> Create a dwc3.h in include/dt-bindings/usb/ ?
> >> >
> >> > Could you please give me some advice here? I'd like to prepare next
> >> > version patch after getting this settled.
> >> >
> >> >> Another question about this remain open is: DWC3 data book's Table
> >> >> 6-5 Cache Type Bit Assignments show that bits definition will
> >> >> differ per MBUS_TYPEs as
> >> >> below:
> >> >> ----------------------------------------------------------------
> >> >> MBUS_TYPE| bit[3] |bit[2] |bit[1] |bit[0]
> >> >> ----------------------------------------------------------------
> >> >> AHB |Cacheable |Bufferable |Privilegge |Data
> >> >> AXI3 |Write Allocate|Read Allocate|Cacheable |Bufferable
> >> >> AXI4 |Allocate Other|Allocate |Modifiable |Bufferable
> >> >> AXI4 |Other Allocate|Allocate |Modifiable |Bufferable
> >> >> Native |Same as AXI |Same as AXI |Same as AXI|Same as AXI
> >> >> ----------------------------------------------------------------
> >> >> Note: The AHB, AXI3, AXI4, and PCIe busses use different names
> >> >> for certain signals, which have the same meaning:
> >> >> Bufferable = Posted
> >> >> Cacheable = Modifiable = Snoop (negation of No Snoop)
> >> >>
> >> >> For Layerscape SoCs, MBUS_TYPE is AXI3. So I am not sure how to
> >> >> use snps,cache-type = <DATA_RD "write allocate">, to cover all
> MBUS_TYPE?
> >> >> (you can notice that AHB and AXI3's cacheable are on different
> >> >> bit) Or I just need to handle AXI3 case?
> >> >
> >> > Also on this open. Thank you in advance.
> >>
> >> You could pass two strings and let the driver process them. Something
> >> like:
> >>
> >> snps,cache_type = <"data_wr" "write allocate">, <"desc_rd"
> >> "cacheable">...
> >>
> >> And so on. The only thing missing is for the mbus_type to be known by the
> driver.
> >> Is that something we can figure out on any of the HWPARAMS registers
> >> or does it have to be told explicitly?
> >
> > I have checked Layerscape Reference manual, HWPARAMS0~8 doesn't
> > contain mbus_type Info, and I didn't know where have declared it explicitly.
> >
> >> Another option would be to pass a string followed by one hex digit for the
> bits:
> >>
> >> snps,cache_type = <"data_wr" 0x8>, <"desc_rd" 0x2>...;
> >>
> >> Then we don't need to describe mbus_type since the bits are what matters.
For this option, looks like DTC doesn't allow form of <"data_wr" 0x8>, <"desc_rd" 0x2>...
It will report error when compiling:
DTC arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dtb
Error: arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi:383.23-24 syntax error
FATAL ERROR: Unable to parse input tree
scripts/Makefile.lib:294: recipe for target 'arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dtb' failed
make[2]: *** [arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dtb] Error 1
make[2]: *** Waiting for unfinished jobs....
Error: arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi:383.23-24 syntax error
FATAL ERROR: Unable to parse input tree
One of the solution I can figure out is to use macro to replace "data_wr", like below:
<DATA_WR 0x8>, <DESC_RD 0x2>...
However, it will require creating file in include/dt-bindings/usb/dwc3.h to
place macro definitions.
Or may I use: "data_wr", <0x8>, "desc_rd", <0x2>... ?
Thanks & Regards,
Ran
> > Yes, it's also what we prefer to use, it will be more flexible, I can
> > add above Table
> > 6-5 Cache Type Bit Assignments in binding to help user decide which
> > value they would use.
> >
> > I would submit another version of patch for further review, thank you very
> much.
>
> cool, thanks
>
> --
> balbi
^ permalink raw reply
* [PATCH V2 1/4] dt-bindings: opp: Support multiple opp-suspend properties
From: Anson.Huang @ 2019-07-09 8:00 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh+dt, mark.rutland, shawnguo, s.hauer,
kernel, festevam, leonard.crestez, p.zabel, ping.bai,
daniel.baluta, l.stach, abel.vesa, angus, andrew.smirnov, ccaione,
agx, linux-pm, devicetree, linux-kernel, linux-arm-kernel
Cc: Linux-imx
From: Anson Huang <Anson.Huang@nxp.com>
Update opp-suspend property's description to support multiple
opp-suspend properties defined in DT, the OPP with highest opp-hz
and with opp-suspend property present will be used as suspend opp.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
New patch.
---
Documentation/devicetree/bindings/opp/opp.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 76b6c79..6859227 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -140,8 +140,8 @@ Optional properties:
frequency for a short duration of time limited by the device's power, current
and thermal limits.
-- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
- the table should have this.
+- opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
+ in the table have this, the OPP with highest opp-hz will be used.
- opp-supported-hw: This enables us to select only a subset of OPPs from the
larger OPP table, based on what version of the hardware we are running on. We
--
2.7.4
^ permalink raw reply related
* [PATCH V2 2/4] opp: of: Support multiple suspend OPPs defined in DT
From: Anson.Huang @ 2019-07-09 8:00 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh+dt, mark.rutland, shawnguo, s.hauer,
kernel, festevam, leonard.crestez, p.zabel, ping.bai,
daniel.baluta, l.stach, abel.vesa, angus, andrew.smirnov, ccaione,
agx, linux-pm, devicetree, linux-kernel, linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <20190709080015.43442-1-Anson.Huang@nxp.com>
From: Anson Huang <Anson.Huang@nxp.com>
With property "opp-supported-hw" introduced, the OPP table
in DT could be a large OPP table and ONLY a subset of OPPs
are available, based on the version of the hardware running
on. That introduces restriction of using "opp-suspend"
property to define the suspend OPP, as we are NOT sure if the
OPP containing "opp-suspend" property is available for the
hardware running on, and the of opp core does NOT allow multiple
suspend OPPs defined in DT OPP table.
To eliminate this restrition, make of opp core allow multiple
suspend OPPs defined in DT, and pick the OPP with highest rate
and with "opp-suspend" property present to be suspend OPP, it
can speed up the suspend/resume process.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
No changes.
---
drivers/opp/of.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index b313aca..7e8ec6c 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -617,9 +617,12 @@ static struct dev_pm_opp *_opp_add_static_v2(struct opp_table *opp_table,
/* OPP to select on device suspend */
if (of_property_read_bool(np, "opp-suspend")) {
if (opp_table->suspend_opp) {
- dev_warn(dev, "%s: Multiple suspend OPPs found (%lu %lu)\n",
- __func__, opp_table->suspend_opp->rate,
- new_opp->rate);
+ /* Pick the OPP with higher rate as suspend OPP */
+ if (new_opp->rate > opp_table->suspend_opp->rate) {
+ opp_table->suspend_opp->suspend = false;
+ new_opp->suspend = true;
+ opp_table->suspend_opp = new_opp;
+ }
} else {
new_opp->suspend = true;
opp_table->suspend_opp = new_opp;
--
2.7.4
^ permalink raw reply related
* [PATCH V2 3/4] arm64: dts: imx8mq: Add opp-suspend property to OPP table
From: Anson.Huang @ 2019-07-09 8:00 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh+dt, mark.rutland, shawnguo, s.hauer,
kernel, festevam, leonard.crestez, p.zabel, ping.bai,
daniel.baluta, l.stach, abel.vesa, angus, andrew.smirnov, ccaione,
agx, linux-pm, devicetree, linux-kernel, linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <20190709080015.43442-1-Anson.Huang@nxp.com>
From: Anson Huang <Anson.Huang@nxp.com>
Add opp-suspend property to each OPP, the of opp core will
select the OPP HW supported and with highest rate to be
suspend opp, it will speed up the suspend/resume process.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 58f66cb..4ba6a25f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -156,6 +156,7 @@
/* Industrial only */
opp-supported-hw = <0xf>, <0x4>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
opp-1000000000 {
@@ -164,6 +165,7 @@
/* Consumer only */
opp-supported-hw = <0xe>, <0x3>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
opp-1300000000 {
@@ -171,6 +173,7 @@
opp-microvolt = <1000000>;
opp-supported-hw = <0xc>, <0x4>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
opp-1500000000 {
@@ -178,6 +181,7 @@
opp-microvolt = <1000000>;
opp-supported-hw = <0x8>, <0x3>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH V2 4/4] arm64: dts: imx8mm: Add opp-suspend property to OPP table
From: Anson.Huang @ 2019-07-09 8:00 UTC (permalink / raw)
To: vireshk, nm, sboyd, robh+dt, mark.rutland, shawnguo, s.hauer,
kernel, festevam, leonard.crestez, p.zabel, ping.bai,
daniel.baluta, l.stach, abel.vesa, angus, andrew.smirnov, ccaione,
agx, linux-pm, devicetree, linux-kernel, linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <20190709080015.43442-1-Anson.Huang@nxp.com>
From: Anson Huang <Anson.Huang@nxp.com>
Add opp-suspend property to each OPP, the of opp core will
select the OPP HW supported and with highest rate to be
suspend opp, it will speed up the suspend/resume process.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 398318b..973f457 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -108,6 +108,7 @@
opp-microvolt = <850000>;
opp-supported-hw = <0xe>, <0x7>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
opp-1600000000 {
@@ -115,6 +116,7 @@
opp-microvolt = <900000>;
opp-supported-hw = <0xc>, <0x7>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
opp-1800000000 {
@@ -122,6 +124,7 @@
opp-microvolt = <1000000>;
opp-supported-hw = <0x8>, <0x3>;
clock-latency-ns = <150000>;
+ opp-suspend;
};
};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH V2 1/4] dt-bindings: opp: Support multiple opp-suspend properties
From: Viresh Kumar @ 2019-07-09 8:14 UTC (permalink / raw)
To: Anson.Huang
Cc: vireshk, nm, sboyd, robh+dt, mark.rutland, shawnguo, s.hauer,
kernel, festevam, leonard.crestez, p.zabel, ping.bai,
daniel.baluta, l.stach, abel.vesa, angus, andrew.smirnov, ccaione,
agx, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
Linux-imx
In-Reply-To: <20190709080015.43442-1-Anson.Huang@nxp.com>
On 09-07-19, 16:00, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Update opp-suspend property's description to support multiple
> opp-suspend properties defined in DT, the OPP with highest opp-hz
> and with opp-suspend property present will be used as suspend opp.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> New patch.
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index 76b6c79..6859227 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -140,8 +140,8 @@ Optional properties:
> frequency for a short duration of time limited by the device's power, current
> and thermal limits.
>
> -- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
> - the table should have this.
> +- opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
> + in the table have this, the OPP with highest opp-hz will be used.
>
> - opp-supported-hw: This enables us to select only a subset of OPPs from the
> larger OPP table, based on what version of the hardware we are running on. We
LGTM. Once Rob Acks it, I will apply the first two patches to the OPP
tree.
--
viresh
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: interrupt-controller: Amazon's Annapurna Labs FIC
From: Marc Zyngier @ 2019-07-09 8:15 UTC (permalink / raw)
To: Shenhar, Talel, Rob Herring
Cc: nicolas.ferre, jason, mark.rutland, mchehab+samsung, davem,
shawn.lin, tglx, devicetree, gregkh, linux-kernel, dwmw, benh,
jonnyc, hhhawa, ronenk, hanochu, barakw
In-Reply-To: <f1fd393d-0b8c-16f1-9ac2-0589e9cb9ea7@amazon.com>
On 09/07/2019 06:59, Shenhar, Talel wrote:
> Marc, should I publish those fixes as new patch that updates the
> dt-bindings or new patchset to this list?
If you are going to update the binding, please submit a patch on top of
mainline, as it's been merged already.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: interrupt-controller: Amazon's Annapurna Labs FIC
From: Shenhar, Talel @ 2019-07-09 8:17 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: nicolas.ferre, jason, mark.rutland, mchehab+samsung, davem,
shawn.lin, tglx, devicetree, gregkh, linux-kernel, dwmw, benh,
jonnyc, hhhawa, ronenk, hanochu, barakw
In-Reply-To: <ff3794af-cd5a-5331-fca0-30280530670e@arm.com>
Thanks, will do.
On 7/9/2019 11:15 AM, Marc Zyngier wrote:
> On 09/07/2019 06:59, Shenhar, Talel wrote:
>> Marc, should I publish those fixes as new patch that updates the
>> dt-bindings or new patchset to this list?
>
> If you are going to update the binding, please submit a patch on top of
> mainline, as it's been merged already.
>
> Thanks,
>
> M.
^ permalink raw reply
* [RFC PATCH V2 0/4] media: platform: Add support for Face Detection (FD) on mt8183 SoC
From: Jerry-ch Chen @ 2019-07-09 8:41 UTC (permalink / raw)
To: hans.verkuil, laurent.pinchart+renesas, tfiga, matthias.bgg,
mchehab
Cc: shik, devicetree, Sean.Cheng, Rynn.Wu, srv_heupstream,
po-yang.huang, suleiman, Jerry-ch.Chen, jungo.lin, sj.huang,
yuzhao, linux-mediatek, zwisler, christie.yu, frederic.chen,
linux-arm-kernel, linux-media
Hello,
This RFC patch series is adding Face Detection (FD) driver on Mediatek
mt8183 SoC. It belongs to the first Mediatek's camera driver series based
on V4L2 and media controller framework. I posted the main part of the FD
driver as RFC to discuss first and would like some review comments.
==============
Introduction
==============
Face Detection (FD) unit provides hardware accelerated face detection
feature. It can detect different sizes of faces in a given image.
The driver is implemented as a normal V4L2 memory-to-memory device and
supports V4L2 controls for detection settings. It has two buffer queues.
1. Video output buffer: RAW image for face detection.
2. Meta capture buffer: Result of the detected faces.
==================
Changes in v2
==================
RFC v2 includes the following modification:
1. Implement FD as a V4L2 mem2mem driver
2. Replace meta input with V4L2 controls
==================
Changes in v1
==================
RFC v1 includes the following modification:
1. Uses Request API instead of FD's buffer collection design
2. removed unnecessary abstraction structurally, including mtk_fd_ctx and
related ops
3. removed the fd_smem node from device tree
4. Fixed the common issues Tomasz commented on Mediatek ISP Pass 1's RFC v0
patch series
==================
Dependent patch
==================
FD driver depends on SCP driver. The patches are as following:
[1]. Add support for mt8183 SCP
https://patchwork.kernel.org/cover/10991065/
==================
Compliance test
==================
* Version: https://git.linuxtv.org/v4l-utils.git/commit/?id=b16f9e945d74aa5
* Note: Those 4 failures are caused by the implementation of FD driver,
whic is a m2m device with VIDEO_OUT and META_CAPTURE queues,
therefore we can't set V4L2_CAP_VIDEO_M2M in device capability, and
fail in some non-m2m v4l2 test cases.
* Test command: v4l2-compliance -m 2
* test output:
v4l2-compliance SHA: not available, 32 bits
Compliance test for mtk-fd-4.0 device /dev/media2:
Media Driver Info:
Driver name : mtk-fd-4.0
Model : MTK-FD-V4L2
Serial :
Bus info : platform:1502b000.fd
Media version : 4.19.56
Hardware revision: 0x00000000 (0)
Driver version : 4.19.56
Required ioctls:
test MEDIA_IOC_DEVICE_INFO: OK
Allow for multiple opens:
test second /dev/media2 open: OK
test MEDIA_IOC_DEVICE_INFO: OK
test for unlimited opens: OK
Media Controller ioctls:
test MEDIA_IOC_G_TOPOLOGY: OK
Entities: 3 Interfaces: 1 Pads: 4 Links: 4
test MEDIA_IOC_ENUM_ENTITIES/LINKS: OK
test MEDIA_IOC_SETUP_LINK: OK
Total for mtk-fd-4.0 device /dev/media2: 7, Succeeded: 7, Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for mtk-fd-4.0 device /dev/video31:
Driver Info:
Driver name : mtk-fd-4.0
Card type : MTK-FD-V4L2
Bus info : platform:1502b000.fd
Driver version : 4.19.56
Capabilities : 0x84a02000
Video Output Multiplanar
Metadata Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04a02000
Video Output Multiplanar
Metadata Capture
Streaming
Extended Pix Format
Media Driver Info:
Driver name : mtk-fd-4.0
Model : MTK-FD-V4L2
Serial :
Bus info : platform:1502b000.fd
Media version : 4.19.56
Hardware revision: 0x00000000 (0)
Driver version : 4.19.56
Interface Info:
ID : 0x0300000c
Type : V4L Video
Entity Info:
ID : 0x00000001 (1)
Name : MTK-FD-V4L2-source
Function : V4L2 I/O
Pad 0x01000002 : 0: Source
Link 0x02000008: to remote pad 0x1000005 of entity 'MTK-FD-V4L2-proc': Data, Enabled, Immutable
Required ioctls:
test MC information (see 'Media Driver Info' above): OK
fail: v4l2-compliance.cpp(668): dcaps & output_caps
test VIDIOC_QUERYCAP: FAIL
Allow for multiple opens:
test second /dev/video31 open: OK
fail: v4l2-compliance.cpp(668): dcaps & output_caps
test VIDIOC_QUERYCAP: FAIL
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 1 Private Controls: 6
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
fail: v4l2-test-formats.cpp(1014): Global format mismatch: 59555956(VYUY)/26x26 vs 56595559(YUYV)/26x26
test VIDIOC_S_FMT: FAIL
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
fail: v4l2-test-buffers.cpp(667): q2.reqbufs(node->node2, 1) != EBUSY
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
test VIDIOC_EXPBUF: OK
test Requests: OK
Total for mtk-fd-4.0 device /dev/video31: 45, Succeeded: 41, Failed: 4, Warnings: 0
Grand Total for mtk-fd-4.0 device /dev/media2: 52, Succeeded: 48, Failed: 4, Warnings: 0
Jerry-ch Chen (4):
dt-bindings: mt8183: Added FD dt-bindings
dts: arm64: mt8183: Add FD nodes
media: platform: Add Mediatek FD driver KConfig
platform: mtk-isp: Add Mediatek FD driver
.../bindings/media/mediatek,mt8183-fd.txt | 33 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 12 +
drivers/media/platform/Kconfig | 2 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/mtk-isp/fd/Kconfig | 17 +
drivers/media/platform/mtk-isp/fd/Makefile | 5 +
drivers/media/platform/mtk-isp/fd/mtk_fd.h | 157 ++
drivers/media/platform/mtk-isp/fd/mtk_fd_40.c | 1259 +++++++++++++++++
include/uapi/linux/v4l2-controls.h | 4 +
9 files changed, 1491 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mediatek,mt8183-fd.txt
create mode 100644 drivers/media/platform/mtk-isp/fd/Kconfig
create mode 100644 drivers/media/platform/mtk-isp/fd/Makefile
create mode 100644 drivers/media/platform/mtk-isp/fd/mtk_fd.h
create mode 100644 drivers/media/platform/mtk-isp/fd/mtk_fd_40.c
--
2.18.0
^ permalink raw reply
* [RFC PATCH V2 1/4] dt-bindings: mt8183: Added FD dt-bindings
From: Jerry-ch Chen @ 2019-07-09 8:41 UTC (permalink / raw)
To: hans.verkuil, laurent.pinchart+renesas, tfiga, matthias.bgg,
mchehab
Cc: shik, devicetree, Sean.Cheng, Rynn.Wu, srv_heupstream,
po-yang.huang, suleiman, Jerry-ch Chen, jungo.lin, sj.huang,
yuzhao, linux-mediatek, zwisler, christie.yu, frederic.chen,
linux-arm-kernel, linux-media
In-Reply-To: <1562661672-22439-1-git-send-email-Jerry-Ch.chen@mediatek.com>
From: Jerry-ch Chen <jerry-ch.chen@mediatek.com>
This patch adds DT binding documentation for the Face Detection (FD)
unit of the Mediatek's mt8183 SoC.
Signed-off-by: Jerry-ch Chen <jerry-ch.chen@mediatek.com>
---
.../bindings/media/mediatek,mt8183-fd.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mediatek,mt8183-fd.txt
diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8183-fd.txt b/Documentation/devicetree/bindings/media/mediatek,mt8183-fd.txt
new file mode 100644
index 0000000..0837223
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mt8183-fd.txt
@@ -0,0 +1,33 @@
+* Mediatek Face Detection Unit (FD)
+
+Face Detection (FD) unit is a typical memory-to-memory HW device.
+It provides hardware accelerated face detection function, and it
+is able to detect different poses of faces. FD will writre result
+of detected face into memory as output.
+
+Required properties:
+- compatible: "mediatek,mt8183-fd"
+- mediatek,scp : the node of system control processor (SCP), see
+ Documentation/devicetree/bindings/remoteproc/mtk,scp.txt for details.
+- iommus: should point to the 3 entries: M4U_PORT_CAM_FDVT_RP,
+ M4U_PORT_CAM_FDVT_WR and M4U_PORT_CAM_FDVT_RB. (Please see
+ Documentation/devicetree/bindings/iommu/mediatek,iommu.txt for details.)
+- reg: Physical base address and length of the register space.
+- interrupts: interrupt number to the cpu.
+- clocks : must contain the FDVT clock, see
+ Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must be "fd".
+
+Example:
+ fd: fd@1502b000 {
+ compatible = "mediatek,mt8183-fd";
+ mediatek,scp = <&scp>;
+ iommus = <&iommu M4U_PORT_CAM_FDVT_RP>,
+ <&iommu M4U_PORT_CAM_FDVT_WR>,
+ <&iommu M4U_PORT_CAM_FDVT_RB>;
+ reg = <0 0x1502b000 0 0x1000>;
+ interrupts = <GIC_SPI 269 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&imgsys CLK_IMG_FDVT>;
+ clock-names = "fd";
+ };
+
--
1.9.1
^ permalink raw reply related
* [RFC PATCH V2 2/4] dts: arm64: mt8183: Add FD nodes
From: Jerry-ch Chen @ 2019-07-09 8:41 UTC (permalink / raw)
To: hans.verkuil, laurent.pinchart+renesas, tfiga, matthias.bgg,
mchehab
Cc: shik, devicetree, Sean.Cheng, Rynn.Wu, srv_heupstream,
po-yang.huang, suleiman, Jerry-ch Chen, jungo.lin, sj.huang,
yuzhao, linux-mediatek, zwisler, christie.yu, frederic.chen,
linux-arm-kernel, linux-media
In-Reply-To: <1562661672-22439-1-git-send-email-Jerry-Ch.chen@mediatek.com>
From: Jerry-ch Chen <jerry-ch.chen@mediatek.com>
This patch adds nodes for Face Detection (FD) unit. FD is embedded
in Mediatek SoCs and works with the co-processor to perform face
detection on the input data and image and output detected face result.
Signed-off-by: Jerry-ch Chen <jerry-ch.chen@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index c3a516e..7c234a0 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -432,6 +432,18 @@
#clock-cells = <1>;
};
+ fd: fd@1502b000 {
+ compatible = "mediatek,mt8183-fd";
+ mediatek,scp = <&scp>;
+ iommus = <&iommu M4U_PORT_CAM_FDVT_RP>,
+ <&iommu M4U_PORT_CAM_FDVT_WR>,
+ <&iommu M4U_PORT_CAM_FDVT_RB>;
+ reg = <0 0x1502b000 0 0x1000>;
+ interrupts = <GIC_SPI 269 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&imgsys CLK_IMG_FDVT>;
+ clock-names = "FD_CLK_IMG_FD";
+ };
+
vdecsys: syscon@16000000 {
compatible = "mediatek,mt8183-vdecsys", "syscon";
reg = <0 0x16000000 0 0x1000>;
--
1.9.1
^ permalink raw reply related
* [RFC PATCH V2 3/4] media: platform: Add Mediatek FD driver KConfig
From: Jerry-ch Chen @ 2019-07-09 8:41 UTC (permalink / raw)
To: hans.verkuil, laurent.pinchart+renesas, tfiga, matthias.bgg,
mchehab
Cc: shik, devicetree, Sean.Cheng, Rynn.Wu, srv_heupstream,
po-yang.huang, suleiman, Jerry-ch Chen, jungo.lin, sj.huang,
yuzhao, linux-mediatek, zwisler, christie.yu, frederic.chen,
linux-arm-kernel, linux-media
In-Reply-To: <1562661672-22439-1-git-send-email-Jerry-Ch.chen@mediatek.com>
From: Jerry-ch Chen <jerry-ch.chen@mediatek.com>
This patch adds KConfig for Mediatek Face Detection driver (FD).
FD is embedded in Mediatek SoCs. It can provide hardware
accelerated face detection function.
Signed-off-by: Jerry-ch Chen <jerry-ch.chen@mediatek.com>
---
drivers/media/platform/Kconfig | 2 ++
drivers/media/platform/mtk-isp/fd/Kconfig | 17 +++++++++++++++++
2 files changed, 19 insertions(+)
create mode 100644 drivers/media/platform/mtk-isp/fd/Kconfig
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index a505e9f..ae99258e 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -32,6 +32,8 @@ source "drivers/media/platform/davinci/Kconfig"
source "drivers/media/platform/omap/Kconfig"
+source "drivers/media/platform/mtk-isp/fd/Kconfig"
+
config VIDEO_ASPEED
tristate "Aspeed AST2400 and AST2500 Video Engine driver"
depends on VIDEO_V4L2
diff --git a/drivers/media/platform/mtk-isp/fd/Kconfig b/drivers/media/platform/mtk-isp/fd/Kconfig
new file mode 100644
index 0000000..0c5eaf0
--- /dev/null
+++ b/drivers/media/platform/mtk-isp/fd/Kconfig
@@ -0,0 +1,17 @@
+config VIDEO_MEDIATEK_FD
+ bool "Mediatek face detection processing function"
+ select DMA_SHARED_BUFFER
+ select VIDEOBUF2_DMA_CONTIG
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_V4L2
+ select VIDEOBUF2_MEMOPS
+ select VIDEOBUF2_VMALLOC
+ select MEDIA_CONTROLLER
+
+ default n
+ help
+ Support the Face Detectioin (FD) feature.
+
+ FD driver is a V4L2 memory-to-memory device driver which
+ provides hardware accelerated face detection function,
+ it can detect different sizes of faces in a raw image.
--
1.9.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