Re: [PATCH/RFC 5/5] usb: Add support for streams alloc/dealloc to devio.c

[Amit Blay]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/