Hi John, I don't recall any responses, but these are good ... :)
I'd actually been hoping for examples that related to drivers other than the hub driver, but those remote wakeup issues sound good to know (for when we implement that functionality). I'd speculate that one good reason to do it is buggy device firmware. Re (1), at least OHCI should handle this already; some laptops are really serious about saving power. - Dave ----- Original Message ----- From: "John S. Howard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, January 11, 2002 9:16 PM Subject: RE: [linux-usb-devel] USB drivers and suspend ... > 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
