On Fri, Sep 24, 2010 at 01:29:46PM -0400, Alan Stern wrote:
> On Fri, 24 Sep 2010, Sarah Sharp wrote:
>
> > On Fri, Sep 24, 2010 at 11:04:50AM -0400, Alan Stern wrote:
> > > On Thu, 23 Sep 2010, Sarah Sharp wrote:
> > >
> > > > Hi Alan,
> > > >
> > > > I'm working on separating out the xHCI roothub into a USB 3.0 and a USB
> > > > 2.0 roothub, and it's turning out to touch way more code than I
> > > > expected. Before I go too far down the rabbit hole, can you check
> > > > whether my initial design is sane?
> > >
> > > Sure.
> > >
> > > > It turns out that the xHCI host has two completely separate busses for
> > > > USB 3.0 and non-SuperSpeed ports. So a USB 3.0 device can have the same
> > > > address as a USB 2.0 device under the same roothub. That to me sounds
> > > > like an argument for having separate usb_bus structures in struct
> > > > usb_hcd.
> > >
> > > I disagree; this approach will only lead to trouble -- as you have
> > > discovered. Since we essentially make no distinction between a usb_bus
> > > and a usb_hcd, you should have two of each.
> >
> > Hmm, what about the bandwidth_mutex in usb_hcd? That's supposed to keep
> > the actions of setting up the changed config/interface, sending the
> > control message to the device, and possibly reverting those changes if
> > they failed as one atomic operation. If there's two usb_hcd structures,
> > it seems like there ought to be a larger structure to hold the bandwidth
> > mutex. Unless one of the bandwidth mutexes could just point to the
> > other...?
>
> Is this really an issue? Don't the LS/FS/HS bus and the SS bus have
> totally independent bandwidth requirements? And doesn't that mean you
> can make simultaneous changes to both without interference?
Theoretically, yes, although only one Configure Endpoint command will be
processed at a time by the hardware from the command ring.
The two buses should have use different bandwidths, but they do use some
shared resources internal to the host controller. The xHC can refuse
the bandwidth request with a "Resource Error if it determines that it
does not have enough internal resources (buffer space, etc.) available
to service all the endpoints defined in the configuration."
Given that, I could see the following scenario:
1. The class driver wants to switch a USB 2.0 to a different alt
setting, perhaps with fewer endpoints. The xHCI Configure Endpoint
command succeeds, freeing some internal resources.
2. A USB 3.0 class driver wants to switch to an alt setting that
uses a lot of internal resources. The xHCI Configure Endpoint
command succeeds, and the device accepts the alt setting control
request.
3. The USB 2.0 device fails to respond to the control transfer to
switch alt settings, and the USB core needs to put the device back
into its old alternate setting. The Configure Endpoint command
fails because the old alt setting would take more internal resources
than is currently available.
Then we're stuck with a device in one alt setting, and the USB core and
xHC in a different alt setting. So I think we need a shared bandwidth
lock for the whole xHCI host controller.
> > > In retrospect the distinction between the two types of structures
> > > should have been made more carefully. But when the code was originally
> > > written, nobody foresaw the possibility of having one host controller
> > > running multiple buses. In fact, I can't think of any other sort of
> > > I/O bus where that happens. So now we have to live with the
> > > situation...
> >
> > Or I could see how difficult extracting the two structures are. It's
> > entirely possible we'll run into this issue again, now that the idea of
> > two buses has been introduced.
>
> You mean that USB-4.0 might add another four wires to the cable (making
> the connector that much larger) and force the controller to manage
> three buses? At what point does the madness stop? :-)
Oh, heaven forbid they add more wires! Actually, I was thinking of a
hardware situation that can occur with the current set of USB 3.0 host
controllers.
I know of a few xHCI prototypes where each port on the xHCI host
controller is a completely separate bus. So each port gets its own
bandwidth and separate bus addresses. I don't think there's a good way
for the xHCI driver to figure out which ports are separate bus instances
(the Get Port Bandwidth command is not quite sufficient), but I could
see a method being added as a xHCI 1.0 ECN, or maybe a USB 4.0 thing.
So it's possible we could see USB hosts with more than two buses.
> > What sorts of trouble do you expect,
> > aside from a large coding effort?
>
> (And the possibility of introducing bugs while making such a widespread
> set of changes.)
Yes, true.
> There might be some difficulty deciding which layer certain items
> belong in. Bear in mind that items which are controller-wide in
> USB-3.0 might change to be bus-specific in USB-4.0 -- then what will
> you do?
I'll cross that bridge when I come to it, I guess.
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
