[subject changed and CC's trimmed] On Tue, 2 Mar 2004, David Brownell wrote:
> Yes, especially if it goes with a KERN_DEBUG message saying > there are no ISO-IN splits yet. It's essentially all coded, > but microframe scheduling needs tweaks for the IN cases. I > decided to force ENOMEM until that code is ready ... someone > willing to play with the code could turn it on and shouldn't > find it needs many changes. FWIW, I've simply disabled the check at the top of sitd_submit. Result: we are passing test 16 as well! > > I had some debugging on the ezusb, so at least I know it was actually > > receiving the iso-out data with correct crc. But I haven't checked for > > synchronisation and data correctness. > > How would you test for ISO synchronization? Dunno, just starting with ISO. Isn't this what the SyncFrame standard request is for? Together with some frame numbering this should IMHO provide the infrastructure for frame tracking to see if/where we are loosing packets. But it requires dedicated support from firmware and driver - thus not now, maybe sometimes later... ;-) > > T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 > > D: Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=ff MxPS=64 #Cfgs= 1 > > P: Vendor=fff0 ProdID=fff0 Rev= 0.01 > > Feel like using an "official" ID, by the way? I have a few IDs > left I can hand out ... Thanks! Sounds like a reasonable thing to do. So far I didn't care because it's just the firmware, no real device, getting distributed. But anyway - way not? We could even start building^H^H^H^H^H^Hselling our own compliance testsuite ;-) > > I: If#= 0 Alt= 1 #EPs= 4 Cls=ff(vend.) Sub=01 Prot=00 Driver=usbtest > > E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > E: Ad=88(I) Atr=01(Isoc) MxPS= 512 Ivl=1ms > > E: Ad=08(O) Atr=01(Isoc) MxPS= 512 Ivl=1ms > > Ah ... sneaky config! Does it work with MaxPS 1023, or MaxPS 1023 is a bit tricky because two endpoints in one AS with MaxPS=1023 are not allowed due to bandwidth requirements. OTOH usbtest currently requires endpoints coming in pairs. Furthermore I guess one might get some strange behaviour of the ezusb because there the iso fifo size is specified modulo 16. So I think 1008 is the maximum sane value here because 1024 is not only off-spec but also identical to 0. But I tried it anyway with 1023 and it seems linux-usb doesn't mind overcomitting the bandwidth. So, yes MaxPS 1023 is apparently working, both OUT and IN. > with bigger intervals? The split transaction support like MaxPS=512, interval=8ms? - yes, working as expected. > needs to use a sixth microframe for transfers larger > than about 940 bytes. I can't currently test those > at 1 msec intervals. Seems I should quite a number off altsettings to the firmware... > > * ./testusb -a -g 8 -v 0 > > Does "-g 32" work too? If there were issues there I'd > expect them to be with "test 10". no problem, just fine here. > > /proc/bus/usb/001/004 test 14, 4.012137 secs > > That's handy: control out testing makes "usbtest" cover > a lot more of the basic host and device functionality. Yep. In fact until very recently it was only working with -v0 for me. Reason was the handling of wLength=0 ep0 data packets. From the spec (5.5.3) it isn't clear to me whether the host whould send a zero-len packet in this case. My firmware assumed yes, but linux-usb didn't. I've changed the firmware now so they behave. > > /proc/bus/usb/001/004 test 15, 8.008405 secs > > /proc/bus/usb/001/004 test 16 --> 12 (error 12) > > Where presumably OHCI worked just fine; and UHCI, which > I rarely test. OHCI: yes, working. UHCI not tested (no 2.6 testbox with UHCI configured at the moment) Martin ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
