[PATCH] ARM: dts: rk3188-radxarock: add GPIO IR receiver node

This adds a device tree node for the infrared receiver connected to a
GPIO pin on the Radxa Rock.

Signed-off-by: Beniamino Galvani <redacted>
---
 arch/arm/boot/dts/rk3188-radxarock.dts |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts b/arch/arm/boot/dts/rk3188-radxarock.dts
index 19d45b4..1d87bcb 100644
--- a/arch/arm/boot/dts/rk3188-radxarock.dts
+++ b/arch/arm/boot/dts/rk3188-radxarock.dts

@@ -23,6 +23,13 @@
 		reg = <0x60000000 0x80000000>;
 	};
 
+	ir_recv: ir-receiver {
+		compatible = "gpio-ir-receiver";
+		gpios = <&gpio0 10 1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ir_recv_pin>;
+	};
+
 	soc {
 		uart0: serial at 10124000 {
 			status = "okay";

@@ -117,6 +124,12 @@
 					rockchip,pins = <RK_GPIO3 27 RK_FUNC_GPIO &pcfg_output_low>;
 				};
 			};
+
+			ir-receiver {
+				ir_recv_pin: ir-recv-pin {
+					rockchip,pins = <RK_GPIO0 10 RK_FUNC_GPIO &pcfg_pull_none>;
+				};
+			};
 		};
 
 	};

-- 
1.7.10.4

Am Sonntag, 13. Juli 2014, 14:10:01 schrieb Beniamino Galvani:

hmm, on second glance, I'm actually not sure if this shouldn't belong in the 
soc subnode, like the gpio-keys and leds.


Heiko

&pcfg_output_low>;

 				};
 			};
+
+			ir-receiver {
+				ir_recv_pin: ir-recv-pin {
+					rockchip,pins = <RK_GPIO0 10 RK_FUNC_GPIO 

&pcfg_pull_none>;

+				};
+			};
 		};

 	};

On Sun, Jul 13, 2014 at 02:37:40PM +0200, Heiko St?bner wrote:

Am Sonntag, 13. Juli 2014, 14:10:01 schrieb Beniamino Galvani:

quoted

This adds a device tree node for the infrared receiver connected to a
GPIO pin on the Radxa Rock.

Signed-off-by: Beniamino Galvani <redacted>
---
 arch/arm/boot/dts/rk3188-radxarock.dts |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts

b/arch/arm/boot/dts/rk3188-radxarock.dts index 19d45b4..1d87bcb 100644

--- a/arch/arm/boot/dts/rk3188-radxarock.dts
+++ b/arch/arm/boot/dts/rk3188-radxarock.dts

@@ -23,6 +23,13 @@
 		reg = <0x60000000 0x80000000>;
 	};

+	ir_recv: ir-receiver {
+		compatible = "gpio-ir-receiver";
+		gpios = <&gpio0 10 1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ir_recv_pin>;
+	};
+

hmm, on second glance, I'm actually not sure if this shouldn't belong in the 
soc subnode, like the gpio-keys and leds.

(adding devicetree mailing list)

I placed the IR receiver under the root node after looking at what
other boards do, for example:

  imx6dl-hummingboard.dts
  imx6qdl-cubox-i.dtsi
  dove-cubox.dts

On the other hand, if gpio-keys and leds are under the soc node
probably it makes sense to follow the same rule also for the IR
receiver.

Beniamino

Am Montag, 14. Juli 2014, 21:04:26 schrieb Beniamino Galvani:

On Sun, Jul 13, 2014 at 02:37:40PM +0200, Heiko St?bner wrote:

quoted

Am Sonntag, 13. Juli 2014, 14:10:01 schrieb Beniamino Galvani:

quoted

This adds a device tree node for the infrared receiver connected to a
GPIO pin on the Radxa Rock.

Signed-off-by: Beniamino Galvani <redacted>
---

 arch/arm/boot/dts/rk3188-radxarock.dts |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts

b/arch/arm/boot/dts/rk3188-radxarock.dts index 19d45b4..1d87bcb 100644

--- a/arch/arm/boot/dts/rk3188-radxarock.dts
+++ b/arch/arm/boot/dts/rk3188-radxarock.dts

@@ -23,6 +23,13 @@

 		reg = <0x60000000 0x80000000>;
 	
 	};

+	ir_recv: ir-receiver {
+		compatible = "gpio-ir-receiver";
+		gpios = <&gpio0 10 1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ir_recv_pin>;
+	};
+

hmm, on second glance, I'm actually not sure if this shouldn't belong in
the soc subnode, like the gpio-keys and leds.

(adding devicetree mailing list)

I placed the IR receiver under the root node after looking at what
other boards do, for example:

  imx6dl-hummingboard.dts
  imx6qdl-cubox-i.dtsi
  dove-cubox.dts

On the other hand, if gpio-keys and leds are under the soc node
probably it makes sense to follow the same rule also for the IR
receiver.

your way was the right one actually ... using artificial subnodes is not 
encouraged at all - see comments I received , so the soc node itself also may 
go away.

I'll add the patch to my queue.


Heiko