> > > 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.
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.
- Dave
> > > Now, why we just disable the interrupts by setting the MIE-Bit in
> > > the HcInterruptDisable Register on suspend and activate the interrupts
> > > by setting the MIE-Bit in the HcInterruptEnable Register on resume, again?
> >
> > Partly because when the chip came back after suspend, its
> > registers acted just like they'd gotten a power-up reset.
> > Tweaking interrupts couldn't restart it, or re-establish
> > the various modes that were previously set up.
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
