enable mmc3 used for wlan and uart1 used for bluetooth
configure the gpios used for wlan and bluetooth controls
add fixed voltage regulator used for wlan power control
Signed-off-by: Eyal Reizer <[email protected]>
---
arch/arm/boot/dts/am437x-sk-evm.dts | 115 ++++++++++++++++++++++++++++++++++++
1 file changed, 115 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
index 16d9db0..afffdb1 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -15,6 +15,7 @@
#include <dt-bindings/pwm/pwm.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
/ {
model = "TI AM437x SK EVM";
@@ -158,6 +159,22 @@
};
};
};
+
+ vmmcwl_fixed: fixedregulator-mmcwl {
+ /*
+ * WL_EN is not SDIO standard compliant. It is an out of band
+ * signal and hard to be dealt with in a standard way by the
+ * SDIO core driver.
+ * So modelling the WL_EN line as a regulator was a natural
+ * choice as the MMC core already deals with MMC supplies.
+ */
+ compatible = "regulator-fixed";
+ regulator-name = "vmmcwl_fixed";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
&am43xx_pinmux {
@@ -424,6 +441,62 @@
AM4372_IOPAD(0xac4, PIN_OUTPUT | MUX_MODE0) /* usb0_drvvbus.usb0_drvvbus */
>;
};
+
+ mmc3_pins_default: pinmux_mmc3_pins_default {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0x9f0, PIN_INPUT_PULLUP | MUX_MODE3) /* (AD21) cam1_data2.mmc2_clk */
+ AM4372_IOPAD(0x9f4, PIN_INPUT_PULLUP | MUX_MODE3) /* (AE22) cam1_data3.mmc2_cmd */
+ AM4372_IOPAD(0x9f8, PIN_INPUT_PULLUP | MUX_MODE3) /* (AD22) cam1_data4.mmc2_dat0 */
+ AM4372_IOPAD(0x9fc, PIN_INPUT_PULLUP | MUX_MODE3) /* (AE23) cam1_data5.mmc2_dat1 */
+ AM4372_IOPAD(0xa00, PIN_INPUT_PULLUP | MUX_MODE3) /* (AD23) cam1_data6.mmc2_dat2 */
+ AM4372_IOPAD(0xa04, PIN_INPUT_PULLUP | MUX_MODE3) /* (AE24) cam1_data7.mmc2_dat3 */
+ >;
+ };
+
+ mmc3_pins_sleep: pinmux_mmc3_pins_sleep {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0x9f0, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (AD21) cam1_data2.mmc2_clk */
+ AM4372_IOPAD(0x9f4, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (AE22) cam1_data3.mmc2_cmd */
+ AM4372_IOPAD(0x9f8, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (AD22) cam1_data4.mmc2_dat0 */
+ AM4372_IOPAD(0x9fc, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (AE23) cam1_data5.mmc2_dat1 */
+ AM4372_IOPAD(0xa00, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (AD23) cam1_data6.mmc2_dat2 */
+ AM4372_IOPAD(0xa04, PIN_INPUT_PULLDOWN | MUX_MODE7) /* (AE24) cam1_data7.mmc2_dat3 */
+ >;
+ };
+
+ wlan_pins_default: pinmux_wlan_pins_default {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0x9d0, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* cam1_data8.gpio4_8 WL_EN */
+ AM4372_IOPAD(0x9e4, PIN_INPUT | WAKEUP_ENABLE | MUX_MODE7) /* cam1_wen.gpio4_13 WL_IRQ */
+ >;
+ };
+
+ wlan_pins_sleep: pinmux_wlan_pins_sleep {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0x9d0, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* cam1_data8.gpio4_8 WL_EN */
+ AM4372_IOPAD(0x9e4, PIN_INPUT | WAKEUP_ENABLE | MUX_MODE7) /* cam1_wen.gpio4_13 WL_IRQ */
+ >;
+ };
+
+ uart1_bt_pins_default: pinmux_uart1_bt_pins_default {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0x980, PIN_INPUT | MUX_MODE0) /* uart1_rxd.uart1_rxd */
+ AM4372_IOPAD(0x984, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart1_txd.uart1_txd */
+ AM4372_IOPAD(0x978, PIN_INPUT_PULLUP | MUX_MODE0) /* uart1_ctsn.uart1_ctsn */
+ AM4372_IOPAD(0x97c, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* uart1_rtsn.uart1_rtsn */
+ AM4372_IOPAD(0x9cc, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* cam1_data9.gpio4_7 BT_EN */
+ >;
+ };
+
+ uart1_bt_pins_sleep: pinmux_uart1_bt_pins_sleep {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0x980, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* uart1_rxd.uart1_rxd */
+ AM4372_IOPAD(0x984, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* uart1_txd.uart1_txd */
+ AM4372_IOPAD(0x978, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* uart1_ctsn.uart1_ctsn */
+ AM4372_IOPAD(0x97c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* uart1_rtsn.uart1_rtsn */
+ AM4372_IOPAD(0x9cc, PIN_OUTPUT_PULLUP | MUX_MODE7) /* cam1_data9.gpio4_7 BT_EN */
+ >;
+ };
};
&i2c0 {
@@ -606,6 +679,10 @@
status = "okay";
};
+&gpio4 {
+ status = "okay";
+};
+
&gpio5 {
status = "okay";
};
@@ -620,6 +697,44 @@
cd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
};
+&uart1 {
+ status = "okay";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&uart1_bt_pins_default>;
+ pinctrl-1 = <&uart1_bt_pins_sleep>;
+};
+
+&mmc3 {
+ status = "okay";
+ /*
+ * these are on the crossbar and are outlined in the
+ * xbar-event-map element
+ */
+ dmas = <&edma_xbar 30 0 1>,
+ <&edma_xbar 31 0 2>;
+ dma-names = "tx", "rx";
+ vmmc-supply = <&vmmcwl_fixed>;
+ bus-width = <4>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&mmc3_pins_default>;
+ pinctrl-1 = <&mmc3_pins_sleep>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+ ti,non-removable;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ wlcore: wlcore@0 {
+ compatible = "ti,wl1835";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&wlan_pins_default>;
+ pinctrl-1 = <&wlan_pins_sleep>;
+ reg = <2>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
+ };
+};
+
&usb2_phy1 {
status = "okay";
};
--
2.7.4
On Tuesday 01 May 2018 12:54 PM, Eyal Reizer wrote:
> enable mmc3 used for wlan and uart1 used for bluetooth
> configure the gpios used for wlan and bluetooth controls
> add fixed voltage regulator used for wlan power control
>
> Signed-off-by: Eyal Reizer <[email protected]>
ARM should be capitalized in subject line.
> +
> +&mmc3 {
> + status = "okay";
> + /*
> + * these are on the crossbar and are outlined in the
> + * xbar-event-map element
> + */
> + dmas = <&edma_xbar 30 0 1>,
> + <&edma_xbar 31 0 2>;
> + dma-names = "tx", "rx";
> + vmmc-supply = <&vmmcwl_fixed>;
> + bus-width = <4>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&mmc3_pins_default>;
> + pinctrl-1 = <&mmc3_pins_sleep>;
> + cap-power-off-card;
> + keep-power-in-suspend;
> + ti,non-removable;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + wlcore: wlcore@0 {
wlcore@2
> + compatible = "ti,wl1835";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&wlan_pins_default>;
> + pinctrl-1 = <&wlan_pins_sleep>;
> + reg = <2>;
> + interrupt-parent = <&gpio4>;
> + interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +};
Thanks,
Sekhar
>
> ARM should be capitalized in subject line.
OK, will be fixed in v2
>
> > +
> > +&mmc3 {
> > + status = "okay";
> > + /*
> > + * these are on the crossbar and are outlined in the
> > + * xbar-event-map element
> > + */
> > + dmas = <&edma_xbar 30 0 1>,
> > + <&edma_xbar 31 0 2>;
> > + dma-names = "tx", "rx";
> > + vmmc-supply = <&vmmcwl_fixed>;
> > + bus-width = <4>;
> > + pinctrl-names = "default", "sleep";
> > + pinctrl-0 = <&mmc3_pins_default>;
> > + pinctrl-1 = <&mmc3_pins_sleep>;
> > + cap-power-off-card;
> > + keep-power-in-suspend;
> > + ti,non-removable;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + wlcore: wlcore@0 {
>
> wlcore@2
>
Will be fixed in v2
> > + compatible = "ti,wl1835";
> > + pinctrl-names = "default", "sleep";
> > + pinctrl-0 = <&wlan_pins_default>;
> > + pinctrl-1 = <&wlan_pins_sleep>;
> > + reg = <2>;
> > + interrupt-parent = <&gpio4>;
> > + interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
> > + };
> > +};
>
Best Regards,
Eyal
* Eyal Reizer <[email protected]> [180501 00:26]:
> enable mmc3 used for wlan and uart1 used for bluetooth
> configure the gpios used for wlan and bluetooth controls
> add fixed voltage regulator used for wlan power control
...
> / {
> model = "TI AM437x SK EVM";
> @@ -158,6 +159,22 @@
> };
> };
> };
> +
> + vmmcwl_fixed: fixedregulator-mmcwl {
> + /*
> + * WL_EN is not SDIO standard compliant. It is an out of band
> + * signal and hard to be dealt with in a standard way by the
> + * SDIO core driver.
> + * So modelling the WL_EN line as a regulator was a natural
> + * choice as the MMC core already deals with MMC supplies.
> + */
> + compatible = "regulator-fixed";
> + regulator-name = "vmmcwl_fixed";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> };
Interesting that it needs much longer delay here compared to the
earlier?
BTW, I do have a patch in work to add pwrseq support for wlcore that
allows leaving out the regulator here. It still needs a bit more
work though.
And I also have a series in work to make wlcore use runtime PM that
needs even more work, just FYI to avoid any duplicate work.
Hmm you don't happen to have a patch series somewhere making
wlcore use the SDIO dat lien interrupt?
I think we should use that when idle rather than the (edge) gpio
interrupt as the SDIO dat interrupt is level sensitive and wired
to the always on gpio bank for most SDIO controller instances.
On runtime PM wakeup, there's no status anywhere to been with the
GPIO edge interrupt.
Regards,
Tony
>
> * Eyal Reizer <[email protected]> [180501 00:26]:
> > enable mmc3 used for wlan and uart1 used for bluetooth
> > configure the gpios used for wlan and bluetooth controls
> > add fixed voltage regulator used for wlan power control
> ...
> > / {
> > model = "TI AM437x SK EVM";
> > @@ -158,6 +159,22 @@
> > };
> > };
> > };
> > +
> > + vmmcwl_fixed: fixedregulator-mmcwl {
> > + /*
> > + * WL_EN is not SDIO standard compliant. It is an out of band
> > + * signal and hard to be dealt with in a standard way by the
> > + * SDIO core driver.
> > + * So modelling the WL_EN line as a regulator was a natural
> > + * choice as the MMC core already deals with MMC supplies.
> > + */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vmmcwl_fixed";
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > };
>
> Interesting that it needs much longer delay here compared to the
> earlier?
Where do you see a delay in here?
There is no startup-delay-us value used in this patch.
>
> BTW, I do have a patch in work to add pwrseq support for wlcore that
> allows leaving out the regulator here. It still needs a bit more
> work though.
>
> And I also have a series in work to make wlcore use runtime PM that
> needs even more work, just FYI to avoid any duplicate work.
>
> Hmm you don't happen to have a patch series somewhere making
> wlcore use the SDIO dat lien interrupt?
wilink has always used out of band interrupt (using wlan_irq gpio).
in-band interrupts was not supported.
See section 10.5.2 in this the wl18xx hardware integration guide:
http://www.ti.com/lit/ug/swru437/swru437.pdf
>
> I think we should use that when idle rather than the (edge) gpio
> interrupt as the SDIO dat interrupt is level sensitive and wired
> to the always on gpio bank for most SDIO controller instances.
> On runtime PM wakeup, there's no status anywhere to been with the
> GPIO edge interrupt.
>
I agree that it would have been better, especially for cases such as wake
On wlan, but again, in-band interrupt was something that was talked
about way back but it was never implemented.
Best Regards,
Eyal
* Reizer, Eyal <[email protected]> [180503 06:43]:
> >
> > * Eyal Reizer <[email protected]> [180501 00:26]:
> > > enable mmc3 used for wlan and uart1 used for bluetooth
> > > configure the gpios used for wlan and bluetooth controls
> > > add fixed voltage regulator used for wlan power control
> > ...
> > > / {
> > > model = "TI AM437x SK EVM";
> > > @@ -158,6 +159,22 @@
> > > };
> > > };
> > > };
> > > +
> > > + vmmcwl_fixed: fixedregulator-mmcwl {
> > > + /*
> > > + * WL_EN is not SDIO standard compliant. It is an out of band
> > > + * signal and hard to be dealt with in a standard way by the
> > > + * SDIO core driver.
> > > + * So modelling the WL_EN line as a regulator was a natural
> > > + * choice as the MMC core already deals with MMC supplies.
> > > + */
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "vmmcwl_fixed";
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <1800000>;
> > > + gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>;
> > > + enable-active-high;
> > > + };
> > > };
> >
> > Interesting that it needs much longer delay here compared to the
> > earlier?
>
> Where do you see a delay in here?
> There is no startup-delay-us value used in this patch.
Oops sorry, I misread the voltage above as the startup-delay-us
value :)
> > BTW, I do have a patch in work to add pwrseq support for wlcore that
> > allows leaving out the regulator here. It still needs a bit more
> > work though.
> >
> > And I also have a series in work to make wlcore use runtime PM that
> > needs even more work, just FYI to avoid any duplicate work.
> >
> > Hmm you don't happen to have a patch series somewhere making
> > wlcore use the SDIO dat lien interrupt?
> wilink has always used out of band interrupt (using wlan_irq gpio).
> in-band interrupts was not supported.
> See section 10.5.2 in this the wl18xx hardware integration guide:
> http://www.ti.com/lit/ug/swru437/swru437.pdf
Hmm yeah I've been wondering about that. Why not follow the SDIO
standard here though? Do you have links to documentation explaining
that?
> > I think we should use that when idle rather than the (edge) gpio
> > interrupt as the SDIO dat interrupt is level sensitive and wired
> > to the always on gpio bank for most SDIO controller instances.
> > On runtime PM wakeup, there's no status anywhere to been with the
> > GPIO edge interrupt.
> >
> I agree that it would have been better, especially for cases such as wake
> On wlan, but again, in-band interrupt was something that was talked
> about way back but it was never implemented.
I think we can have both if performance is the reason for the
out of band interrupt. We could still use SDIO dat line interrupt
during idle for wake-up events.
Regards,
Tony
>
> * Reizer, Eyal <[email protected]> [180503 06:43]:
> > >
> > > * Eyal Reizer <[email protected]> [180501 00:26]:
> > > > enable mmc3 used for wlan and uart1 used for bluetooth
> > > > configure the gpios used for wlan and bluetooth controls
> > > > add fixed voltage regulator used for wlan power control
> > > ...
> > > > / {
> > > > model = "TI AM437x SK EVM";
> > > > @@ -158,6 +159,22 @@
> > > > };
> > > > };
> > > > };
> > > > +
> > > > + vmmcwl_fixed: fixedregulator-mmcwl {
> > > > + /*
> > > > + * WL_EN is not SDIO standard compliant. It is an out of band
> > > > + * signal and hard to be dealt with in a standard way by the
> > > > + * SDIO core driver.
> > > > + * So modelling the WL_EN line as a regulator was a natural
> > > > + * choice as the MMC core already deals with MMC supplies.
> > > > + */
> > > > + compatible = "regulator-fixed";
> > > > + regulator-name = "vmmcwl_fixed";
> > > > + regulator-min-microvolt = <1800000>;
> > > > + regulator-max-microvolt = <1800000>;
> > > > + gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>;
> > > > + enable-active-high;
> > > > + };
> > > > };
> > >
> > > Interesting that it needs much longer delay here compared to the
> > > earlier?
> >
> > Where do you see a delay in here?
> > There is no startup-delay-us value used in this patch.
>
> Oops sorry, I misread the voltage above as the startup-delay-us
> value :)
>
No issue :)
> > > BTW, I do have a patch in work to add pwrseq support for wlcore that
> > > allows leaving out the regulator here. It still needs a bit more
> > > work though.
> > >
> > > And I also have a series in work to make wlcore use runtime PM that
> > > needs even more work, just FYI to avoid any duplicate work.
> > >
> > > Hmm you don't happen to have a patch series somewhere making
> > > wlcore use the SDIO dat lien interrupt?
> > wilink has always used out of band interrupt (using wlan_irq gpio).
> > in-band interrupts was not supported.
> > See section 10.5.2 in this the wl18xx hardware integration guide:
> > http://www.ti.com/lit/ug/swru437/swru437.pdf
>
> Hmm yeah I've been wondering about that. Why not follow the SDIO
> standard here though? Do you have links to documentation explaining
> that?
>
I will try to see what I can find out and why it has always been used only
With out-of band interrupts and whether there is a real hardware
Limitation behind it .
In the past also the omap-hsmmc driver was not really supporting in-band
sdio interrupt out of the box.
Not sure what is the state of it tofday.
> > > I think we should use that when idle rather than the (edge) gpio
> > > interrupt as the SDIO dat interrupt is level sensitive and wired
> > > to the always on gpio bank for most SDIO controller instances.
> > > On runtime PM wakeup, there's no status anywhere to been with the
> > > GPIO edge interrupt.
> > >
> > I agree that it would have been better, especially for cases such as wake
> > On wlan, but again, in-band interrupt was something that was talked
> > about way back but it was never implemented.
>
> I think we can have both if performance is the reason for the
> out of band interrupt. We could still use SDIO dat line interrupt
> during idle for wake-up events.
Correct, assuming we can make in-band interrupt work with wilink8.
Best Regards,
Eyal
* Reizer, Eyal <[email protected]> [180506 07:47]:
> I will try to see what I can find out and why it has always been used only
> With out-of band interrupts and whether there is a real hardware
> Limitation behind it .
> In the past also the omap-hsmmc driver was not really supporting in-band
> sdio interrupt out of the box.
> Not sure what is the state of it tofday.
Yeah my guess is that the reason for the separate GPIO interrupt was
that on omap3 we did not have SDIO interrupt working for years. This was
because of the issues related to padconf interrupts for off mode.
We now have Linux generic wakeirq support working with SDIO and it has
been confirmed to work also for off mode with mwifiex at least. So
there should be no reason to not also use the SDIO interrupt.
Regards,
Tony
Hi Tony,
>
> Yeah my guess is that the reason for the separate GPIO interrupt was
> that on omap3 we did not have SDIO interrupt working for years. This was
> because of the issues related to padconf interrupts for off mode.
>
> We now have Linux generic wakeirq support working with SDIO and it has
> been confirmed to work also for off mode with mwifiex at least. So
> there should be no reason to not also use the SDIO interrupt.
>
There is more to this than just the padconf.
Using in-band interrupt instead of the out of band one requires
Supporting a feature called "Asynchronous interrupts in 4Bit mode"
Which is part of SDIO 3.0 spec:
https://www.sdcard.org/downloads/pls/pdf/index.php?p=PartE1_SDIO_Simplified_Specification_Ver3.00.jpg&f=PartE1_SDIO_Simplified_Specification_Ver3.00.pdf&e=EN_SSE1
Take a look at page 41 at the bottom part of the table.
Wilink8 supports this feature but AFAIK this support is still not part of the
mmc/sdio core in the Linux kernel.
If we want wilink8 to trigger a host wakeup using the in-band interrupt instead
Of the wlan_irq pin we would need to enable/use this feature.
I did use it internally in the past and was able to patch the Ubuntu kernel
(3.5.0 at that time) to use wilink8 in a standard SD Card slot of an Ubuntu Laptop
while removing the use of wlan_irq pin completely.
However this was an experimental patch set written by a third party
that was not up-steamtable at that time.
I do have this patch set somewhere...
It is similar to the following patch which is not upstream as well for some reason:
https://gitlab.com/k2wl/g2_kernel/commit/5c4970fdaa50422d7ea7220efa20fb35148a4bca
It is not the only patch needed, there are a couple of additional patches needed
for fully using it from driver.
I did check latest Linux-next and don't see this support there. Not sure why.
Best Regards,
Eyal
* Reizer, Eyal <[email protected]> [180507 06:57]:
> Hi Tony,
>
> >
> > Yeah my guess is that the reason for the separate GPIO interrupt was
> > that on omap3 we did not have SDIO interrupt working for years. This was
> > because of the issues related to padconf interrupts for off mode.
> >
> > We now have Linux generic wakeirq support working with SDIO and it has
> > been confirmed to work also for off mode with mwifiex at least. So
> > there should be no reason to not also use the SDIO interrupt.
> >
>
> There is more to this than just the padconf.
> Using in-band interrupt instead of the out of band one requires
> Supporting a feature called "Asynchronous interrupts in 4Bit mode"
> Which is part of SDIO 3.0 spec:
> https://www.sdcard.org/downloads/pls/pdf/index.php?p=PartE1_SDIO_Simplified_Specification_Ver3.00.jpg&f=PartE1_SDIO_Simplified_Specification_Ver3.00.pdf&e=EN_SSE1
>
> Take a look at page 41 at the bottom part of the table.
> Wilink8 supports this feature but AFAIK this support is still not part of the
> mmc/sdio core in the Linux kernel.
> If we want wilink8 to trigger a host wakeup using the in-band interrupt instead
> Of the wlan_irq pin we would need to enable/use this feature.
Well the SDIO dat line interrupt is working just fine with
mwifiex_sdio driver and runtime PM like I said :)
> I did use it internally in the past and was able to patch the Ubuntu kernel
> (3.5.0 at that time) to use wilink8 in a standard SD Card slot of an Ubuntu Laptop
> while removing the use of wlan_irq pin completely.
> However this was an experimental patch set written by a third party
> that was not up-steamtable at that time.
> I do have this patch set somewhere...
>
> It is similar to the following patch which is not upstream as well for some reason:
> https://gitlab.com/k2wl/g2_kernel/commit/5c4970fdaa50422d7ea7220efa20fb35148a4bca
> It is not the only patch needed, there are a couple of additional patches needed
> for fully using it from driver.
> I did check latest Linux-next and don't see this support there. Not sure why.
Hmm not sure if this is needed here. When things enter idle, the whole
SDIO block is off and the SDIO dat interrupt is delivered as wakeirq to
the pinctrl-single driver instead that manages padconf wake events.
Then we have runtime PM wake up MMC subsystem and the SDIO dat line
interrupt is still there and will trigger as it's level sensitive.
So the test to do would be simply configure wlcore to use SDIO dat line
interrupt instead of the GPIO interrupt and configure a wakeirq for
the board on the SDIO dat line. Sounds like I need to get my wlcore
runtime PM patches ready though as that is needed for using the wakeirq.
Regards,
Tony
