>> > For us to do this would be a little difficult. System suspend is easy >> > enough to handle because we don't actually need to put any external >> > ports into suspend; the entire bus will go into global suspend when the >> > root hub is suspended. In fact, this is what we should be doing now >> > (but we aren't). >> > >> Do you think is it OK to set ehci->no_selective_suspend = 1 for single >> port controller? > > In general you should avoid setting that flag if possible. Setting it > would prevent the attached device from being runtime suspended. But if > that device is a hub, it wouldn't prevent the hub's children from being > runtime suspended. > > The issue described in this email thread affects only external hubs, > not root hubs. It's perfectly okay to suspend an EHCI root hub while > the ports are suspended -- in fact, the EHCI spec requires this. > >> Currently, both ehci_hub_control and ehci_bus_suspend will go bus suspend >> routine when CONFIG_USB_SUSPEND is defined, and I am not sure if >> PSE and ASE is cleared before we let bus go to suspend (at ehci_hub_control). > > Where does ehci_hub_control put the bus into suspend? It suspends only > individual ports, not the whole bus. > > If if there's only one port, suspending that port does not suspend the > whole bus. The frame counter continues to update and the root hub will > continue to respond to URBs. > >From the code, the URB for roothub just read/write register portsc, it has not traffic on usb bus. Take my controller as an example, it is chipidea (Synopsis now) single port controller, this single port is just controller. Set portsc.suspendM will stop the SOF, but frame counter will not stop until phy clock is disabled. > 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
