OMAP-L138: CPPI DMA with MUSB

Hi Muhammad,

I've forwarded this to the experts. Their feedback should be posted here.

BR
Tsvetolin Shulev

Thanks for your swift response. That's why I love posting my queries on e2e forum.

I have one more question. Do you guys guarantee functionality after the workarounds are implemented? I have all above workarounds done in my driver but still I am not able to make CPPI DMA work.
I did another experiment. In my USBH device, Endpoint0 and one BULK-IN and one BULK-OUT endpoints are active. BULK-IN and BULK-OUT endpoints use CPPI DMA. If I enable double buffering support for control endpoint (EP0), the occasional timeouts go away and Ethernet starts working perfectly but after some time (around 3-4 minutes), same lockup happens again and all the activity stops. Processor keeps on receiving interrupts but status register reads 0. Any guesses on this?

Umair

Hi,

Do you guys guarantee functionality after the workarounds are implemented?

The workarounds are tested & should guarantee that the interface works properly.

As for the problem you experience, I'll notify the chip designers to elaborate.

Best Regards,
Yordan

Thanks

Waiting for your reply,
Umair

Any updates on this?

Umair

Hi Umair,

I've not received feedback yet. I've escalated this internally.

Best Regards,
Yordan

Hi
I am not aware of any specific bugs/erratas listed that require disabling the i/d cache to work around.
can you clarify what SDK/software/kernel you are using

You mention ethernet in conjunction with USB - is it so that the issue does not occur when it is stand alone USB and only happens when ethernet traffic is there?

When you say lock up - can you further elaborate - what error messages/logs - and does the issue once locked up go away again if you disable ethernet traffic? Trying to make sure you do not have some sort of a Interrupt mapping , handling issue?

Hi Mukul,

The symptoms I described are just my observations. I am using a proprietary software.

Yes, this issue appears when using ECM class with USBH.

I got this term "lock-up" from one of TI's Linux commits where it is described as a situation when CPPI DMA becomes unresponsive. What I am having is also similar to this. Sometimes there is no interrupt at all and status register doesn't raise any error flag too. Sometimes, USB interrupts keep on triggering with status register reading zero (no pending interrupt).

If you want any register dumps at the time of, so called, lock-up, I can provide that. 

Thanks,

Umair

Ok thanks. We have a new SDK released planned with kernel v4.4 and the system stress test is on going with CPPI DMA , I will let you know if we find any issues related to the patches you mentioned.
Like I said before I am not aware of any issues other than the ones in the silicon errata and am not aware of any issues that require the work around to be to disable the i and d cache.

Since you say you are using proprietary software is it Linux, SYSBIOS or bare metal ? It would be good to ensure that you do not have any issues with interrupt management with multiple masters (like EMAC and USB) or some sort of timing issue that is getting masked when you disable caches.

Can you confirm that without ethernet in picture you do not see an issue?

This is with Mentor Nucleus RTOS. Muhammad Umair Khan - did you check without Ethernet as suggested by Mukul Bhatnagar ?

Sorry I haven't tried it yet, I was in middle of another task. I'll try it out on Monday and will give the update.

Umair

Hi Umair

I did want to also update that system regressions with kernel v4.4 using MUSB DMA did not show an issue for mass storarge, audio, WIFI testing etc. 

We will also see if we can test USB-ECM.  So I don't see you are running into any processor level issues or silicon bugs. 

Regards

Mukul 

Started working on it today. Will leave an update here as soon as I finish.

Umair

Hi Mukul,
I did some stress testing with mass storage class and I didn't see any "lockup".

Thanks,
Umair