On Sat, Feb 15, 2014 at 12:55:18AM -0000, Thomas Gleixner wrote: > synchronize_irq() waits for hard irq and threaded handlers to complete > before returning. For some special cases we only need to make sure > that the hard interrupt part of the irq line is not in progress when > we disabled the - possibly shared - interrupt at the device level. > > A proper use case for this was provided by Russell. The sdhci driver > requires some irq triggered functions to be run in thread context. The > current implementation of the thread context is a sdio private kthread > construct, which has quite some shortcomings. These can be avoided > when the thread is directly associated to the device interrupt via the > generic threaded irq infrastructure. > > Though there is a corner case related to run time power management > where one side disables the device interrupts at the device level and > needs to make sure, that an already running hard interrupt handler has > completed before proceeding further. Though that hard interrupt > handler might wake the associated thread, which in turn can request > the runtime PM to reenable the device. Using synchronize_irq() leads > to an immediate deadlock of the irq thread waiting for the PM lock and > the synchronize_irq() waiting for the irq thread to complete. > > Due to the fact that it is sufficient for this case to ensure that no > hard irq handler is executing a new function which avoids the check > for the thread is required. > > Add a function, which just monitors the hard irq parts and ignores the > threaded handlers. > > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> Acked-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx> -- 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
