On Wednesday 11 May 2005 7:08 pm, Alan Stern wrote: > On Wed, 11 May 2005, David Brownell wrote: > > [ re difference between root hub autosuspend and full suspend ] > > The fact that there's any difference was primarily because of > > the timer mess. > > That's a fragile way of doing things. It requires the HCD, while avoiding > actually calling usb_suspend_device, nevertheless to duplicate most of its > functionality so that usb_resume_device can reverse things properly.
The HCD parts of the functionality are in the hub_suspend() method. Everything except (for now) turning off the timer... no duplication. > It's not good programming practice. > > (Ideally these calls should go through the PM core, not just through > usbcore. However the PM core is not yet up to handling such things.) The PM core has never exported a function to suspend individual devices. And there are few conceptual problems it has with that notion too, including assumptions coupled to that big list of devices that are suspended (or not) and pm_parent. > > > and (b) if autosuspend didn't need a process context then neither > > > does autoresume. From these it follow that if USB_SUSPEND isn't set then > > > resume_root_hub simply isn't needed. > > > > But (b) was a rather wrong assumption; resuming requires things > > like longish delays (I think minimum of 30 msec, plus more for > > fudge and things like working around that one Lucent bug). In > > fact OHCI autoresume has always used a process context. > > I didn't know that. It does make things rather more difficult... I thought you did know, especially since you'd suggested OHCI use that method instead of its own workqueue entry. > > OHCI autosuspends whenever the root hub is idle, whether or not any > > devices are connected. That is, connected-but-suspended is also a > > fine reason to autosuspend. And that would in fact be isomorphic > > to the the "Save 2 Watts on Centrino laptops with USB mouse and UHCI" > > configuration ... the one where UHCI changes would extend battery > > life significantly, by letting the CPU use the C3 state. > > The UHCI driver could do that easily enough; only one subroutine (the one > that checks whether any active devices are attached) would need to be > changed. One key point is that I don't like the idea of autosuspending > immediately. Right now ... partly it's a legacy ... I won't worry about those details; and UHCI can use different answers. > Anyway, here's the problem as I understand it. OHCI (EHCI too?) needs a > process context to resume, if not to suspend. Yes, and in fact the hub_resume() method is guaranteed to be called in a task context. > It does autosuspend without > calling usb_suspend_device (which doesn't even exist if USB_SUSPEND isn't > set). Hence it ought to autoresume without calling usb_resume_device. It could just call hub_resume() more directly ... > And here's a suggestion for a solution. Make usb_hcd_resume_root_hub > conditional on CONFIG_PM rather than CONFIG_USB_SUSPEND (i.e., use your > patch), and make khubd call the hub_resume method directly if > root_hub->state != USB_STATE_SUSPENDED -- which will always be the case if > !CONFIG_USB_SUSPEND. This means also changing OHCI so that it leaves the > state equal to USB_STATE_CONFIGURED when autosuspending. How does that > sound? Simplest to just _always_ call hub_resume(). After all, the HCD would not have told usbcore to wake the hub up if it didn't need it ... :) But again, the timer stuff comes up. Once the HCD has full control over that stuff (again), that'll be no problem. - Dave ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&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
