* [PATCH v5 4/6] ARM: dts: imx6: Add support for phyBOARD-Mira i.MX 6 DualLight/Solo RDK
From: Stefan Riedmueller @ 2018-01-09 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515514200-9801-1-git-send-email-s.riedmueller@phytec.de>
From: Christian Hemp <c.hemp@phytec.de>
Add support for the PHYTEC phyBOARD-Mira Low-Cost Rapid Development Kit
with i.MX 6DualLight/Solo with NAND.
Following interfaces are supported:
- 100 MBit Ethernet
- USB Host
- RS232
- HDMI
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Christ <s.christ@phytec.de>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts | 64 +++++++++++++++++++++++
2 files changed, 65 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b793617..07d99a1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -388,6 +388,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-icore-rqs.dtb \
imx6dl-nit6xlite.dtb \
imx6dl-nitrogen6x.dtb \
+ imx6dl-phytec-mira-rdk-nand.dtb \
imx6dl-phytec-pbab01.dtb \
imx6dl-rex-basic.dtb \
imx6dl-riotboard.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts b/arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts
new file mode 100644
index 0000000..a8adcb2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-phytec-phycore-som.dtsi"
+#include "imx6qdl-phytec-mira.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Mira DualLite/Solo Carrier-Board with NAND";
+ compatible = "phytec,imx6dl-pbac06-nand", "phytec,imx6dl-pbac06",
+ "phytec,imx6qdl-pcm058", "fsl,imx6dl";
+
+ chosen {
+ linux,stdout-path = &uart2;
+ };
+};
+
+ðphy {
+ max-speed = <100>;
+};
+
+&fec {
+ status = "okay";
+};
+
+&gpmi {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbotg {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/6] ARM: dts: imx6: Add support for phyBOARD-Mira i.MX 6Quad/Dual RDK
From: Stefan Riedmueller @ 2018-01-09 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515514200-9801-1-git-send-email-s.riedmueller@phytec.de>
From: Christian Hemp <c.hemp@phytec.de>
Add support for the PHYTEC phyBOARD-Mira Rapid Development Kit with
i.MX 6Quad/Dual with eMMC or NAND.
Following interfaces are supported:
- Gigabit Ethernet
- USB Host
- CAN
- RS232
- PCIe
- LVDS
- HDMI
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Christ <s.christ@phytec.de>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts | 72 ++++++++++++++++++++++++
arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts | 72 ++++++++++++++++++++++++
3 files changed, 146 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts
create mode 100644 arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9..b793617 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -449,6 +449,8 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-nitrogen6_max.dtb \
imx6q-nitrogen6_som2.dtb \
imx6q-novena.dtb \
+ imx6q-phytec-mira-rdk-emmc.dtb \
+ imx6q-phytec-mira-rdk-nand.dtb \
imx6q-phytec-pbab01.dtb \
imx6q-pistachio.dtb \
imx6q-rex-pro.dtb \
diff --git a/arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts b/arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts
new file mode 100644
index 0000000..8fdce3c
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-phytec-phycore-som.dtsi"
+#include "imx6qdl-phytec-mira.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Mira Quad Carrier-Board with eMMC";
+ compatible = "phytec,imx6q-pbac06-emmc", "phytec,imx6q-pbac06",
+ "phytec,imx6qdl-pcm058", "fsl,imx6q";
+
+ chosen {
+ linux,stdout-path = &uart2;
+ };
+};
+
+&can1 {
+ status = "okay";
+};
+
+&fec {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+&m25p80 {
+ status = "okay";
+};
+
+&pcie {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbotg {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
+
+&usdhc4 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts b/arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts
new file mode 100644
index 0000000..8afa5ce
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-phytec-phycore-som.dtsi"
+#include "imx6qdl-phytec-mira.dtsi"
+
+/ {
+ model = "PHYTEC phyBOARD-Mira Quad Carrier-Board with NAND";
+ compatible = "phytec,imx6q-pbac06-nand", "phytec,imx6q-pbac06",
+ "phytec,imx6qdl-pcm058", "fsl,imx6q";
+
+ chosen {
+ linux,stdout-path = &uart2;
+ };
+};
+
+&can1 {
+ status = "okay";
+};
+
+&fec {
+ status = "okay";
+};
+
+&gpmi {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c_rtc {
+ status = "okay";
+};
+
+&m25p80 {
+ status = "okay";
+};
+
+&pcie {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbotg {
+ status = "okay";
+};
+
+&usdhc1 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/6] ARM: dts: imx6: Add initial support for phyBOARD-Mira
From: Stefan Riedmueller @ 2018-01-09 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515514200-9801-1-git-send-email-s.riedmueller@phytec.de>
This patch adds basic support for PHYTEC phyBOARD-Mira as carrier board
for PHYTEC phyCORE-i.MX 6.
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Christ <s.christ@phytec.de>
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi | 390 +++++++++++++++++++++++++++++
1 file changed, 390 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi
new file mode 100644
index 0000000..9ebd438
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi
@@ -0,0 +1,390 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+
+/ {
+ aliases {
+ rtc0 = &i2c_rtc;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ power-supply = <®_backlight>;
+ pwms = <&pwm1 0 5000000>;
+ status = "okay";
+ };
+
+ gpio_leds: leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpioleds>;
+ status = "disabled";
+
+ red {
+ label = "phyboard-mira:red";
+ gpios = <&gpio5 22 GPIO_ACTIVE_HIGH>;
+ };
+
+ green {
+ label = "phyboard-mira:green";
+ gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>;
+ };
+
+ blue {
+ label = "phyboard-mira:blue";
+ gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ };
+ };
+
+ reg_backlight: regulator-backlight {
+ compatible = "regulator-fixed";
+ regulator-name = "backlight_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_en_switch: regulator-en-switch {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_en_switch>;
+ regulator-name = "Enable Switch";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ enable-active-high;
+ gpio = <&gpio3 4 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ };
+
+ reg_flexcan1: regulator-flexcan1 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1_en>;
+ regulator-name = "flexcan1-reg";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ gpio = <&gpio2 20 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_panel: regulator-panel {
+ compatible = "regulator-fixed";
+ regulator-name = "panel-power-supply";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_pcie: regulator-pcie {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie_reg>;
+ regulator-name = "mPCIe_1V5";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ gpio = <&gpio3 0 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usb_h1_vbus: usb-h1-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh1_vbus>;
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usbotg_vbus: usbotg-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg_vbus>;
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ panel {
+ compatible = "auo,g104sn02";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_panel_en>;
+ power-supply = <®_panel>;
+ enable-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>;
+ backlight = <&backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ xceiver-supply = <®_flexcan1>;
+ status = "disabled";
+};
+
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmicec>;
+ ddc-i2c-bus = <&i2c2>;
+ status = "disabled";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ clock-frequency = <400000>;
+ status = "disabled";
+
+ stmpe: touchctrl at 44 {
+ compatible = "st,stmpe811";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_stmpe>;
+ reg = <0x44>;
+ interrupt-parent = <&gpio7>;
+ interrupts = <12 IRQ_TYPE_NONE>;
+ status = "disabled";
+
+ stmpe_touchscreen {
+ compatible = "st,stmpe-ts";
+ st,sample-time = <4>;
+ st,mod-12b = <1>;
+ st,ref-sel = <0>;
+ st,adc-freq = <1>;
+ st,ave-ctrl = <1>;
+ st,touch-det-delay = <2>;
+ st,settling = <2>;
+ st,fraction-z = <7>;
+ st,i-drive = <1>;
+ };
+ };
+
+ i2c_rtc: rtc at 68 {
+ compatible = "microcrystal,rv4162";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rtc_int>;
+ reg = <0x68>;
+ interrupt-parent = <&gpio7>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ clock-frequency = <100000>;
+ status = "disabled";
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel at 0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "disabled";
+
+ port at 4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie>;
+ reset-gpio = <&gpio2 25 GPIO_ACTIVE_LOW>;
+ vpcie-supply = <®_pcie>;
+ status = "disabled";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ uart-has-rtscts;
+ status = "disabled";
+};
+
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ disable-over-current;
+ status = "disabled";
+};
+
+&usbotg {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ vbus-supply = <®_usbotg_vbus>;
+ disable-over-current;
+ status = "disabled";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio6 31 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_panel_en: panelen1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_EB0__GPIO2_IO28 0xb0b1
+ >;
+ };
+
+ pinctrl_en_switch: enswitchgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_DA4__GPIO3_IO04 0xb0b1
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
+ MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
+ >;
+ };
+
+ pinctrl_flexcan1_en: flexcan1engrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_A18__GPIO2_IO20 0xb0b1
+ >;
+ };
+
+ pinctrl_gpioleds: gpioledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT4__GPIO5_IO22 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT5__GPIO5_IO23 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT6__GPIO5_IO24 0x1b0b0
+ >;
+ };
+
+ pinctrl_hdmicec: hdmicecgrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_pcie: pciegrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__GPIO2_IO25 0xb0b1
+ >;
+ };
+
+ pinctrl_pcie_reg: pciereggrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_DA0__GPIO3_IO00 0xb0b1
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_9__PWM1_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_rtc_int: rtcintgrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_RST__GPIO7_IO08 0x1b0b0
+ >;
+ };
+
+ pinctrl_stmpe: stmpegrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D26__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_EB3__UART3_CTS_B 0x1b0b1
+ MX6QDL_PAD_EIM_D23__UART3_RTS_B 0x1b0b1
+ MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbh1_vbus: usbh1vbusgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_A20__GPIO2_IO18 0xb0b1
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
+ >;
+ };
+
+ pinctrl_usbotg_vbus: usbotgvbusgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_A19__GPIO2_IO19 0xb0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x170f9
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100f9
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170f9
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170f9
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170f9
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170f9
+ MX6QDL_PAD_EIM_BCLK__GPIO6_IO31 0xb0b1 /* CD */
+ >;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 1/6] ARM: dts: imx6: Add initial support for phyCORE-i.MX 6 SOM
From: Stefan Riedmueller @ 2018-01-09 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515514200-9801-1-git-send-email-s.riedmueller@phytec.de>
This patch adds basic support for PHYTEC phyCORE-i.MX 6 SOM with i.MX
6Quad/Dual or i.MX 6DualLight/Solo.
Signed-off-by: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Stefan Christ <s.christ@phytec.de>
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi | 279 ++++++++++++++++++++++
1 file changed, 279 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
new file mode 100644
index 0000000..6486df3
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
@@ -0,0 +1,279 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 PHYTEC Messtechnik GmbH
+ * Author: Christian Hemp <c.hemp@phytec.de>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ aliases {
+ rtc1 = &da9062_rtc;
+ rtc2 = &snvs_rtc;
+ };
+
+ /*
+ * Set the minimum memory size here and
+ * let the bootloader set the real size.
+ */
+ memory at 10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x8000000>;
+ };
+
+ gpio_leds_som: somleds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpioleds_som>;
+
+ som-led-green {
+ label = "phycore:green";
+ gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&ecspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ m25p80: flash at 0 {
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ status = "disabled";
+ };
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-handle = <ðphy>;
+ phy-mode = "rgmii";
+ phy-supply = <&vdd_eth_io>;
+ phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>;
+ status = "disabled";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy: ethernet-phy at 3 {
+ reg = <3>;
+ txc-skew-ps = <1680>;
+ rxc-skew-ps = <1860>;
+ };
+ };
+};
+
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ nand-on-flash-bbt;
+ status = "disabled";
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ clock-frequency = <400000>;
+ status = "okay";
+
+ eeprom at 50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
+
+ pmic at 58 {
+ compatible = "dlg,da9062";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ reg = <0x58>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+
+ da9062_rtc: rtc {
+ compatible = "dlg,da9062-rtc";
+ };
+
+ watchdog {
+ compatible = "dlg,da9062-watchdog";
+ };
+
+ regulators {
+ vdd_arm: buck1 {
+ regulator-name = "vdd_arm";
+ regulator-min-microvolt = <730000>;
+ regulator-max-microvolt = <1380000>;
+ regulator-always-on;
+ };
+
+ vdd_soc: buck2 {
+ regulator-name = "vdd_soc";
+ regulator-min-microvolt = <730000>;
+ regulator-max-microvolt = <1380000>;
+ regulator-always-on;
+ };
+
+ vdd_ddr3_1p5: buck3 {
+ regulator-name = "vdd_ddr3";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ };
+
+ vdd_eth_1p2: buck4 {
+ regulator-name = "vdd_eth";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ };
+
+ vdd_snvs: ldo1 {
+ regulator-name = "vdd_snvs";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+
+ vdd_high: ldo2 {
+ regulator-name = "vdd_high";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+
+ vdd_eth_io: ldo3 {
+ regulator-name = "vdd_eth_io";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+
+ vdd_emmc_1p8: ldo4 {
+ regulator-name = "vdd_emmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
+ };
+};
+
+®_arm {
+ vin-supply = <&vdd_arm>;
+};
+
+®_pu {
+ vin-supply = <&vdd_soc>;
+};
+
+®_soc {
+ vin-supply = <&vdd_soc>;
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&usdhc4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc4>;
+ bus-width = <8>;
+ non-removable;
+ vmmc-supply = <&vdd_emmc_1p8>;
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
+ MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
+ MX6QDL_PAD_SD2_DAT1__GPIO1_IO14 0x1b0b0
+ >;
+ };
+
+ pinctrl_gpioleds_som: gpioledssomgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1b0b0
+ >;
+ };
+
+ pinctrl_gpmi_nand: gpminandgrp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CLE__NAND_CLE 0xb0b1
+ MX6QDL_PAD_NANDF_ALE__NAND_ALE 0xb0b1
+ MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0xb0b1
+ MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0xb000
+ MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0xb0b1
+ MX6QDL_PAD_NANDF_CS1__NAND_CE1_B 0xb0b1
+ MX6QDL_PAD_NANDF_CS2__NAND_CE2_B 0xb0b1
+ MX6QDL_PAD_NANDF_CS3__NAND_CE3_B 0xb0b1
+ MX6QDL_PAD_SD4_CMD__NAND_RE_B 0xb0b1
+ MX6QDL_PAD_SD4_CLK__NAND_WE_B 0xb0b1
+ MX6QDL_PAD_NANDF_D0__NAND_DATA00 0xb0b1
+ MX6QDL_PAD_NANDF_D1__NAND_DATA01 0xb0b1
+ MX6QDL_PAD_NANDF_D2__NAND_DATA02 0xb0b1
+ MX6QDL_PAD_NANDF_D3__NAND_DATA03 0xb0b1
+ MX6QDL_PAD_NANDF_D4__NAND_DATA04 0xb0b1
+ MX6QDL_PAD_NANDF_D5__NAND_DATA05 0xb0b1
+ MX6QDL_PAD_NANDF_D6__NAND_DATA06 0xb0b1
+ MX6QDL_PAD_NANDF_D7__NAND_DATA07 0xb0b1
+ MX6QDL_PAD_SD4_DAT0__NAND_DQS 0x00b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
+ MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
+ MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
+ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x1b0b0
+ >;
+ };
+
+ pinctrl_pmic: pmicgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ >;
+ };
+
+ pinctrl_usdhc4: usdhc4grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_CMD__SD4_CMD 0x17059
+ MX6QDL_PAD_SD4_CLK__SD4_CLK 0x10059
+ MX6QDL_PAD_SD4_DAT0__SD4_DATA0 0x17059
+ MX6QDL_PAD_SD4_DAT1__SD4_DATA1 0x17059
+ MX6QDL_PAD_SD4_DAT2__SD4_DATA2 0x17059
+ MX6QDL_PAD_SD4_DAT3__SD4_DATA3 0x17059
+ MX6QDL_PAD_SD4_DAT4__SD4_DATA4 0x17059
+ MX6QDL_PAD_SD4_DAT5__SD4_DATA5 0x17059
+ MX6QDL_PAD_SD4_DAT6__SD4_DATA6 0x17059
+ MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
+ >;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 0/6] ARM: dts: Add PHYTEC phyCORE-i.MX 6 and phyBOARD-Mira carrier board support
From: Stefan Riedmueller @ 2018-01-09 16:09 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for the PHYTEC phyCORE-i.MX 6 and phyBOARD-Mira.
Following boards are included:
phyBOARD-Mira with phyCORE-i.MX 6 Quad/Dual with:
- i.MX 6Quad/Dual SOC
- NAND or eMMC
- HDMI interface
- LVDS display interface
- Gigabit Ethernet
- USB Host
- CAN
- RS232
- PCIe
This board also contains an LVDS camera interface and parallel display
interface which are not yet supported.
phyBAORD-Mira with phyCORE-i.MX 6 DualLight/Solo with:
- i.MX 6DualLight/Solo
- NAND
- HDMI interface
- 100 MBit/s Ethernet
- USB Host
- RS232
phyBOARD-Mira with phyCORE-i.MX 6 QuadPlus with:
- i.MX 6QuadPlus SOC
- NAND
- HDMI interface
- LVDS display interface
- Gigabit Ethernet
- USB Host
- CAN
- RS232
- PCIe
This board also contains an LVDS camera interface and parallel display
interface which are not yet supported.
The entire series is based on v4.15-rc4.
Changes since v1:
- Removed unnecessary ipu aliases
- Added unit-address to memory node name
- Fixed eeprom compatible to correct vendor name (atmel instead of cat)
- Fixed rtc compatible to correct vendor name (microcrystal instead of mc)
- Changed pcie regulator to be used with vpcie-supply in &pcie node and
removed regulator-always-on
- Changed pcie reset-gpio polarity to GPIO_ACTIVE_LOW
- Replaced fsl,uart-has-rtscts by uart-has-rtscts
- Fixed typos in defconfig patch
Changes since v2:
- Fixed typo in patch subject PATCH 4/6
- Added reviewed by tags on PATCH 4/6 and PATCH 6/6
Changes since v3:
- Removed model and compatible from phycore dtsi
- Changed flash compatible to jedec,spi-nor
- Renamed some_green node to som-led-green
- Dropped labels for eeprom, pmic, da9062_wdt and da9062_reg
- Renamed flash label to m25p80
- Put compatible at beginning of property lists
- Changed copyright year to 2018
- Added reviewed by tags on PATCH 1/6, 2/6, 3/6 and 5/6
Changes since v4:
- Rearranged &m25p80 node in dts files to fit alphabetical order
- Fixed a parenthesis for uniformity in mira dtsi
Christian Hemp (2):
ARM: dts: imx6: Add support for phyBOARD-Mira i.MX 6Quad/Dual RDK
ARM: dts: imx6: Add support for phyBOARD-Mira i.MX 6 DualLight/Solo
RDK
Enrico Scholz (1):
ARM: dts: imx6: Add support for phyBOARD-Mira with i.MX 6QuadPlus
Stefan Riedmueller (3):
ARM: dts: imx6: Add initial support for phyCORE-i.MX 6 SOM
ARM: dts: imx6: Add initial support for phyBOARD-Mira
ARM: imx_v6_v7_defconfig: Enable Dialog Semiconductor DA9062 driver
arch/arm/boot/dts/Makefile | 4 +
arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts | 64 ++++
arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts | 72 ++++
arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts | 72 ++++
arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi | 390 ++++++++++++++++++++++
arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi | 279 ++++++++++++++++
arch/arm/boot/dts/imx6qp-phytec-mira-rdk-nand.dts | 72 ++++
arch/arm/configs/imx_v6_v7_defconfig | 4 +
8 files changed, 957 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-phytec-mira-rdk-nand.dts
create mode 100644 arch/arm/boot/dts/imx6q-phytec-mira-rdk-emmc.dts
create mode 100644 arch/arm/boot/dts/imx6q-phytec-mira-rdk-nand.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
create mode 100644 arch/arm/boot/dts/imx6qp-phytec-mira-rdk-nand.dts
--
2.7.4
^ permalink raw reply
* [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
From: Laurent Pinchart @ 2018-01-09 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10903755.CJpSM8RM5e@jernej-laptop>
Hello,
On Tuesday, 9 January 2018 17:58:46 EET Jernej ?krabec wrote:
> Dne torek, 09. januar 2018 ob 11:43:08 CET je Archit Taneja napisal(a):
> > On 12/31/2017 02:31 AM, Jernej Skrabec wrote:
> >> Parts of PHY code could be useful also for custom PHYs. For example,
> >> Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> >> with few additional memory mapped registers, so most of the Synopsys PHY
> >> related code could be reused.
> >>
> >> It turns out that even completely custom HDMI PHYs, such as the one
> >> found in Allwinner H3, can reuse some of those functions. This would
> >> suggest that (some?) functions exported in this commit are actually part
> >> of generic PHY interface and not really specific to Synopsys PHYs.
> >>
> >> Export useful PHY functions.
> >>
> >> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> ---
> >>
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 +++++++++++++++++-------
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> >> include/drm/bridge/dw_hdmi.h | 10 +++++++
> >> 3 files changed, 44 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> >> 7ca14d7325b5..67467d0b683a 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
[snip]
> >> @@ -1065,6 +1067,23 @@ static void
> >> dw_hdmi_phy_sel_interface_control(struct dw_hdmi *hdmi, u8 enable)
> >> HDMI_PHY_CONF0_SELDIPIF_MASK);
> >> }
> >>
> >> +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> >> +{
> >> + hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> >> + HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> >> + HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> >> +}
> >> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
I don't remember the details, is the reset signal Gen2-specific ?
How about asserting and deasserting the reset signal in the same call instead
of having to call this function twice ?
> >> +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> >> +{
> >> + hdmi_phy_test_clear(hdmi, 1);
> >> + hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> >> + HDMI_PHY_I2CM_SLAVE_ADDR);
> >> + hdmi_phy_test_clear(hdmi, 0);
> >> +}
> >> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
> >
> > Should this be called dw_hdmi_phy_gen2_set_slave_addr?
>
> Probably. I will rename it in v2 to be consistent with other phy functions.
The I2C write function is called dw_hdmi_phy_i2c_write(). If we want to be
conosistent we should either rename this one to dw_hdmi_phy_i2c_set_addr() or
rename them both to dw_hdmi_phy_gen2_i2c_write() and
dw_hdmi_phy_gen2_i2c_set_addr(). I think I'd prefer the former, and we could
even drop gen2 from dw_hdmi_phy_gen2_pddq() and dw_hdmi_phy_gen2_txpwron() if
desired.
> > Looks good otherwise. Same for patches 3 and 4 in this series.
> >
> >> +
> >> static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> >> {
> >> const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
[snip]
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
From: Jernej Škrabec @ 2018-01-09 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4765263.5spOVExvvT@avalon>
Hi Laurent,
Dne torek, 09. januar 2018 ob 14:30:22 CET je Laurent Pinchart napisal(a):
> Hi Jernej,
>
> Thank you for the patch.
>
> On Saturday, 30 December 2017 23:01:56 EET Jernej Skrabec wrote:
> > Parts of PHY code could be useful also for custom PHYs. For example,
> > Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> > with few additional memory mapped registers, so most of the Synopsys PHY
> > related code could be reused.
> >
> > It turns out that even completely custom HDMI PHYs, such as the one
> > found in Allwinner H3, can reuse some of those functions. This would
> > suggest that (some?) functions exported in this commit are actually part
> > of generic PHY interface and not really specific to Synopsys PHYs.
>
> That's correct, those functions control the interface between the HDMI
> controller and the PHY. They're not specific to Synopsys PHYs, but they're
> specific to the PHY interface as designed by Synopsys.
Ok, I'll update commit message.
>
> > Export useful PHY functions.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45
> > ++++++++++++++++++++-------
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> > include/drm/bridge/dw_hdmi.h | 10 +++++++
> > 3 files changed, 44 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 7ca14d7325b5..67467d0b683a 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct
> > dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SVSRET_MASK);
> >
> > }
> >
> > -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
> > HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
> >
> > -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
> > HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
> >
> > static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
> > {
> >
> > @@ -1065,6 +1067,23 @@ static void
> > dw_hdmi_phy_sel_interface_control(struct
> > dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SELDIPIF_MASK);
> >
> > }
> >
> > +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> > +{
> > + hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
> > +
> > +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> > +{
> > + hdmi_phy_test_clear(hdmi, 1);
> > + hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > + HDMI_PHY_I2CM_SLAVE_ADDR);
> > + hdmi_phy_test_clear(hdmi, 0);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
>
> Should the I2C address be passed as an argument ?
Yes, I already planned to do that for v2.
Best regards,
Jernej
>
> > static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> > {
> >
> > const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> >
> > @@ -1204,15 +1223,12 @@ static int hdmi_phy_configure(struct dw_hdmi
> > *hdmi)
> >
> > dw_hdmi_phy_enable_svsret(hdmi, 1);
> >
> > /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> >
> > - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> > - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> > + dw_hdmi_phy_gen2_reset(hdmi, 1);
> > + dw_hdmi_phy_gen2_reset(hdmi, 0);
> >
> > hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
> >
> > - hdmi_phy_test_clear(hdmi, 1);
> > - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > - HDMI_PHY_I2CM_SLAVE_ADDR);
> > - hdmi_phy_test_clear(hdmi, 0);
> > + dw_hdmi_phy_set_slave_addr(hdmi);
> >
> > /* Write to the PHY as configured by the platform */
> > if (pdata->configure_phy)
> >
> > @@ -1251,15 +1267,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> > *hdmi, void *data) dw_hdmi_phy_power_off(hdmi);
> >
> > }
> >
> > -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi
> > *hdmi, - void *data)
> > +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> > + void *data)
> >
> > {
> >
> > return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
> >
> > connector_status_connected : connector_status_disconnected;
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
> >
> > -static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> > - bool force, bool disabled, bool rxsense)
> > +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> > + bool force, bool disabled, bool rxsense)
> >
> > {
> >
> > u8 old_mask = hdmi->phy_mask;
> >
> > @@ -1271,8 +1288,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi
> > *hdmi, void *data, if (old_mask != hdmi->phy_mask)
> >
> > hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_update_hpd);
> >
> > -static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
> > +void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
> >
> > {
> >
> > /*
> >
> > * Configure the PHY RX SENSE and HPD interrupts polarities and clear
> >
> > @@ -1291,6 +1309,7 @@ static void dw_hdmi_phy_setup_hpd(struct dw_hdmi
> > *hdmi, void *data) hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD |
> > HDMI_IH_PHY_STAT0_RX_SENSE), HDMI_IH_MUTE_PHY_STAT0);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_setup_hpd);
> >
> > static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
> >
> > .init = dw_hdmi_phy_init,
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index
> > 9d90eb9c46e5..fd150430d0b3 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > @@ -950,6 +950,8 @@ enum {
> >
> > /* MC_PHYRSTZ field values */
> >
> > HDMI_MC_PHYRSTZ_PHYRSTZ = 0x01,
> >
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET = 0x00,
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_MASK = 0x01,
> >
> > /* MC_HEACPHY_RST field values */
> >
> > HDMI_MC_HEACPHY_RST_ASSERT = 0x1,
> >
> > diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> > index 182f83283e24..f5cca4362154 100644
> > --- a/include/drm/bridge/dw_hdmi.h
> > +++ b/include/drm/bridge/dw_hdmi.h
> > @@ -159,5 +159,15 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
> >
> > /* PHY configuration */
> > void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
> >
> > unsigned char addr);
> >
> > +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> > + void *data);
> > +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> > + bool force, bool disabled, bool rxsense);
> > +void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
> > +
> > +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable);
> > +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable);
> > +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable);
> > +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi);
> >
> > #endif /* __IMX_HDMI_H__ */
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
From: Jernej Škrabec @ 2018-01-09 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b454804-e910-e8e8-6d2b-5bc25c7a4d4c@codeaurora.org>
Hi Archit,
Dne torek, 09. januar 2018 ob 11:43:08 CET je Archit Taneja napisal(a):
> On 12/31/2017 02:31 AM, Jernej Skrabec wrote:
> > Parts of PHY code could be useful also for custom PHYs. For example,
> > Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> > with few additional memory mapped registers, so most of the Synopsys PHY
> > related code could be reused.
> >
> > It turns out that even completely custom HDMI PHYs, such as the one
> > found in Allwinner H3, can reuse some of those functions. This would
> > suggest that (some?) functions exported in this commit are actually part
> > of generic PHY interface and not really specific to Synopsys PHYs.
> >
> > Export useful PHY functions.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45
> > ++++++++++++++++++++++---------
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> > include/drm/bridge/dw_hdmi.h | 10 +++++++
> > 3 files changed, 44 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 7ca14d7325b5..67467d0b683a 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct
> > dw_hdmi *hdmi, u8 enable)>
> > HDMI_PHY_CONF0_SVSRET_MASK);
> >
> > }
> >
> > -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
> > HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
> >
> > -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
> > HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
> >
> > static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
> > {
> >
> > @@ -1065,6 +1067,23 @@ static void
> > dw_hdmi_phy_sel_interface_control(struct dw_hdmi *hdmi, u8 enable)>
> > HDMI_PHY_CONF0_SELDIPIF_MASK);
> >
> > }
> >
> > +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> > +{
> > + hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
> > +
> > +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> > +{
> > + hdmi_phy_test_clear(hdmi, 1);
> > + hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > + HDMI_PHY_I2CM_SLAVE_ADDR);
> > + hdmi_phy_test_clear(hdmi, 0);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
>
> Should this be called dw_hdmi_phy_gen2_set_slave_addr?
Probably. I will rename it in v2 to be consistent with other phy functions.
Best regards,
Jernej
>
> Looks good otherwise. Same for patches 3 and 4 in this series.
>
> Thanks,
> Archit
>
> > +
> >
> > static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> > {
> >
> > const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> >
> > @@ -1204,15 +1223,12 @@ static int hdmi_phy_configure(struct dw_hdmi
> > *hdmi)
> >
> > dw_hdmi_phy_enable_svsret(hdmi, 1);
> >
> > /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> >
> > - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> > - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> > + dw_hdmi_phy_gen2_reset(hdmi, 1);
> > + dw_hdmi_phy_gen2_reset(hdmi, 0);
> >
> > hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
> >
> > - hdmi_phy_test_clear(hdmi, 1);
> > - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > - HDMI_PHY_I2CM_SLAVE_ADDR);
> > - hdmi_phy_test_clear(hdmi, 0);
> > + dw_hdmi_phy_set_slave_addr(hdmi);
> >
> > /* Write to the PHY as configured by the platform */
> > if (pdata->configure_phy)
> >
> > @@ -1251,15 +1267,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> > *hdmi, void *data)>
> > dw_hdmi_phy_power_off(hdmi);
> >
> > }
> >
> > -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi
> > *hdmi, - void *data)
> > +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> > + void *data)
> >
> > {
> >
> > return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
> >
> > connector_status_connected : connector_status_disconnected;
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
> >
> > -static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> > - bool force, bool disabled, bool rxsense)
> > +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> > + bool force, bool disabled, bool rxsense)
> >
> > {
> >
> > u8 old_mask = hdmi->phy_mask;
> >
> > @@ -1271,8 +1288,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi
> > *hdmi, void *data,>
> > if (old_mask != hdmi->phy_mask)
> >
> > hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_update_hpd);
> >
> > -static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
> > +void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
> >
> > {
> >
> > /*
> >
> > * Configure the PHY RX SENSE and HPD interrupts polarities and clear
> >
> > @@ -1291,6 +1309,7 @@ static void dw_hdmi_phy_setup_hpd(struct dw_hdmi
> > *hdmi, void *data)>
> > hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD |
> > HDMI_IH_PHY_STAT0_RX_SENSE),
> >
> > HDMI_IH_MUTE_PHY_STAT0);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_setup_hpd);
> >
> > static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
> >
> > .init = dw_hdmi_phy_init,
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index
> > 9d90eb9c46e5..fd150430d0b3 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > @@ -950,6 +950,8 @@ enum {
> >
> > /* MC_PHYRSTZ field values */
> >
> > HDMI_MC_PHYRSTZ_PHYRSTZ = 0x01,
> >
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET = 0x00,
> > + HDMI_MC_PHYRSTZ_PHYRSTZ_MASK = 0x01,
> >
> > /* MC_HEACPHY_RST field values */
> >
> > HDMI_MC_HEACPHY_RST_ASSERT = 0x1,
> >
> > diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> > index 182f83283e24..f5cca4362154 100644
> > --- a/include/drm/bridge/dw_hdmi.h
> > +++ b/include/drm/bridge/dw_hdmi.h
> > @@ -159,5 +159,15 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
> >
> > /* PHY configuration */
> > void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
> >
> > unsigned char addr);
> >
> > +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> > + void *data);
> > +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> > + bool force, bool disabled, bool rxsense);
> > +void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
> > +
> > +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable);
> > +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable);
> > +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable);
> > +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi);
> >
> > #endif /* __IMX_HDMI_H__ */
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 05/67] dma-mapping: replace PCI_DMA_BUS_IS_PHYS with a flag in struct dma_map_ops
From: Jesper Nilsson @ 2018-01-09 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171229081911.2802-6-hch@lst.de>
On Fri, Dec 29, 2017 at 09:18:09AM +0100, Christoph Hellwig wrote:
> The current PCI_DMA_BUS_IS_PHYS decided if a dma implementation is bound
> by the dma mask in the device because it directly maps to a physical
> address range (modulo an offset in the device), or if it is virtualized
> by an iommu and can map any address (that includes virtual iommus like
> swiotlb). The problem with this scheme is that it is per-architecture and
> not per dma_ops instance, and we are growing more and more setups that
> have multiple different dma operations in use on a single system, for
> which this scheme can't provide a correct answer. Depending on the
> architecture that means we either get a false positive or false negative
> at the moment.
>
> This patch instead extents the is_phys flag in struct dma_map_ops that
> is currently only used by a few architectures to be used tree wide.
>
> Note that this means that we now need a struct device parent in the
> Scsi_Host or netdevice. Every modern driver has these, but there might
> still be a few outdated legacy drivers out there, which now won't make
> an intelligent decision.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
For the CRIS part:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> ---
> arch/cris/arch-v32/drivers/pci/dma.c | 1 +
> arch/cris/include/asm/pci.h | 6 ------
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply
* [PATCH 22/67] dma-mapping: clear harmful GFP_* flags in common code
From: Jesper Nilsson @ 2018-01-09 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171229081911.2802-23-hch@lst.de>
On Fri, Dec 29, 2017 at 09:18:26AM +0100, Christoph Hellwig wrote:
> Life the code from x86 so that we behave consistently. In the future we
> should probably warn if any of these is set.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> ---
> arch/cris/arch-v32/drivers/pci/dma.c | 3 ---
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls
From: Jernej Škrabec @ 2018-01-09 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v6463B-JVw5A9C39iiuo7Xzj3Bq06m6VzdAUqr0b-S91MQ@mail.gmail.com>
Hi Chen-Yu,
Dne ponedeljek, 08. januar 2018 ob 10:19:47 CET je Chen-Yu Tsai napisal(a):
> On Fri, Jan 5, 2018 at 3:28 AM, Jernej ?krabec <jernej.skrabec@siol.net>
wrote:
> > Hi,
> >
> > Dne ?etrtek, 04. januar 2018 ob 15:45:18 CET je Chen-Yu Tsai napisal(a):
> >> On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec <jernej.skrabec@siol.net>
> >
> > wrote:
> >> > For example, A83T have nmp plls which are modelled as nkmp plls. Since
> >> > k
> >> > is not specified, it has offset 0, shift 0 and lowest value 1. This
> >> > means that LSB bit is always set to 1, which may change clock rate.
> >> >
> >> > Fix that by applying k factor only if k width is greater than 0.
> >> >
> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> > ---
> >> >
> >> > drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +++++++++++++--------
> >> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >> >
> >> > diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c
> >> > b/drivers/clk/sunxi-ng/ccu_nkmp.c index e58c95787f94..709f528af2b3
> >> > 100644
> >> > --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> >> > +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> >> > @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct
> >> > clk_hw
> >> > *hw,>
> >> >
> >> > unsigned long parent_rate)
> >> >
> >> > {
> >> >
> >> > struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> >> >
> >> > - unsigned long n, m, k, p;
> >> > + unsigned long n, m, k = 1, p;
> >> >
> >> > u32 reg;
> >> >
> >> > reg = readl(nkmp->common.base + nkmp->common.reg);
> >> >
> >> > @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct
> >> > clk_hw *hw,>
> >> >
> >> > if (!n)
> >> >
> >> > n++;
> >> >
> >> > - k = reg >> nkmp->k.shift;
> >> > - k &= (1 << nkmp->k.width) - 1;
> >> > - k += nkmp->k.offset;
> >> > - if (!k)
> >> > - k++;
> >> > + if (nkmp->k.width) {
> >> > + k = reg >> nkmp->k.shift;
> >> > + k &= (1 << nkmp->k.width) - 1;
> >> > + k += nkmp->k.offset;
> >> > + if (!k)
> >> > + k++;
> >> > + }
> >>
> >> The conditional shouldn't be necessary. With nkmp->k.width = 0,
> >> you'd simply get k & 0, which is 0, which then gets bumped up to 1,
> >> unless k.offset > 1, which would be a bug.
> >>
> >> > m = reg >> nkmp->m.shift;
> >> > m &= (1 << nkmp->m.width) - 1;
> >> >
> >> > @@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw,
> >> > unsigned long rate,>
> >> >
> >> > reg = readl(nkmp->common.base + nkmp->common.reg);
> >> > reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1,
> >> > nkmp->n.shift);
> >> >
> >> > - reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
> >> > nkmp->k.shift);
> >> > + if (nkmp->k.width)
> >> > + reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
> >> > + nkmp->k.shift);
> >> >
> >> > reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1,
> >> > nkmp->m.shift);
> >> > reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1,
> >> > nkmp->p.shift);
> >> >
> >> > reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
> >> >
> >> > - reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> >> > + if (nkmp->k.width)
> >> > + reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> >>
> >> I think a better way would be
> >>
> >> reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) &
> >>
> >> GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
> >>
> >> And do this for all the factors, not just k. This pattern is what
> >> regmap_update_bits does, which seems much safer. I wonder what
> >> GENMASK() with a negative value would do though...
> >
> > You're right, GENMASK(-1, 0) equals 0 (calculated by hand, not tested).
> > This seems much more elegant solution.
> >
> > Semi-related question: All nmp PLLs have much wider N range than real nkmp
> > PLLs. This causes integer overflow when using nkmp formula from datasheet.
> > Usually, N is 1-256 for nmp PLLs, which means that for very high N
> > factors, it overflows. This also causes issue that M factor is never
> > higher than 1.
> Sounds like we can't use u8 for storing the factors. At least the
> intermediate values we use to calculate the rates.
Only issue with u8 could be max field in struct ccu_mult_internal for K factor.
But since it's not used, there is no issue. All intermediate variables in
ccu_nkmp are wider.
>
> > I was wondering, if patch would be acceptable which would change this
> > formula:
> >
> > RATE = (24MHz * N * K) / (M * P)
> >
> > to this:
> >
> > RATE ((24MHz / M) * N * K) / P
> >
> > I checked all M factors and are all in 1-4 or 1-2 range, which means it
> > wouldn't have any impact for real nkmp PLLs when parent is 24 MHz clock
> > which is probably always.
> >
> > What do you think?
>
> I think this is acceptable. M is normally the pre-divider, so this
> actually fits how the hardware works, including possible rounding
> errors.
Ok, I'll add a patch for that in v2.
Best regards,
Jernej
>
> ChenYu
>
> > I discovered that when I tried to set A83T PLL_VIDEO to 346.5 MHz which is
> > possible only when above formula is changed.
> >
> > Best regards,
> > Jernej
> >
> >> ChenYu
> >>
> >> > reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift;
> >> > reg |= ilog2(_nkmp.p) << nkmp->p.shift;
> >> >
> >> > --
> >> > 2.15.1
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > linux-sunxi+unsubscribe at googlegroups.com. For more options, visit
> > https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-09 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109151735.GB23676@kwain>
Hi Russell,
On Tue, Jan 09, 2018 at 04:17:35PM +0100, Antoine Tenart wrote:
> On Tue, Jan 09, 2018 at 02:44:48PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote:
> > > val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
> > > MVPP2_GMAC_CONFIG_FULL_DUPLEX;
> > > + else if (port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
> > > + val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
> > > + MVPP2_GMAC_CONFIG_MII_SPEED |
> > > + MVPP2_GMAC_CONFIG_FULL_DUPLEX;
> >
> > I think you'll find you don't need to set MII_SPEED here, since
> > MII_SPEED selects between 10 and 100, GMII_SPEED always takes
> > precidence selecting 1000, and 2500 is done by the comphy
> > increasing the clocks by 2.5x.
>
> I just had a look at the datasheet, and as you say it seems GMII_SPEED
> takes over MII_SPEED. I'll see if there is a corner case here or if
> selecting MII_SPEED doesn't make sense, and update accordingly.
I just checked, this can be removed for this mode. I'll update the
patch.
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 34/67] cris: use dma-direct
From: Jesper Nilsson @ 2018-01-09 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171229081911.2802-35-hch@lst.de>
On Fri, Dec 29, 2017 at 09:18:38AM +0100, Christoph Hellwig wrote:
> cris currently has an incomplete direct mapping dma_map_ops implementation
> is PCI support is enabled. Replace it with the fully feature generic
> dma-direct implementation.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
For CRIS:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> ---
> arch/cris/Kconfig | 4 ++
> arch/cris/arch-v32/drivers/pci/Makefile | 2 +-
> arch/cris/arch-v32/drivers/pci/dma.c | 78 ---------------------------------
> arch/cris/include/asm/Kbuild | 1 +
> arch/cris/include/asm/dma-mapping.h | 20 ---------
> 5 files changed, 6 insertions(+), 99 deletions(-)
> delete mode 100644 arch/cris/arch-v32/drivers/pci/dma.c
> delete mode 100644 arch/cris/include/asm/dma-mapping.h
>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply
* [PATCH v2 3/7] PCI: aardvark: set host and device to the same MAX payload size
From: Thomas Petazzoni @ 2018-01-09 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171005173102.GR25517@bhelgaas-glaptop.roam.corp.google.com>
Hello Bjorn,
On Thu, 5 Oct 2017 12:31:02 -0500, Bjorn Helgaas wrote:
> On Thu, Sep 28, 2017 at 02:58:34PM +0200, Thomas Petazzoni wrote:
> > From: Victor Gu <xigu@marvell.com>
> >
> > Since the Aardvark does not implement a PCIe root bus,
>
> What exactly do you mean by "does not implement a PCIe root bus"? I
> assume there is still a hierarchy of PCI buses, and I assume the
> hierarchy has a top-most ("root") bus.
>
> Maybe there's no Root Port? There are other systems that don't have
> Root Ports, and we've made changes to accommodate that, e.g.,
>
> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?id=1b8a6079015f
I'm trying to get back (finally) to this topic. Unfortunately, your
branch has been rebased, and this commit no longer exists. Do you have
an updated pointer about what you suggest to use for systems that don't
have Root Ports ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
From: Christoph Hellwig @ 2018-01-09 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104084930.GB3251@lst.de>
On Thu, Jan 04, 2018 at 09:49:30AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 02, 2018 at 08:45:30PM +1100, Michael Ellerman wrote:
> > Christoph Hellwig <hch@lst.de> writes:
> >
> > > We want to use the dma_direct_ namespace for a generic implementation,
> > > so rename powerpc to the second best choice: dma_nommu_.
> >
> > I'm not a fan of "nommu". Some of the users of direct ops *are* using an
> > IOMMU, they're just setting up a 1:1 mapping once at init time, rather
> > than mapping dynamically.
> >
> > Though I don't have a good idea for a better name, maybe "1to1",
> > "linear", "premapped" ?
>
> It seems like a nice counter part to the dma_iommu_ops used just about
> anywhere else in ppc.
>
> But I'll happily take any maintainer bike shed decision for the next
> series. Remember that in a merge window or two it will hopefully
> go away in favor of the new generic dma_direct ops.
Michael, please suggest what name you want for the next iteration,
I don't want to hold up the series on a naming bikeshed.
^ permalink raw reply
* [PATCH v2] iommu/exynos: Don't unconditionally steal bus ops
From: Robin Murphy @ 2018-01-09 15:34 UTC (permalink / raw)
To: linux-arm-kernel
Removing the early device registration hook overlooked the fact that
it only ran conditionally on a compatible device being present in the
DT. With exynos_iommu_init() now running as an unconditional initcall,
problems arise on non-Exynos systems when other IOMMU drivers find
themselves unable to install their ops on the platform bus, or at worst
the Exynos ops get called with someone else's domain and all hell breaks
loose.
The global ops/cache setup could probably all now be triggered from the
first IOMMU probe, as with dma_dev assigment, but for the time being the
simplest fix is to resurrect the logic from commit a7b67cd5d9af
("iommu/exynos: Play nice in multi-platform builds") to explicitly check
the DT for the presence of an Exynos IOMMU before trying anything.
Fixes: 928055a01b3f ("iommu/exynos: Remove custom platform device registration code")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Use the simpler explicit DT check.
drivers/iommu/exynos-iommu.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 79c45650f8de..736d4552d96f 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1353,8 +1353,15 @@ static const struct iommu_ops exynos_iommu_ops = {
static int __init exynos_iommu_init(void)
{
+ struct device_node *np;
int ret;
+ np = of_find_matching_node(NULL, sysmmu_of_match);
+ if (!np)
+ return 0;
+
+ of_node_put(np);
+
lv2table_kmem_cache = kmem_cache_create("exynos-iommu-lv2table",
LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL);
if (!lv2table_kmem_cache) {
--
2.13.4.dirty
^ permalink raw reply related
* [PATCH] pwm: mediatek: fix up PWM4 and PWM5 malfunction on MT7623
From: Matthias Brugger @ 2018-01-09 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7ddf36f5b9400b29578d4897ddea72c57c1c8d11.1514213639.git.sean.wang@mediatek.com>
On 12/25/2017 03:59 PM, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Since the offset for both registers, PWMDWIDTH and PWMTHRES, used to
> control PWM4 or PWM5 are distinct from the other PWMs, whose wrong
> programming on PWM hardware causes waveform cannot be output as expected.
> Thus, the patch adds the extra condition for fixing up the weird case to
> let PWM4 or PWM5 able to work on MT7623.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Cc: Zhi Mao <zhi.mao@mediatek.com>
> Cc: John Crispin <john@phrozen.org>
> ---
> drivers/pwm/pwm-mediatek.c | 24 +++++++++++++++++++++---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
> index f5d97e0..9311574 100644
> --- a/drivers/pwm/pwm-mediatek.c
> +++ b/drivers/pwm/pwm-mediatek.c
> @@ -29,7 +29,9 @@
> #define PWMGDUR 0x0c
> #define PWMWAVENUM 0x28
> #define PWMDWIDTH 0x2c
> +#define PWM45DWIDTH_QUIRK 0x30
> #define PWMTHRES 0x30
> +#define PWM45THRES_QUIRK 0x34
>
> #define PWM_CLK_DIV_MAX 7
>
> @@ -54,6 +56,7 @@ static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
>
> struct mtk_pwm_platform_data {
> unsigned int num_pwms;
> + bool pwm45_quirk;
> };
>
> /**
> @@ -66,6 +69,7 @@ struct mtk_pwm_chip {
> struct pwm_chip chip;
> void __iomem *regs;
> struct clk *clks[MTK_CLK_MAX];
> + const struct mtk_pwm_platform_data *soc;
> };
>
> static const unsigned int mtk_pwm_reg_offset[] = {
> @@ -131,7 +135,8 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> {
> struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
> struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
> - u32 resolution, clkdiv = 0;
> + u32 resolution, clkdiv = 0, reg_width = PWMDWIDTH,
> + reg_thres = PWMTHRES;
> int ret;
>
> ret = mtk_pwm_clk_enable(chip, pwm);
> @@ -151,9 +156,18 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> return -EINVAL;
> }
>
> + if (pc->soc->pwm45_quirk && pwm->hwpwm > 2) {
> + /*
> + * PWM[4,5] has distinct offset for PWMDWIDTH and PWMTHRES
> + * from the other PWMs on MT7623.
> + */
> + reg_width = PWM45DWIDTH_QUIRK;
> + reg_thres = PWM45THRES_QUIRK;
> + }
> +
> mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv);
> - mtk_pwm_writel(pc, pwm->hwpwm, PWMDWIDTH, period_ns / resolution);
> - mtk_pwm_writel(pc, pwm->hwpwm, PWMTHRES, duty_ns / resolution);
> + mtk_pwm_writel(pc, pwm->hwpwm, reg_width, period_ns / resolution);
> + mtk_pwm_writel(pc, pwm->hwpwm, reg_thres, duty_ns / resolution);
>
> mtk_pwm_clk_disable(chip, pwm);
>
> @@ -211,6 +225,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
> data = of_device_get_match_data(&pdev->dev);
> if (data == NULL)
> return -EINVAL;
> + pc->soc = data;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> pc->regs = devm_ioremap_resource(&pdev->dev, res);
> @@ -251,14 +266,17 @@ static int mtk_pwm_remove(struct platform_device *pdev)
>
> static const struct mtk_pwm_platform_data mt2712_pwm_data = {
> .num_pwms = 8,
> + .pwm45_quirk = false,
Hm for me it doesn't look like a quirk but just the values a different. I wonder
why you decided to add a quirk flag. I'd added the access values to the
mtk_pwm_platform_data struct directly.
Regards,
Matthias
^ permalink raw reply
* [PATCH 03/11] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a
From: Neil Armstrong @ 2018-01-09 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3367423.0HCaRuLuz8@avalon>
Hi,
I think this question is for Jose.
On 09/01/2018 13:56, Laurent Pinchart wrote:
> Hi Jernej,
>
> Thank you for the patch.
>
> On Saturday, 30 December 2017 23:01:55 EET Jernej Skrabec wrote:
>> Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
>> magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.
We observe the same issue on Amlogic SoCs with the dw hdmi controller v2.01a.
Rockchip seems to also use count=1 for 0x200a, 0x201a and 0x211a in
https://github.com/rockchip-linux/kernel/commit/cafa8ebd5f4df41425d6f2f61633d5bc64f20e65
Changelog is :
The issue can be worked around by issuing a TMDS software reset and
then write one of the FC registers several times. After tested, the
number of iterations of RK3399/RK3328(v2.11a), RK3368(v2.01a),
RK3288(v2.00a) is one.
Can you confirm it is necessary ?
Neil
>>
>> Tests show that one iteration is enough.
>>
>> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>
> This does not break R-Car DU, so
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +++++---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
>> a38db40ce990..7ca14d7325b5 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -1634,9 +1634,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi
>> *hdmi) * then write one of the FC registers several times.
>> *
>> * The number of iterations matters and depends on the HDMI TX revision
>> - * (and possibly on the platform). So far only i.MX6Q (v1.30a) and
>> - * i.MX6DL (v1.31a) have been identified as needing the workaround, with
>> - * 4 and 1 iterations respectively.
>> + * (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
>> + * (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
>> + * as needing the workaround, with 4 iterations for v1.30a and 1
>> + * iteration for others.
>> */
>>
>> switch (hdmi->version) {
>> @@ -1644,6 +1645,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi
>> *hdmi) count = 4;
>> break;
>> case 0x131a:
>> + case 0x132a:
>> count = 1;
>> break;
>> default:
>
^ permalink raw reply
* [PATCH] soc: imx: gpc: de-register power domains only if initialized
From: Lucas Stach @ 2018-01-09 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180107134905.15624-1-stefan@agner.ch>
Am Sonntag, den 07.01.2018, 14:49 +0100 schrieb Stefan Agner:
> If power domain information are missing in the device tree, no
> power domains get initialized. However, imx_gpc_remove tries to
> remove power domains always in the old DT binding case. Only
> remove power domains when imx_gpc_probe initialized them in
> first place.
>
> Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC
> driver")
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> ?drivers/soc/imx/gpc.c | 10 +++++++++-
> ?1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index 53f7275d6cbd..62bb724726d9 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -470,13 +470,21 @@ static int imx_gpc_probe(struct platform_device
> *pdev)
> ?
> ?static int imx_gpc_remove(struct platform_device *pdev)
> ?{
> + struct device_node *pgc_node;
> ? int ret;
> ?
> + pgc_node = of_get_child_by_name(pdev->dev.of_node, "pgc");
> +
> + /* bail out if DT too old and doesn't provide the necessary
> info */
> + if (!of_property_read_bool(pdev->dev.of_node, "#power-
> domain-cells") &&
> + ????!pgc_node)
> + return 0;
> +
> ? /*
> ? ?* If the old DT binding is used the toplevel driver needs
> to
> ? ?* de-register the power domains
> ? ?*/
> - if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
> + if (!pgc_node) {
> ? of_genpd_del_provider(pdev->dev.of_node);
> ?
> ? ret =
> pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
^ permalink raw reply
* [PATCH] ARM: imx: Remove epit support
From: Fabio Estevam @ 2018-01-09 15:24 UTC (permalink / raw)
To: linux-arm-kernel
Currently there is no user of EPIT, so remove such unused code.
If someone wants to add EPIT support back, then the person needs to
create a proper support into drivers/clocksource/ and add device
tree support, proper bindings, etc.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/mach-imx/Kconfig | 13 ---
arch/arm/mach-imx/Makefile | 1 -
arch/arm/mach-imx/epit.c | 228 ---------------------------------------------
3 files changed, 242 deletions(-)
delete mode 100644 arch/arm/mach-imx/epit.c
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 782699e..1831319 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -32,18 +32,6 @@ config MXC_DEBUG_BOARD
data/address de-multiplexing and decode, signal level shift,
interrupt control and various board functions.
-config HAVE_EPIT
- bool
-
-config MXC_USE_EPIT
- bool "Use EPIT instead of GPT"
- depends on HAVE_EPIT
- help
- Use EPIT as the system timer on systems that have it. Normally you
- don't have a reason to do so as the EPIT has the same features and
- uses the same clocks as the GPT. Anyway, on some systems the GPT
- may be in use for other purposes.
-
config HAVE_IMX_ANATOP
bool
@@ -85,7 +73,6 @@ config SOC_IMX31
config SOC_IMX35
bool
select ARCH_MXC_IOMUX_V3
- select HAVE_EPIT
select MXC_AVIC
select PINCTRL_IMX35
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 8ff7105..04ba789 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -20,7 +20,6 @@ obj-$(CONFIG_ARCH_MXC_IOMUX_V3) += iomux-v3.o
obj-$(CONFIG_MXC_TZIC) += tzic.o
obj-$(CONFIG_MXC_AVIC) += avic.o
-obj-$(CONFIG_MXC_USE_EPIT) += epit.o
obj-$(CONFIG_MXC_DEBUG_BOARD) += 3ds_debugboard.o
ifeq ($(CONFIG_CPU_IDLE),y)
diff --git a/arch/arm/mach-imx/epit.c b/arch/arm/mach-imx/epit.c
deleted file mode 100644
index fb9a73a..0000000
--- a/arch/arm/mach-imx/epit.c
+++ /dev/null
@@ -1,228 +0,0 @@
-/*
- * linux/arch/arm/plat-mxc/epit.c
- *
- * Copyright (C) 2010 Sascha Hauer <s.hauer@pengutronix.de>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
- * MA 02110-1301, USA.
- */
-
-#define EPITCR 0x00
-#define EPITSR 0x04
-#define EPITLR 0x08
-#define EPITCMPR 0x0c
-#define EPITCNR 0x10
-
-#define EPITCR_EN (1 << 0)
-#define EPITCR_ENMOD (1 << 1)
-#define EPITCR_OCIEN (1 << 2)
-#define EPITCR_RLD (1 << 3)
-#define EPITCR_PRESC(x) (((x) & 0xfff) << 4)
-#define EPITCR_SWR (1 << 16)
-#define EPITCR_IOVW (1 << 17)
-#define EPITCR_DBGEN (1 << 18)
-#define EPITCR_WAITEN (1 << 19)
-#define EPITCR_RES (1 << 20)
-#define EPITCR_STOPEN (1 << 21)
-#define EPITCR_OM_DISCON (0 << 22)
-#define EPITCR_OM_TOGGLE (1 << 22)
-#define EPITCR_OM_CLEAR (2 << 22)
-#define EPITCR_OM_SET (3 << 22)
-#define EPITCR_CLKSRC_OFF (0 << 24)
-#define EPITCR_CLKSRC_PERIPHERAL (1 << 24)
-#define EPITCR_CLKSRC_REF_HIGH (1 << 24)
-#define EPITCR_CLKSRC_REF_LOW (3 << 24)
-
-#define EPITSR_OCIF (1 << 0)
-
-#include <linux/interrupt.h>
-#include <linux/irq.h>
-#include <linux/clockchips.h>
-#include <linux/clk.h>
-#include <linux/err.h>
-#include <asm/mach/time.h>
-
-#include "common.h"
-#include "hardware.h"
-
-static struct clock_event_device clockevent_epit;
-
-static void __iomem *timer_base;
-
-static inline void epit_irq_disable(void)
-{
- u32 val;
-
- val = imx_readl(timer_base + EPITCR);
- val &= ~EPITCR_OCIEN;
- imx_writel(val, timer_base + EPITCR);
-}
-
-static inline void epit_irq_enable(void)
-{
- u32 val;
-
- val = imx_readl(timer_base + EPITCR);
- val |= EPITCR_OCIEN;
- imx_writel(val, timer_base + EPITCR);
-}
-
-static void epit_irq_acknowledge(void)
-{
- imx_writel(EPITSR_OCIF, timer_base + EPITSR);
-}
-
-static int __init epit_clocksource_init(struct clk *timer_clk)
-{
- unsigned int c = clk_get_rate(timer_clk);
-
- return clocksource_mmio_init(timer_base + EPITCNR, "epit", c, 200, 32,
- clocksource_mmio_readl_down);
-}
-
-/* clock event */
-
-static int epit_set_next_event(unsigned long evt,
- struct clock_event_device *unused)
-{
- unsigned long tcmp;
-
- tcmp = imx_readl(timer_base + EPITCNR);
-
- imx_writel(tcmp - evt, timer_base + EPITCMPR);
-
- return 0;
-}
-
-/* Left event sources disabled, no more interrupts appear */
-static int epit_shutdown(struct clock_event_device *evt)
-{
- unsigned long flags;
-
- /*
- * The timer interrupt generation is disabled at least
- * for enough time to call epit_set_next_event()
- */
- local_irq_save(flags);
-
- /* Disable interrupt in GPT module */
- epit_irq_disable();
-
- /* Clear pending interrupt */
- epit_irq_acknowledge();
-
- local_irq_restore(flags);
-
- return 0;
-}
-
-static int epit_set_oneshot(struct clock_event_device *evt)
-{
- unsigned long flags;
-
- /*
- * The timer interrupt generation is disabled at least
- * for enough time to call epit_set_next_event()
- */
- local_irq_save(flags);
-
- /* Disable interrupt in GPT module */
- epit_irq_disable();
-
- /* Clear pending interrupt, only while switching mode */
- if (!clockevent_state_oneshot(evt))
- epit_irq_acknowledge();
-
- /*
- * Do not put overhead of interrupt enable/disable into
- * epit_set_next_event(), the core has about 4 minutes
- * to call epit_set_next_event() or shutdown clock after
- * mode switching
- */
- epit_irq_enable();
- local_irq_restore(flags);
-
- return 0;
-}
-
-/*
- * IRQ handler for the timer
- */
-static irqreturn_t epit_timer_interrupt(int irq, void *dev_id)
-{
- struct clock_event_device *evt = &clockevent_epit;
-
- epit_irq_acknowledge();
-
- evt->event_handler(evt);
-
- return IRQ_HANDLED;
-}
-
-static struct irqaction epit_timer_irq = {
- .name = "i.MX EPIT Timer Tick",
- .flags = IRQF_TIMER | IRQF_IRQPOLL,
- .handler = epit_timer_interrupt,
-};
-
-static struct clock_event_device clockevent_epit = {
- .name = "epit",
- .features = CLOCK_EVT_FEAT_ONESHOT,
- .set_state_shutdown = epit_shutdown,
- .tick_resume = epit_shutdown,
- .set_state_oneshot = epit_set_oneshot,
- .set_next_event = epit_set_next_event,
- .rating = 200,
-};
-
-static int __init epit_clockevent_init(struct clk *timer_clk)
-{
- clockevent_epit.cpumask = cpumask_of(0);
- clockevents_config_and_register(&clockevent_epit,
- clk_get_rate(timer_clk),
- 0x800, 0xfffffffe);
-
- return 0;
-}
-
-void __init epit_timer_init(void __iomem *base, int irq)
-{
- struct clk *timer_clk;
-
- timer_clk = clk_get_sys("imx-epit.0", NULL);
- if (IS_ERR(timer_clk)) {
- pr_err("i.MX epit: unable to get clk\n");
- return;
- }
-
- clk_prepare_enable(timer_clk);
-
- timer_base = base;
-
- /*
- * Initialise to a known state (all timers off, and timing reset)
- */
- imx_writel(0x0, timer_base + EPITCR);
-
- imx_writel(0xffffffff, timer_base + EPITLR);
- imx_writel(EPITCR_EN | EPITCR_CLKSRC_REF_HIGH | EPITCR_WAITEN,
- timer_base + EPITCR);
-
- /* init and register the timer to the framework */
- epit_clocksource_init(timer_clk);
- epit_clockevent_init(timer_clk);
-
- /* Make irqs happen */
- setup_irq(irq, &epit_timer_irq);
-}
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: vfp: Go back to using vfp_current_hw_state()
From: Fabio Estevam @ 2018-01-09 15:19 UTC (permalink / raw)
To: linux-arm-kernel
Commit 384b38b66947 ("ARM: 7873/1: vfp: clear vfp_current_hw_state
for dying cpu") fixed the cpu dying notifier by using
vfp_current_hw_state(). However commit e5b61bafe704 ("arm: Convert VFP
hotplug notifiers to state machine") incorrectly used the original
vfp_force_reload() function in the cpu dying notifier.
Fix it by going back to the correct vfp_current_hw_state() usage.
Fixes: e5b61bafe704 ("arm: Convert VFP hotplug notifiers to state machine")
Cc: linux-stable <stable@vger.kernel.org>
Reported-by: Kohji Okuno <okuno.kohji@jp.panasonic.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/vfp/vfpmodule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index a71a48e..aa7496b 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,7 +648,7 @@ int vfp_restore_user_hwstate(struct user_vfp __user *ufp,
*/
static int vfp_dying_cpu(unsigned int cpu)
{
- vfp_force_reload(cpu, current_thread_info());
+ vfp_current_hw_state[cpu] = NULL;
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-09 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109144447.GI17719@n2100.armlinux.org.uk>
Hi Russell,
On Tue, Jan 09, 2018 at 02:44:48PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote:
> > This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
> > driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
> > nearly the same code path.
>
> Sorry, also...
Comments always welcomed :)
> > @@ -4668,6 +4692,10 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
> > */
> > val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
> > MVPP2_GMAC_CONFIG_FULL_DUPLEX;
> > + else if (port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
> > + val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
> > + MVPP2_GMAC_CONFIG_MII_SPEED |
> > + MVPP2_GMAC_CONFIG_FULL_DUPLEX;
>
> I think you'll find you don't need to set MII_SPEED here, since
> MII_SPEED selects between 10 and 100, GMII_SPEED always takes
> precidence selecting 1000, and 2500 is done by the comphy
> increasing the clocks by 2.5x.
I just had a look at the datasheet, and as you say it seems GMII_SPEED
takes over MII_SPEED. I'll see if there is a corner case here or if
selecting MII_SPEED doesn't make sense, and update accordingly.
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-09 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109144238.GH17719@n2100.armlinux.org.uk>
Hi Russell,
On Tue, Jan 09, 2018 at 02:42:38PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote:
> > This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
> > driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
> > nearly the same code path.
>
> For 2500Base-X, do you report a speed of 2500Mbps through ethtool, or
> are you reporting 1000Mbps? I don't see any code in this patch that
> deals with that.
The mvpp2 driver uses phy_ethtool_get_link_ksettings() to report the
link speed to Ethtool. So it's reporting the speed set by the PHY
driver.
So it'll be something to ensure when adding PHYs supporting the mode.
We'll have the opportunity to see this when adding the last mcbin
interface.
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* arm: Is VFP hotplug notifiers wrong?
From: Fabio Estevam @ 2018-01-09 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <104db10119fd453ba38edac32a228ab6@JPA000SECMN21.palet.jp.panasonic.com>
Hi Okuno,
On Tue, Jan 9, 2018 at 12:46 PM, <okuno.kohji@jp.panasonic.com> wrote:
> Dear Russel and Thomas,
>
> Thank you for your quick response.
> Thomas, do you create the patch?
Looks like the fix should be like this:
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,7 +648,7 @@ int vfp_restore_user_hwstate(struct user_vfp __user *ufp,
*/
static int vfp_dying_cpu(unsigned int cpu)
{
- vfp_force_reload(cpu, current_thread_info());
+ vfp_current_hw_state[cpu] = NULL;
return 0;
}
Could you please test it?
Thanks
^ permalink raw reply
* soc: imx: gpcv2: removing and probing fails
From: Lucas Stach @ 2018-01-09 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d71311e13720724b3b3bccd06fe9309b@agner.ch>
Am Dienstag, den 09.01.2018, 15:44 +0100 schrieb Stefan Agner:
> On 2018-01-09 15:24, Lucas Stach wrote:
> > Am Sonntag, den 07.01.2018, 11:48 +0100 schrieb Stefan Agner:
> > > Hi Andrew,
> > >
> > > I noticed that the driver fails when removing and probing again.
> > > As far
> > > as I can see due to duplicate add of the platform devices.
> > >
> > > As far as I can tell the driver should register the remove
> > > callback and
> > > do a platform_device_unregister on the newly created platform
> > > devices.
> > > However, as far as I can tell we don't hold on to a reference to
> > > them...
> > > I guess we could keep references in imx_gpcv2_probe, but maybe
> > > there is
> > > an easier way?
> >
> > The GPC v1 driver adds the necessary device dependency between the
> > power domain devices and the GPC parent device. See the
> > device_link_add() in imx_pgc_power_domain_probe().
>
> Note that despite device_link_add, GPC v1 seems to cause issue with
> CONFIG_DEBUG_TEST_DRIVER_REMOVE=y:
> https://marc.info/?l=linux-arm-kernel&m=151544599904423&w=4
>
> (sorry, I made it confusing, by adding a stack trace when using GPC
> v1
> in the gpcv2 thread...)
IMHO this is an issue with the?CONFIG_DEBUG_TEST_DRIVER_REMOVE option,
as it just blindly calls the remove callback instead of doing a proper
__device_release_driver(). All the regular driver/device unbind paths
will properly unbind the consumer devices before removing the driver.
I think this should be fixed in the device driver core instead of
individual drivers.
Regards,
Lucas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox