On Fri, 3 Aug 2012, Ming Lei wrote: > On Fri, Aug 3, 2012 at 10:20 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 2 Aug 2012, Rafael J. Wysocki wrote: > > > Hmmm. You'd probably want a version that does a "get" at the same > > time. I suppose you would call func directly if the device was already > > resumed, without going through the workqueue? > > Maybe it isn't good, the 'func' might not be run in the current context > (irq context or some spinlock is held). True. But we don't want to wait for the workqueue if the device is already at full power. Suggestions? > >> And what if you are a parent waited for by a child to resume so that _it_ > >> can process its data? Would you still want to process your data in the > >> resume callback in that case? > > Looks the child is always resumed after its parent completes the resuming, > and current pm_runtime_get doesn't delay the resume of the parent, and > just make the .runtime_resume run in another context. I don't understand. Rafael's point was that if the parent's resume callback did a bunch of real work, it would delay resuming the child because the child can't be resumed until the parent's resume callback returns. > Also are there actual examples about the above situation? I don't know of any. I suspect there aren't many examples. It wouldn't make much sense. > IMO, the .runtime_resume callback can handle the IO things easily > via scheduling worker function if the driver don't want to delay > its children's resume. That was one of Rafael's other suggestions. But calling pm_request_resume_and_call() is easier than scheduling a worker function. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
