* [PATCH 6/6] arm64: dts: k3-j721e: Add gpio-keys on common processor board
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
From: Nikhil Devshatwar <nikhil.nd@ti.com>
Common processor board for K3 J721E platform has two push buttons
namely SW10 and SW11.
Add a gpio-keys device node to model them as input keys in Linux.
Add required pinmux nodes to set GPIO pins as input.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../dts/ti/k3-j721e-common-proc-board.dts | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
index 509579ca3db2..d2894d55fbbe 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
@@ -6,12 +6,49 @@
/dts-v1/;
#include "k3-j721e-som-p0.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
/ {
chosen {
stdout-path = "serial2:115200n8";
bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000";
};
+
+ gpio_keys: gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sw10_button_pins_default &sw11_button_pins_default>;
+
+ sw10: sw10 {
+ label = "GPIO Key USER1";
+ linux,code = <BTN_0>;
+ gpios = <&main_gpio0 0 GPIO_ACTIVE_LOW>;
+ };
+
+ sw11: sw11 {
+ label = "GPIO Key USER2";
+ linux,code = <BTN_1>;
+ gpios = <&wkup_gpio0 7 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&main_pmx0 {
+ sw10_button_pins_default: sw10_button_pins_default {
+ pinctrl-single,pins = <
+ J721E_IOPAD(0x0, PIN_INPUT, 7) /* (AC18) EXTINTn.GPIO0_0 */
+ >;
+ };
+};
+
+&wkup_pmx0 {
+ sw11_button_pins_default: sw11_button_pins_default {
+ pinctrl-single,pins = <
+ J721E_WKUP_IOPAD(0xcc, PIN_INPUT, 7) /* (G28) WKUP_GPIO0_7 */
+ >;
+ };
};
&wkup_uart0 {
--
2.22.0
^ permalink raw reply related
* [PATCH 5/6] dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
Add pinctrl macros for J721E SoC. These macro definitions are
similar to that of AM6, but adding new definitions to avoid
any naming confusions in the soc dts files.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
---
include/dt-bindings/pinctrl/k3.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h
index 45e11b6170ca..499de6216581 100644
--- a/include/dt-bindings/pinctrl/k3.h
+++ b/include/dt-bindings/pinctrl/k3.h
@@ -32,4 +32,7 @@
#define AM65X_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
#define AM65X_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
+#define J721E_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
+#define J721E_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
+
#endif
--
2.22.0
^ permalink raw reply related
* [PATCH 4/6] arm64: dts: ti: k3-j721e-common-proc-board: Disable unused gpio modules
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
There are 10 gpio instances inside SoC with 3 groups as below:
- Group1: main_gpio0, main_gpio2, main_gpio4, main_gpio6
- Group2: main_gpio1, main_gpio3, main_gpio5, main_gpio7
- Group3: wkup_gpio0, wkup_gpio1
Only one instance can be used in each group at a time. So use main_gpio0,
main_gpio1 and wkup_gpio0 for the current linux context and mark other
gpio nodes as disabled.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../dts/ti/k3-j721e-common-proc-board.dts | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
index 63b47b839388..509579ca3db2 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
@@ -52,3 +52,31 @@
/* UART not brought out */
status = "disabled";
};
+
+&main_gpio2 {
+ status = "disabled";
+};
+
+&main_gpio3 {
+ status = "disabled";
+};
+
+&main_gpio4 {
+ status = "disabled";
+};
+
+&main_gpio5 {
+ status = "disabled";
+};
+
+&main_gpio6 {
+ status = "disabled";
+};
+
+&main_gpio7 {
+ status = "disabled";
+};
+
+&wkup_gpio1 {
+ status = "disabled";
+};
--
2.22.0
^ permalink raw reply related
* [PATCH 3/6] arm64: dts: ti: k3-j721e: Add gpio nodes in wakeup domain
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
Similar to the gpio groups in main domain, there is one gpio group
in wakup domain with 2 module instances in it. This gpio group pins
out 84 lines(6 banks). Add DT node for these 2 gpio module instances.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 34 +++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
index e616c2481f51..555dc7b7aedc 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
@@ -87,4 +87,38 @@
ti,sci-dst-id = <14>;
ti,sci-rm-range-girq = <0x5>;
};
+
+ wkup_gpio0: gpio@42110000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x42110000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&wkup_gpio_intr>;
+ interrupts = <113 0>, <113 1>, <113 2>,
+ <113 3>, <113 4>, <113 5>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <84>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 113 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 113 0>;
+ clock-names = "gpio";
+ };
+
+ wkup_gpio1: gpio@42100000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x42100000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&wkup_gpio_intr>;
+ interrupts = <114 0>, <114 1>, <114 2>,
+ <114 3>, <114 4>, <114 5>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <84>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 114 0>;
+ clock-names = "gpio";
+ };
};
--
2.22.0
^ permalink raw reply related
* [PATCH 2/6] arm64: dts: ti: k3-j721e: Add gpio nodes in main domain
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
There are 8 instances of gpio modules in main domain divided into 2 groups:
- Group1: gpio0, gpio2, gpio4, gpio6
- Group2: gpio1, gpio3, gpio5, gpio7
Groups are created to provide protection between two different processor
virtual worlds. There are x gpio lines coming out of each group. Each module
in a group has equal x gpio lines pinned out. There is a top level mux for
selecting the module instance for each pin coming out of group. Exactly
one module can be selected to control the corresponding pin. This muxing
can be controlled along the pad mux configuration registers.
Group1 pins out 128 lines(8 banks). Group 2 pins out 36 lines(2 banks).
Add DT nodes for each module instance in the main domain. Users should
make sure that correct gpio instance is selected in their pad configuration.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 132 ++++++++++++++++++++++
1 file changed, 132 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index 01661c22c39d..199bc9a00b20 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -240,4 +240,136 @@
clocks = <&k3_clks 286 0>;
clock-names = "fclk";
};
+
+ main_gpio0: gpio@600000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00600000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <105 0>, <105 1>, <105 2>, <105 3>,
+ <105 4>, <105 5>, <105 6>, <105 7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <128>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 105 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio1: gpio@601000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00601000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <106 0>, <106 1>, <106 2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <36>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 106 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio2: gpio@610000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00610000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <107 0>, <107 1>, <107 2>, <107 3>,
+ <107 4>, <107 5>, <107 6>, <107 7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <128>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 107 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio3: gpio@611000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00611000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <108 0>, <108 1>, <108 2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <36>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 108 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 108 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio4: gpio@620000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00620000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <109 0>, <109 1>, <109 2>, <109 3>,
+ <109 4>, <109 5>, <109 6>, <109 7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <128>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 109 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 109 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio5: gpio@621000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00621000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <110 0>, <110 1>, <110 2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <36>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 110 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 110 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio6: gpio@630000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00630000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <111 0>, <111 1>, <111 2>, <111 3>,
+ <111 4>, <111 5>, <111 6>, <111 7>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <128>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 111 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 111 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio7: gpio@631000 {
+ compatible = "ti,j721e-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x00631000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <112 0>, <112 1>, <112 2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <36>;
+ ti,davinci-gpio-unbanked = <0>;
+ power-domains = <&k3_pds 112 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 112 0>;
+ clock-names = "gpio";
+ };
};
--
2.22.0
^ permalink raw reply related
* [PATCH 1/6] dt-bindings: gpio: davinci: Add new compatible for J721E SoCs
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
In-Reply-To: <20190809082947.30590-1-lokeshvutla@ti.com>
J721e SoCs have same gpio IP as K2G davinci gpio. Add a new compatible to
handle J721E SoCs.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
Documentation/devicetree/bindings/gpio/gpio-davinci.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index bc6b4b62df83..cd91d61eac31 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -6,6 +6,7 @@ Required Properties:
66AK2E SoCs
"ti,k2g-gpio", "ti,keystone-gpio": for 66AK2G
"ti,am654-gpio", "ti,keystone-gpio": for TI K3 AM654
+ "ti,j721e-gpio", "ti,keystone-gpio": for J721E SoCs
- reg: Physical base address of the controller and the size of memory mapped
registers.
--
2.22.0
^ permalink raw reply related
* [PATCH 0/6] arm64: dts: ti: k3-j721e: Add gpio nodes
From: Lokesh Vutla @ 2019-08-09 8:29 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, linus.walleij
Cc: Device Tree Mailing List, Lokesh Vutla, Keerthy, linux-gpio,
Rob Herring, Linux ARM Mailing List
This series adds gpio nodes for J721E SoC and enable gpio keys
in J72E common process board.
Tested Boot log: https://pastebin.ubuntu.com/p/P6QqmZYtSC/
This series depends on Power-domain cells update series:
https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=152109
Lokesh Vutla (5):
dt-bindings: gpio: davinci: Add new compatible for J721E SoCs
arm64: dts: ti: k3-j721e: Add gpio nodes in main domain
arm64: dts: ti: k3-j721e: Add gpio nodes in wakeup domain
arm64: dts: ti: k3-j721e-common-proc-board: Disable unused gpio
modules
dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
Nikhil Devshatwar (1):
arm64: dts: k3-j721e: Add gpio-keys on common processor board
.../devicetree/bindings/gpio/gpio-davinci.txt | 1 +
.../dts/ti/k3-j721e-common-proc-board.dts | 65 +++++++++
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 132 ++++++++++++++++++
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 34 +++++
include/dt-bindings/pinctrl/k3.h | 3 +
5 files changed, 235 insertions(+)
--
2.22.0
^ permalink raw reply
* Re: [PATCH v8 4/4] arm64: dts: allwinner: orange-pi-3: Enable HDMI output
From: Code Kipper @ 2019-08-09 8:25 UTC (permalink / raw)
To: megous-5qf/QAjKc83QT0dZR+AlfA
Cc: linux-sunxi, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Jernej Škrabec, David Airlie, Daniel Vetter, Mark Rutland,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20190806155744.10263-5-megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
On Tue, 6 Aug 2019 at 17:57, <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
>
> From: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
>
> Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
> I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
> This is realized by the ddc-en-gpios property.
Great work. Is there any chance you can move this to the
arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi?, as all the H6
based orange-pi's have this feature.
BR,
CK
>
> Signed-off-by: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
> ---
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> index 2c6807b74ff6..01bb1bafe284 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -22,6 +22,18 @@
> stdout-path = "serial0:115200n8";
> };
>
> + connector {
> + compatible = "hdmi-connector";
> + ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&hdmi_out_con>;
> + };
> + };
> + };
> +
> leds {
> compatible = "gpio-leds";
>
> @@ -72,6 +84,10 @@
> cpu-supply = <®_dcdca>;
> };
>
> +&de {
> + status = "okay";
> +};
> +
> &ehci0 {
> status = "okay";
> };
> @@ -91,6 +107,16 @@
> status = "okay";
> };
>
> +&hdmi {
> + status = "okay";
> +};
> +
> +&hdmi_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> +};
> +
> &mdio {
> ext_rgmii_phy: ethernet-phy@1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> --
> 2.22.0
>
> --
> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190806155744.10263-5-megous%40megous.com.
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: soundwire: add slave bindings
From: Srinivas Kandagatla @ 2019-08-09 8:25 UTC (permalink / raw)
To: Vinod Koul, Mark Brown
Cc: Pierre-Louis Bossart, bgoswami, plai, robh+dt, devicetree,
lgirdwood, alsa-devel, linux-kernel
In-Reply-To: <20190809045459.GG12733@vkoul-mobl.Dlink>
On 09/08/2019 05:54, Vinod Koul wrote:
> On 08-08-19, 20:52, Mark Brown wrote:
>> On Thu, Aug 08, 2019 at 05:48:56PM +0100, Srinivas Kandagatla wrote:
>>> On 08/08/2019 16:58, Pierre-Louis Bossart wrote:
>>
>>>>> +- sdw-instance-id: Should be ('Instance ID') from SoundWire
>>>>> + Enumeration Address. Instance ID is for the cases
>>>>> + where multiple Devices of the same type or Class
>>>>> + are attached to the bus.
>>
>>>> so it is actually required if you have a single Slave device? Or is it
>>>> only required when you have more than 1 device of the same type?
>>
>>> This is mandatory for any slave device!
>>
>> If it's mandatory the wording is a bit unclear. How about something
>> like:
>>
>> Should be ('Instance ID') from the SoundWire Enumeration
>> Address. This must always be provided, if multiple devices
>> with the same type or class or attached to the bus each
>> instance must have a distinct value.
>
> That helps to make it clear.
>
> Also the section of properties starts with Mandatory property, it should
> be made Mandatory Properties instead, like in other binding docs to make
> it clear that properties mentioned in the section are mandatory
Will update as suggested!
thanks,
srini
>
^ permalink raw reply
* Re: [PATCH v2 2/4] soundwire: core: add device tree support for slave devices
From: Srinivas Kandagatla @ 2019-08-09 8:24 UTC (permalink / raw)
To: Vinod Koul
Cc: broonie, bgoswami, plai, pierre-louis.bossart, robh+dt,
devicetree, lgirdwood, alsa-devel, linux-kernel
In-Reply-To: <20190809050700.GJ12733@vkoul-mobl.Dlink>
On 09/08/2019 06:07, Vinod Koul wrote:
> On 08-08-19, 15:45, Srinivas Kandagatla wrote:
>> This patch adds support to parsing device tree based
>> SoundWire slave devices.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>> drivers/soundwire/bus.c | 2 ++
>> drivers/soundwire/bus.h | 1 +
>> drivers/soundwire/slave.c | 47 +++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 50 insertions(+)
>>
>> diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
>> index fe745830a261..324c54dc52fb 100644
>> --- a/drivers/soundwire/bus.c
>> +++ b/drivers/soundwire/bus.c
>> @@ -77,6 +77,8 @@ int sdw_add_bus_master(struct sdw_bus *bus)
>> */
>> if (IS_ENABLED(CONFIG_ACPI) && ACPI_HANDLE(bus->dev))
>> ret = sdw_acpi_find_slaves(bus);
>> + else if (IS_ENABLED(CONFIG_OF) && bus->dev->of_node)
>> + ret = sdw_of_find_slaves(bus);
>> else
>> ret = -ENOTSUPP; /* No ACPI/DT so error out */
>>
>> diff --git a/drivers/soundwire/bus.h b/drivers/soundwire/bus.h
>> index 3048ca153f22..ee46befedbd1 100644
>> --- a/drivers/soundwire/bus.h
>> +++ b/drivers/soundwire/bus.h
>> @@ -15,6 +15,7 @@ static inline int sdw_acpi_find_slaves(struct sdw_bus *bus)
>> }
>> #endif
>>
>> +int sdw_of_find_slaves(struct sdw_bus *bus);
>> void sdw_extract_slave_id(struct sdw_bus *bus,
>> u64 addr, struct sdw_slave_id *id);
>>
>> diff --git a/drivers/soundwire/slave.c b/drivers/soundwire/slave.c
>> index f39a5815e25d..8ab76f5d5a56 100644
>> --- a/drivers/soundwire/slave.c
>> +++ b/drivers/soundwire/slave.c
>> @@ -2,6 +2,7 @@
>> // Copyright(c) 2015-17 Intel Corporation.
>>
>> #include <linux/acpi.h>
>> +#include <linux/of.h>
>> #include <linux/soundwire/sdw.h>
>> #include <linux/soundwire/sdw_type.h>
>> #include "bus.h"
>> @@ -35,6 +36,7 @@ static int sdw_slave_add(struct sdw_bus *bus,
>>
>> slave->dev.release = sdw_slave_release;
>> slave->dev.bus = &sdw_bus_type;
>> + slave->dev.of_node = of_node_get(to_of_node(fwnode));
>> slave->bus = bus;
>> slave->status = SDW_SLAVE_UNATTACHED;
>> slave->dev_num = 0;
>> @@ -112,3 +114,48 @@ int sdw_acpi_find_slaves(struct sdw_bus *bus)
>> }
>>
>> #endif
>> +
>> +/*
>> + * sdw_of_find_slaves() - Find Slave devices in master device tree node
>> + * @bus: SDW bus instance
>> + *
>> + * Scans Master DT node for SDW child Slave devices and registers it.
>> + */
>> +int sdw_of_find_slaves(struct sdw_bus *bus)
>> +{
>> + struct device *dev = bus->dev;
>> + struct device_node *node;
>> +
>> + for_each_child_of_node(bus->dev->of_node, node) {
>> + struct sdw_slave_id id;
>> + const char *compat = NULL;
>> + int unique_id, ret;
>> + int ver, mfg_id, part_id, class_id;
>> +
>> + compat = of_get_property(node, "compatible", NULL);
>> + if (!compat)
>> + continue;
>
> Why not use of_find_compatible_node() that will return the node which is
> sdw* and we dont need to checks on that..
Am not sure if wild characters are really supported in this api.
Also AFIU, it would not very optimal to use this api and it would
complicate the code without much gain.
>
>> +
>> + ret = sscanf(compat, "sdw%x,%x,%x,%x",
>> + &ver, &mfg_id, &part_id, &class_id);
>> + if (ret != 4) {
>> + dev_err(dev, "Manf ID & Product code not found %s\n",
>> + compat);
>> + continue;
>> + }
>> +
>> + ret = of_property_read_u32(node, "sdw-instance-id", &unique_id);
>> + if (ret) {
>> + dev_err(dev, "Instance id not found:%d\n", ret);
>> + continue;
>> + }
>> +
>> + id.sdw_version = ver - 0xF;
>> + id.unique_id = unique_id;
>> + id.mfg_id = mfg_id;
>> + id.part_id = part_id;
>> + id.class_id = class_id;
>
> empty line here please
yep, will add that.
thanks,
srini
>
>> + sdw_slave_add(bus, &id, of_fwnode_handle(node));
>> + }
>
> and here as well
>
>> + return 0;
>> +}
>> --
>> 2.21.0
>
^ permalink raw reply
* Re: [PATCH v2 2/4] soundwire: core: add device tree support for slave devices
From: Srinivas Kandagatla @ 2019-08-09 8:24 UTC (permalink / raw)
To: Vinod Koul
Cc: Pierre-Louis Bossart, broonie, bgoswami, plai, robh+dt,
devicetree, lgirdwood, alsa-devel, linux-kernel
In-Reply-To: <20190809054602.GK12733@vkoul-mobl.Dlink>
On 09/08/2019 06:46, Vinod Koul wrote:
>>>> +int sdw_of_find_slaves(struct sdw_bus *bus)
>>>> +{
>>>> + struct device *dev = bus->dev;
>>>> + struct device_node *node;
>>>> +
>>>> + for_each_child_of_node(bus->dev->of_node, node) {
>>>> + struct sdw_slave_id id;
>>>> + const char *compat = NULL;
>>>> + int unique_id, ret;
>>>> + int ver, mfg_id, part_id, class_id;
>>>> +
>>>> + compat = of_get_property(node, "compatible", NULL);
>>>> + if (!compat)
>>>> + continue;
>>>> +
>>>> + ret = sscanf(compat, "sdw%x,%x,%x,%x",
>>>> + &ver, &mfg_id, &part_id, &class_id);
>>>> + if (ret != 4) {
>>>> + dev_err(dev, "Manf ID & Product code not found %s\n",
>>>> + compat);
>>>> + continue;
>>>> + }
>>>> +
>>>> + ret = of_property_read_u32(node, "sdw-instance-id", &unique_id);
>>>> + if (ret) {
>>>> + dev_err(dev, "Instance id not found:%d\n", ret);
>>>> + continue;
>>> I am confused here.
>>> If you have two identical devices on the same link, isn't this property
>>> required and that should be a real error instead of a continue?
>> Yes, I agree it will be mandatory in such cases.
>>
>> Am okay either way, I dont mind changing it to returning EINVAL in all the
>> cases.
> Do we want to abort? We are in loop scanning for devices so makes sense
> if we do not do that and continue to check next one..
That was my inital plan.
Pierre suggested a better compatible to include instance ID and LinkID
so this check would be part of the check one before this line.
--srini
^ permalink raw reply
* Re: [PATCH 1/2] mmc: sdhci-of-at91: add quirk for broken HS200
From: Ludovic Desroches @ 2019-08-09 8:08 UTC (permalink / raw)
To: Ulf Hansson
Cc: Eugen.Hristev, Nicolas Ferre, Alexandre Belloni, Adrian Hunter,
Linux ARM, DTML, Linux Kernel Mailing List,
linux-mmc@vger.kernel.org
In-Reply-To: <CAPDyKFrUr8_VP1JLRk48zR8_p1Y62wKLBnS0iTgdhUSArwD49Q@mail.gmail.com>
On Thu, Aug 08, 2019 at 05:23:00PM +0200, Ulf Hansson wrote:
> On Thu, 8 Aug 2019 at 10:35, <Eugen.Hristev@microchip.com> wrote:
> >
> > From: Eugen Hristev <eugen.hristev@microchip.com>
> >
> > HS200 is not implemented in the driver, but the controller claims it
> > through caps.
> > Remove it via quirk.
> > Without this quirk, the mmc core will try to enable hs200, which will fail,
> > and the eMMC initialization will fail.
> >
> > Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>
> Should this be applied as a fix and possibly tagged for stable?
>
> In such case, do you have a specific commit that it fixes?
I think so, I would say:
Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
Cc: stable@vger.kernel.org #v4.4 and later
It doesn't apply on 4.4 but resolution is trivial.
Regards
Ludovic
>
> Kind regards
> Uffe
>
> > ---
> > drivers/mmc/host/sdhci-of-at91.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
> > index 57fe3b2..3a8c6d8 100644
> > --- a/drivers/mmc/host/sdhci-of-at91.c
> > +++ b/drivers/mmc/host/sdhci-of-at91.c
> > @@ -370,6 +370,9 @@ static int sdhci_at91_probe(struct platform_device *pdev)
> > pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
> > pm_runtime_use_autosuspend(&pdev->dev);
> >
> > + /* HS200 is broken at this moment */
> > + host->quirks2 = SDHCI_QUIRK2_BROKEN_HS200;
> > +
> > ret = sdhci_add_host(host);
> > if (ret)
> > goto pm_runtime_disable;
> > --
> > 2.7.4
> >
^ permalink raw reply
* Re: [RFC PATCH V2 4/4] platform: mtk-isp: Add Mediatek FD driver
From: Tomasz Figa @ 2019-08-09 8:07 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: laurent.pinchart+renesas@ideasonboard.com,
Rynn Wu (吳育恩),
Po-Yang Huang (黃柏陽), suleiman@chromium.org,
Jerry-ch Chen, Jungo Lin (林明俊),
hans.verkuil@cisco.com, Sakari Ailus,
Frederic Chen (陳俊元),
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
Sj Huang (黃信璋), yuzhao@chromium.org,
linux-mediatek@lists.infradead.org, matthias.bgg
In-Reply-To: <1564401491.15267.405.camel@mtksdccf07>
On Mon, Jul 29, 2019 at 8:58 PM Jerry-ch Chen
<Jerry-ch.Chen@mediatek.com> wrote:
>
> Hi Tomasz,
>
> On Mon, 2019-07-29 at 17:57 +0800, Tomasz Figa wrote:
> > On Mon, Jul 29, 2019 at 3:01 PM Jerry-ch Chen
> > <Jerry-ch.Chen@mediatek.com> wrote:
> > >
> > > Hi Enrico,
> > >
> > > On Tue, 2019-07-09 at 18:56 +0800, Enrico Weigelt, metux IT consult
> > > wrote:
> > > > On 09.07.19 10:41, Jerry-ch Chen wrote:
> > > >
> > > > Hi,
> > > >
> > > >
> > > > > diff --git a/drivers/media/platform/mtk-isp/fd/mtk_fd.h b/drivers/media/platform/mtk-isp/fd/mtk_fd.h
> > > > > new file mode 100644
> > > > > index 0000000..289999b
> > > > > --- /dev/null
> > > > > +++ b/drivers/media/platform/mtk-isp/fd/mtk_fd.h
> > > > > @@ -0,0 +1,157 @@
> > > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > > +//
> > > > > +// Copyright (c) 2018 MediaTek Inc.
> > > > > +
> > > > > +#ifndef __MTK_FD_HW_H__
> > > > > +#define __MTK_FD_HW_H__
> > > > > +
> > > > > +#include <linux/io.h>
> > > > > +#include <linux/types.h>
> > > > > +#include <linux/platform_device.h>
> > > > > +#include <media/v4l2-ctrls.h>
> > > > > +#include <media/v4l2-device.h>
> > > > > +#include <media/videobuf2-v4l2.h>
> > > > > +
> > > > > +#define MTK_FD_OUTPUT_MIN_WIDTH 26U
> > > > > +#define MTK_FD_OUTPUT_MIN_HEIGHT 26U
> > > > > +#define MTK_FD_OUTPUT_MAX_WIDTH 640U
> > > > > +#define MTK_FD_OUTPUT_MAX_HEIGHT 480U
> > > > > +
> > > > > +/* Control the user defined image widths and heights
> > > > > + * to be scaled and performed face detection in FD HW.
> > > > > + * MTK FD support up to 14 user defined image sizes to perform face detection.
> > > > > + */
> > > > > +#define V4L2_CID_MTK_FD_SCALE_IMG_WIDTH (V4L2_CID_USER_MTK_FD_BASE + 1)
> > > > > +#define V4L2_CID_MTK_FD_SCALE_IMG_HEIGHT (V4L2_CID_USER_MTK_FD_BASE + 2)
> > > >
> > > > I've got a *really* bad feeling about introducing chip specific
> > > > uapi stuff. (by the way: uapi stuff belongs into include/uapi/...)
> > > >
> > > Thanks for your comments,
> > >
> > > If we remain chip-specific control IDs, I will move the uapi stuff into
> > > inlcude/uapi/mtk_fd.h (filename TBD)
> > >
> > > > Maybe you could tell us what that's *really* about, so we can find some
> > > > standard / chip-independent api for these things. That's one of the
> > > > major point of the kernel: hardware abstraction.
> > > >
> > > I am not sure if it is possible for us to add some standard
> > > v4l2-controls for face detection, a further explanations of controls are
> > > listed below.
> > >
> > > In v4l2-controls, there exists V4L2_CID_DETECT_CLASS, but I haven't
> > > found the standards or api that can be used for face detection yet.
> > > https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/v4l2-controls.h#L1092
> > >
> > > For detecting certain face angle and head direction, we would need
> > > V4L2_CID_DETECT_ANGLE, V4L2_CID_DETECT_DIRECTION controls for user to
> > > specify the angle and direction to be detected.
> > > In MTK FD driver, we support the following angles and directions to be
> > > selected by user, and they are both multiple selected .
> > > FD_angle_table[] = {-90, -45, 0 , 45, 90}
> > > FD_direction_table[] = {0, 30, 60, 90, 120, 150, ..., 330}
> > >
> > > Assuming these v4l2-controls are array of V4L2_CTRL_TYPE_U16 with
> > > dimension 5 and 12.
> > > User can select the desired angle and directions to be detected into
> > > arrays and bring it to driver by these controls, however, the more they
> > > select, the longer execution time needed by HW.
> > >
> >
> > Sounds like we need some kind of a menu bitmask control here, but I
> > don't see V4L2 having anything like that.
> >
> > Hans, Sakari, any ideas?
> >
> > > For detecting different sizes of faces and increase the detection speed,
> > > FD driver might need to scales down the input image into different
> > > smaller sizes
> >
> > Do you mean the FD hardware would do the scaling or the driver code
> > itself? It would be undesirable to do such scaling in a kernel driver,
> > so if that's not something handled by the hardware, the downscaled
> > image might need to be provided from the userspace.
> >
> Thanks for your comments.
>
> Yes, FD hardware will do the scaling itself, so driver could set the
> sizes.
>
> > >, besides driver default values, user or proprietary
> > > algorithm library can manually set the desired image sizes, therefore,
> > > we would need the following controls:
> > > V4L2_CID_DETECT_SCALE_DOWN_IMG_WIDTH and
> > > V4L2_CID_DETECT_SCALE_DOWN_IMG_HEIGHT.
> > > In MTK FD driver, we implement these controls as array of
> > > V4L2_CTRL_TYPE_U16 with the dimension 15.
> >
> > Why 15?
> >
> It consists of one input image size and 14 down-scaled image sizes,
> the amount 15 (or say 14) is defined by the MTK FD algo library,
> therefore I remain the number of 15 here for communicate with the
> library.
> Maybe it should be defined as following?
> MTK_FD_MAX_SCALE_SIZE_NUM 14
> and
> MTK_FD_SCALE_ARR_NUM 15
>
> > >
> > > For controlling detection speed, we would need the
> > > V4L2_CID_DETECT_SPEED, the faster speedup implies the lower accuracy of
> > > detection, In MTK FD driver, the max level of speedup is 7, and default
> > > value is 0.
> > >
> > > For MTK FD algorithm user library, they would need select extra
> > > detection features(models) used in HW, we need
> > > V4L2_CID_MTK_FD_EXTRA_MODEL, this will be set to 1 for using extra
> > > model. However, we are considering make this control more
> > > chip-independent and can be added into standard.
> > > for example, V4L2_CID_DETECTION_FD_MODEL or ...FD_ALGO,
> > > drivers can define the detection algorithm or detection model to be used
> > > for users to select. How do you think?
> >
> > Sounds like something that could be a menu control, so it could vary
> > between drivers.
> >
> Ok, and maybe it should be created by v4l2_ctrl_new_int_menu(...)?
>
> > >
> > > In short, I summery the control IDs as following:
> > > V4L2_CID_DETECT_ANGLE: set the angle of face in degrees. 90 ~ -90
> > > degrees.
> > > V4L2_CID_DETECT_DIRECTION: set the rotation of the head in degrees.
> > > 0~330 degrees.
> > > V4L2_CID_DETECT_SCALE_DOWN_IMG_WIDTH: set the image widths for an input
> > > image to be scaled down for face detection
> > > V4L2_CID_DETECT_SCALE_DOWN_IMG_HEIGHT: set the image heights for an
> > > input image to be scaled down for face detection
> > > V4L2_CID_DETECT_SPEED: set the detection speed, usually reducing
> > > accuracy.
> > > V4L2_CID_DETECTION_FD_MODEL: select the detection model or algorithm to
> > > be used by face detection driver.
> > >
> > > > > +#define ENABLE_FD 0x111
> > > > > +#define FD_HW_ENABLE 0x4
> > > > > +#define FD_INT_EN 0x15c
> > > > > +#define FD_INT 0x168
> > > > > +#define FD_RESULT 0x178
> > > > > +#define FD_IRQ_MASK 0x001
> > > > > +
> > > > > +#define RS_MAX_BUF_SIZE 2288788
> > > > > +#define FD_MAX_SPEEDUP 7
> > > > > +#define FD_MAX_POSE_VAL 0xfffffffffffffff
> > > > > +#define FD_DEF_POSE_VAL 0x3ff
> > > > > +#define MAX_FD_SEL_NUM 1026
> > > >
> > > > If that file is supposed to be included by anything beyond the driver
> > > > itself, we need proper prefixing. (same for anything else in here)
> > > >
> > > I will fix it as following:
> > >
> > > #define FD_ENABLE 0x111
> > >
> > > #define FD_REG_OFFSET_HW_ENABLE 0x4
> > > #define FD_REG_OFFSET_INT_EN 0x15c
> > > #define FD_REG_OFFSET_INT_VAL 0x168
> > > #define FD_REG_OFFSET_RESULT 0x178
> > >
> > > #define FD_IRQ_MASK 1
> > > #define FD_MAX_RS_BUF_SIZE 2288788
> > > #define FD_MAX_SPEEDUP 7
> > > #define FD_MAX_RESULT_NUM 1026
> > >
> >
> > I'd suggest the MTK_FD_ prefix.
> >
> Ok, I will use MTK_FD_ prefix.
>
> > > > > diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> > > > > index 3dcfc61..eae876e 100644
> > > > > --- a/include/uapi/linux/v4l2-controls.h
> > > > > +++ b/include/uapi/linux/v4l2-controls.h
> > > > > @@ -192,6 +192,10 @@ enum v4l2_colorfx {
> > > > > * We reserve 16 controls for this driver. */
> > > > > #define V4L2_CID_USER_IMX_BASE (V4L2_CID_USER_BASE + 0x10b0)
> > > > >
> > > > > +/* The base for the mediatek FD driver controls */
> > > > > +/* We reserve 16 controls for this driver. */
> > > > > +#define V4L2_CID_USER_MTK_FD_BASE (V4L2_CID_USER_BASE + 0x10d0)
> > > >
> > > > Why only the base, but not the actual IDs in uapi ?
> > > >
> > > I will put actual IDs in uapi/ for user to reference.
Enrico, any thoughts on the explanation that Jerry provided and
further discussion above?
Thanks,
Tomasz
^ permalink raw reply
* Re: [PATCH v6 02/13] media: v4l2-fwnode: add v4l2_fwnode_connector
From: Marco Felsch @ 2019-08-09 7:55 UTC (permalink / raw)
To: Laurent Pinchart
Cc: mchehab, sakari.ailus, hans.verkuil, jacopo+renesas, robh+dt,
linux-media, devicetree, kernel, Jacopo Mondi
In-Reply-To: <20190516163632.GO14820@pendragon.ideasonboard.com>
Hi Laurent,
On 19-05-16 19:36, Laurent Pinchart wrote:
> Hi Marco,
>
> Thank you for the patch.
Thanks for the review and sorry for the delayed reply.
> On Mon, Apr 15, 2019 at 02:44:02PM +0200, Marco Felsch wrote:
> > Currently every driver needs to parse the connector endpoints by it self.
>
> s/it self/itself/
>
> > This is the initial work to make this generic. The generic connector has
> > some common fields and some connector specific parts. The generic one
> > includes:
> > - type
> > - label
> > - remote_port (the port where the connector is connected to)
> > - remote_id (the endpoint where the connector is connected to)
>
> This assumes a single connection between a connector and a remote port,
> and a single port on the connector side. Is this guaranteed ? For the
> mini-DIN-4 connectors (often used for S-Video) for instance, I recall
> from the extensive discussions we had in the past that they should be
> modeled with two pins, one for the Y component and one for C components.
> The rationale for this is to support systems where such a connector
> could be used to carry S-Video, but also two composite video signals
> (usually through an external adapter from 2 RCA female connectors to one
> S-Video male connector) that would be routed to two separate video
> decoders (or two different inputs of the same video decoder). Other
> topologies may be possible too.
I got your concerns and I also remember the tvp5150 port bindings
myself in the past. Do you know how often such a setup you described
above happens these days? I would rather add more documentation to the
bindings [1] and add a check to v4l2_fwnode_parse_connector() to
guarantee that one port has only one endpoint. Because I don't think
that analog connectors has a bright future these days.
[1] Documentation/devicetree/bindings/display/connector/ \
analog-tv-connector.txt
> > The specific fields are within a union, since only one of them can be
> > available at the time. Since this is the initial support the patch adds
> > only the analog-connector specific ones.
> >
> > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
> > ---
> > [1] https://patchwork.kernel.org/cover/10794703/
> >
> > v6:
> > - fix some spelling and style issues
> > - rm unnecessary comments
> > - drop vga and dvi connector
> >
> > v2-v4:
> > - nothing since the patch was squashed from series [1] into this
> > series.
> >
> > include/media/v4l2-connector.h | 30 ++++++++++++++++++++++++++++++
> > include/media/v4l2-fwnode.h | 33 +++++++++++++++++++++++++++++++++
> > 2 files changed, 63 insertions(+)
> > create mode 100644 include/media/v4l2-connector.h
> >
> > diff --git a/include/media/v4l2-connector.h b/include/media/v4l2-connector.h
> > new file mode 100644
> > index 000000000000..3a951c54f50e
> > --- /dev/null
> > +++ b/include/media/v4l2-connector.h
> > @@ -0,0 +1,30 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * v4l2-connector.h
> > + *
> > + * V4L2 connector types.
> > + *
> > + * Copyright 2019 Pengutronix, Marco Felsch <kernel@pengutronix.de>
> > + */
> > +
> > +#ifndef V4L2_CONNECTOR_H
> > +#define V4L2_CONNECTOR_H
> > +
> > +#define V4L2_CONNECTOR_MAX_LABEL 41
>
> Hans pointed out this was a weird number. Should you turn the label
> field into a pointer to make this more generic (with a
> v4l2_fwnode_connector_cleanup() function then) ?
Yes, that would be the better approach. I will change that.
Regards,
Marco
> > +
> > +/**
> > + * enum v4l2_connector_type - connector type
> > + * @V4L2_CON_UNKNOWN: unknown connector type, no V4L2 connetor configuration
> > + * @V4L2_CON_COMPOSITE: analog composite connector
> > + * @V4L2_CON_SVIDEO: analog svideo connector
> > + * @V4L2_CON_HDMI: digital hdmi connector
> > + */
> > +enum v4l2_connector_type {
> > + V4L2_CON_UNKNOWN,
> > + V4L2_CON_COMPOSITE,
> > + V4L2_CON_SVIDEO,
> > + V4L2_CON_HDMI,
> > +};
> > +
> > +#endif /* V4L2_CONNECTOR_H */
> > +
> > diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h
> > index 6c07825e18b9..f4df1b95c5ef 100644
> > --- a/include/media/v4l2-fwnode.h
> > +++ b/include/media/v4l2-fwnode.h
> > @@ -22,6 +22,7 @@
> > #include <linux/list.h>
> > #include <linux/types.h>
> >
> > +#include <media/v4l2-connector.h>
> > #include <media/v4l2-mediabus.h>
> > #include <media/v4l2-subdev.h>
> >
> > @@ -126,6 +127,38 @@ struct v4l2_fwnode_link {
> > unsigned int remote_port;
> > };
> >
> > +/**
> > + * struct v4l2_fwnode_connector_analog - analog connector data structure
> > + * @supported_tvnorms: tv norms this connector supports, set to V4L2_STD_ALL
> > + * if no restrictions are specified.
> > + */
> > +struct v4l2_fwnode_connector_analog {
> > + v4l2_std_id supported_tvnorms;
> > +};
> > +
> > +/**
> > + * struct v4l2_fwnode_connector - the connector data structure
> > + * @remote_port: identifier of the remote endpoint port the connector connects
> > + * to
> > + * @remote_id: identifier of the remote endpoint the connector connects to
> > + * @label: connetor label
> > + * @type: connector type
> > + * @connector: connector configuration
> > + * @connector.analog: analog connector configuration
> > + * &struct v4l2_fwnode_connector_analog
> > + */
> > +struct v4l2_fwnode_connector {
> > + unsigned int remote_port;
> > + unsigned int remote_id;
> > + char label[V4L2_CONNECTOR_MAX_LABEL];
> > + enum v4l2_connector_type type;
> > +
> > + union {
> > + struct v4l2_fwnode_connector_analog analog;
> > + /* future connectors */
> > + } connector;
> > +};
> > +
> > /**
> > * v4l2_fwnode_endpoint_parse() - parse all fwnode node properties
> > * @fwnode: pointer to the endpoint's fwnode handle
>
> --
> Regards,
>
> Laurent Pinchart
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 4/4] regulator: qcom-rpmh: Update PMIC modes for PMIC5
From: Vinod Koul @ 2019-08-09 7:36 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-msm, Bjorn Andersson, Vinod Koul, Andy Gross,
Liam Girdwood, Rob Herring, Mark Rutland, linux-kernel,
devicetree
In-Reply-To: <20190809073616.1235-1-vkoul@kernel.org>
Add the PMIC5 modes and use them pmic5 ldo and smps
Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
drivers/regulator/qcom-rpmh-regulator.c | 52 +++++++++++++++++++++----
1 file changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c
index 391ed844a251..db6c085da65e 100644
--- a/drivers/regulator/qcom-rpmh-regulator.c
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -50,6 +50,20 @@ enum rpmh_regulator_type {
#define PMIC4_BOB_MODE_AUTO 2
#define PMIC4_BOB_MODE_PWM 3
+#define PMIC5_LDO_MODE_RETENTION 3
+#define PMIC5_LDO_MODE_LPM 4
+#define PMIC5_LDO_MODE_HPM 7
+
+#define PMIC5_SMPS_MODE_RETENTION 3
+#define PMIC5_SMPS_MODE_PFM 4
+#define PMIC5_SMPS_MODE_AUTO 6
+#define PMIC5_SMPS_MODE_PWM 7
+
+#define PMIC5_BOB_MODE_PASS 2
+#define PMIC5_BOB_MODE_PFM 4
+#define PMIC5_BOB_MODE_AUTO 6
+#define PMIC5_BOB_MODE_PWM 7
+
/**
* struct rpmh_vreg_hw_data - RPMh regulator hardware configurations
* @regulator_type: RPMh accelerator type used to manage this
@@ -488,6 +502,14 @@ static const int pmic_mode_map_pmic4_ldo[REGULATOR_MODE_STANDBY + 1] = {
[REGULATOR_MODE_FAST] = -EINVAL,
};
+static const int pmic_mode_map_pmic5_ldo[REGULATOR_MODE_STANDBY + 1] = {
+ [REGULATOR_MODE_INVALID] = -EINVAL,
+ [REGULATOR_MODE_STANDBY] = PMIC5_LDO_MODE_RETENTION,
+ [REGULATOR_MODE_IDLE] = PMIC5_LDO_MODE_LPM,
+ [REGULATOR_MODE_NORMAL] = PMIC5_LDO_MODE_HPM,
+ [REGULATOR_MODE_FAST] = -EINVAL,
+};
+
static unsigned int rpmh_regulator_pmic4_ldo_of_map_mode(unsigned int rpmh_mode)
{
unsigned int mode;
@@ -518,6 +540,14 @@ static const int pmic_mode_map_pmic4_smps[REGULATOR_MODE_STANDBY + 1] = {
[REGULATOR_MODE_FAST] = PMIC4_SMPS_MODE_PWM,
};
+static const int pmic_mode_map_pmic5_smps[REGULATOR_MODE_STANDBY + 1] = {
+ [REGULATOR_MODE_INVALID] = -EINVAL,
+ [REGULATOR_MODE_STANDBY] = PMIC5_SMPS_MODE_RETENTION,
+ [REGULATOR_MODE_IDLE] = PMIC5_SMPS_MODE_PFM,
+ [REGULATOR_MODE_NORMAL] = PMIC5_SMPS_MODE_AUTO,
+ [REGULATOR_MODE_FAST] = PMIC5_SMPS_MODE_PWM,
+};
+
static unsigned int
rpmh_regulator_pmic4_smps_of_map_mode(unsigned int rpmh_mode)
{
@@ -552,6 +582,14 @@ static const int pmic_mode_map_pmic4_bob[REGULATOR_MODE_STANDBY + 1] = {
[REGULATOR_MODE_FAST] = PMIC4_BOB_MODE_PWM,
};
+static const int pmic_mode_map_pmic5_bob[REGULATOR_MODE_STANDBY + 1] = {
+ [REGULATOR_MODE_INVALID] = -EINVAL,
+ [REGULATOR_MODE_STANDBY] = -EINVAL,
+ [REGULATOR_MODE_IDLE] = PMIC5_BOB_MODE_PFM,
+ [REGULATOR_MODE_NORMAL] = PMIC5_BOB_MODE_AUTO,
+ [REGULATOR_MODE_FAST] = PMIC5_BOB_MODE_PWM,
+};
+
static unsigned int rpmh_regulator_pmic4_bob_of_map_mode(unsigned int rpmh_mode)
{
unsigned int mode;
@@ -643,7 +681,7 @@ static const struct rpmh_vreg_hw_data pmic5_pldo = {
.voltage_range = REGULATOR_LINEAR_RANGE(1504000, 0, 255, 8000),
.n_voltages = 256,
.hpm_min_load_uA = 10000,
- .pmic_mode_map = pmic_mode_map_pmic4_ldo,
+ .pmic_mode_map = pmic_mode_map_pmic5_ldo,
.of_map_mode = rpmh_regulator_pmic4_ldo_of_map_mode,
};
@@ -653,7 +691,7 @@ static const struct rpmh_vreg_hw_data pmic5_pldo_lv = {
.voltage_range = REGULATOR_LINEAR_RANGE(1504000, 0, 62, 8000),
.n_voltages = 63,
.hpm_min_load_uA = 10000,
- .pmic_mode_map = pmic_mode_map_pmic4_ldo,
+ .pmic_mode_map = pmic_mode_map_pmic5_ldo,
.of_map_mode = rpmh_regulator_pmic4_ldo_of_map_mode,
};
@@ -663,7 +701,7 @@ static const struct rpmh_vreg_hw_data pmic5_nldo = {
.voltage_range = REGULATOR_LINEAR_RANGE(320000, 0, 123, 8000),
.n_voltages = 124,
.hpm_min_load_uA = 30000,
- .pmic_mode_map = pmic_mode_map_pmic4_ldo,
+ .pmic_mode_map = pmic_mode_map_pmic5_ldo,
.of_map_mode = rpmh_regulator_pmic4_ldo_of_map_mode,
};
@@ -672,7 +710,7 @@ static const struct rpmh_vreg_hw_data pmic5_hfsmps510 = {
.ops = &rpmh_regulator_vrm_ops,
.voltage_range = REGULATOR_LINEAR_RANGE(320000, 0, 215, 8000),
.n_voltages = 216,
- .pmic_mode_map = pmic_mode_map_pmic4_smps,
+ .pmic_mode_map = pmic_mode_map_pmic5_smps,
.of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode,
};
@@ -681,7 +719,7 @@ static const struct rpmh_vreg_hw_data pmic5_ftsmps510 = {
.ops = &rpmh_regulator_vrm_ops,
.voltage_range = REGULATOR_LINEAR_RANGE(300000, 0, 263, 4000),
.n_voltages = 264,
- .pmic_mode_map = pmic_mode_map_pmic4_smps,
+ .pmic_mode_map = pmic_mode_map_pmic5_smps,
.of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode,
};
@@ -690,7 +728,7 @@ static const struct rpmh_vreg_hw_data pmic5_hfsmps515 = {
.ops = &rpmh_regulator_vrm_ops,
.voltage_range = REGULATOR_LINEAR_RANGE(2800000, 0, 4, 1600),
.n_voltages = 5,
- .pmic_mode_map = pmic_mode_map_pmic4_smps,
+ .pmic_mode_map = pmic_mode_map_pmic5_smps,
.of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode,
};
@@ -699,7 +737,7 @@ static const struct rpmh_vreg_hw_data pmic5_bob = {
.ops = &rpmh_regulator_vrm_bypass_ops,
.voltage_range = REGULATOR_LINEAR_RANGE(300000, 0, 135, 32000),
.n_voltages = 136,
- .pmic_mode_map = pmic_mode_map_pmic4_bob,
+ .pmic_mode_map = pmic_mode_map_pmic5_bob,
.of_map_mode = rpmh_regulator_pmic4_bob_of_map_mode,
};
--
2.20.1
^ permalink raw reply related
* [PATCH 3/4] regulator: qcom-rpmh: Fix pmic5_bob voltage count
From: Vinod Koul @ 2019-08-09 7:36 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-msm, Bjorn Andersson, Vinod Koul, Andy Gross,
Liam Girdwood, Rob Herring, Mark Rutland, linux-kernel,
devicetree
In-Reply-To: <20190809073616.1235-1-vkoul@kernel.org>
pmic5_bob voltages count is 136 [0,135] so update it
Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
drivers/regulator/qcom-rpmh-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c
index 0ef2716da3bd..391ed844a251 100644
--- a/drivers/regulator/qcom-rpmh-regulator.c
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -698,7 +698,7 @@ static const struct rpmh_vreg_hw_data pmic5_bob = {
.regulator_type = VRM,
.ops = &rpmh_regulator_vrm_bypass_ops,
.voltage_range = REGULATOR_LINEAR_RANGE(300000, 0, 135, 32000),
- .n_voltages = 135,
+ .n_voltages = 136,
.pmic_mode_map = pmic_mode_map_pmic4_bob,
.of_map_mode = rpmh_regulator_pmic4_bob_of_map_mode,
};
--
2.20.1
^ permalink raw reply related
* [PATCH 2/4] regulator: qcom-rpmh: Sort the compatibles
From: Vinod Koul @ 2019-08-09 7:36 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-msm, Bjorn Andersson, Vinod Koul, Andy Gross,
Liam Girdwood, Rob Herring, Mark Rutland, linux-kernel,
devicetree
In-Reply-To: <20190809073616.1235-1-vkoul@kernel.org>
It helps to keep sorted order for compatibles, so sort them
Suggested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
drivers/regulator/qcom-rpmh-regulator.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c
index 693ffec62f3e..0ef2716da3bd 100644
--- a/drivers/regulator/qcom-rpmh-regulator.c
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -878,18 +878,14 @@ static int rpmh_regulator_probe(struct platform_device *pdev)
}
static const struct of_device_id rpmh_regulator_match_table[] = {
- {
- .compatible = "qcom,pm8998-rpmh-regulators",
- .data = pm8998_vreg_data,
- },
- {
- .compatible = "qcom,pmi8998-rpmh-regulators",
- .data = pmi8998_vreg_data,
- },
{
.compatible = "qcom,pm8005-rpmh-regulators",
.data = pm8005_vreg_data,
},
+ {
+ .compatible = "qcom,pm8009-rpmh-regulators",
+ .data = pm8009_vreg_data,
+ },
{
.compatible = "qcom,pm8150-rpmh-regulators",
.data = pm8150_vreg_data,
@@ -899,8 +895,12 @@ static const struct of_device_id rpmh_regulator_match_table[] = {
.data = pm8150l_vreg_data,
},
{
- .compatible = "qcom,pm8009-rpmh-regulators",
- .data = pm8009_vreg_data,
+ .compatible = "qcom,pm8998-rpmh-regulators",
+ .data = pm8998_vreg_data,
+ },
+ {
+ .compatible = "qcom,pmi8998-rpmh-regulators",
+ .data = pmi8998_vreg_data,
},
{}
};
--
2.20.1
^ permalink raw reply related
* [PATCH 1/4] regulator: dt-bindings: Sort the compatibles and nodes
From: Vinod Koul @ 2019-08-09 7:36 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-msm, Bjorn Andersson, Vinod Koul, Andy Gross,
Liam Girdwood, Rob Herring, Mark Rutland, linux-kernel,
devicetree
It helps to keep sorted order for compatibles and nodes, so sort them
Suggested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
.../regulator/qcom,rpmh-regulator.txt | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
index 1a9cab50503a..bab9f71140b8 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
@@ -22,12 +22,12 @@ RPMh resource.
The names used for regulator nodes must match those supported by a given PMIC.
Supported regulator node names:
- PM8998: smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2
- PMI8998: bob
PM8005: smps1 - smps4
+ PM8009: smps1 - smps2, ldo1 - ldo7
PM8150: smps1 - smps10, ldo1 - ldo18
PM8150L: smps1 - smps8, ldo1 - ldo11, bob, flash, rgb
- PM8009: smps1 - smps2, ld01 - ldo7
+ PM8998: smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2
+ PMI8998: bob
========================
First Level Nodes - PMIC
@@ -36,12 +36,13 @@ First Level Nodes - PMIC
- compatible
Usage: required
Value type: <string>
- Definition: Must be one of: "qcom,pm8998-rpmh-regulators",
- "qcom,pmi8998-rpmh-regulators" or
- "qcom,pm8005-rpmh-regulators" or
- "qcom,pm8150-rpmh-regulators" or
- "qcom,pm8150l-rpmh-regulators" or
- "qcom,pm8009-rpmh-regulators".
+ Definition: Must be one of below:
+ "qcom,pm8005-rpmh-regulators"
+ "qcom,pm8009-rpmh-regulators"
+ "qcom,pm8150-rpmh-regulators"
+ "qcom,pm8150l-rpmh-regulators"
+ "qcom,pm8998-rpmh-regulators"
+ "qcom,pmi8998-rpmh-regulators"
- qcom,pmic-id
Usage: required
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v6 02/13] media: v4l2-fwnode: add v4l2_fwnode_connector
From: Marco Felsch @ 2019-08-09 7:20 UTC (permalink / raw)
To: Hans Verkuil
Cc: mchehab, sakari.ailus, hans.verkuil, jacopo+renesas, robh+dt,
laurent.pinchart, linux-media, devicetree, kernel, Jacopo Mondi
In-Reply-To: <c5c4b88d-7977-e253-1242-b9a86228a302@xs4all.nl>
On 19-05-06 11:50, Hans Verkuil wrote:
> On 4/15/19 2:44 PM, Marco Felsch wrote:
> > Currently every driver needs to parse the connector endpoints by it self.
> > This is the initial work to make this generic. The generic connector has
> > some common fields and some connector specific parts. The generic one
> > includes:
> > - type
> > - label
> > - remote_port (the port where the connector is connected to)
> > - remote_id (the endpoint where the connector is connected to)
> >
> > The specific fields are within a union, since only one of them can be
> > available at the time. Since this is the initial support the patch adds
> > only the analog-connector specific ones.
> >
> > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
> > ---
> > [1] https://patchwork.kernel.org/cover/10794703/
> >
> > v6:
> > - fix some spelling and style issues
> > - rm unnecessary comments
> > - drop vga and dvi connector
> >
> > v2-v4:
> > - nothing since the patch was squashed from series [1] into this
> > series.
> >
> > include/media/v4l2-connector.h | 30 ++++++++++++++++++++++++++++++
> > include/media/v4l2-fwnode.h | 33 +++++++++++++++++++++++++++++++++
> > 2 files changed, 63 insertions(+)
> > create mode 100644 include/media/v4l2-connector.h
> >
> > diff --git a/include/media/v4l2-connector.h b/include/media/v4l2-connector.h
> > new file mode 100644
> > index 000000000000..3a951c54f50e
> > --- /dev/null
> > +++ b/include/media/v4l2-connector.h
> > @@ -0,0 +1,30 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * v4l2-connector.h
> > + *
> > + * V4L2 connector types.
> > + *
> > + * Copyright 2019 Pengutronix, Marco Felsch <kernel@pengutronix.de>
> > + */
> > +
> > +#ifndef V4L2_CONNECTOR_H
> > +#define V4L2_CONNECTOR_H
> > +
> > +#define V4L2_CONNECTOR_MAX_LABEL 41
>
> Where does 41 come from? It's a weird number...
What would you suggest?
>
> > +
> > +/**
> > + * enum v4l2_connector_type - connector type
> > + * @V4L2_CON_UNKNOWN: unknown connector type, no V4L2 connetor configuration
>
> typo: connetor -> connector
>
> > + * @V4L2_CON_COMPOSITE: analog composite connector
> > + * @V4L2_CON_SVIDEO: analog svideo connector
> > + * @V4L2_CON_HDMI: digital hdmi connector
> > + */
> > +enum v4l2_connector_type {
> > + V4L2_CON_UNKNOWN,
> > + V4L2_CON_COMPOSITE,
> > + V4L2_CON_SVIDEO,
> > + V4L2_CON_HDMI,
> > +};
> > +
> > +#endif /* V4L2_CONNECTOR_H */
> > +
>
> Is there a reason to create a new header for this? I think it is perfectly OK to
> add this define + enum for v4l2-fwnode.h.
Okay, I can squash it.
>
> > diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h
> > index 6c07825e18b9..f4df1b95c5ef 100644
> > --- a/include/media/v4l2-fwnode.h
> > +++ b/include/media/v4l2-fwnode.h
> > @@ -22,6 +22,7 @@
> > #include <linux/list.h>
> > #include <linux/types.h>
> >
> > +#include <media/v4l2-connector.h>
> > #include <media/v4l2-mediabus.h>
> > #include <media/v4l2-subdev.h>
> >
> > @@ -126,6 +127,38 @@ struct v4l2_fwnode_link {
> > unsigned int remote_port;
> > };
> >
> > +/**
> > + * struct v4l2_fwnode_connector_analog - analog connector data structure
> > + * @supported_tvnorms: tv norms this connector supports, set to V4L2_STD_ALL
> > + * if no restrictions are specified.
> > + */
> > +struct v4l2_fwnode_connector_analog {
> > + v4l2_std_id supported_tvnorms;
> > +};
> > +
> > +/**
> > + * struct v4l2_fwnode_connector - the connector data structure
> > + * @remote_port: identifier of the remote endpoint port the connector connects
> > + * to
> > + * @remote_id: identifier of the remote endpoint the connector connects to
> > + * @label: connetor label
>
> Same typo. It's probably a good idea to grep for this typo in this patch series :-)
I will grep it shortly before I send the new v7 ;-)
Regards,
Marco
>
> > + * @type: connector type
> > + * @connector: connector configuration
> > + * @connector.analog: analog connector configuration
> > + * &struct v4l2_fwnode_connector_analog
> > + */
> > +struct v4l2_fwnode_connector {
> > + unsigned int remote_port;
> > + unsigned int remote_id;
> > + char label[V4L2_CONNECTOR_MAX_LABEL];
> > + enum v4l2_connector_type type;
> > +
> > + union {
> > + struct v4l2_fwnode_connector_analog analog;
> > + /* future connectors */
> > + } connector;
> > +};
> > +
> > /**
> > * v4l2_fwnode_endpoint_parse() - parse all fwnode node properties
> > * @fwnode: pointer to the endpoint's fwnode handle
> >
>
> Regards,
>
> Hans
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: media: i2c: Add bindings for Maxim Integrated MAX9286
From: Geert Uytterhoeven @ 2019-08-09 7:19 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Jacopo Mondi, Kieran Bingham, Laurent Pinchart,
Linux Media Mailing List, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20190809040558.10698-2-niklas.soderlund+renesas@ragnatech.se>
CC devicetree
cover letter at
https://lore.kernel.org/linux-renesas-soc/20190809040558.10698-1-niklas.soderlund+renesas@ragnatech.se/
On Fri, Aug 9, 2019 at 6:07 AM Niklas Söderlund
<niklas.soderlund+renesas@ragnatech.se> wrote:
> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>
> The MAX9286 deserializes video data received on up to 4 Gigabit
> Multimedia Serial Links (GMSL) and outputs them on a CSI-2 port using up
> to 4 data lanes.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> .../bindings/media/i2c/maxim,max9286.txt | 182 ++++++++++++++++++
> 1 file changed, 182 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt
> new file mode 100644
> index 0000000000000000..afff77a55bb70744
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt
> @@ -0,0 +1,182 @@
> +Maxim Integrated Quad GMSL Deserializer
> +---------------------------------------
> +
> +The MAX9286 deserializer receives video data on up to 4 Gigabit Multimedia
> +Serial Links (GMSL) and outputs them on a CSI-2 D-PHY port using up to 4 data
> +lanes.
> +
> +In addition to video data, the GMSL links carry a bidirectional control channel
> +that encapsulates I2C messages. The MAX9286 forwards all I2C traffic not
> +addressed to itself to the other side of the links, where a GMSL serializer
> +will output it on a local I2C bus. In the other direction all I2C traffic
> +received over GMSL by the MAX9286 is output on the local I2C bus.
> +
> +Required Properties:
> +
> +- compatible: Shall be "maxim,max9286"
> +- reg: I2C device address
> +
> +Optional Properties:
> +
> +- poc-supply: Regulator providing Power over Coax to the cameras
> +- enable-gpios: GPIO connected to the #PWDN pin with inverted polarity
> +
> +Required endpoint nodes:
> +-----------------------
> +
> +The connections to the MAX9286 GMSL and its endpoint nodes are modelled using
> +the OF graph bindings in accordance with the video interface bindings defined
> +in Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +The following table lists the port number corresponding to each device port.
> +
> + Port Description
> + ----------------------------------------
> + Port 0 GMSL Input 0
> + Port 1 GMSL Input 1
> + Port 2 GMSL Input 2
> + Port 3 GMSL Input 3
> + Port 4 CSI-2 Output
> +
> +Optional Endpoint Properties for GMSL Input Ports (Port [0-3]):
> +
> +- remote-endpoint: phandle to the remote GMSL source endpoint subnode in the
> + remote node port.
> +
> +Required Endpoint Properties for CSI-2 Output Port (Port 4):
> +
> +- remote-endpoint: phandle to the remote CSI-2 sink endpoint node.
> +- data-lanes: array of physical CSI-2 data lane indexes.
> +
> +Required i2c-mux nodes:
> +----------------------
> +
> +Each GMSL link is modelled as a child bus of an i2c bus multiplexer/switch, in
> +accordance with bindings described in
> +Documentation/devicetree/bindings/i2c/i2c-mux.txt. The serializer device on the
> +remote end of the GMSL link shall be modelled as a child node of the
> +corresponding I2C bus.
> +
> +Required i2c child bus properties:
> +- all properties described as required i2c child bus nodes properties in
> + Documentation/devicetree/bindings/i2c/i2c-mux.txt.
> +
> +Example:
> +-------
> +
> + gmsl-deserializer@2c {
> + compatible = "maxim,max9286";
> + reg = <0x2c>;
> + poc-supply = <&camera_poc_12v>;
> + enable-gpios = <&gpio 13 GPIO_ACTIVE_HIGH>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + max9286_in0: endpoint {
> + remote-endpoint = <&rdacm20_out0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + max9286_in1: endpoint {
> + remote-endpoint = <&rdacm20_out1>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + max9286_in2: endpoint {
> + remote-endpoint = <&rdacm20_out2>;
> + };
> + };
> +
> + port@3 {
> + reg = <3>;
> + max9286_in3: endpoint {
> + remote-endpoint = <&rdacm20_out3>;
> + };
> + };
> +
> + port@4 {
> + reg = <4>;
> + max9286_out: endpoint {
> + data-lanes = <1 2 3 4>;
> + remote-endpoint = <&csi40_in>;
> + };
> + };
> + };
> +
> + i2c@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + camera@51 {
> + compatible = "imi,rdacm20";
> + reg = <0x51 0x61>;
> +
> + port {
> + rdacm20_out0: endpoint {
> + remote-endpoint = <&max9286_in0>;
> + };
> + };
> +
> + };
> + };
> +
> + i2c@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + camera@52 {
> + compatible = "imi,rdacm20";
> + reg = <0x52 0x62>;
> + port {
> + rdacm20_out1: endpoint {
> + remote-endpoint = <&max9286_in1>;
> + };
> + };
> + };
> + };
> +
> + i2c@2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <2>;
> +
> + camera@53 {
> + compatible = "imi,rdacm20";
> + reg = <0x53 0x63>;
> + port {
> + rdacm20_out2: endpoint {
> + remote-endpoint = <&max9286_in2>;
> + };
> + };
> + };
> + };
> +
> + i2c@3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <3>;
> +
> + camera@54 {
> + compatible = "imi,rdacm20";
> + reg = <0x54 0x64>;
> + port {
> + rdacm20_out3: endpoint {
> + remote-endpoint = <&max9286_in3>;
> + };
> + };
> + };
> + };
> + };
> --
> 2.22.0
>
^ permalink raw reply
* [PATCH 4/4] ARM: dts: imx7ulp: Add wdog1 node
From: Anson Huang @ 2019-08-09 7:14 UTC (permalink / raw)
To: wim, linux, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, linux, otavio, leonard.crestez, schnitzeltony,
u.kleine-koenig, jan.tuerk, linux-watchdog, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1565334842-28161-1-git-send-email-Anson.Huang@nxp.com>
Add wdog1 node to support watchdog driver.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx7ulp.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index 6859a3a..1fdb5a35 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -264,6 +264,16 @@
#clock-cells = <1>;
};
+ wdog1: wdog@403d0000 {
+ compatible = "fsl,imx7ulp-wdt";
+ reg = <0x403d0000 0x10000>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
+ assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
+ assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>;
+ timeout-sec = <40>;
+ };
+
pcc2: clock-controller@403f0000 {
compatible = "fsl,imx7ulp-pcc2";
reg = <0x403f0000 0x10000>;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] ARM: imx_v6_v7_defconfig: Enable CONFIG_IMX7ULP_WDT by default
From: Anson Huang @ 2019-08-09 7:14 UTC (permalink / raw)
To: wim, linux, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, linux, otavio, leonard.crestez, schnitzeltony,
u.kleine-koenig, jan.tuerk, linux-watchdog, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1565334842-28161-1-git-send-email-Anson.Huang@nxp.com>
Select CONFIG_IMX7ULP_WDT by default to support i.MX7ULP watchdog.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index bd2e2f5..f69075b 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -235,6 +235,7 @@ CONFIG_DA9062_WATCHDOG=y
CONFIG_DA9063_WATCHDOG=m
CONFIG_RN5T618_WATCHDOG=y
CONFIG_IMX2_WDT=y
+CONFIG_IMX7ULP_WDT=y
CONFIG_MFD_DA9052_I2C=y
CONFIG_MFD_DA9062=y
CONFIG_MFD_DA9063=y
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] watchdog: Add i.MX7ULP watchdog support
From: Anson Huang @ 2019-08-09 7:14 UTC (permalink / raw)
To: wim, linux, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, linux, otavio, leonard.crestez, schnitzeltony,
u.kleine-koenig, jan.tuerk, linux-watchdog, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1565334842-28161-1-git-send-email-Anson.Huang@nxp.com>
The i.MX7ULP Watchdog Timer (WDOG) module is an independent timer
that is available for system use.
It provides a safety feature to ensure that software is executing
as planned and that the CPU is not stuck in an infinite loop or
executing unintended code. If the WDOG module is not serviced
(refreshed) within a certain period, it resets the MCU.
Add driver support for i.MX7ULP watchdog.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/watchdog/Kconfig | 13 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/imx7ulp_wdt.c | 221 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 235 insertions(+)
create mode 100644 drivers/watchdog/imx7ulp_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 8188963..0884e53 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -740,6 +740,19 @@ config IMX_SC_WDT
To compile this driver as a module, choose M here: the
module will be called imx_sc_wdt.
+config IMX7ULP_WDT
+ tristate "IMX7ULP Watchdog"
+ depends on ARCH_MXC || COMPILE_TEST
+ select WATCHDOG_CORE
+ help
+ This is the driver for the hardware watchdog on the Freescale
+ IMX7ULP and later processors. If you have one of these
+ processors and wish to have watchdog support enabled,
+ say Y, otherwise say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx7ulp_wdt.
+
config UX500_WATCHDOG
tristate "ST-Ericsson Ux500 watchdog"
depends on MFD_DB8500_PRCMU
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 7caa920..7d32537 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o
+obj-$(CONFIG_IMX7ULP_WDT) += imx7ulp_wdt.o
obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
diff --git a/drivers/watchdog/imx7ulp_wdt.c b/drivers/watchdog/imx7ulp_wdt.c
new file mode 100644
index 0000000..8d56023
--- /dev/null
+++ b/drivers/watchdog/imx7ulp_wdt.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reboot.h>
+#include <linux/watchdog.h>
+
+#define WDOG_CS 0x0
+#define WDOG_CS_CMD32EN (1 << 13)
+#define WDOG_CS_ULK (1 << 11)
+#define WDOG_CS_RCS (1 << 10)
+#define WDOG_CS_EN (1 << 7)
+#define WDOG_CS_UPDATE (1 << 5)
+
+#define WDOG_CNT 0x4
+#define WDOG_TOVAL 0x8
+
+#define REFRESH_SEQ0 0xA602
+#define REFRESH_SEQ1 0xB480
+#define REFRESH ((REFRESH_SEQ1 << 16) | (REFRESH_SEQ0))
+
+#define UNLOCK_SEQ0 0xC520
+#define UNLOCK_SEQ1 0xD928
+#define UNLOCK ((UNLOCK_SEQ1 << 16) | (UNLOCK_SEQ0))
+
+#define DEFAULT_TIMEOUT 60
+#define MAX_TIMEOUT 128
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0000);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct imx7ulp_wdt_device {
+ struct notifier_block restart_handler;
+ struct watchdog_device wdd;
+ void __iomem *base;
+ int rate;
+};
+
+static inline void imx7ulp_wdt_enable(void __iomem *base, bool enable)
+{
+ u32 val = readl(base + WDOG_CS);
+
+ writel(UNLOCK, base + WDOG_CNT);
+ if (enable)
+ writel(val | WDOG_CS_EN, base + WDOG_CS);
+ else
+ writel(val & ~WDOG_CS_EN, base + WDOG_CS);
+}
+
+static inline bool imx7ulp_wdt_is_enabled(void __iomem *base)
+{
+ u32 val = readl(base + WDOG_CS);
+
+ return val & WDOG_CS_EN;
+}
+
+static int imx7ulp_wdt_ping(struct watchdog_device *wdog)
+{
+ struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
+
+ writel(REFRESH, wdt->base + WDOG_CNT);
+
+ return 0;
+}
+
+static int imx7ulp_wdt_start(struct watchdog_device *wdog)
+{
+ struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
+
+ imx7ulp_wdt_enable(wdt->base, true);
+
+ return 0;
+}
+
+static int imx7ulp_wdt_stop(struct watchdog_device *wdog)
+{
+ struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
+
+ imx7ulp_wdt_enable(wdt->base, false);
+
+ return 0;
+}
+
+static int imx7ulp_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int timeout)
+{
+ struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
+ u32 val = wdt->rate * timeout;
+
+ writel(UNLOCK, wdt->base + WDOG_CNT);
+ writel(val, wdt->base + WDOG_TOVAL);
+
+ wdog->timeout = timeout;
+
+ return 0;
+}
+
+static const struct watchdog_ops imx7ulp_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = imx7ulp_wdt_start,
+ .stop = imx7ulp_wdt_stop,
+ .ping = imx7ulp_wdt_ping,
+ .set_timeout = imx7ulp_wdt_set_timeout,
+};
+
+static const struct watchdog_info imx7ulp_wdt_info = {
+ .identity = "i.MX7ULP watchdog timer",
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+ WDIOF_MAGICCLOSE,
+};
+
+static inline void imx7ulp_wdt_init(void __iomem *base, unsigned int timeout)
+{
+ u32 val;
+
+ /* unlock the wdog for reconfiguration */
+ writel_relaxed(UNLOCK_SEQ0, base + WDOG_CNT);
+ writel_relaxed(UNLOCK_SEQ1, base + WDOG_CNT);
+
+ /* set an initial timeout value in TOVAL */
+ writel(timeout, base + WDOG_TOVAL);
+ /* enable 32bit command sequence and reconfigure */
+ val = (1 << 13) | (1 << 8) | (1 << 5);
+ writel(val, base + WDOG_CS);
+}
+
+static int imx7ulp_wdt_probe(struct platform_device *pdev)
+{
+ struct imx7ulp_wdt_device *imx7ulp_wdt;
+ struct device *dev = &pdev->dev;
+ struct watchdog_device *wdog;
+ int ret;
+
+ imx7ulp_wdt = devm_kzalloc(&pdev->dev,
+ sizeof(*imx7ulp_wdt), GFP_KERNEL);
+ if (!imx7ulp_wdt)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, imx7ulp_wdt);
+
+ imx7ulp_wdt->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(imx7ulp_wdt->base))
+ return PTR_ERR(imx7ulp_wdt->base);
+
+ imx7ulp_wdt->rate = 1000;
+ wdog = &imx7ulp_wdt->wdd;
+ wdog->info = &imx7ulp_wdt_info;
+ wdog->ops = &imx7ulp_wdt_ops;
+ wdog->min_timeout = 1;
+ wdog->max_timeout = MAX_TIMEOUT;
+ wdog->parent = dev;
+ wdog->timeout = DEFAULT_TIMEOUT;
+
+ watchdog_init_timeout(wdog, 0, dev);
+ watchdog_stop_on_reboot(wdog);
+ watchdog_stop_on_unregister(wdog);
+ watchdog_set_drvdata(wdog, imx7ulp_wdt);
+ imx7ulp_wdt_init(imx7ulp_wdt->base, wdog->timeout * imx7ulp_wdt->rate);
+
+ ret = devm_watchdog_register_device(dev, wdog);
+ if (ret)
+ dev_err(dev, "Failed to register watchdog device\n");
+
+ return ret;
+}
+
+static int __maybe_unused imx7ulp_wdt_suspend(struct device *dev)
+{
+ struct imx7ulp_wdt_device *imx7ulp_wdt = dev_get_drvdata(dev);
+
+ if (watchdog_active(&imx7ulp_wdt->wdd))
+ imx7ulp_wdt_stop(&imx7ulp_wdt->wdd);
+
+ return 0;
+}
+
+static int __maybe_unused imx7ulp_wdt_resume(struct device *dev)
+{
+ struct imx7ulp_wdt_device *imx7ulp_wdt = dev_get_drvdata(dev);
+ u32 timeout = imx7ulp_wdt->wdd.timeout * imx7ulp_wdt->rate;
+
+ if (imx7ulp_wdt_is_enabled(imx7ulp_wdt->base))
+ imx7ulp_wdt_init(imx7ulp_wdt->base, timeout);
+
+ if (watchdog_active(&imx7ulp_wdt->wdd))
+ imx7ulp_wdt_start(&imx7ulp_wdt->wdd);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(imx7ulp_wdt_pm_ops, imx7ulp_wdt_suspend,
+ imx7ulp_wdt_resume);
+
+static const struct of_device_id imx7ulp_wdt_dt_ids[] = {
+ { .compatible = "fsl,imx7ulp-wdt", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, imx7ulp_wdt_dt_ids);
+
+static struct platform_driver imx7ulp_wdt_driver = {
+ .probe = imx7ulp_wdt_probe,
+ .driver = {
+ .name = "imx7ulp-wdt",
+ .pm = &imx7ulp_wdt_pm_ops,
+ .of_match_table = imx7ulp_wdt_dt_ids,
+ },
+};
+module_platform_driver(imx7ulp_wdt_driver);
+
+MODULE_AUTHOR("Anson Huang <Anson.Huang@nxp.com>");
+MODULE_DESCRIPTION("Freescale i.MX7ULP watchdog driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: watchdog: Add i.MX7ULP bindings
From: Anson Huang @ 2019-08-09 7:13 UTC (permalink / raw)
To: wim, linux, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, linux, otavio, leonard.crestez, schnitzeltony,
u.kleine-koenig, jan.tuerk, linux-watchdog, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
Add the watchdog bindings for Freescale i.MX7ULP.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../bindings/watchdog/fsl-imx7ulp-wdt.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
new file mode 100644
index 0000000..d83fc5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt
@@ -0,0 +1,22 @@
+* Freescale i.MX7ULP Watchdog Timer (WDT) Controller
+
+Required properties:
+- compatible : Should be "fsl,imx7ulp-wdt"
+- reg : Should contain WDT registers location and length
+- interrupts : Should contain WDT interrupt
+- clocks: Should contain a phandle pointing to the gated peripheral clock.
+
+Optional properties:
+- timeout-sec : Contains the watchdog timeout in seconds
+
+Examples:
+
+wdog1: wdog@403d0000 {
+ compatible = "fsl,imx7ulp-wdt";
+ reg = <0x403d0000 0x10000>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
+ assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>;
+ assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>;
+ timeout-sec = <40>;
+};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 7/9] dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml
From: Neil Armstrong @ 2019-08-09 7:00 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, Rob Herring, kishon, robh+dt, linux-amlogic,
linux-arm-kernel
In-Reply-To: <CAFBinCBnVdTxWgqmnrPo-5uZ5gxy7p68w0PUa=_42fYxhVrDXQ@mail.gmail.com>
Hi,
On 08/08/2019 21:50, Martin Blumenstingl wrote:
> On Thu, Aug 8, 2019 at 10:54 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> Now that we have the DT validation in place, let's convert the device tree
>> bindings for the Amlogic G12A USB3 + PCIE Combo PHY over to a YAML schemas.
>>
>> While the original phy bindings specifies phy-supply as required,
>> the examples and implementations makes it optional, thus phy-supply
>> is not present in the properties and required lists.
> nit-pick: the original bindings didn't mention the phy-supply property at all
> I'm not sure if you have to re-send it, maybe this can be fixed up
> while applying?
It didn't, but the phy.txt made it mandatory, but was optional in all examples
and implementation, thus rob asked me to precise it in the commit log.
Neil
>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
^ 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