hi alan: 2013/10/2 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Wed, 2 Oct 2013, yoma sophian wrote: > >> hi alan: >> >> 2013/10/2 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: >> > On Wed, 2 Oct 2013, yoma sophian wrote: >> > >> >> 1. in susped, we will gate our ehci clk >> >> in resumt, we need to release clk gating to let ehci control work. >> >> and above are platform specific behavior need to do >> >> there seems no such place to do above 2 things. >> > >> > You don't do these things in the USB suspend routine; you do them in >> > the controller suspend routine. For example, take a look at >> > s5p_ehci_suspend() and s5p_ehci_resume() in ehci-s5p.c. >> I found what you mentioned. >> 1. When will platform register dev_pm_ops be called? Is it called >> before or after usb_device_pm_ops ? > > The platform suspend routine is called after the USB suspend routine. > The platform resume routine is called before the USB resume routine. I found some driver register a. platform_driver->suspend/resume instead of b. platform_driver->driver->pm->suspend/resume is there any difference between above a) and b)? > >> 2. in ehci-s5p.c, it create a ".of_match_table". >> Under what circumstance, the match will happen? >> That mean how could I make sure the .pm I register in >> platform_driver will be matched and activated in the feature? > > The of_match_table entry is used during probe. It matters only for > drivers that use Open Firmware (i.e., Device Tree). > >> >> 2. in ehci_bus_resume, which handle ehci go back from both suspend/hibernate. >> >> This function handle ehci basic register default setting, such as >> >> re-init operational registers and restore CMD_RUN, framelist size, and >> >> irq threshold >> >> Why don't we put "handle basic register default setting, such as >> re-init operational registers and restore CMD_RUN, framelist size, and >> irq threshold" as pci_suspend and pci_resume like xhci does? > > Some of those things could indeed be moved from ehci_bus_resume to > ehci_resume. Not CMD_RUN, though. > > However, xHCI is fundamentally different from EHCI. A single xHCI > controller manages two physically independent buses: a SuperSpeed bus > and a full/low/high-speed bus. An EHCI controller, on the other hand, > manages only one bus. Therefore the drivers need to be somewhat > different. Is that the reason why we register 2 HCDs in xhci driver? if so, how driver decide to use which hcd when Super/Non-Super speed devices plug in? > >> That mean ehci_bus_resume will handle both "usb port resume" and >> "system hibernate" jobs. But xhci_bus_resume only handle "usb port >> resume", right? > > No. ehci_bus_resume and xhci_bus_resume both handle bus resume jobs, > whereas ehci_resume and xhci_resume both handle controller resume jobs. > > Bus suspend means putting an entire USB bus into low-power mode. In > particular, it means the controller should stop sending packets > (even SOF packets). > > Controller suspend means putting the controller itself into low-power > mode. > > System sleep (which includes system suspend and system hibernate) > involves both sorts of job: bus suspend/resume _and_ controller > suspend/resume. If we are doing hibernate for example, why we still need to put bus/controller suspend? it should be fine if we just reset it and re-initialize it when hibernate happen. After all, OS is power down in hibernate, right? Many thanks for your kind help, -- 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
