Re: [PATCH v3 0/5] Add support for SW babble Control
Hi Bin,
On 5/15/2014 8:49 PM, Bin Liu wrote:
George,
On Thu, May 15, 2014 at 1:28 AM, George Cherian george.cher...@ti.com wrote:
Hi Bin,
On 5/14/2014 10:13 PM, Bin Liu wrote:
George,
On Wed, May 14, 2014 at 9:34 AM, Bin Liu binml...@gmail.com wrote:
George,
On Wed, May 14, 2014 at 12:37 AM, George Cherian george.cher...@ti.com
wrote:
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com
wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the
MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c
b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions
when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without
an
IP
reset .
2) Babble condition - which could be recovered from only by doing an
IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting
the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as
of
now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL
value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP
core.
How do you test babble errors, is there any way to force them to
happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?
You don't have to resend the patches. Nishanth Menon showed me a way
to extract the patch from Gmail - Thanks Nishanth.
But which repo do you want to me test with? The first patch ([PATCH v2
1/5] usb: musb: core: Convert babble recover work to delayed work)
does not apply to v3.15-rc4 tag. the current musb_core.c does not have
the recovery work for musb. Please let me know what I missed.
Oops I missed to mention the same.
Please try on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
The test is done. The babble always causes STUCK_J is reset,
MUSB_BABBLE_CTL is 0x44 or 0x4. MUSB reset happens.
Thankyou Bin for the help.
Can I get a Tested-by from you?
Do you think when re-start happens the driver should print a message
on console saying re-start due to babble? It would help debug the
babble problems while the dynamic debug is off.
It prints out a message saying babble condition occured.
More over, it re-enumerates all the devices connected as part of Musb
re-start.
Don't you think that is sufficient enough ?
Thanks,
-Bin.
Thanks,
-Bin.
I read these linux-usb emails in Gmail, and am not aware of any easy
way to extract patches from Gmail.
BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB never restarts.
Thanks,
-Bin.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble
interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Re: [PATCH v3 0/5] Add support for SW babble Control
Hi George,
On Mon, May 19, 2014 at 3:40 AM, George Cherian george.cher...@ti.com wrote:
Hi Bin,
On 5/15/2014 8:49 PM, Bin Liu wrote:
George,
On Thu, May 15, 2014 at 1:28 AM, George Cherian george.cher...@ti.com
wrote:
Hi Bin,
On 5/14/2014 10:13 PM, Bin Liu wrote:
George,
On Wed, May 14, 2014 at 9:34 AM, Bin Liu binml...@gmail.com wrote:
George,
On Wed, May 14, 2014 at 12:37 AM, George Cherian
george.cher...@ti.com
wrote:
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian
george.cher...@ti.com
wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the
MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c
b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result
as
without the patch: a full glue reset is conducted. Do I get you
right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions
when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from
without
an
IP
reset .
2) Babble condition - which could be recovered from only by doing an
IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting
the
same).
Case 1 is really hard to reproduce. I don't have a reliable method
as
of
now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL
value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP
core.
How do you test babble errors, is there any way to force them to
happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?
You don't have to resend the patches. Nishanth Menon showed me a way
to extract the patch from Gmail - Thanks Nishanth.
But which repo do you want to me test with? The first patch ([PATCH v2
1/5] usb: musb: core: Convert babble recover work to delayed work)
does not apply to v3.15-rc4 tag. the current musb_core.c does not have
the recovery work for musb. Please let me know what I missed.
Oops I missed to mention the same.
Please try on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
The test is done. The babble always causes STUCK_J is reset,
MUSB_BABBLE_CTL is 0x44 or 0x4. MUSB reset happens.
Thankyou Bin for the help.
Can I get a Tested-by from you?
Yes, sure.
Do you think when re-start happens the driver should print a message
on console saying re-start due to babble? It would help debug the
babble problems while the dynamic debug is off.
It prints out a message saying babble condition occured.
That is good, but I think we also want to know the babble type - the
controller is reset or not.
More over, it re-enumerates all the devices connected as part of Musb
re-start.
Sometimes the custom board has hw or sw issue, for example USB
basically does not functional, maybe after babble there is no
re-enumeration, then we cannot tell if controller reset happened or
not from the log. I think a specific message telling that will
helpful.
Regards,
-Bin.
Don't you think that is sufficient enough ?
Thanks,
-Bin.
Thanks,
-Bin.
I read these linux-usb emails in Gmail, and am not aware of any easy
way to extract patches from Gmail.
BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB
Re: [PATCH v3 0/5] Add support for SW babble Control
Hi Bin,
On 5/14/2014 10:13 PM, Bin Liu wrote:
George,
On Wed, May 14, 2014 at 9:34 AM, Bin Liu binml...@gmail.com wrote:
George,
On Wed, May 14, 2014 at 12:37 AM, George Cherian george.cher...@ti.com wrote:
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com
wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c
b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an
IP
reset .
2) Babble condition - which could be recovered from only by doing an IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of
now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?
You don't have to resend the patches. Nishanth Menon showed me a way
to extract the patch from Gmail - Thanks Nishanth.
But which repo do you want to me test with? The first patch ([PATCH v2
1/5] usb: musb: core: Convert babble recover work to delayed work)
does not apply to v3.15-rc4 tag. the current musb_core.c does not have
the recovery work for musb. Please let me know what I missed.
Oops I missed to mention the same.
Please try on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
Thanks,
-Bin.
I read these linux-usb emails in Gmail, and am not aware of any easy
way to extract patches from Gmail.
BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB never restarts.
Thanks,
-Bin.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
-George
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add support for SW babble Control
George,
On Thu, May 15, 2014 at 1:28 AM, George Cherian george.cher...@ti.com wrote:
Hi Bin,
On 5/14/2014 10:13 PM, Bin Liu wrote:
George,
On Wed, May 14, 2014 at 9:34 AM, Bin Liu binml...@gmail.com wrote:
George,
On Wed, May 14, 2014 at 12:37 AM, George Cherian george.cher...@ti.com
wrote:
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com
wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the
MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c
b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions
when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without
an
IP
reset .
2) Babble condition - which could be recovered from only by doing an
IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting
the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as
of
now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL
value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP
core.
How do you test babble errors, is there any way to force them to
happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?
You don't have to resend the patches. Nishanth Menon showed me a way
to extract the patch from Gmail - Thanks Nishanth.
But which repo do you want to me test with? The first patch ([PATCH v2
1/5] usb: musb: core: Convert babble recover work to delayed work)
does not apply to v3.15-rc4 tag. the current musb_core.c does not have
the recovery work for musb. Please let me know what I missed.
Oops I missed to mention the same.
Please try on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
The test is done. The babble always causes STUCK_J is reset,
MUSB_BABBLE_CTL is 0x44 or 0x4. MUSB reset happens.
Do you think when re-start happens the driver should print a message
on console saying re-start due to babble? It would help debug the
babble problems while the dynamic debug is off.
Thanks,
-Bin.
Thanks,
-Bin.
I read these linux-usb emails in Gmail, and am not aware of any easy
way to extract patches from Gmail.
BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB never restarts.
Thanks,
-Bin.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble
interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap
in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH v3 0/5] Add support for SW babble Control
George,
On Wed, May 14, 2014 at 12:37 AM, George Cherian george.cher...@ti.com wrote:
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com
wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c
b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an
IP
reset .
2) Babble condition - which could be recovered from only by doing an IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of
now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?
I read these linux-usb emails in Gmail, and am not aware of any easy
way to extract patches from Gmail.
BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB never restarts.
Thanks,
-Bin.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add support for SW babble Control
George,
On Wed, May 14, 2014 at 9:34 AM, Bin Liu binml...@gmail.com wrote:
George,
On Wed, May 14, 2014 at 12:37 AM, George Cherian george.cher...@ti.com
wrote:
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com
wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c
b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an
IP
reset .
2) Babble condition - which could be recovered from only by doing an IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of
now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?
You don't have to resend the patches. Nishanth Menon showed me a way
to extract the patch from Gmail - Thanks Nishanth.
But which repo do you want to me test with? The first patch ([PATCH v2
1/5] usb: musb: core: Convert babble recover work to delayed work)
does not apply to v3.15-rc4 tag. the current musb_core.c does not have
the recovery work for musb. Please let me know what I missed.
Thanks,
-Bin.
I read these linux-usb emails in Gmail, and am not aware of any easy
way to extract patches from Gmail.
BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB never restarts.
Thanks,
-Bin.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/5] Add support for SW babble Control
Series add support for SW babble control logic found in new silicon versions of AM335x. Runtime differentiation of silicon version is done by checking the BABBLE_CTL register. For newer silicon the register default value read is 0x4 and for older versions its 0x0. Patch 1 - Convert recover work to delayed work. Patch 2 - usb_phy_vbus_(off/_on) are NOPs for am335x PHY so use usb_phy(_shutdown/_init) in musb_platform_reset() Patch 3 - Add return value for musb_platform_reset() in prepration to support SW babble_ctrl Patch 4 - Add the sw_babble_control() Patch 5 - Enable sw babble control for newer silicon v2 - v3 : Modify musb_platform_reset() to return zero on success. v1 - v2 : Fixed the issue with Patch 5. In v1 it was not calling sw_babble_control(). George Cherian (5): usb: musb: core: Convert babble recover work to delayed work usb: musb: dsps: Call usb_phy(_shutdown/_init) during musb_platform_reset() usb: musb: core: Convert the musb_platform_reset to have a return value. usb: musb: dsps: Add the sw_babble_control() usb: musb: dsps: Enable sw babble control for newer silicon drivers/usb/musb/musb_core.c | 49 ++ drivers/usb/musb/musb_core.h | 12 --- drivers/usb/musb/musb_dsps.c | 83 ++-- drivers/usb/musb/musb_regs.h | 7 4 files changed, 121 insertions(+), 30 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add support for SW babble Control
Hi George, On 05/13/2014 10:31 AM, George Cherian wrote: Series add support for SW babble control logic found in new silicon versions of AM335x. Runtime differentiation of silicon version is done by checking the BABBLE_CTL register. For newer silicon the register default value read is 0x4 and for older versions its 0x0. I tested this on a AM33xx platform and don't see any regression at least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE. Anything particular you want me to test as well? Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add support for SW babble Control
On 5/13/2014 3:16 PM, Daniel Mack wrote: Hi George, On 05/13/2014 10:31 AM, George Cherian wrote: Series add support for SW babble control logic found in new silicon versions of AM335x. Runtime differentiation of silicon version is done by checking the BABBLE_CTL register. For newer silicon the register default value read is 0x4 and for older versions its 0x0. I tested this on a AM33xx platform and don't see any regression at least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE. Anything particular you want me to test as well? Are you seeing a wrapper restart done always or does it continue with a restart after the babble condition? You can check for musb_hdrc: setup fifo_mode 4 prints . Thanks, Daniel -- -George -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add support for SW babble Control
On 05/13/2014 01:57 PM, George Cherian wrote: On 5/13/2014 3:16 PM, Daniel Mack wrote: On 05/13/2014 10:31 AM, George Cherian wrote: Series add support for SW babble control logic found in new silicon versions of AM335x. Runtime differentiation of silicon version is done by checking the BABBLE_CTL register. For newer silicon the register default value read is 0x4 and for older versions its 0x0. I tested this on a AM33xx platform and don't see any regression at least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE. Anything particular you want me to test as well? Are you seeing a wrapper restart done always or does it continue with a restart after the babble condition? MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE, so sw_babble_control() is called from dsps_musb_reset(). However, MUSB_BABBLE_CTL still returns 0x04 (MUSB_BABBLE_RCV_DISABLE) inside that function, which means (babble_ctl MUSB_BABBLE_STUCK_J) is false, and hence sw_babble_control() returns 1. Consequently, the glue is fully reset in this case. Does this help? FWIW, this is the output of dsps_musb_reset() with dev_dbg() enabled: [ 54.066124] CAUTION: musb: Babble Interrupt Occurred [ 54.071856] usb 1-1: USB disconnect, device number 8 [ 54.159495] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 4 [ 54.166446] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset I only have one exact USB device to reproduce the babble condition, so I guess this is all I can do for now. Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add support for SW babble Control
On 5/13/2014 5:50 PM, Daniel Mack wrote:
On 05/13/2014 01:57 PM, George Cherian wrote:
On 5/13/2014 3:16 PM, Daniel Mack wrote:
On 05/13/2014 10:31 AM, George Cherian wrote:
Series add support for SW babble control logic found in
new silicon versions of AM335x. Runtime differentiation of
silicon version is done by checking the BABBLE_CTL register.
For newer silicon the register default value read is 0x4 and
for older versions its 0x0.
I tested this on a AM33xx platform and don't see any regression at
least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE.
Anything particular you want me to test as well?
Are you seeing a wrapper restart done always or does it continue with a
restart
after the babble condition?
MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE, so sw_babble_control() is
called from dsps_musb_reset(). However, MUSB_BABBLE_CTL still returns
0x04 (MUSB_BABBLE_RCV_DISABLE) inside that function, which means
(babble_ctl MUSB_BABBLE_STUCK_J) is false, and hence
sw_babble_control() returns 1.
Ah Missed a critical portion
My bad...
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
-- 1.8.3.1
I will resend the series, if this works fine.
Thanks for all your help.
Consequently, the glue is fully reset in
this case. Does this help?
FWIW, this is the output of dsps_musb_reset() with dev_dbg() enabled:
[ 54.066124] CAUTION: musb: Babble Interrupt Occurred
[ 54.071856] usb 1-1: USB disconnect, device number 8
[ 54.159495] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 4
[ 54.166446] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I only have one exact USB device to reproduce the babble condition, so I
guess this is all I can do for now.
Same with me also . I also have only one device with which i get the issue.
Thanks,
Daniel
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add support for SW babble Control
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add support for SW babble Control
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an
IP reset .
2) Babble condition - which could be recovered from only by doing an IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of
now to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
There is no 100% reliable method to force it to happen. Following is
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add support for SW babble Control
On 05/13/2014 03:24 PM, George Cherian wrote: Basically, there are 2 types of babble conditions. 1) Transient babble condition - which could be recovered from without an IP reset . 2) Babble condition - which could be recovered from only by doing an IP reset. Ok, thanks for the explanation. Looks like you are always hitting case 2 (Most times am also hitting the same). Seems like, yes. There is no 100% reliable method to force it to happen. Following is my setup , I have a HUB with 4 devices connected , which gives me a Babble interrupt on both connects and disconnects ( Not always though). I also get them at disconnects, but only with one specific USB device. But as I don't ever see case 1) above, I can't say if your approach works. What I can say, though, is that your patches don't break the recovery from babble conditions that I experienced :) Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add support for SW babble Control
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an IP
reset .
2) Babble condition - which could be recovered from only by doing an IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add support for SW babble Control
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an IP
reset .
2) Babble condition - which could be recovered from only by doing an IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
