Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Wed, 6 Oct 2010, Rafael J. Wysocki wrote: > >> Defer the resume. That's the only thing you can do in any case, whether you're >> going to busy loop or just use a workqueue. > > They are not the same. With a busy-wait you handle the device as soon > as possible, before the interrupt routine returns. With a workqueue > you have to mask the entire IRQ line, possibly losing interrupt > requests from other devices, until the workqueue routine can run. > >> > On the whole, I don't see any striking reason for the PM core not to >> > busy-wait during a concurrent state change. >> >> I do. That shouldn't happen in a fast path and we're talking about one, >> aren't we? Besides, I don't like busy waiting as a rule. > > On Wed, 6 Oct 2010, Kevin Hilman wrote: > >> Not sure I follow where you're going with this last paragraph. Of >> course, calls from ISR context cannot busy wait. > > What do you guys think spin_lock() does? It busy-waits until the lock > is free! If you don't like busy-waiting then you don't like spinlocks, > and if you believe ISR's can't busy-wait then you believe they can't > acquire spinlocks. :-) 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. Kevin -- 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
