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. :-) Really, what I'm talking about is not much different from continuing to hold dev->power.lock across the runtime_resume and runtime_suspend callbacks. Would you prefer to do that instead of explicitly busy-waiting? There would be two disadvantages. First, the runtime_suspend routine would not be able to call pm_request_idle() or pm_schedule_suspend() and then return -EBUSY. Second, if the driver uses a private lock then the callback routines might not be able to acquire it. On Wed, 6 Oct 2010, Rafael J. Wysocki wrote: > Overall, we seem to have a corner case to cover and we're considering doing > intrusive changes to the framework because of that, even though that changes > may not be really necessary in practice. I think we should focus more on the > corner case instead. I'm not sure what you mean. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
