Johannes (or anyone else who can help):
I could use some advice on tracking this problem down. You can follow the entire discussion in the thread going forward from
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=107550399505642&w=2
Basically the problem goes like this. The device (a digital camera) sends a babble reply to a bulk-in transfer, and after that the host controller doesn't seem to do anything. In particular, it doesn't raise any interrupt requests, even after uhci_set_next_interrupt(). Note that the controller is still running (the Run-Stop bit in the USBCMD register is set) and the schedule is not corrupted at all. And interrupt routing is okay, because USB transfers worked correctly prior to the babble occurrence.
The email thread shows that detailed debugging that justifies these conclusion. Furthermore, several people have reported similar problems. The real questions are: Is this actually a fault in the controller hardware? And if it is, how can we work around it?
It's not a bug, it's a feature: VIA UHCI controllers turn themselves off after bable. HC_RESET is the only way to get them going again.
I've got a USB card-reader which babbles on card-removal.
changes along the line of
if( status & TD_CTRL_BABBLE ){
reset_hc();
...
}
hacked into uhci_hcd.c::hacked into uhci_map_status() result in enumeration after babble, but keep the entire usb system running.
- sda
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
