On Tue, 18 Aug 2009, Sarah Sharp wrote: > The four patches that follow this message are the (untested but > compilable) code to add support for USB 3.0 bulk endpoint streams. > Streams are basically a way of queueing multiple transfers to one > endpoint, which allows the device to complete them out of order. > > I'd appreciate it if people reviewed the documentation and new > interfaces included the last patch. UASP drivers (the new mass storage > device class) will probably use these interfaces first. If you are > developing a UASP driver, I would appreciate if you could test these > patches (and post your code). > > > I also need a bit of advice on how to deal with the USB core. > > First, is anything going to break in the USB core when URBs for an > endpoint are completed out of order? There's no blindly taking the head > of a list of queued URBs, is there? No. It's already possible for URBs to complete out of order -- it happens whenever you unlink an URB that isn't at the head of its queue. > My second question involves resetting devices when a driver has enabled > streams for an endpoint. Here's how I understand usb_reset_device() works: > 1. Call the pre_reset driver method for all interface drivers, or it call > their unbind method. > 2. Reset the port and get the descriptors. > 3. Reinstall the old configuration and alt settings. > 4. Call the interface driver's post_reset or bind methods. Right. > I have yet to support resetting configured devices under the xHCI driver > because I have to add a new hook after the reset port in step two. That > hook will issue (and wait) on a Reset Device command, and tear down all > the internal structures that relate to endpoints other than control > endpoint zero. That means that any structures relating to streams will > also be lost. Is there any way to avoid losing those structures? > To enable streams, the driver must call usb_alloc_streams(). When the > driver is done using streams, it should call usb_free_streams(). Would > it be appropriate to ask drivers to call usb_free_streams() in their > pre_reset and then call usb_alloc_streams() in their post_reset method? That would be okay. But if you're going to lose the structures anyway, why bother calling usb_free_streams()? > I'm also not quite sure what happens when a driver is unbound from a > device. Is their close method called? If so, drives would need to call > usb_free_streams() in their close method. Unbinding involves calling the disconnect method, not the close method (which many drivers don't even have). What happens if a driver fails to call usb_free_streams during unbinding? Maybe the HCD's endpoint_disable method should automatically free all streams associated with the endpoint. Then drivers wouldn't have to worry about it. > Another approach would be to have the USB core keep track of how many > stream IDs are enabled for an endpoint and reinstate them after the > reset. It would need to stash the number of streams in some structure, > perhaps usb_host_endpoint? Wouldn't it need to know what the IDs are, not just how many? > I'm leaning towards letting drivers re-allocate streams after a reset, > what are your thoughts? Not having any examples to consider, it's hard to weigh up the advantages and disadvantages. 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
