On Tue, 26 Sep 2017, Felipe Balbi wrote:
> > Does uvc use isochronous transfers? I assume it would, since it's a
> > video protocol.
>
> yes, it does :-)
>
> > dummy-hcd does not support isochronous. I don't know what would happen
>
> really? Then why is it registering iso endpoints to the gadget layer?
>
> static const struct {
> const char *name;
> const struct usb_ep_caps caps;
> } ep_info[] = {
> #define EP_INFO(_name, _caps) \
> { \
> .name = _name, \
> .caps = _caps, \
> }
>
> /* everyone has ep0 */
> EP_INFO(ep0name,
> USB_EP_CAPS(USB_EP_CAPS_TYPE_CONTROL, USB_EP_CAPS_DIR_ALL)),
> /* act like a pxa250: fifteen fixed function endpoints */
> EP_INFO("ep1in-bulk",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep2out-bulk",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep3in-iso",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep4out-iso",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep5in-int",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_INT, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep6in-bulk",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep7out-bulk",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep8in-iso",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep9out-iso",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep10in-int",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_INT, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep11in-bulk",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep12out-bulk",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep13in-iso",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep14out-iso",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep15in-int",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_INT, USB_EP_CAPS_DIR_IN)),
> /* or like sa1100: two fixed function endpoints */
> EP_INFO("ep1out-bulk",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep2in-bulk",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK, USB_EP_CAPS_DIR_IN)),
> /* and now some generic EPs so we have enough in multi config */
> EP_INFO("ep3out",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep4in",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep5out",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep6out",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep7in",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep8out",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep9in",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep10out",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep11out",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep12in",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep13out",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_OUT)),
> EP_INFO("ep14in",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_IN)),
> EP_INFO("ep15out",
> USB_EP_CAPS(USB_EP_CAPS_TYPE_ALL, USB_EP_CAPS_DIR_OUT)),
>
> #undef EP_INFO
> };
>
> > if you tried it, but one way or another it would not work the way you
> > want.
>
> if that's really the case, then maybe we should remove all the iso
> endpoints from dummy. Right?
Or comment them out, in case somebody decides to add isochronous
support in the future. Yes, there's no point having them in the
driver, given the way it works currently. All isochronous URBs
complete with a -ENOSYS error status:
switch (usb_pipetype(urb->pipe)) {
case PIPE_ISOCHRONOUS:
/* FIXME is it urb->interval since the last xfer?
* use urb->iso_frame_desc[i].
* complete whether or not ep has requests queued.
* report random errors, to debug drivers.
*/
limit = max(limit, periodic_bytes(dum, ep));
status = -ENOSYS;
break;
The comment could be improved too. I'll send in a patch.
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
