omap_hsmmc: sdio: issue with generic wakeup IRQ handling

DISCUSSION Vishal Thanki 3 participants 8 messages Feb 18, 2016 – Feb 25, 2016

Subsystems (2)

MMC, SD and SDIO Networking drivers (wireless)

lore

Share & tools

lore

Vishal Thanki

author

2016-02-18 18:27 UTC #0 lore raw

Hi,

On a custom built am335x based board, I am facing an issue mwifiex wifi module which is connected to host via SDIO interface. I am using kernel version 4.4.

The problem is related to the wifi "ext_scan" command getting timed out over SDIO. This was working with old kernel (v4.0), but does not work on kernel v4.4. I found the following commit is responsible for this behavior.

=================================
5b83b2234be6733cfe22036c38031b2c890b3db8

mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq

We can now use generic wakeirq handling and remove the custom handling for the wake-up interrupts.
=================================

There is no wifi issue if I revert the above mentioned commit on kernel v4.4.

I see that before this commit, the wakeup IRQ handler was registered within the omap_hsmmc.c itself with additional IRQF_TRIGGER_LOW flag. But with the introduction to dev_pm_set_dedicated_wake_irq(), the generic wakeup IRQ handler is registered which does not take the IRQF_TRIGGER flag. I am not sure if that is the issue, but I added that IRQF_TRIGGER_LOW flag in dev_pm_set_dedicated_wake_irq() while registering a threaded IRQ handler, I could see the problem disappears. However, this change is causing the infinite interrupts because the of level triggered interrupt is not handled in generic wakeup IRQ handling code (as it was done specially in omap_hsmmc.c code earlier).

I am not much familiar with MMC/SDIO driver and I am not sure how to fix this behavior. So any guidance would be really helpful.

Thanks,
Vishal

Andreas Fenkart

2016-02-18 21:31 UTC #1 lore raw

Hi Vishal,

I remember there was a problem with IRQ, but can't remember on top of my head. Meanwhile this might be some pointer:

(quoted diff) +0 -0

b/drivers/net/wireless/mwifiex/sta_ioctl.c
index a6c8a4f..67587c2 100644

drivers/net/wireless/mwifiex/sta_ioctl.c +11 -0

@@ -517,6 +517,17 @@ int mwifiex_enable_hs(struct mwifiex_adapter *adapter)
        adapter->hs_enabling = true;
        mwifiex_cancel_all_pending_cmd(adapter);
 
+       /* if the MMC host is already in suspend it will not detect SDIO irq
+        * and we might run into response timeout. By claiming the MMC host we
+        * wake it up, which is sufficient to detect a pending IRQ
+        */
+       {
+               struct sdio_mmc_card *card = adapter->card;
+               sdio_claim_host(card->func);
+               printk("+++ poll mmc host for IRQ +++\n");
+               sdio_release_host(card->func);
+       }
+
        if (mwifiex_set_hs_params(mwifiex_get_priv(adapter,
                                                   MWIFIEX_BSS_ROLE_STA),
                                  HostCmd_ACT_GEN_SET, MWIFIEX_SYNC_CMD,

2016-02-18 19:27 GMT+01:00 Vishal Thanki <[email protected]>:

Quoted 39 lines

Hi,
On a custom built am335x based board, I am facing an issue mwifiex wifi module which is connected to host via SDIO interface. I am using kernel version 4.4.
The problem is related to the wifi "ext_scan" command getting timed out over SDIO. This was working with old kernel (v4.0), but does not work on kernel v4.4. I found the following commit is responsible for this behavior.
=================================
5b83b2234be6733cfe22036c38031b2c890b3db8
mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq
We can now use generic wakeirq handling and remove the custom handling for the wake-up interrupts.
=================================
There is no wifi issue if I revert the above mentioned commit on kernel v4.4.
I see that before this commit, the wakeup IRQ handler was registered within the omap_hsmmc.c itself with additional IRQF_TRIGGER_LOW flag. But with the introduction to dev_pm_set_dedicated_wake_irq(), the generic wakeup IRQ handler is registered which does not take the IRQF_TRIGGER flag. I am not sure if that is the issue, but I added that IRQF_TRIGGER_LOW flag in dev_pm_set_dedicated_wake_irq() while registering a threaded IRQ handler, I could see the problem disappears. However, this change is causing the infinite interrupts because the of level triggered interrupt is not handled in generic wakeup IRQ handling code (as it was done specially in omap_hsmmc.c code earlier).
I am not much familiar with MMC/SDIO driver and I am not sure how to fix this behavior. So any guidance would be really helpful.
Thanks,
Vishal

Vishal Thanki

author

2016-02-19 14:11 UTC #2 lore raw

Hi Andreas,

Quoted 18 lines · Andreas Fenkart

Hi Vishal,

I remember there was a problem with IRQ, but can't remember on top of my head. Meanwhile this might be some pointer:

drivers/net/wireless/mwifiex/sta_ioctl.c +4 -0

index a6c8a4f..67587c2 100644
@@ -517,6 +517,17 @@ int mwifiex_enable_hs(struct mwifiex_adapter *adapter)
        adapter->hs_enabling = true;
        mwifiex_cancel_all_pending_cmd(adapter);
 
+       /* if the MMC host is already in suspend it will not detect SDIO irq
+        * and we might run into response timeout. By claiming the MMC host we
+        * wake it up, which is sufficient to detect a pending IRQ
+        */

drivers/net/wireless/mwifiex/sta_ioctl.c int mwifiex_enable_hs(struct mwifiex_adapter *adapter) · line 533

Quoted 10 lines

drivers/net/wireless/mwifiex/sta_ioctl.c +7 -0

+       {
+               struct sdio_mmc_card *card = adapter->card;
+               sdio_claim_host(card->func);
+               printk("+++ poll mmc host for IRQ +++\n");
+               sdio_release_host(card->func);
+       }
+
        if (mwifiex_set_hs_params(mwifiex_get_priv(adapter,
                                                   MWIFIEX_BSS_ROLE_STA),
                                  HostCmd_ACT_GEN_SET, MWIFIEX_SYNC_CMD,

I tried this code change but that did not help. I saw that the code change is in a function called mwifiex_enable_hs(), which only gets invoked by mwifiex_sdio_suspend(); which is why I think it is not having any effect. Because when I run the command to scan the channel list (i.e. iw dev wlan0 scan), the system is not in suspend state. And I noticed (by adding prints in omap_hsmmc.c for suspend and resume callbacks) that during the "scan" command, the suspend routine gets invoked for HSMMC but it never gets resumed (may be due to the missed wakeup IRQ) from mwifiex and the command times out.

Thanks for your help.

Vishal

Quoted 41 lines

2016-02-18 19:27 GMT+01:00 Vishal Thanki <[email protected]>:
Quoted 39 lines
Hi,
On a custom built am335x based board, I am facing an issue mwifiex wifi module which is connected to host via SDIO interface. I am using kernel version 4.4.
The problem is related to the wifi "ext_scan" command getting timed out over SDIO. This was working with old kernel (v4.0), but does not work on kernel v4.4. I found the following commit is responsible for this behavior.
=================================
5b83b2234be6733cfe22036c38031b2c890b3db8
mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq
We can now use generic wakeirq handling and remove the custom handling for the wake-up interrupts.
=================================
There is no wifi issue if I revert the above mentioned commit on kernel v4.4.
I see that before this commit, the wakeup IRQ handler was registered within the omap_hsmmc.c itself with additional IRQF_TRIGGER_LOW flag. But with the introduction to dev_pm_set_dedicated_wake_irq(), the generic wakeup IRQ handler is registered which does not take the IRQF_TRIGGER flag. I am not sure if that is the issue, but I added that IRQF_TRIGGER_LOW flag in dev_pm_set_dedicated_wake_irq() while registering a threaded IRQ handler, I could see the problem disappears. However, this change is causing the infinite interrupts because the of level triggered interrupt is not handled in generic wakeup IRQ handling code (as it was done specially in omap_hsmmc.c code earlier).
I am not much familiar with MMC/SDIO driver and I am not sure how to fix this behavior. So any guidance would be really helpful.
Thanks,
Vishal

Vishal Thanki

author

2016-02-24 21:32 UTC #3 lore raw

Hi,

Quoted 33 lines · Vishal Thanki

Hi Andreas,

Quoted 18 lines · Andreas Fenkart

Hi Vishal,

I remember there was a problem with IRQ, but can't remember on top of my head. Meanwhile this might be some pointer:

drivers/net/wireless/mwifiex/sta_ioctl.c +4 -0

index a6c8a4f..67587c2 100644
@@ -517,6 +517,17 @@ int mwifiex_enable_hs(struct mwifiex_adapter *adapter)
        adapter->hs_enabling = true;
        mwifiex_cancel_all_pending_cmd(adapter);
 
+       /* if the MMC host is already in suspend it will not detect SDIO irq
+        * and we might run into response timeout. By claiming the MMC host we
+        * wake it up, which is sufficient to detect a pending IRQ
+        */

drivers/net/wireless/mwifiex/sta_ioctl.c int mwifiex_enable_hs(struct mwifiex_adapter *adapter) · line 533

Quoted 10 lines

drivers/net/wireless/mwifiex/sta_ioctl.c +7 -0

+       {
+               struct sdio_mmc_card *card = adapter->card;
+               sdio_claim_host(card->func);
+               printk("+++ poll mmc host for IRQ +++\n");
+               sdio_release_host(card->func);
+       }
+
        if (mwifiex_set_hs_params(mwifiex_get_priv(adapter,
                                                   MWIFIEX_BSS_ROLE_STA),
                                  HostCmd_ACT_GEN_SET, MWIFIEX_SYNC_CMD,

I tried this code change but that did not help. I saw that the code

Quoted 9 lines

change is in a function called mwifiex_enable_hs(), which only gets invoked by mwifiex_sdio_suspend(); which is why I think it is not having any effect. Because when I run the command to scan the channel list (i.e. iw dev wlan0 scan), the system is not in suspend state. And I noticed (by adding prints in omap_hsmmc.c for suspend and resume callbacks) that during the "scan" command, the suspend routine gets invoked for HSMMC but it never gets resumed (may be due to the missed wakeup IRQ) from mwifiex and the command times out.

Is there any other suggestion for mwifiex that I should try out? Or is there any way in omap_hsmmc to specify the wakeup interrupt type (IRQF_TRIGGER_LOW) while using generic wakeup IRQ mechanism. I could not find it, but I may be missing something.

Thanks,
Vishal

Quoted 46 lines

Thanks for your help.
Vishal
Quoted 41 lines
2016-02-18 19:27 GMT+01:00 Vishal Thanki <[email protected]>:
Quoted 39 lines
Hi,
On a custom built am335x based board, I am facing an issue mwifiex wifi module which is connected to host via SDIO interface. I am using kernel version 4.4.
The problem is related to the wifi "ext_scan" command getting timed out over SDIO. This was working with old kernel (v4.0), but does not work on kernel v4.4. I found the following commit is responsible for this behavior.
=================================
5b83b2234be6733cfe22036c38031b2c890b3db8
mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq
We can now use generic wakeirq handling and remove the custom handling for the wake-up interrupts.
=================================
There is no wifi issue if I revert the above mentioned commit on kernel v4.4.
I see that before this commit, the wakeup IRQ handler was registered within the omap_hsmmc.c itself with additional IRQF_TRIGGER_LOW flag. But with the introduction to dev_pm_set_dedicated_wake_irq(), the generic wakeup IRQ handler is registered which does not take the IRQF_TRIGGER flag. I am not sure if that is the issue, but I added that IRQF_TRIGGER_LOW flag in dev_pm_set_dedicated_wake_irq() while registering a threaded IRQ handler, I could see the problem disappears. However, this change is causing the infinite interrupts because the of level triggered interrupt is not handled in generic wakeup IRQ handling code (as it was done specially in omap_hsmmc.c code earlier).
I am not much familiar with MMC/SDIO driver and I am not sure how to fix this behavior. So any guidance would be really helpful.
Thanks,
Vishal

Grygorii Strashko

2016-02-25 10:46 UTC #4 lore raw

Quoted 44 lines · Vishal Thanki

Hi,
Quoted 41 lines · Vishal Thanki
Hi Andreas,
Quoted 18 lines · Andreas Fenkart
Hi Vishal,
I remember there was a problem with IRQ, but can't remember on top of my head. Meanwhile this might be some pointer:
drivers/net/wireless/mwifiex/sta_ioctl.c +4 -0
index a6c8a4f..67587c2 100644
@@ -517,6 +517,17 @@ int mwifiex_enable_hs(struct mwifiex_adapter *adapter)
         adapter->hs_enabling = true;
         mwifiex_cancel_all_pending_cmd(adapter);
 
+       /* if the MMC host is already in suspend it will not detect SDIO irq
+        * and we might run into response timeout. By claiming the MMC host we
+        * wake it up, which is sufficient to detect a pending IRQ
+        */
drivers/net/wireless/mwifiex/sta_ioctl.c int mwifiex_enable_hs(struct mwifiex_adapter *adapter) · line 533
Quoted 10 lines
drivers/net/wireless/mwifiex/sta_ioctl.c +7 -0
+       {
+               struct sdio_mmc_card *card = adapter->card;
+               sdio_claim_host(card->func);
+               printk("+++ poll mmc host for IRQ +++\n");
+               sdio_release_host(card->func);
+       }
+
         if (mwifiex_set_hs_params(mwifiex_get_priv(adapter,
                                                    MWIFIEX_BSS_ROLE_STA),
                                   HostCmd_ACT_GEN_SET, MWIFIEX_SYNC_CMD,
I tried this code change but that did not help. I saw that the code change is in a function called mwifiex_enable_hs(), which only gets invoked by mwifiex_sdio_suspend(); which is why I think it is not having any effect. Because when I run the command to scan the channel list (i.e. iw dev wlan0 scan), the system is not in suspend state. And I noticed (by adding prints in omap_hsmmc.c for suspend and resume callbacks) that during the "scan" command, the suspend routine gets invoked for HSMMC but it never gets resumed (may be due to the missed wakeup IRQ) from mwifiex and the command times out.

Suspend or Runtime suspend?

Quoted 6 lines

Quoted 1 line
Is there any other suggestion for mwifiex that I should try out? Or is there any way in omap_hsmmc to specify the wakeup interrupt type (IRQF_TRIGGER_LOW) while using generic wakeup IRQ mechanism. I could not find it, but I may be missing something.

How your irqs defined in DT? Could you provide mmc+wifi nodes?

Quoted 39 lines

Quoted 39 lines
Quoted 39 lines
2016-02-18 19:27 GMT+01:00 Vishal Thanki <[email protected]>:
Quoted 37 lines
Hi,
On a custom built am335x based board, I am facing an issue mwifiex wifi module which is connected to host via SDIO interface. I am using kernel version 4.4.
The problem is related to the wifi "ext_scan" command getting timed out over SDIO. This was working with old kernel (v4.0), but does not work on kernel v4.4. I found the following commit is responsible for this behavior.
=================================
5b83b2234be6733cfe22036c38031b2c890b3db8
mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq
We can now use generic wakeirq handling and remove the custom handling for the wake-up interrupts.
=================================
There is no wifi issue if I revert the above mentioned commit on kernel v4.4.
I see that before this commit, the wakeup IRQ handler was registered within the omap_hsmmc.c itself with additional IRQF_TRIGGER_LOW flag. But with the introduction to dev_pm_set_dedicated_wake_irq(), the generic wakeup IRQ handler is registered which does not take the IRQF_TRIGGER flag. I am not sure if that is the issue, but I added that IRQF_TRIGGER_LOW flag in dev_pm_set_dedicated_wake_irq() while registering a threaded IRQ handler, I could see the problem disappears. However, this change is causing the infinite interrupts because the of level triggered interrupt is not handled in generic wakeup IRQ handling code (as it was done specially in omap_hsmmc.c code earlier).
I am not much familiar with MMC/SDIO driver and I am not sure how to fix this behavior. So any guidance would be really helpful.

Signature · 2 lines

regards,
-grygorii

Vishal Thanki

author

2016-02-25 11:18 UTC #5 lore raw

Quoted 46 lines · Grygorii Strashko

Quoted 44 lines · Vishal Thanki
Hi,
Quoted 41 lines · Vishal Thanki
Hi Andreas,
Quoted 18 lines · Andreas Fenkart
Hi Vishal,
I remember there was a problem with IRQ, but can't remember on top of my head. Meanwhile this might be some pointer:
drivers/net/wireless/mwifiex/sta_ioctl.c +4 -0
index a6c8a4f..67587c2 100644
@@ -517,6 +517,17 @@ int mwifiex_enable_hs(struct mwifiex_adapter *adapter)
        adapter->hs_enabling = true;
        mwifiex_cancel_all_pending_cmd(adapter);
 
+       /* if the MMC host is already in suspend it will not detect SDIO irq
+        * and we might run into response timeout. By claiming the MMC host we
+        * wake it up, which is sufficient to detect a pending IRQ
+        */
drivers/net/wireless/mwifiex/sta_ioctl.c int mwifiex_enable_hs(struct mwifiex_adapter *adapter) · line 533
Quoted 10 lines
drivers/net/wireless/mwifiex/sta_ioctl.c +7 -0
+       {
+               struct sdio_mmc_card *card = adapter->card;
+               sdio_claim_host(card->func);
+               printk("+++ poll mmc host for IRQ +++\n");
+               sdio_release_host(card->func);
+       }
+
        if (mwifiex_set_hs_params(mwifiex_get_priv(adapter,
                                                   MWIFIEX_BSS_ROLE_STA),
                                  HostCmd_ACT_GEN_SET, MWIFIEX_SYNC_CMD,
I tried this code change but that did not help. I saw that the code change is in a function called mwifiex_enable_hs(), which only gets invoked by mwifiex_sdio_suspend(); which is why I think it is not having any effect. Because when I run the command to scan the channel list (i.e. iw dev wlan0 scan), the system is not in suspend state. And I noticed (by adding prints in omap_hsmmc.c for suspend and resume callbacks) that during the "scan" command, the suspend routine gets invoked for HSMMC but it never gets resumed (may be due to the missed wakeup IRQ) from mwifiex and the command times out.

Quoted 1 line

Suspend or Runtime suspend?

The it is the runtime suspend routine for omap_hsmmc.c

	mmc1_pins: pinmux_mmc1_pins {
		pinctrl-single,pins = <
			0x0fc 0x38	/* MMC0_DAT0 */
			0x0f8 0x38	/* MMC0_DAT1 */
			0x0f4 0x38	/* MMC0_DAT2 */
			0x0f0 0x38	/* MMC0_DAT3 */
			0x100 0x38	/* MMC0_CLK */
			0x104 0x38	/* MMC0_CMD */
			0x88  0x07	/* GPMC_CSN3 -> GPIO2_0 */
		>;
	};

	mmc1_sleep_pins: pinmux_mmc1_sleep_pins {
		pinctrl-single,pins = <
			0x0fc 0x3f	/* MMC0_DAT0 */
			0x0f8 0x3f	/* MMC0_DAT1 */
			0x0f4 0x3f	/* MMC0_DAT2 */
			0x0f0 0x3f	/* MMC0_DAT3 */
			0x100 0x3f	/* MMC0_CLK */
			0x104 0x3f	/* MMC0_CMD */
			0x88  0x17	/* GPMC_CSN3 -> GPIO2_0 PULL UP */
		>;
	};

	mmc1_cirq_pin: pinmux_cirq_pin {
		pinctrl-single,pins = <
			0x0f8 0x3f	/* MMC0_DAT1 as GPIO2_28 */
		>;
	};

	wlan0_pwrseq: pwrseq {
		compatible = "mmc-pwrseq-simple";
		reset-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
		clocks = <&clk_32768_ck>;
		clock-names = "ext_clock";
	};

&mmc1 {
	status = "okay";
	pinctrl-names = "default", "idle", "sleep";
	pinctrl-0 = <&mmc1_pins>;
	pinctrl-1 = <&mmc1_cirq_pin>;
	pinctrl-2 = <&mmc1_sleep_pins>;
	interrupts-extended = <&intc 64 &gpio2 28 0>;
	ti,non-removable;
	bus-width = <4>;
	vmmc-supply = <&ldo2_reg>;
	vmmc_aux-supply = <&vmmc>;
	keep-power-in-suspend;
	enable-sdio-wakeup;
	mmc-pwrseq = <&wlan0_pwrseq>;
};

Quoted 59 lines

Quoted 7 lines
Quoted 2 lines
Is there any other suggestion for mwifiex that I should try out? Or is there any way in omap_hsmmc to specify the wakeup interrupt type (IRQF_TRIGGER_LOW) while using generic wakeup IRQ mechanism. I could not find it, but I may be missing something.
How your irqs defined in DT? Could you provide mmc+wifi nodes?
Quoted 39 lines
Quoted 39 lines
Quoted 39 lines
2016-02-18 19:27 GMT+01:00 Vishal Thanki <[email protected]>:
Quoted 37 lines
Hi,
On a custom built am335x based board, I am facing an issue mwifiex wifi module which is connected to host via SDIO interface. I am using kernel version 4.4.
The problem is related to the wifi "ext_scan" command getting timed out over SDIO. This was working with old kernel (v4.0), but does not work on kernel v4.4. I found the following commit is responsible for this behavior.
=================================
5b83b2234be6733cfe22036c38031b2c890b3db8
mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq
We can now use generic wakeirq handling and remove the custom handling for the wake-up interrupts.
=================================
There is no wifi issue if I revert the above mentioned commit on kernel v4.4.
I see that before this commit, the wakeup IRQ handler was registered within the omap_hsmmc.c itself with additional IRQF_TRIGGER_LOW flag. But with the introduction to dev_pm_set_dedicated_wake_irq(), the generic wakeup IRQ handler is registered which does not take the IRQF_TRIGGER flag. I am not sure if that is the issue, but I added that IRQF_TRIGGER_LOW flag in dev_pm_set_dedicated_wake_irq() while registering a threaded IRQ handler, I could see the problem disappears. However, this change is causing the infinite interrupts because the of level triggered interrupt is not handled in generic wakeup IRQ handling code (as it was done specially in omap_hsmmc.c code earlier).
I am not much familiar with MMC/SDIO driver and I am not sure how to fix this behavior. So any guidance would be really helpful.
Signature · 2 lines
regards,
-grygorii

Grygorii Strashko

2016-02-25 11:47 UTC #6 lore raw

On 02/25/2016 01:18 PM, Vishal Thanki wrote:

[...]

Quoted 42 lines

Quoted 2 lines

Suspend or Runtime suspend?

The it is the runtime suspend routine for omap_hsmmc.c

	mmc1_pins: pinmux_mmc1_pins {
		pinctrl-single,pins = <
			0x0fc 0x38	/* MMC0_DAT0 */
			0x0f8 0x38	/* MMC0_DAT1 */
			0x0f4 0x38	/* MMC0_DAT2 */
			0x0f0 0x38	/* MMC0_DAT3 */
			0x100 0x38	/* MMC0_CLK */
			0x104 0x38	/* MMC0_CMD */
			0x88  0x07	/* GPMC_CSN3 -> GPIO2_0 */
		>;
	};

	mmc1_sleep_pins: pinmux_mmc1_sleep_pins {
		pinctrl-single,pins = <
			0x0fc 0x3f	/* MMC0_DAT0 */
			0x0f8 0x3f	/* MMC0_DAT1 */
			0x0f4 0x3f	/* MMC0_DAT2 */
			0x0f0 0x3f	/* MMC0_DAT3 */
			0x100 0x3f	/* MMC0_CLK */
			0x104 0x3f	/* MMC0_CMD */
			0x88  0x17	/* GPMC_CSN3 -> GPIO2_0 PULL UP */
		>;
	};

	mmc1_cirq_pin: pinmux_cirq_pin {
		pinctrl-single,pins = <
			0x0f8 0x3f	/* MMC0_DAT1 as GPIO2_28 */
		>;
	};

	wlan0_pwrseq: pwrseq {
		compatible = "mmc-pwrseq-simple";
		reset-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
		clocks = <&clk_32768_ck>;
		clock-names = "ext_clock";
	};

Quoted 7 lines

&mmc1 {
	status = "okay";
	pinctrl-names = "default", "idle", "sleep";
	pinctrl-0 = <&mmc1_pins>;
	pinctrl-1 = <&mmc1_cirq_pin>;
	pinctrl-2 = <&mmc1_sleep_pins>;
	interrupts-extended = <&intc 64 &gpio2 28 0>;

^^ you can define IRQ type here

&gpio2 28 IRQ_TYPE_LEVEL_LOW

Quoted 24 lines

	ti,non-removable;
	bus-width = <4>;
	vmmc-supply = <&ldo2_reg>;
	vmmc_aux-supply = <&vmmc>;
	keep-power-in-suspend;
	enable-sdio-wakeup;
	mmc-pwrseq = <&wlan0_pwrseq>;
};
Quoted 14 lines
Quoted 7 lines
Quoted 2 lines
Is there any other suggestion for mwifiex that I should try out? Or is there any way in omap_hsmmc to specify the wakeup interrupt type (IRQF_TRIGGER_LOW) while using generic wakeup IRQ mechanism. I could not find it, but I may be missing something.
How your irqs defined in DT? Could you provide mmc+wifi nodes?

[..]

Signature · 2 lines

regards,
-grygorii

Vishal Thanki

author

2016-02-25 12:18 UTC #7 lore raw

Quoted 57 lines · Grygorii Strashko

On 02/25/2016 01:18 PM, Vishal Thanki wrote:

[...]

Quoted 43 lines

Quoted 2 lines

Suspend or Runtime suspend?

The it is the runtime suspend routine for omap_hsmmc.c

        mmc1_pins: pinmux_mmc1_pins {
                pinctrl-single,pins = <
                        0x0fc 0x38      /* MMC0_DAT0 */
                        0x0f8 0x38      /* MMC0_DAT1 */
                        0x0f4 0x38      /* MMC0_DAT2 */
                        0x0f0 0x38      /* MMC0_DAT3 */
                        0x100 0x38      /* MMC0_CLK */
                        0x104 0x38      /* MMC0_CMD */
                        0x88  0x07      /* GPMC_CSN3 -> GPIO2_0 */
                >;
        };

        mmc1_sleep_pins: pinmux_mmc1_sleep_pins {
                pinctrl-single,pins = <
                        0x0fc 0x3f      /* MMC0_DAT0 */
                        0x0f8 0x3f      /* MMC0_DAT1 */
                        0x0f4 0x3f      /* MMC0_DAT2 */
                        0x0f0 0x3f      /* MMC0_DAT3 */
                        0x100 0x3f      /* MMC0_CLK */
                        0x104 0x3f      /* MMC0_CMD */
                        0x88  0x17      /* GPMC_CSN3 -> GPIO2_0 PULL UP */
                >;
        };

        mmc1_cirq_pin: pinmux_cirq_pin {
                pinctrl-single,pins = <
                        0x0f8 0x3f      /* MMC0_DAT1 as GPIO2_28 */
                >;
        };

        wlan0_pwrseq: pwrseq {
                compatible = "mmc-pwrseq-simple";
                reset-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
                clocks = <&clk_32768_ck>;
                clock-names = "ext_clock";
        };

Quoted 7 lines

&mmc1 {
        status = "okay";
        pinctrl-names = "default", "idle", "sleep";
        pinctrl-0 = <&mmc1_pins>;
        pinctrl-1 = <&mmc1_cirq_pin>;
        pinctrl-2 = <&mmc1_sleep_pins>;
        interrupts-extended = <&intc 64 &gpio2 28 0>;

Quoted 4 lines

^^ you can define IRQ type here
&gpio2 28 IRQ_TYPE_LEVEL_LOW

Thank you very much Grygorii for pointing it out. With that change, I am not seeing any problem now.

Thanks,
Vishal

Quoted 32 lines

Quoted 26 lines
        ti,non-removable;
        bus-width = <4>;
        vmmc-supply = <&ldo2_reg>;
        vmmc_aux-supply = <&vmmc>;
        keep-power-in-suspend;
        enable-sdio-wakeup;
        mmc-pwrseq = <&wlan0_pwrseq>;
};
Quoted 16 lines
Quoted 7 lines
Quoted 2 lines
Is there any other suggestion for mwifiex that I should try out? Or is there any way in omap_hsmmc to specify the wakeup interrupt type (IRQF_TRIGGER_LOW) while using generic wakeup IRQ mechanism. I could not find it, but I may be missing something.
How your irqs defined in DT? Could you provide mmc+wifi nodes?
[..]
--
regards,
-grygorii