| Message ID | 20181213230411.5009-1-tony@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/3] ARM: dts: Add wlcore wakeirq for omap3-evm | expand |
On Thu, Dec 13, 2018 at 5:05 PM Tony Lindgren <tony@atomide.com> wrote: > > 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 <tony@atomide.com> > --- > 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(-) > > diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi b/arch/arm/boot/dts/omap3-evm-common.dtsi > --- a/arch/arm/boot/dts/omap3-evm-common.dtsi > +++ b/arch/arm/boot/dts/omap3-evm-common.dtsi > @@ -122,6 +122,7 @@ > }; > > &mmc2 { > + interrupts-extended = <&intc 86 &omap3_pmx_core 0x12e>; > vmmc-supply = <&wl12xx_vmmc>; > non-removable; > bus-width = <4>; > @@ -132,8 +133,10 @@ > wlcore: wlcore@2 { > compatible = "ti,wl1271"; > reg = <2>; > - interrupt-parent = <&gpio5>; > - interrupts = <21 IRQ_TYPE_EDGE_RISING>; /* gpio 149 */ > + /* gpio_149 with uart1_rts pad as wakeirq */ > + interrupts-extended = <&gpio5 21 IRQ_TYPE_EDGE_RISING>, > + <&omap3_pmx_core 0x14e>; > + interrupt-names = "irq", "wakeup"; Tony, Question... 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? adam > ref-clock-frequency = <38400000>; > }; > }; > diff --git a/arch/arm/boot/dts/omap3-evm-processor-common.dtsi b/arch/arm/boot/dts/omap3-evm-processor-common.dtsi > --- a/arch/arm/boot/dts/omap3-evm-processor-common.dtsi > +++ b/arch/arm/boot/dts/omap3-evm-processor-common.dtsi > @@ -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
* Adam Ford <aford173@gmail.com> [181222 20:54]: > 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? > 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
On Sun, Dec 23, 2018 at 10:30 AM Tony Lindgren <tony@atomide.com> wrote: > > * Adam Ford <aford173@gmail.com> [181222 20:54]: > > 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? :-) adam > > > 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
* Adam Ford <aford173@gmail.com> [181227 14:33]: > On Sun, Dec 23, 2018 at 10:30 AM Tony Lindgren <tony@atomide.com> wrote: > > > > * Adam Ford <aford173@gmail.com> [181222 20:54]: > > > 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? :-) 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
On Thu, Dec 27, 2018 at 10:58 AM Tony Lindgren <tony@atomide.com> wrote: > > * Adam Ford <aford173@gmail.com> [181227 14:33]: > > On Sun, Dec 23, 2018 at 10:30 AM Tony Lindgren <tony@atomide.com> wrote: > > > > > > * Adam Ford <aford173@gmail.com> [181222 20:54]: > > > > 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? :-) > > 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. 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. adam > > Regards, > > Tony
* Adam Ford <aford173@gmail.com> [181227 17:05]: > 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. Yes as those boards work with off-mode during idle. Unless you configure the wlcore wakeirq, pinging a device will not wake up the SoC. And ssh latency will be bad. Regards, Tony
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi b/arch/arm/boot/dts/omap3-evm-common.dtsi --- a/arch/arm/boot/dts/omap3-evm-common.dtsi +++ b/arch/arm/boot/dts/omap3-evm-common.dtsi @@ -122,6 +122,7 @@ }; &mmc2 { + interrupts-extended = <&intc 86 &omap3_pmx_core 0x12e>; vmmc-supply = <&wl12xx_vmmc>; non-removable; bus-width = <4>; @@ -132,8 +133,10 @@ wlcore: wlcore@2 { compatible = "ti,wl1271"; reg = <2>; - interrupt-parent = <&gpio5>; - interrupts = <21 IRQ_TYPE_EDGE_RISING>; /* gpio 149 */ + /* gpio_149 with uart1_rts pad as wakeirq */ + interrupts-extended = <&gpio5 21 IRQ_TYPE_EDGE_RISING>, + <&omap3_pmx_core 0x14e>; + interrupt-names = "irq", "wakeup"; ref-clock-frequency = <38400000>; }; }; diff --git a/arch/arm/boot/dts/omap3-evm-processor-common.dtsi b/arch/arm/boot/dts/omap3-evm-processor-common.dtsi --- a/arch/arm/boot/dts/omap3-evm-processor-common.dtsi +++ b/arch/arm/boot/dts/omap3-evm-processor-common.dtsi @@ -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 */ >; };
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 <tony@atomide.com> --- 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(-)