On Friday 11 March 2005 11:17 am, Olav Kongas wrote: > Hi, > > Recent days I have been working on suspend/resume > functionality of the isp116x-hcd (on 2.6.11-mm2). There are > things I still don't understand. > > Basic suspend/resume of root hub (RH) from the system seems > to be working. As a response to echo -n 3 > > /sys/bus/usb/devices/usb1/power/state the ports are > suspended and then the RH is suspended (via > isp116x_hub_suspend(), assigned to struct > hc_driver.hub_suspend in isp116x-hcd). The current > consumption of the chip drops as expected. Reversing all > this via /sys interface takes first the root hub out of > suspend and then resumes ports. Previously enumerated > devices (e.g. a mounted memory stick) are functional after > such a suspend/resume cycle. > > When I try to access the stick while RH is suspended, the > attempt fails with -EHOSTUNREACH (this is OK, right?).
All that sounds good. When you say they're "functional" after the resume, that means they still work with the previously assigned address, right? > However, after resuning via /sys the stick will be > re-enumerated. Is this re-enumeration a sign of a > malfunctioning HCD? I think not. Currently, usb-storage doesn't know how to cope with suspend. Didn't you get nasty messages about that during the suspend? > I've also tried to resume from remote wakeup events like > moving a previously enumerated mouse behind the suspended > RH. Such a wakeup event triggers ResumeDetected interrupt. > Then the irq handler schedules isp116x_hub_resume() (via > events workqueue), which resumes the root hub, but it > doesn't change the /sys/.../power/state contents. The /sys/.../power/state stuff is messy. You've got to patch it in USB code, since the PM framework support for it is internally inconsistent. (Some would say "broken", and I tend to agree, but how-to-fixit is problematic.) > Which function should I schedule in the irq handler instead > of (or in addition to) isp116x_hub_resume() to trigger the > same sequence of resuming events like via /sys interface? Or > should remote wakeup handled some other way? See what OHCI (or maybe EHCI) does, those worked most recently in those scenarios. I'd not swear they work quite right in 2.6.11, there's too much change in the relevant areas and I've not re-tested. > Also, after a remote wakeup has triggered > isp116x_hub_resume(), only that RH port will be operational, > which got the resume signal. The other is still suspended > (isp116x has got 2 ports). Should isp116x_hub_resume() > resume also the other port? It could be argued either way, I suppose, but today I'd argue that it shouldn't. So long as that other port works correctly ... it resumes OK both through sysfs (or the usb resume calls, same thing) and from remote wakeup. > > Thanks in advance, > Olav > > PS. Thanks Alan for your answers to my questions about the > registering/unregistering HCD structures. Doing this in a > 2.6.11-mm2 way was easy indeed. Indeed, that's part of why I wanted to be sure you knew those patches were in the queue before your isp116x-hcd patch! :) - Dave ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
