>IMO, I think testing with usb-uhci.c and uhci.c is still useful, but
>testing with the -hcd variants is the most ideal since that will be the
>final code base.
Ok. Here is feedback on 2.5.17 uhci-hcd and usb-uhci-hcd.
I did not notice any difference in behavior. Both have the same
performance, just like 2.4.19-pre8.
One-shot interrupt transfers are broken in *-hcd drivers. core/hcd.c
returns EINVAL if urb->interval==0.
My Broadcom FW loader (uses usbdevfs) needs one-shot interrupts. So in
order to test Broadcom devices
I changed to hcd.c to allow urb->interval==0. With that change uhci-hcd
works just fine, I can load fw and
use the device. But usb-uhci-hcd kills the machine pretty hard (hw reset
needed).
Here is a patch for hcd.c.
--- hcd.c.orig Tue May 21 17:50:09 2002
+++ hcd.c Tue May 21 17:01:44 2002
@@ -1456,11 +1456,9 @@
* supports different values... this uses EHCI/UHCI defaults (and
* EHCI can use smaller non-default values).
*/
- switch (temp) {
- case PIPE_ISOCHRONOUS:
- case PIPE_INTERRUPT:
+ if (urb->interval && (temp == PIPE_ISOCHRONOUS || temp ==
PIPE_INTERRUPT)) {
/* too small? */
- if (urb->interval <= 0)
+ if (urb->interval < 0)
return -EINVAL;
/* too big? */
switch (urb->dev->speed) {
usb-uhci-hcd has to be fixed.
btw It tries to round interval value even thought it's done by hcd.c
So, Bluetooth USB devices should work fine with either usb-uhci-hcd or
uhci-hcd.
(assuming that above patch is applied and one-shot is fixed in usb-uhci-hcd)
On a side note. Why are URBs still not SLABified ?
Drivers still have those silly urb pools and stuff. I thought you guys were
gonna fix that.
Max
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
