On Thu, 7 Oct 2010, Kevin Hilman wrote: > My confusion is not about the use of spinlocks, it's a question of what > is being busy-waited for, and the thread that is being waited for is > going to complete when interrupts are disabled. > > Sorry to be dense, but can you (re)summarize what you're proposing as I > think I'm getting mixed up with all the various options we've been > tossing around. > > If it can work, I'm certainly in favor of a busy-wait approach as it > really ensures that sync requests are handled quickly. Okay, here's the story in a nutshell. Allowing a subsystem's or driver's runtime-PM callbacks to run with interrupts disabled faces two obstacles: (1): We don't want two different CPUs to run callbacks for the same device at the same time. So if a callback is already running on one CPU (i.e., if the device's runtime status is either SUSPENDING or RESUMING) then another CPU can't be allowed to invoke a callback. Thus, you can't do a synchronous pm_runtime_resume_irq() if the device is in the middle of a suspend or resume operation. We're left with two choices: Fail the synchronous call and force the driver to defer matters to a workqueue (possibly masking an IRQ line in the meantime), or busy-wait until the concurrent operation finishes. If the PM core simply avoids releasing dev->power.lock before invoking the runtime_suspend or runtime_resume callback, the end result is almost the same as with busy-waiting. (2): In general we can't resume a device if its parent is suspended. If the parent's runtime_resume routine needs to run with interrupts enabled then there's no way to resume the device while keeping interrupts disabled. Possible solutions involve, again, deferring matters to a workqueue, or else simply not allowing the situation to arise in the first place (forbid a device to have interrupt-disabled callbacks unless its parent does too or the parent doesn't use runtime PM at all). In general I'm against the solutions that require a workqueue. Raphael appears to favor workqueues for (1) and be against them for (2). Alan Stern -- 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
