On Sun, 26 Sep 2004, David Brownell wrote: > > We may have no option. Unless I'm mistaken, suspend-to-RAM puts most PCI > > devices into D3cold. > > That'd be a bug. STR isn't supposed to discard state like that; it's > supposed to leave devices (low-)powered but able to resume > quickly (give or take a few breaths), not turn them off wholesale. > Otherwise it'd need to be called suspend-to-disk. :)
Not as I understand it. The only difference between STR and STD is that RAM is kept alive and refreshed. Everything else is still turned off. Maybe you're thinking of Standby -- we should check with Pavel. Furthermore, it turns out the resuming from STD requires the same sort of processing as resuming a powered-off USB device. See below... > > There's no real difference between what root hubs do here and what > > external hubs do. Before the resume-from-idle, khubd hasn't been running > > (or hasn't been running for long, anyway) -- so there probably aren't any > > USB devices enabled except the root hubs. > > There can be whole trees of devices sitting in USB suspend state, which > will be enabled just fine by correctly resuming the tree. Heck, one of > them may have just woken the system up ... :) Not from a suspend-to-disk! :-) > > As each device is discovered > > and initialized, it needs to be reattached to the driver which owned it > > before. That's essentially what usb_reset_device() does now. > > Better yet, when the system uses resume() on those devices then > no re-enumeration/probing is needed. No -- re-enumeration is unavoidable during resume-from-disk. Think about it. We start with a normal bootup, which may or may not include initializing the USB drivers (depending on whether they are linked into the kernel or kept as loadable modules). In either case very few USB devices will have been detected and initialized before the kernel begins its resume-from-disk procedure. The memory image is restored and then the PM core tells everyone to bring their devices back from the prepare-memory-image idle state. USB devices that weren't detected by the bootup kernel have to be detected now. Even devices that were detected and enumerated have probably been assigned addresses that are different from the ones stored in the memory image. Furthermore, we will want to check the descriptors on each device to make sure they haven't morphed (or that a different device was plugged into the same port) while power was off. So resume-from-disk requires detecting, initializing, and enumerating every USB device, pretty much like usb_reset_device() does now. Given that this infrastructure _has_ to be in place, why not reuse it to allow resume from selective power-off? > But I still think the default > handling of suspend should be disconnect() for drivers that don't > provide even minimal suspend/resume handlers. So that in those > cases, resuming should involve re-enumeration. I have no objection to this. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
