Hi Robert, On Monday 12 January 2009, Robert Lukassen wrote: > > > Hi, > > > > > > I've noticed that the URB size in case of Bulk transport is set to > > > the maximum payload size, or to a limit that is a multiple of the bulk > > > packet size (psize * UVC_MAX_ISO_PACKETS). The rationale behind this > > > is 'to be consistent with isochronous mode'. > > > > To be honest, the real reason is that I had to set a limit and that > > value wasn't really worse than another (at least at that time) :-) > > > > > We encounter some difficulties with this approach. These occur when > > > operating Bulk transport over a full-speed link. In that case, the > > > limit becomes 64 * 40 = 2560 bytes per URB. The device we use has 16KB > > > payloads. The frames typically do not consist of an exact multiple > > > of 16KB, so a frame is send as a sequence of 16KB USB bulk transfers, > > > ending with a bulk transfer < 16KB. > > > > It's really unfortunate that the USB 2.0 and UVC 1.1 specifications > > use the term "payload" for two different concepts. > > > > In USB 2.0, a payload is the data that is carried in the data field of > > a data packet within a bus transaction. In UVC 1.1, a Payload Transfer > > is a unit of data transfer common to bulk and isochronous endpoints. > > Your device has 16kB "payloads". As bulk payloads can be 512 bytes long > > at most (in high-speed) mode, I assume you mean UVC payloads (a UVC header > > followed by frame data). Is that correct ? > > > > In that case, every 16kB UVC payload should be terminated by a short > > packet, not only the last payload. > > ... > > > Let's first discuss the above confusion between USB and UVC payloads. > > If it turns our I was wrong, I'll analyse your patch :-) > > I did not know about the USB 2.0 terminology (payload == data in a > transaction packet), now I do. My references to 'payload' are always to > the UVC payload term.
Ok. So I assume that every 16kB payload you mentioned starts with a UVC header. > My main confusion is on the situation where a frame is split in multiple > UVC payloads, all of them of maximum size except for the last. You are > stating that for those 'maximum sized' payloads (in our device's case: > 16384 bytes) the device should insert a zero-length packet. We did some > experiments and if the device was made to insert a zero-length packet in > between two 'maximum sized' UVC payloads, we received three URB's in > uvc_video_decode_bulk(): > > [ 16384 ] [0] [ 16384 ] Now I'm getting confused. The USB 2.0 specification could be clearer. Section 5.8.3 states that "[A bulk] endpoint must always transmit data payloads with a data field less than or equal to the endpoint’s reported wMaxPacketSize value. When a bulk IRP involves more data than can fit in one maximum-sized data payload, all data payloads are required to be maximum size except for the last data payload, which will contain the remaining data. A bulk transfer is complete when the endpoint does one of the following: - Has transferred exactly the amount of data expected - Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet" This seems to mean, in my opinion, that a device should always send a zero-length packet to the host to signal the end of the UVC payload and push the data to the UVC driver. I might be wrong though. > There was one zero-length URB in between those two payload transfers. > Apparently, the USB host driver completes the URB based on its receive > buffer being full, before it handles the zero length packet. The next > URB then starts with a zero length packet and immediately completes with > 0 bytes data received. Right. The host behaviour is consistent with the USB specification (which doesn't solve our problem of knowing if the zero-length packet should be sent or not). > We wanted to figure out why this was happening, so we looked into the > USB 2.0 specification and saw those 'rules' about ending a USB bulk > transfer. We think the USB host implementation in Linux signals an URB > complete when it has gathered enough data to fill the URB receive > buffer. When the last full packet comes in, the URB is 'complete' as all > 16384 bytes in its receive buffer are full. The hypothesis is that this > is done under the first clause of those Bulk transfer rules: if the > expected amount of data is received, the bulk transfer is complete. I agree with that. > We changed the behaviour of the device to only send zero length packets > in case of 'short' UVC payloads (shorter than the maximum payload size > signaled in the configuration descriptor) that end in a full bulk > packet. That worked without problems. That will only work if the host driver uses an URB size that divides exactly the UVC maximum payload size. > The patch that I suggested has more to do with the limit on the payload > size that is imposed in the Bulk situation. Simply put, because of the > difference in maxium size of packets in Full speed (1023 in ISO, 64 in > Bulk), there is a huge difference in the computed payload buffer size. > For ISO, the buffer size is determined based on MAX_ISO_PACKETS * 1023 > (potentially, if this is the size signaled by the device) while for > Bulk, this is MAX_ISO_PACKETS * 64. When I implemented bulk support in the uvcvideo driver I allocated bulk buffers big enough to hold a whole UVC payload. As some devices use a single UVC payload to transfer a video frame, the amount of USB buffer memory was huge for embedded systems. This is why I put a limit on the USB buffer size. Your problem doesn't arises from a small buffer size, but rather from a buffer size which is not a sub multiple of the UVC maximum payload size. In your case this could easily be fixed, even with small URB buffer sizes, but there is no generic solution other than sending a ZLP between UVC payloads (imagine a device using a large prime number for its UVC maximum payload size). > We will repeat some experiments with the device sending ZLP in between > maximally sized UVC payloads using a USB bus analyser to verify these > findings. We'll post the results to this list. I'm looking forward to discussing the results with you. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
