Dave, I never saw any followup to this query. did I miss something or did anyone respond?
The general rules (as I recall) are: 1. if the destination D-state results in loss of power to the root hub (i.e. host controller in most cases) then you know you gotta do a complete re-enumeration when the system resumes. I don't know what impact this has on the client device drivers. One way to handle would to simulate a disconnect at the root hub. 2. if the destination D-state does not result in loss of power to the root hub, then (at least) all downstream ports in the enabled state should be selectively suspended, before the transition to the D-state occurs. If a device is identified as a remote-wake source, then it should be enabled for remote wake only just before it's parent port is suspended (sorry, the reason for this was compelling, but I can't recall why). the selective suspends are required to limit the power drain if a device drives resume signaling. Devices in the suspended state can return to drawing configured power as soon as they see bus activity, and resume is considered bus activity. without selective suspend, a couple of 4-port hubs, with all 1unit loads attached could potentially pull 1A out of the system during resume, which potentially could over tax the aux power supply. 2a. in addition to suspending the all enabled ports, a *more intelligent* implementation might be able to actually power down and disconnect all devices not identified as remote-wake sources. this is lots harder because you only get benefit if the device is connected to a port that has power switching (gang switching can even make it harder). the benefit is in additional power savings, you only provide power to devices that you need to detect external events and wake the system. Of course, this is lots harder (bookeeping wise) and takes the system longer to resume (in order to power on and re-enumerate the devices). not sure whether anyone ever thought about re-enumerating on demand ... kind of like some file systems don't mount directories until someone tries to touch them (afs??). seems like a similar thingy might be doable for usb resume... always have to handle the case where someone moved the darned device...:) none of this stuff is new,... is this the kind of stuff you were looking for? Regards John H. > > I'm curious what examples we have of cases where > drivers need to do intelligent things at particular levels > of suspend. > > One comes to mind: The hub driver should disconnect > all devices connected to some bus-powered hubs, at > least for suspend states where the root hub powers down. > (I think that's D3, at least D3cold, from what I remember > from last time I looked at this stuff.) They won't be around > after resume. > > Do any other good examples lurk? Note that this doesn't > include policies like "VM should flush all dirty pages", since > that's not a driver level issue. > > - Dave > _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
