[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141118211734.GA19146@saruman>
Date: Tue, 18 Nov 2014 15:17:34 -0600
From: Felipe Balbi <balbi@...com>
To: George Cherian <george.cherian@...com>
CC: <balbi@...com>, <gregkh@...uxfoundation.org>,
<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<bigeasy@...utronix.de>
Subject: Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is
fully handled
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@...com>
> Signed-off-by: George Cherian <george.cherian@...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
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists