Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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 signature.asc Description: Digital signature
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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/0040
[ 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
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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 signature.asc Description: Digital signature
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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 pgpIA7n8PbrzV.pgp Description: PGP signature
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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 signature.asc Description: Digital signature
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 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/0040
[ 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
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
Felipe,
On Tue, Nov 18, 2014 at 3:17 PM, Felipe Balbi ba...@ti.com 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 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.
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/0040
[ 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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 ba...@ti.com 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 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. 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 signature.asc Description: Digital signature
[PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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
---
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
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
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 signature.asc Description: Digital signature
