ARM: dts: Add wlcore wakeirq for omap3-evm

With wlcore supporting optional wakeirqs, we can configure it for pandaboard.

This makes ssh connection usable with the SoC
entering deeper idle states.

Let's configure a wakeirq both for the wlcore GPIO and the SDIO dat1 pin in case wlcore starts supporting SDIO dat1 interrupt at some point.

And let's also add the missing keep-power-in-suspend while at it.

Signed-off-by Tony Lindgren <[email protected]>

---
 arch/arm/boot/dts/omap4-droid4-xt894.dts | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

arch/arm/boot/dts/omap4-droid4-xt894.dts +7 -3

@@ -359,20 +359,24 @@
 
 &mmc3 {
 	vmmc-supply = <&wl12xx_vmmc>;
+	/* uart2_tx.sdmmc3_dat1 pad as wakeirq */
 	interrupts-extended = <&wakeupgen GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH
 			       &omap4_pmx_core 0xde>;
-
+	interrupt-names = "irq", "wakeup";
 	non-removable;
 	bus-width = <4>;
 	cap-power-off-card;
+	keep-power-in-suspend;
 
 	#address-cells = <1>;
 	#size-cells = <0>;
 	wlcore: wlcore@2 {
 		compatible = "ti,wl1285", "ti,wl1283";
 		reg = <2>;
-		interrupt-parent = <&gpio4>;
-		interrupts = <4 IRQ_TYPE_EDGE_RISING>; /* gpio100 */
+		/* gpio_100 with gpmc_wait2 pad as wakeirq */
+		interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>,
+				      <&omap4_pmx_core 0x4e>;
+		interrupt-names = "irq", "wakeup";
 		ref-clock-frequency = <26000000>;
 		tcxo-clock-frequency = <26000000>;
 	};

Signature · 1 line

2.19.2

Hi,

Quoted 2 lines · Tony Lindgren

With wlcore supporting optional wakeirqs, we can configure it for pandaboard.

-ENOPANDA

From tony Mon Sep 17 00:00:00 2001

With wlcore supporting optional wakeirqs, let's configure it for omap3-evm and update the related pin muxing as some pins are left unmuxed.

Let's configure a wakeirq both for the wlcore GPIO and the SDIO dat1 pin in case wlcore starts supporting SDIO dat1 interrupt at some point.

Note that for off-mode, the wlcore reset GPIO will have a glitch meaning wlcore will reset. The only way to workaround for this currently is to configure the reset pin with SAFE_MODE + PULL.

Signed-off-by Tony Lindgren <[email protected]>

---
 arch/arm/boot/dts/omap3-evm-common.dtsi           |  7 +++++--
 arch/arm/boot/dts/omap3-evm-processor-common.dtsi | 10 +++++++++-
 2 files changed, 14 insertions(+), 3 deletions(-)

arch/arm/boot/dts/omap3-evm-common.dtsi +1 -0

@@ -122,6 +122,7 @@
 };
 
 &mmc2 {
+       interrupts-extended = <&intc 86 &omap3_pmx_core 0x12e>;
        vmmc-supply = <&wl12xx_vmmc>;
        non-removable;
        bus-width = <4>;

arch/arm/boot/dts/omap3-evm-common.dtsi +0 -0

                ref-clock-frequency = <38400000>;
        };
 };

arch/arm/boot/dts/omap3-evm-processor-common.dtsi +9 -2

@@ -86,6 +86,10 @@
                        OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat1.sdmmc2_dat1 */
                        OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat2.sdmmc2_dat2 */
                        OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat3.sdmmc2_dat3 */
+                       OMAP3_CORE1_IOPAD(0x2164, PIN_OUTPUT | MUX_MODE1)       /* sdmmc2_dat4.sdmmc2_dir_dat0 */
+                       OMAP3_CORE1_IOPAD(0x2166, PIN_OUTPUT | MUX_MODE1)       /* sdmmc2_dat5.sdmmc2_dir_dat1 */
+                       OMAP3_CORE1_IOPAD(0x2168, PIN_OUTPUT | MUX_MODE1)       /* sdmmc2_dat6.sdmmc2_dir_cmd */
+                       OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT | MUX_MODE1)        /* sdmmc2_dat7.sdmmc2_clkin */
                >;
        };
 

@@ -127,9 +131,13 @@
                >;
        };
 
+       /*
+        * Note that gpio_150 pulled high with internal pull to prevent wlcore
+        * reset on return from off mode in idle.
+        */
        wl12xx_gpio: pinmux_wl12xx_gpio {
                pinctrl-single,pins = <
-                       OMAP3_CORE1_IOPAD(0x2180, PIN_OUTPUT | MUX_MODE4)               /* uart1_cts.gpio_150 */
+                       OMAP3_CORE1_IOPAD(0x2180, PIN_INPUT_PULLUP | MUX_MODE7)         /* uart1_cts.gpio_150 */
                        OMAP3_CORE1_IOPAD(0x217e, PIN_INPUT | MUX_MODE4)                /* uart1_rts.gpio_149 */
                >;
        };
--

2.19.2

I noticed for your patch, I noticed you listed both the IRQ, gpio 149 as well as uart1_rts. Looking at the device tree, I see that uart1_rts is configured as gpio 149.

I did a quick scan of other
boards, I haven't noticed other boards listing the same gpio twice, once under IRQ and once under the pmx_core wakeup. Is that something we should do on other boards, or is that something unique to the omap3-evm?

Quoted 3 lines · Adam Ford

I noticed for your patch, I noticed you listed both the IRQ, gpio 149 as well as uart1_rts. Looking at the device tree, I see that uart1_rts is configured as gpio 149.

The uart1_rts is just the pad name used in the TRM, so it should probably say uart1_rts.gpio_149 meaning pad uart1_rts is muxed to gpio_149.

Would that clear the issue for you?

Quoted 6 lines

I did a quick scan of other
boards, I haven't noticed other boards listing the same gpio twice, once under IRQ and once under the pmx_core wakeup. Is that something we should do on other boards, or is that something unique to the omap3-evm?

No just trying to come up with some some less confusing comments, but obviously that did not work so far :)

Regards,

Tony

Quoted 11 lines · Tony Lindgren

Quoted 3 lines · Adam Ford

I noticed for your patch, I noticed you listed both the IRQ, gpio 149 as well as uart1_rts. Looking at the device tree, I see that uart1_rts is configured as gpio 149.

The uart1_rts is just the pad name used in the TRM, so it should probably say uart1_rts.gpio_149 meaning pad uart1_rts is muxed to gpio_149.

Would that clear the issue for you?

That part I understand. I poorly phrased my question. What was mostly confusing to me is why both irq and wakeup interrupts are needed since it seems like

<&gpio5 21 IRQ_TYPE_EDGE_RISING>,

and
<&omap3_pmx_core 0x14e>;
point to the same pin. Or did I mis-interpret the datasheet again? :-)

Quoted 17 lines · Adam Ford

Quoted 11 lines · Tony Lindgren

Quoted 3 lines · Adam Ford

I noticed for your patch, I noticed you listed both the IRQ, gpio 149 as well as uart1_rts. Looking at the device tree, I see that uart1_rts is configured as gpio 149.

The uart1_rts is just the pad name used in the TRM, so it should probably say uart1_rts.gpio_149 meaning pad uart1_rts is muxed to gpio_149.

Would that clear the issue for you?

That part I understand. I poorly phrased my question. What was mostly confusing to me is why both irq and wakeup interrupts are needed since it seems like

Quoted 5 lines

<&gpio5 21 IRQ_TYPE_EDGE_RISING>,

and
<&omap3_pmx_core 0x14e>;
point to the same pin. Or did I mis-interpret the datasheet again? :-)

Ah OK. Yes the same pin can trigger interrupts at two different controllers. During runtime a proper GPIO is triggered, and then in deeper idle states only the padconf interrupt is triggered as the GPIO can be powered off. So the padconf interrupt is there to provide wake-up events if configured. This allows the device to enter off-mode during idle with things like ping and ssh working with some extra latency :)

The padconf interrupt can also be something other than a GPIO pin, such as UART RX pin, and the padconf device is separate from the GPIO device. So they're treated as two separate interrupt controllers. They can be both active the same time although that is undesired for the extra overhead.

Eventually we should be able to make the GPIO interrupts work in a transparent way with the padconf interrupts.

Regards,

Tony

Thanks for the clarifcation. Is this additional IRQ and wakeup stuff something I should add to the Torpedo and SOM-LV boards? I think right now, I'm just triggering on the GPIO rising edge.