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 <[email protected]>
Signed-off-by: George Cherian <[email protected]>
---
drivers/usb/musb/musb_core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3345c94..992c768 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -423,6 +423,7 @@ void musb_hnp_stop(struct musb *musb)
musb->port1_status &= ~(USB_PORT_STAT_C_CONNECTION << 16);
}
+static void musb_generic_disable(struct musb *musb);
/*
* Interrupt Service Routine to record USB "global" interrupts.
* Since these do not happen often and signify things of
@@ -846,9 +847,11 @@ b_host:
}
/* handle babble condition */
- if (int_usb & MUSB_INTR_BABBLE && is_host_active(musb))
+ if (int_usb & MUSB_INTR_BABBLE && is_host_active(musb)) {
+ musb_generic_disable(musb);
schedule_delayed_work(&musb->recover_work,
msecs_to_jiffies(100));
+ }
#if 0
/* REVISIT ... this would be for multiplexing periodic endpoints, or
--
1.8.3.1
On 11/14/2014 09:24 AM, 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.
How do you trigger the babble error? Is this something that happens
during suspend resume, plugging / unplugging a device or randomly while
the device is used?
Sebastian
On 11/14/2014 02:12 PM, Sebastian Andrzej Siewior wrote:
> On 11/14/2014 09:24 AM, 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.
> How do you trigger the babble error? Is this something that happens
> during suspend resume, plugging / unplugging a device or randomly while
> the device is used?
I have never seen this error while device is successfully enumerated
and while working fine.
Mostly u get it when we connect/disconnect devices to HOST port.
Normally I use the following for testing BABBLE
- Especially when a fully loaded USB HUB getting connected to HOST port.
- Or repeatedly load and unload musb_hdrc.ko with some device connected.
If nothing of the above work you might be the lucky one to have a good
board!!!!
>
> Sebastian
>
On Fri, Nov 14, 2014 at 02:41:57PM +0530, George Cherian wrote:
>
> On 11/14/2014 02:12 PM, Sebastian Andrzej Siewior wrote:
> >On 11/14/2014 09:24 AM, 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.
> >How do you trigger the babble error? Is this something that happens
> >during suspend resume, plugging / unplugging a device or randomly while
> >the device is used?
> I have never seen this error while device is successfully enumerated and
> while working fine.
> Mostly u get it when we connect/disconnect devices to HOST port.
> Normally I use the following for testing BABBLE
> - Especially when a fully loaded USB HUB getting connected to HOST port.
> - Or repeatedly load and unload musb_hdrc.ko with some device connected.
>
> If nothing of the above work you might be the lucky one to have a good
> board!!!!
if you have a BBB, connect host port to device port, load g_zero and run
any of testusb test cases.
--
balbi
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 <[email protected]>
> Signed-off-by: George Cherian <[email protected]>
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
Felipe,
On Tue, Nov 18, 2014 at 3:17 PM, Felipe Balbi <[email protected]> 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 <[email protected]>
>> Signed-off-by: George Cherian <[email protected]>
>
> 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
On Tue, Nov 18, 2014 at 06:44:39PM -0600, Bin Liu wrote:
> Felipe,
>
> On Tue, Nov 18, 2014 at 3:17 PM, Felipe Balbi <[email protected]> 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 <[email protected]>
> >> Signed-off-by: George Cherian <[email protected]>
> >
> > 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.
it only happens with my BBB when peripheral port is connected straight
to host port. If I use another board as g_zero, then tests work just
fine.
If someone else can confirm this is the case with their board, I'd be
happy.
--
balbi
On 11/18/2014 10:17 PM, Felipe Balbi wrote:
> 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.
Exactly. On the same device. I see the same problem if I connect host
to peripheral port on am335x-evm (as well as on BBB). I don't see this
if I connect cross-connect am335x-evm and BBB (no matter who plays
host).
> 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.
You receive a "set altsetting to 0 failed, -71" before you see the
babble. So either host or the device is not responding well. Too bad
both is on the same HW.
It might be, that the host is in sleep and it is not ready early enough.
I think that this somehow PM related because If I disable
CONFIG_PM_RUNTIME I don't see the problem anymore. So the babble event
looks valid even if under strange conditions.
And yes, the patch fixes the endless "Babble Interrupt" message and it
makes sense to keep the interrupts disabled until the device recovers
from the babble trouble.
Sebastian
On 11/18/2014 10:17 PM, Felipe Balbi wrote:
> 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.
It also occurs if the device moves more than packet_size bytes. Not
really helping, I know?
Sebastian
On Mon, Nov 24, 2014 at 06:49:50PM +0100, Sebastian Andrzej Siewior wrote:
> On 11/18/2014 10:17 PM, Felipe Balbi wrote:
> > 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.
>
> It also occurs if the device moves more than packet_size bytes. Not
> really helping, I know…
hmm, why would the device move more than wMaxPacketSize at a time ?
That's certainly babble :-) We *must* move data in the wire in
<=wMaxPacketSize chunks.
--
balbi
Felipe Balbi wrote:
> > > A babble only occurs when
> > > the device side tries to move data without the host asking for anything.
> >
> > It also occurs if the device moves more than packet_size bytes. Not
> > really helping, I know…
>
> hmm, why would the device move more than wMaxPacketSize at a time ?
Some devices are buggy.
> That's certainly babble :-)
Certainly! But musb shouldn't fall over or lock up because of it, should it?
//Peter
On 11/24/2014 09:39 PM, Peter Stuge wrote:
> Felipe Balbi wrote:
>>>> A babble only occurs when
>>>> the device side tries to move data without the host asking for anything.
>>>
>>> It also occurs if the device moves more than packet_size bytes. Not
>>> really helping, I know…
>>
>> hmm, why would the device move more than wMaxPacketSize at a time ?
>
> Some devices are buggy.
for instance if the device comes out of resume and the clock is not yet
stable but the device sends data. That is not the case here, but an
example :)
I *think* for some reason the host did not really receive ep0
set_config request as planned. And device's answer is probably then
interpreted as data which is not expected (as Felipe said "device side
tries to move data without the host asking for anything").
>> That's certainly babble :-)
>
> Certainly! But musb shouldn't fall over or lock up because of it, should it?
No and the patch fixes the issue. The strange thing is that it only
happens on the same device. Not if you connect host<->device with two
boards.
> //Peter
>
Sebastian
On Mon, Nov 24, 2014 at 09:56:28PM +0100, Sebastian Andrzej Siewior wrote:
> On 11/24/2014 09:39 PM, Peter Stuge wrote:
> > Felipe Balbi wrote:
> >>>> A babble only occurs when
> >>>> the device side tries to move data without the host asking for anything.
> >>>
> >>> It also occurs if the device moves more than packet_size bytes. Not
> >>> really helping, I know…
> >>
> >> hmm, why would the device move more than wMaxPacketSize at a time ?
> >
> > Some devices are buggy.
>
> for instance if the device comes out of resume and the clock is not yet
> stable but the device sends data. That is not the case here, but an
> example :)
that would be a bug on clk driver, it shouldn't return control to the
user until clk *is* stable :-)
> I *think* for some reason the host did not really receive ep0
> set_config request as planned. And device's answer is probably then
> interpreted as data which is not expected (as Felipe said "device side
> tries to move data without the host asking for anything").
that's definitely a bug, unfortunately I can't think of any Erratum
right now.
> >> That's certainly babble :-)
> >
> > Certainly! But musb shouldn't fall over or lock up because of it,
> > should it?
>
> No and the patch fixes the issue. The strange thing is that it only
> happens on the same device. Not if you connect host<->device with two
> boards.
probably some crap going on within the interconnect when both instances
are used.
--
balbi
On 11/25/2014 02:09 AM, Felipe Balbi wrote:
>
>> I *think* for some reason the host did not really receive ep0
>> set_config request as planned. And device's answer is probably then
>> interpreted as data which is not expected (as Felipe said "device side
>> tries to move data without the host asking for anything").
>
> that's definitely a bug, unfortunately I can't think of any Erratum
> right now.
maybe there will be a new one :)
>>>> That's certainly babble :-)
>>>
>>> Certainly! But musb shouldn't fall over or lock up because of it,
>>> should it?
>>
>> No and the patch fixes the issue. The strange thing is that it only
>> happens on the same device. Not if you connect host<->device with two
>> boards.
>
> probably some crap going on within the interconnect when both instances
> are used.
Either that or something is synchronized since both instances use
probably the same clock source. But there is definitely something
switched off since it does not happen without PM enabled.
Sebastian
Hi,
On Tue, Nov 25, 2014 at 09:24:46AM +0100, Sebastian Andrzej Siewior wrote:
> On 11/25/2014 02:09 AM, Felipe Balbi wrote:
> >
> >> I *think* for some reason the host did not really receive ep0
> >> set_config request as planned. And device's answer is probably then
> >> interpreted as data which is not expected (as Felipe said "device side
> >> tries to move data without the host asking for anything").
> >
> > that's definitely a bug, unfortunately I can't think of any Erratum
> > right now.
>
> maybe there will be a new one :)
maybe :-)
> >>>> That's certainly babble :-)
> >>>
> >>> Certainly! But musb shouldn't fall over or lock up because of it,
> >>> should it?
> >>
> >> No and the patch fixes the issue. The strange thing is that it only
> >> happens on the same device. Not if you connect host<->device with two
> >> boards.
> >
> > probably some crap going on within the interconnect when both instances
> > are used.
> Either that or something is synchronized since both instances use
> probably the same clock source. But there is definitely something
> switched off since it does not happen without PM enabled.
ok, then we can blame somebody else. Good. We're off the hook, next!
I think it might be wise to look at which clocks the USB block is using
and making sure drivers/clk/ti/ waits for clocks to be stable before
returning control to caller.
cheers ;-)
--
balbi