I figured that while we're on the subject of power mangement, I'd mention
this odd behavior I've seen, just so people are aware of this.
On Apple PowerBooks which have USB ports on them, the ports behave
somewhat strangely when the computer is suspended. Specifically, if you
connect a mouse while suspended, it will initialize the device partially.
It does not seem to do this for other devices. This is most obvious if
you have one of those M$ mice with the light on them -- the light will
come on. Interstingly enough, the hardware won't initialize hubs, so you
can't connect a hub and a mouse (on the hub) and have it initialize.
The current theory on this behavior is that the mouce must be initialized
so that it can be used to wake up the computer. But I wonder how the
controller and HCD will react when it resumes.
Matt Dharm
On Tue, 4 Apr 2000, Dunlap, Randy wrote:
> and Jim Blackson wrote:
>
> > Just to confuse the issue a little more ... :-)
> > ... does/will/should linux support USB device remote wakeup?
>
> I expect it to. Seems to me that the reasons that this
> support is not there now is based on (1) priorities [it
> was low], (2) resources [we only have a few HCD developers
> and they stay fairly busy; maybe we should have someone
> else pick up power management issues], and (3) the power
> management code in the kernel is changing for 2.3/2.4 [it
> has a new API for APM xor ACPI support, but full ACPI support
> won't be ready for 2.4.0].
>
> > > > > I don't think this is the right way to handle suspend/resume.
> > > > > So, I don't like that patch.
> > > >
> > > > I could perhaps try an alternate patch you provided. What is
> > > > the issue you have with this one?
> > >
> > > You disconnect all devices and reset the USB-subsystem.
>
> To confuse the issue even more, you don't know what devices
> the user may have unplugged, added, or moved around
> during suspend, so wouldn't a complete re-enumeration
> be advisable, or is there something that would alert the
> hub driver that a re-enumeration is needed?
>
> ~Randy
>
> >
> > They were getting disconnected later anyway. (Oops!) And as
> > I noted, the USB controller seemed to need resetting before
> > it'd transfer data again.
> >
> > > This is like a shutdown of a computer at a suspend and a
> > > boot at a resume.
> >
> > It's certainly a "guaranteed to work in worst case" solution
> > for most purposes, using code paths we have reason to trust.
> > I didn't notice any delays in suspending or restarting.
> >
> > The OHCI spec shows me (fig 6-1) that the paths out of the
> > "operational" state are either (a) through "reset", or else
> > (b) through "suspend" then "resume". "suspend" state requires
> > support of remote wakeups, which I didn't see in the driver.
> >
> > I wasn't seeing (b) work ... I didn't see another choice.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
Matthew Dharm Home: [EMAIL PROTECTED]
Engineer, Qualcomm, Inc. Work: [EMAIL PROTECTED]
G: Let me guess, you started on the 'net with AOL, right?
C: WOW! d00d! U r leet!
-- Greg and Customer
User Friendly, 2/12/1999
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
