On 08/27/2012 09:24 AM, Arend van Spriel wrote:

On 08/27/2012 12:25 PM, Wei Ni wrote:

quoted

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.

quoted

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?