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