On Thu, Oct 18, 2012 at 10:37 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 18 Oct 2012, Pavan Kondeti wrote: > >> Hi Alan, >> >> I have a theoretical question in EHCI driver. We ensure that there is >> 5 msec window between suspend and next resume by keeping time_before() >> check in ehci_bus_resume function. If the next_statechange update in >> suspend occur just before the next timer tick (say 1 jiffies = 10 >> msec), then time_before() return false even when the resume is >> initiated <5 msec after suspend. I am not seeing any issue with this. >> Just would like to get a clarification from you. should we replace >> time_before with time_before_eq? > > In fact the whole thing shouldn't be using jiffies at all. We should > use ktime_t instead. And instead of having a fixed 5-ms delay at the > start of ehci_bus_suspend/resume, we should delay only by the amount of > time remaining. Likewise for ehci_suspend/resume. > Okay. Why are we having this check in ehci_suspend()? By the time ehci_suspend() is called, ehci_bus_suspend() is already called in which next_statechange is updated. we might end up giving 10msec delay in ehci_suspend(). why is 100 msec delay in ehci_resume? ehci_bus_resume has only 5 msec delay. > Would you like to write a patch to do this? > I will submit a patch next week. Thanks, Pavan -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation. -- 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
