On 02/24/2016 11:32 PM, Vishal Thanki wrote:
Hi,
On Fri, Feb 19, 2016 at 7:41 PM, Vishal Thanki <vishalthanki@xxxxxxxxx> wrote:
Hi Andreas,
On Thu, Feb 18, 2016 at 10:31:04PM +0100, Andreas Fenkart wrote:
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:
diff --git a/drivers/net/wireless/mwifiex/sta_ioctl.c
b/drivers/net/wireless/mwifiex/sta_ioctl.c
index a6c8a4f..67587c2 100644
--- a/drivers/net/wireless/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
@@ -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,
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?
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?
2016-02-18 19:27 GMT+01:00 Vishal Thanki <vishalthanki@xxxxxxxxx>:
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.
--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
