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.
>
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
> Thanks for your help.
>
> Vishal
>
>
>>
>> 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.
>> >
>> > Thanks,
>> > Vishal
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
