On Fri, 2 Dec 2005, David Brownell wrote: > > Power cycling the ports is one difference; you want to do > > it during a start (or a restart) but not during a resume. The same is > > true for resetting the controller -- in fact, power cycling should be > > _part_ of resetting the controller. > > Actually, the critical point is maintaining the power session. > > The controller doesn't matter ... reset it during resume if you > like (see how EHCI is specified, it's a fairly small appendix > which shows how the PCI Vaux power well can keep _part_ of the > USB hardware powered) so long as you don't break the power session > during the "suspend" cycle. > > (The phrase "power session" is from the OTG spec. It's important > because of the "Session Request Protocol" ... SRP allows hosts to > stop powering idle devices. It's an even more aggressive power > savings scheme than "USB suspend". Non-SRP hosts manage the > same sort of power sessions, but they only terminate sessions > on host power-down or certain system suspend modes.)
Maybe that's not such a good term. What good does it do to maintain the power session if the host controller disables the port during a reset? It might be better to call it a "port session". > The only state that _necessarily_ matters is the port power session; > when that terminates, the port gets disabled. Much of the port state has to be maintained as well. Maybe you mean to include that as part of the power session. > Of course, some controllers can't reset without also breaking their > port power sessions. Point being that there can be no hard and fast > rule applying to all controllers, beyond the one about power sessions. Point taken. > > The business about telling khubd to disconnect all the children can be an > > extra addition or it can be part of the normal startup as well (where it > > will do nothing). In either case, the resume procedure leaves the > > controller on and the root hub suspended, so it makes sense for the start > > procedure to do the same thing. But then there's a chicken-and-egg > > problem if the root hub hasn't yet been registered... > > True. Maybe registering the hub should be what starts the controller > the first time, then resume() could assume it's already registered. > (Or root_hub.set_interface could start it ...) That feels a bit klugey. On the other hand we need to change usbcore anyhow, so that probing interfaces on suspended devices will automatically resume the device. So we register the root hub in an already-suspended state, and usbcore takes care of the rest. Just an idea. But what if CONFIG_PM isn't on? Then it won't mean anything to say the root hub starts out in a suspended state... > > Not necessarily in that order. The problem is to find a logical > > organization. > > Also a reasonable interlock between key stages of HCD bringup, > including enabling the IRQ, starting polling, and doing whatever > control register write is activating the controller. If we do it right, the code should be organized in such a way that interlocks are unnecessary. > There's a related point. With OTG-capable hardware, those final > activation stages need to hold off until the gadget driver > (say, file_storage) is registered and the peripheral side is > ready to go too. There'd normally be just one "go" bit that > applies to both state machine roles. Something to keep in mind. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
