Hi Ming, Thanks for your input. > > Looks ehci_bus_resume will do "Force Port Resume" on suspended ports, so > in theory ehci host driver can deal with your case if RUN/STOP is set > after > handling port resume as done in attachment patch. The patch does work > well > in my box. > > Per ehci spec, RUN/STOP is used to start/stop transactions schedule, so > it should be set after complete of port resume in ehci_bus_resume. > For call/SMS remote wakeup system case, the ehci_bus_resume may be called after 20ms later when remote wakeup interrupt occurs. Before ehci_bus_resume is called, there are many usb stuffs and some of them at process context. For example, usb phy/controller's wakeup handler, usb phy/controller's wakeup routine, PCD interrupt, etc. And one thing I am not very sure is if the hcd->wakeup_work will only be scheduled after other device's resume has finished (due to work queue will only be re-kick) > > > > The usb_hcd_resume_root_hub is only called at PCD interrupt when > usbcmd.rs=0, > > I would like to set usbcmd.rs as early as possible (at platform or > controller > > code), but don't want break usb core. Current, my solution is run > > usb_hcd_resume_root_hub at controller code, and the PCD interrupt will > be > > triggered later. Any risks for this solution, do you have any better > suggestions? > > IMO, it isn't a good idea to enable RUN/STOP very soon, which may cause > early > SOF sent to resuming ports. > >From my point, if the resume signal has not finished, the SOF will not be sent out even usbcmd.rs=1, the SOF sending process is controlled by hardware. The controller needs to makes sure there is no big bus idle time between resume signal and SOF when software operation has finished (portsc.fpr=1 and usbcmd.rs=1). > > Thanks, > -- > Ming Lei -- 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
