Why L138 USB2.0 controller can not work in USB1.1 mode when enable CPPI

David,

USB2.0 port is backward compatible with usb1.1.  Just plug the cable to a PC (usb2.0/usb1.1) usb port and it would switch accordingly to the correct speed.  We have tested the ping test in RNDIS mode and do not see any issues.  Can you confirm that you have used the defconfig/configured or enabled the correct configs w.r.t USB2.0 port?

regards

swami

Hi swami,

My software version is  DaVinci-PSP-SDK-03.20.00.12, I config USB2.0 controller to periipheral mode,not OTG

CONFIG_USB_MUSB_PERIPHERAL=y
CONFIG_USB_GADGET_MUSB_HDRC=y

then I change function "musb_start" in drivers/usb/musb_core.c to force USB2.0 controller to work in USB1.1 mode  

                                                /*| MUSB_POWER_HSENAB*/           (disable this line to force controller to USB1.1 mode)
                                                /* ENSUSPEND wedges tusb */
                                                /* | MUSB_POWER_ENSUSPEND */

build kernel and test, you can found packe loss and delay is too long.

# ping 192.168.30.30
PING 192.168.30.30 (192.168.30.30): 56 data bytes
64 bytes from 192.168.30.30: seq=0 ttl=128 time=1006.924 ms
64 bytes from 192.168.30.30: seq=1 ttl=128 time=1002.872 ms
64 bytes from 192.168.30.30: seq=2 ttl=128 time=1003.032 ms
64 bytes from 192.168.30.30: seq=3 ttl=128 time=1002.995 ms
64 bytes from 192.168.30.30: seq=4 ttl=128 time=1003.025 ms
64 bytes from 192.168.30.30: seq=5 ttl=128 time=1003.074 ms
64 bytes from 192.168.30.30: seq=6 ttl=128 time=1002.990 ms
64 bytes from 192.168.30.30: seq=7 ttl=128 time=1001.856 ms
64 bytes from 192.168.30.30: seq=8 ttl=128 time=1003.169 ms
64 bytes from 192.168.30.30: seq=9 ttl=128 time=1003.115 ms
^C
--- 192.168.30.30 ping statistics ---
11 packets transmitted, 10 packets received, 9% packet loss
round-trip min/avg/max = 1001.856/1003.305/1006.924 ms

David,

Pl. do not do any modifications to the code.  As I mentioned if you connect the cable to the PS Full Speed USB port L138 will automatically come up as a FS device.  Pl. do the testing in that configuration.

Also can you provide dmesg log also?

regards

swami

swami,

I understand what you mean, the USB2.0 controller can work with usb1.1 port. But because there are some hardware limitation on board we manufactured, we must force usb2.0 controller to work only in usb1.1 mode, even if it connect to a USB2.0 port of PC, so we changed the code.

Is there a way to force Full Speed Mode (with DMA support) even when connected to USB 2.0 port?

Roberto,

Could you confirm whether DMA works in USB1.1 mode without changing the code in the driver?

regards

swami

Swami,

Do you mean connect the USB cable to a USB1.1 port  of PC, if yes, we have test it, it works, but there some packets lost when with RNDIS

David,

If by connecting to a PC usb1.1 port things work (when the controller is in 2.0 mode) I do not believe the issue to be related to software.  Could you get your usb board design validated?  Removing the HSENABLE bit and forcing the controller to 1.1 mode and connecting to a PC 1.1 port when configured in 2.0 mode are exactly the same from software and DMA perspective.

regards

swami

swami,

I have also doubted the issue is a hardware issue, but I have test the software in TI EVM board and our product board, there is same issue,you can also test on TI L138 EVM board. If it is a hardware issue, can TI give us a clear response.

David,

Pl. note that the EVM board layout is done keeping Highspeed OTG guidelines in mind.  I am not clear whether forcing the controller in the usb1.1 mode can work with the same layout.  will try forcing the EVM and get back to you.

regards

swami

David

The issue is due to TX-DMA early completion when the data is still in FIFO.

Please try with following patch and let us know.

From 535aac08dd0f5a4af74850f15221bb40cc61713e Mon Sep 17 00:00:00 2001

From: Ravi B <ravibabu@ti.com>

Date: Tue, 9 Nov 2010 19:07:40 +0530

Subject: [PATCH] usb: fix for cppi41-dma issue when musb forced to FS

This is workaround fixe for CPPI41-DMA issue when musb

controller forced to FS/USB1.1 mode. The issue is

due to early completion of DMA interrupt still the

packets are in cppi-fifo and musb fifos.

Signed-off-by: Ravi B <ravibabu@ti.com>

---

drivers/usb/musb/cppi41_dma.c | 1 +

drivers/usb/musb/musb_core.c | 2 +-

2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/musb/cppi41_dma.c b/drivers/usb/musb/cppi41_dma.c

index 4000bf2..1a426b7 100644

--- a/drivers/usb/musb/cppi41_dma.c

+++ b/drivers/usb/musb/cppi41_dma.c

@@ -1233,6 +1233,7 @@ static void usb_process_tx_queue(struct cppi41 *cppi, unsigned index)

* failure with iperf.

*/

/* Tx completion routine callback */

+ mdelay(5);

musb_dma_completion(cppi->musb, ep_num, 1);

}

}

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c

index 512b2d9..55fe204 100644

--- a/drivers/usb/musb/musb_core.c

+++ b/drivers/usb/musb/musb_core.c

@@ -909,7 +909,7 @@ void musb_start(struct musb *musb)

/* put into basic highspeed mode and start session */

musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE

| MUSB_POWER_SOFTCONN

- | MUSB_POWER_HSENAB

+ /*| MUSB_POWER_HSENAB */

/* ENSUSPEND wedges tusb */

/* | MUSB_POWER_ENSUSPEND */

);

Regards

Ravi B

Hi Ravi,

With the patch provided by TI, the issue seems to be fixed, but when i check the patch, I found it just add a "mdelay", so I want to know the if the fix is just a workround.

From 535aac08dd0f5a4af74850f15221bb40cc61713e Mon Sep 17 00:00:00 2001
From: Ravi B <ravibabu@ti.com>
Date: Tue, 9 Nov 2010 19:07:40 +0530
Subject: [PATCH] usb: fix for cppi41-dma issue when musb forced to FS

 This is workaround fixe for CPPI41-DMA issue when musb
 controller forced to FS/USB1.1 mode. The issue is
 due to early completion of DMA interrupt still the
 packets are in cppi-fifo and musb fifos.

Signed-off-by: Ravi B <ravibabu@ti.com>
---
 drivers/usb/musb/cppi41_dma.c |    1 +
 drivers/usb/musb/musb_core.c  |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/musb/cppi41_dma.c b/drivers/usb/musb/cppi41_dma.c
index 4000bf2..1a426b7 100644
--- a/drivers/usb/musb/cppi41_dma.c
+++ b/drivers/usb/musb/cppi41_dma.c
@@ -1233,6 +1233,7 @@ static void usb_process_tx_queue(struct cppi41 *cppi, unsigned index)
     * failure with iperf.
     */
    /* Tx completion routine callback */
+   mdelay(5);
    musb_dma_completion(cppi->musb, ep_num, 1);
   }
  }
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 512b2d9..55fe204 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -909,7 +909,7 @@ void musb_start(struct musb *musb)
  /* put into basic highspeed mode and start session */
  musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
       | MUSB_POWER_SOFTCONN
-      | MUSB_POWER_HSENAB
+      /*| MUSB_POWER_HSENAB */
       /* ENSUSPEND wedges tusb */
       /* | MUSB_POWER_ENSUSPEND */
       );
--
1.6.2.4

Hi

Yes it is workaround, use the following changes (better compared to previous one), we are working to better logic for this early tx completion issue.

static void usb_process_tx_queue(struct cppi41 *cppi, unsigned index)

{

......

                else if (tx_ch->channel.actual_len >= tx_ch->length) {
                        void __iomem *epio = tx_ch->end_pt->regs;
                        u16 csr, timeout = 5000;
                        tx_ch->channel.status = MUSB_DMA_STATUS_FREE;

                        /*
                         * We get Tx DMA completion interrupt even when
                         * data is still in FIFO and not moved out to
                         * USB bus. As we program the next request we
                         * flush out and old data in FIFO which affects
                         * USB functionality. So far, we have obsered
                         * failure with iperf.
                         */
                        do {
                                csr = musb_readw(epio, MUSB_TXCSR);
                        } while (csr & MUSB_TXCSR_TXPKTRDY && timeout--);

                        /* Tx completion routine callback */
                        musb_dma_completion(cppi->musb, ep_num, 1);
 ....

}

What is the duration of time to empty the fifo?   If its small, then maybe this type of sw delay/poll is no big deal.   If its not small, then maybe hurtful.

If we had a timer to throw at it, maybe the usb edma channel could trigger a timer, whose interrupt we could actually pay attention to concerning the end of transfer.  (not that there are a plethora of timers on L138 ;)

Same problem with the mcbsp fifos as well.

Matt

Matt,

The udelay of 15 seems to be good enough in all our testing so far. But would suggest to use the later fix given by RAvi instead of using delay.

Regards,

Ajay

Hi Ajay,

Thank you for the quick response.  Given the fifo length, and the example transfer rate, how long do you think this code-section could run, worst case?

do {
                                csr = musb_readw(epio, MUSB_TXCSR);
                        } while (csr & MUSB_TXCSR_TXPKTRDY && timeout--);

I'm considering this mainly from a 'MIP' perspective.    Normally, if the EOF were tied to the flushing of the fifo (the actual data completion), the interrupt would simply be the act of re-engaging the peripheral for the next block of data (a quick transaction limited by the CPU speed and the duration of the context switching).  With Ravi's proposed solution, every interrupt is that action, plus waiting for the fifo to clear.    In other words, that fifo clearing period is now a fixed block of time the EOF interrupt will wait.   If the tx blocks are large (compared to the fifo length), then this extra time will be marginalized compared to the total transfer time.   If the tx blocks are smaller though, then the interrupt will fire more often and this do-loop will occur more often.

It may be the case that, by the time the interrupt code reaches the do-loop after the EOF has been fired, some of the fifo has already been emptied, reducing the worst case scenario.  Unfortunately, I don't have a good concept of those times/durations.

Could you help us profile this solution a little better?  What is the proposal really costing MIP-wise?  How can we optimize the variables that influence its performance?

Br,

Matt

Hi

The duration of time to empty fifo is in micro seconds(worst case 1 SOF time frame), we are working to fix this issue using SOF based logic. I will the provide the patch once it is done.

Regards

Ravi B

Can you give a time frame for the updated patch?  Thanks.

Roberto,

We would be discussing on possible solution either with SOF interrupt or other options and would keep you updated. As of now the above solution is breaking CDC gadget and so we have modified it as shown below;

---------------------------------------------------------------

u32 timeout = 100000;

                       udelay(10);
                        do {
                                cpu_relax();
                                csr = musb_readw(epio, MUSB_TXCSR);
                        } while ((csr & MUSB_TXCSR_TXPKTRDY) && --timeout);

                        if (!timeout)
                                udelay(10);

---------------------------------------------------------------

I understand that this is not a clean solution to hardware issue. We will keep you posted on the further development on this debugging most likely in March,2011 end.

Regards,

Ajay

Hi Ajay,

  Is there an update time frame for a resolution?  Also is there any reason why we only see this in Full Speed operation?  Shouldn't the same issue exist in High Speed?

It all depends how fast the connected device responds in receiving the data present in Tx FIFO. High speed devices are faster and thus the issue is not observed so frequently.

As of now I can't give timeline due to multiple other tasks in parallel.

Regards,
Ajay

Hi Ajay,

  Is there an updated on an optimized patch.  You had mentioned earlier that you were looking at a March 2011 timeframe.

Thanks!

Hi Ajay,

If there is optimized patch? thank you.

you can refer the latest driver at http://arago-project.org/git/people/?p=sekhar/linux-omapl1.git;a=shortlog;h=refs/heads/DAVINCIPSP_03.20.00.14

Regards,
ajay