USB Babble Interrupt in AM3352 connected to Microchip USB2513B hub

Hi Joebel,

I will forward this to the support team, but since you say the project is sensitive it would be best to exchange information with them via e-mail.

Hi Biser,

Thanks for the prompt response. I agree. If they can send me an email, I can link them up to the discussion with the existing TI team who are supporting us right now. 

Mukul,

I'd presume Doug have as well forwarded to you the trail of email discussions.  You may reply to that for the offline discussion or you can send me an email privately so I can link your team.  You will also find there some scope captures as well as snippets of the protocol analysis we've done together with local TI and Microchip support team.

We would like to set a tentative end date for the resolution of this issue or at least identify the root cause so that our pending design could move forward.  Do you think you can provide that?

Joebel,

I'm the engineer directly responsible for working this issue currently. I'm looped into the email discussions and have access to the referenced scope captures and protocol analysis.

I have been able to repro the issue locally and am working to provide the items you request here, but unfortunately I cannot provide a schedule for these. This is a previously unreported issue so driving to root-cause just isn't something I (or anyone) can put a time frame on. I can say that this issue is a priority for me/us and that we are working it as such. I'll be in touch when we have more.

-DK

DK,

I'm glad that we are now aligned with the previous findings from our side related to this issue.  In the meantime, we look forward to your updates and eventually the closure of this investigation.

Here is the patch:

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 85f7257..2c28a30 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2366,7 +2366,7 @@ static int musb_runtime_resume(struct device *dev)
        if (musb->need_finish_resume) {
                musb->need_finish_resume = 0;
                schedule_delayed_work(&musb->finish_resume_work,
-                               msecs_to_jiffies(20));
+                               msecs_to_jiffies(40));
        }
 
        return 0;

Joebel,

Sorry, I think I sent this patch too quick.

The patch above very likely will not be directly applicable to you, it is based on TI 3.14 kernel, and a patch I submitted to mainline (3.20) a couple weeks ago.

First could you please remind me which SDK/kernel version do you use? I will make a patch for your specific kernel version.

Joebel,

The following patch fixes the resume issue for SDK7.0 kernel.

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 96f2c92..6781b93 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -509,7 +509,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 int_usb,
                                                (USB_PORT_STAT_C_SUSPEND << 16)
                                                | MUSB_PORT_STAT_RESUME;
                                musb->rh_timer = jiffies
-                                               + msecs_to_jiffies(20);
+                                               + msecs_to_jiffies(40);
 
                                musb->xceiv->state = OTG_STATE_A_HOST;
                                musb->is_active = 1;

Joebel Sorioso said:

The kernel we use was taken from TI kernel tree version 3.12.17

Can you please provide the commit ID from which you checked out the 3.12.17 kernel? Is it "2acf1c2 Linux 3.12.17"? We will only support the kernels in TI official SDK releases, not intermediate commit in TI kernel tree. The tree has many merges from upstream kernels, so very likely any intermediate commit could point to the upstream which does not have any TI submitted patches.

Joebel,

Joebel Sorioso said:

Commit id is f0d4672: Merge tag 'v3.12.17'

Ok, then my patch above for sdk7.0 should fix the issue. Please validate it.