On Fri, Nov 14, 2014 at 01:54:46PM +0530, George Cherian wrote: > Disable the MUSB interrupts till MUSB is recovered fully from BABBLE > condition. There are chances that we could get multiple interrupts > till the time the babble recover work gets scheduled. Sometimes > this could even end up in an endless loop making MUSB itself unusable. > > Reported-by: Felipe Balbi <ba...@ti.com> > Signed-off-by: George Cherian <george.cher...@ti.com>
while this helps the situation it doesn't solve the problem I'm having
with testusb on BBB when host port is connected to peripheral port on
the same BBB.
I still have:
# ./testusb -t 13 -c 10 -s 2048 -a
unknown speed /dev/bus/usb/002/004 0
[ 114.811407] usbtest 2-1:3.0: set altsetting to 0 failed, -71
/dev/bus/usb/002/004 test 13 --> 71 (error 71)
[ 114.862387] CAUTION: musb: Babble Interrupt Occurred
[ 114.868132] usb 2-1: USB disconnect, device number 4
[ 114.961491] musb-hdrc musb-hdrc.1.auto: Restarting MUSB to recover from
Babble
[ 115.430829] usb 2-1: new high-speed USB device number 5 using musb-hdrc
[ 115.573471] zero gadget: high-speed config #3: source/sink
[ 115.584014] usbtest 2-1:3.0: Linux gadget zero
[ 115.588682] usbtest 2-1:3.0: high-speed {control in/out bulk-in bulk-out}
tests (+alt)
I think the driver is mis-detecting Babble. A babble only occurs when
the device side tries to move data without the host asking for anything.
--
balbi
signature.asc
Description: Digital signature
