On Sun, 8 Mar 2009, Martin Fuzzey wrote: > It has already been posted on the arm mailing list and deemed to be "overall > quite good" by Sascha Hauer (the mxc platform maintainer). This version includes > some modifications suggested by Sascha. > > There are still a few checkpatch warnings (all about long lines) > > Sparse gives a warning about locking context but the calls are correct: > drivers/usb/host/imx21-hcd.c:620:11: warning: context problem in 'noniso_etd_done': 'urb_done' expected different context > drivers/usb/host/imx21-hcd.c:620:11: context 'lock': wanted >= 1, got 0 > (this function is only called from process_etd_done which holds the spinlock A more serious problem is that your dequeue method forgets to call usb_hcd_check_unlink_urb(). > I'm struggling a bit to understand why the iso transfers don't work. > I've tested this with a phillips webcam (pwc driver) and get one of the folowing > behaviours (seemingly randomly) > > 1) etd done interrupts occur correctly (with the correct frame numbers) but > always zero bytes transferred. > 2) etd done interrupts occured with status code 0x8 = data overrun and 196 bytes > > Comparing with the behaviour on a intel system I see that there are also around > 100 empty transfers before the camera starts sending data. Then I get 192 byte > packets. In both cases the maxpacket size and buffer size is 196 bytes. > > Unfortunately I don't have a USB analyser to see what's on the wire. > > Case 2) seems very strange to me - how can more data be sent than expected? > I have run usbmon traces on both the mx21 and intel systems and the camera > setup commands are the same. One possibility is that the amount expected is wrong (too small). > I also wonder how I should handle the case where iso scheduling arrives too late > currently I just log a message - is this an error condition or should I > recalculate the frame numbers? What do you mean by "iso scheduling arrives too late"? The algorithm used by uhci-hcd goes like this: If the stream isn't already active, choose a suitable start frame in the near future. If the stream is already active and there are URBs queued, use the next slot after the end of the last URB in the queue. If the stream is active but no URBs are queued and URB_ISO_ASAP is set, choose the next slot after the current frame (as a result some slots may get skipped). If the stream is active but no URBs are queued and URB_ISO_ASAP is not set, use the next slot after the most recent URB. The frame for this slot may already have expired; if it has then one or more of the urb->iso_frame_desc[].status values will be set to -EXDEV. 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
