On Mon, 27 Sep 2010, Sarah Sharp wrote:
> > > 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.
You know, I'm not so sure a shared lock will work -- not even in the
form we're using now. Consider this variant 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. An URB is submitted for some other device entirely, consuming some
of the internal resources.
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 are currently available.
Is there anything in the spec that says this can't happen? For that
matter, is there anything that says the hardware can't accept a
Configure Endpoint at one time and refuse it at another time, even with
the _same_ amount of resources available? (Sort of like the way
fragmentation can affect memory allocation.)
This is beginning to sound sufficiently difficult that it ought to be
addressed officially. Can you bring this up before the USB-IF or ask
somebody there at Intel? How does one change between alternate
settings in a way that is guaranteed to backtrack successfully if the
device refuses the change?
> 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.
The bandwidth and bus addresses don't really concern the OS because
they are all handled internally by the xHCI hardware. To what extent
would the USB core need to know that each port has its own bus?
Alan Stern
--
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
