Felipe,
On Tue, Nov 18, 2014 at 3:17 PM, Felipe Balbi <balbi@xxxxxx> wrote:
> 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 <balbi@xxxxxx>
>> Signed-off-by: George Cherian <george.cherian@xxxxxx>
>
> 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.
Try to find a BB white (which has rev 1.0 SoC) to see if babble still
happens, this could be PHY hw issue.
Regards,
-Bin.
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
