On Mon, 28 Nov 2005, David Brownell wrote:
> > Maybe it would make more sense to have the method formerly known as
> > "reset" prepare almost everything, leaving the hardware essentially in
> > bus-suspend state.
>
> I'd say "bus off", actually. There are some devices that can't enumerate
> properly unless they get a full VBUS power cycle, and switching power off
> during USB startup is a big help. (I'm thinking of a particular MGS UPS,
> oddly enough.)
>
> That in fact is what the OHCI and EHCI init/setup/reset routine should be
> doing now.
How much distinction do we want to draw between stop/start and
suspend/resume? Power cycling the ports is one difference; you want to do
it during a start (or a restart) but not during a resume. The same is
true for resetting the controller -- in fact, power cycling should be
_part_ of resetting the controller.
> > Then instead of calling start, we could just call
> > bus_resume. Likewise, for remove processing we would call bus_suspend
> > followed by a new "destroy" method.
>
> Sounds like a good approach to me. There's some confusion about just
> what stop() does ... currently it includes some of what I'd expect that
> destroy() to handle.
>
> How would that work for the resume-after-poweroff scenario though?
> It'd be nice if that were basically the same HCD startup sequence.
The way I see it, during resume the driver has to check and see whether
the old controller state is still intact. That means suspend power was on
and the firmware didn't change any settings. If the state has been
changed then the driver has to do a complete reset, otherwise the reset
can be skipped.
This complete reset should be essentially the same as an normal startup.
The business about telling khubd to disconnect all the children can be an
extra addition or it can be part of the normal startup as well (where it
will do nothing). In either case, the resume procedure leaves the
controller on and the root hub suspended, so it makes sense for the start
procedure to do the same thing. But then there's a chicken-and-egg
problem if the root hub hasn't yet been registered...
Perhaps it's time to start thinking about updating the HCD glue layer's
API in this regard. Common tasks include such things as:
Allocate the hcd structure and the root hub
Allocate the I/O or memory resources (PCI only)
Other PCI-centric device initialization (set_master, etc)
Initialize the private data structures
Initialize the controller hardware and the USB bus
Allocate the irq
Register the root hub
Resume the root hub and the bus
Suspend the root hub and the bus
Unregister the root hub
Release the irq
Destroy the private data structures
Turn off PCI settings
Release I/O or memory resources
Free the hcd structure and the root hub
Not necessarily in that order. The problem is to find a logical
organization.
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
