It works! Now, all data are received by the host. The only strange behavior is that two or more host's callbacks are almost always needed to really get all the data of a single urb. For example, for a 32-packet request, a first callback where 22 packets have iso_frame_desc[n].actual_length > 0 and second callback (with the remaining 10 packets) are called. I thought that it could be due to the gadget which sends packets not fast enough, thus I tryed tuning both the host-side and the gadget-side urb interval flag. But even with a host-side interval=16 and a gadget-side bInterval=1 nothing changes. I also tryed the double-buffering technique suggested by Hans, but no changes. By the way, this is not really a problem, since the most important thing is that data are correctly received. It could be just a "curiosity" issue... :-) Thanks so much, Daniele 2011/3/18 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Fri, 18 Mar 2011, Daniele Capuano wrote: > >> A little update. >> It seems that the gadget itself has a strange behavior: I start >> monitoring the usb transfers using usbmon. >> My setup has remained the same, but NUM_ISO_PACKETS is 32. I also >> tryed, as Hans suggested, to submit two urbs in order to achieve >> double buffering, but nothing changed. >> I attach a little view of the usbmon output. As you can see, the first >> packet (second line) is received correctly, even though 1024 bytes are >> received while a packet of 512 bytes was requested by the host. After > > No. The host requested 32 packets of 512 bytes each. 32 packets were > received, but the only first two contained 512 bytes of data; the > others all contained 0 bytes. > > BTW, that submission has a buffer-overrun bug. All the > iso_frame_desc[n].offset values after the first lie beyond the end of > the transfer buffer. You need to make sure that iso_in->iso_in_buffer > is large enough to hold all NUM_ISO_PACKETS worth of data. > > Maybe this means you should set iso_in->maxpacket to 512, set > iso_in->iso_in_buffer to iso_in->maxpacket * NUM_ISO_PACKETS, set > urb->iso_frame_desc[i].offset to i * iso_in->maxpacket, and set > urb->iso_frame_desc[i].length to iso_in->maxpacket. > >> such receipt, nothing more is received. >> From the gadget, I monitored the callback calls, and I noticed that >> the callback is continuously called, even before the host submit the >> first urb. > > That sounds like a bug in the gadget's device controller driver. The > callback shouldn't be called until the data transfer is completed, > which can't happen until the host asks for it. > > I don't know the state of support for isochronous transfers using > OMAP3550 in 2.6.32.. > >> Maybe this means that zero-length packets are sent all the >> time before the host's first request. But what about the strange >> behavior after the host's requests? A first data buffer is sent, but >> then nothing more... it's seems quite strange to me... >> >> Thanks in advance for any idea... >> Daniele >> >> --------USBMON OUTPUT------------ >> f63bb000 2632500048 S Zi:5:009:2 -115:8:0 32 -18:0:512 -18:512:512 >> -18:1024:512 -18:1536:512 -18:2048:512 512 < >> f63bb000 2632540517 C Zi:5:009:2 0:8:8112:0 32 0:0:512 0:512:512 >> 0:1024:0 0:1536:0 0:2048:0 1024 = bafcc8fc d0fcc4fc ccfcc1fc d1fcccfc >> c8fcc1fc cafcbbfc c1fcc6fc c7fcd9fc > > 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
