On 08/28/2012 04:13 AM, Wei Ni wrote:
On Tue, 2012-08-28 at 04:06 +0800, Stephen Warren wrote:
On 08/27/2012 09:24 AM, Arend van Spriel wrote:
On 08/27/2012 12:25 PM, Wei Ni wrote:
In case of inband interrupts, if we handle the interrupt in dpc thread,
two level of thread switching takes place to process wifi interrupts.
One in SDHCI driver and the other in Wifi driver. This may cause the
system
instability.
Looking into the sdhci/mmc code indeed shows that the brcmfmac irq
handler is not called in true IRQ context. So the dpc thread may add
unnecessary complexity, but to me there is not indication that there is
a stability issue.
The brcmfmac irq handler is called in the thread sdio_irq_thread(), this
thread indeed is driven by the sdhci irq, although it's not the true IRQ
context. If the brcmfmac doesn't clear the IRQ condition ASAP, the
sdio_irq_thread will be triggered again and again, and in this condition
it's too difficult to run the brcmfmac dpc thread, more and more
interrupt can't be handled.
Because the SDHCI calls sdio_irq_thread() to handle the irq, this
thread locks
mmc host and calls wifi handler. It expects WiFi handler to be quick and
enables sdio interrupt from card at end. If wifi handler defers this
work for
a different thread, sdio_irq_thread() will be stuck on next wifi
interrupt
since mmc lock is not freed.
Not sure if I can follow this explanation. The isr is called with host
claimed (by sdio_irq_thread) and all it does is at a linked list member
and signal the dpc thread. After doing this the host is released.
Is the issue something like the ISR handler or first level of threading
does:
* Trigger DPC
* Re-enable interrupt
So that the interrupt then fires again before the triggered DPC can run
to handle/clear it, thus causing an interrupt storm?
Whereas handling the interrupt directly prevents this race condition?
Above is my understanding.
Hi Wei,
I understand the issue here and totally agree that we should treat
in-band and out-band interrupts differently. But my concern is that the
behavior of releasing the host before calling brcmf_sdbrcm_isr and grab
it after is likely error prone. Also we are restructuring the dpc
routine internally and it's almost done. I will find a better solution
for in-band interrupt and get it the queue as well. So I suggest
dropping this patch.
Thanks,
Franky
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
