> > That's not right. If the gadget isn't sending data then > iso_frame_desc[n].status should not be 0. It should be -EPROTO or > something like that. If status is 0, it means that the gadget actually > did send a zero-length packet rather than sending nothing at all. > I tryed to set the USB_SHORT_NOT_OK urb flag and then the callback returns with urb->status = -121 (i.e. -EREMOTEIO). The iso_frame_desc[i].status is always zero. >> I use: >> - a kernel 2.6.31.12 with the RT patch on the host; > > What type of host controller? > The gadget is registered as a high-speed device using ehci_hcd. > Why not use a more recent kernel, like 2.6.37? > I can't use one of the latest kernel versions since I'm using the RT-patch and, as you can see on http://www.kernel.org/pub/linux/kernel/projects/rt/, the last available kernel version for such patch is 2.6.33. > This is almost certainly wrong. If NUM_ISO_PACKETS were larger than 1 > then the packet buffers would overlap, unless the endpoint's maxpacket > size is 1. More likely this should be i * iso_in->iso_in_size. > ok, fixed, thanks :-) > > What happened to .bEndpointAddress? You have to specify USB_DIR_IN. > Yes, i did. It has been properly initialized in the bind() function. >> I suspect that it should be a synchronization issue. > > I doubt it. More likely the gadget code isn't sending the packets > properly. > I think it is not the case since if i try to send a single buffer it is received correctly, but only when the read urb on the host is submitted AFTER the gadget has started sending data. I know that the usb protocol works with the host starting each transmission, but it seems to don't work... > Alan Stern > Thanks, Daniele -- 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
