Hi Sarah, I apologize for the delay responding to the thread. Thanks for your comments. I would like to continue and fix the previous patch according to the comments. Also, I would like to split this patch, and implement the actual usage of streams for bulk EP transfers (passing the stream ID with the URB) to a different patch. > > It looks like userspace doesn't have a way to specify the number of > streams USBFS needs to allocate. Not all userspace applications are > You probably also need a way to communicate back to userspace how many > streams were actually allocated. The program could choose to free > So you're just taking the max_streams from the first endpoint that has > streams? What if other endpoints have varying numbers of max streams? > What if you have endpoints on an interface that don't support streams? > So it seems like you also need a way for userspace to specify which > endpoints get streams, and which endpoints have streams freed. I will What I have in mind is user space passing a structure holding: 1. Interface number [IN] 2. Bitmap indicating which EP to allocate streams for [IN] 3. Number of streams to allocate, one number [IN} 4. Number of streams actually allocated, one number [OUT] The devio alloc function will double check if all EPs belong to the interface passed by the user space. Then it will call the HCI alloc function with the required number of streams. It will return the number of streams actually allocated by the HCD. Items 3 & 4 can be merged to one IN/OUT parameter. No error checking will be done in devio for number of required streams (i.e, comparing it with the reported max streams). This kind of error checking is already done by the xHCI driver. Please let me know if the solution is acceptable. Thanks, Amit. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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
