On Tue, 8 Nov 2005, Neil Brown wrote: > Is there public available specs for such a controller that I could use > to help me understand the code, compare it with 2.4 to see what > differences there are and maybe start twiddling bits until something > happens?
It won't be easy: The two drivers have no code in common. You'd be better off comparing the usblp drivers. On Tue, 8 Nov 2005, Pete Zaitcev wrote: > If you start experimenting, try to set the NO_FSBR flag in usblp.c > to writeurb->transfer_flags. Good Lord, no, don't do that! With NO_FSBR set, the maximum theoretical transfer rate is 64 bytes/ms. If you leave it unset, the maximum theoretical transfer rate is 1216 bytes/ms. Let's take a look at some of the data posted earlier. This is from the start of the usbmon log. c7e12560 2264943329 S Bi:002:01 -115 8192 < Bulk-in? Probably monitoring printer status. Presumably we can ignore this. c7e12500 2264943987 S Bo:002:01 -115 8192 = 1b252d31 32333435 5840504a 4c205345 54205041 47455052 4f544543 543d4155 c7e12500 2284767551 C Bo:002:01 0 8192 > 8192 byte bulk-out transfer. At the maximum theoretical rate, it should take about 7 ms. In fact it took 20 seconds! You can't blame that on the USB controller. c7e12500 2284767883 S Bo:002:01 -115 8192 = 03feff00 f0fe0000 3ffeffff 000003ff ff05003f fffc000f fbff00fc ff00feff c7e12500 2284926541 C Bo:002:01 0 8192 > A similar transfer. This one took 160 ms instead of 7. c7e12500 2284926741 S Bo:002:01 -115 8192 = ffff0000 03feffff 00000ffe ffff0000 0ffdff00 c0fe0000 0fffff00 f0ff0000 c7e12500 2288645138 C Bo:002:01 0 8192 > Another one, taking almost 4 seconds. Unless you were running some other extremely bandwidth-consuming device on the same USB bus at the same time, I'd say these delays were caused by the printer. Now maybe they were caused by the Linux driver not configuring the printer properly... That's always a possibility. c7e12500 2288645387 S Bo:002:01 -115 8192 = fe00003f ffff00fc f900fdff 00fcff00 feff02f0 000ffeff fe00feff 00f0ff00 c7e12500 2288916098 C Bo:002:01 0 8192 > 8192 bytes taking 270 ms. c7e12500 2288916302 S Bo:002:01 -115 8192 = 0ffeff00 fcfa00fe ff02f000 03feff00f 0fe00fb ff00fcf4 00fdff00 f0fa0000 c7e12500 2289294084 C Bo:002:01 0 8192 > 8192 bytes taking 380 ms. The pattern is pretty clear. The printer takes a relatively long time to accept a relatively small batch of data, with occasional outliers taking much longer. Perhaps those long delays are where the paper was ejected? Alan Stern ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
