• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 1275 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

USB host problems in DM365

George K
Prodigy 170 points

We are facing problems in USB host support in DM365 EVM and DVR boards.

Following is the description:

 

===================================================================

Linux kernel : 2.6.18 ( LSP 2.10) [  as provided with  the EVM & DVR ]

 

Problem1 :  USB audio does not work DMA is enabled.  [ Seen in DVR & EVK]

 

The problem occurs while using the USB host to connect to a USB sound card and exercising alsa (aplay) to play a wav file. In the EVM board we see a hang while on DVR board same sequence of steps gives a kernel crash. If we disable USB DMA mode this problem does not occur.

 

The sequence of steps to reproduce the problems is as follows:

1. Compile the DM365 linux kernel with default davinci_dm365_defconfig 2. Edit .config to enable CONFIG_SND_USB_AUDIO (uncomment and set it to

CONFIG_SNG_USB_AUDIO=y)

3. Run 'make oldconfig'

4. Compile the kernel again.

5. Boot the board with built kernel

6. Connect a usb sound card to the board 7. Run 'aplay -D hw:1,0 test.wav' [48KHz, 192kbps file, 16 bit stereo wav file]

8. Ctrl-C to abort aplay before the playback finishes

9. Run aplay again. aplay hangs here and does not produce any sound.

 

After some time (few mins) following log is seen

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BUG: time warp detected!

prev > now, 000000f226b46481 > 0000003f29dd347d:

= 768746139652 delta, on CPU#0

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

10. In DVR similar sequence gives a kernel crash.

 

 

Problem2 : USB reset occurs while using aplay is used in PIO mode [ seen in DVR & EVK ]

 

In order to work around the problem, we used USB in PIO mode. To enable PIO mode we enabled CONFIG_MUSB_PIO_ONLY in .config. On enabling PIO we don't see hang/crash as above.

 

In PIO mode we see another problem. We have not seen this problem with aplay but with our own application based on libasound (alsa library).

This application records data from the usb sound card and plays out the data on the same usb sound card (loopback).

The problem happens once in few 10s of runs, on starting the application we see the following log ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

musb_h_tx_flush_fifo 124: Could not flush host TX fifo: csr: 2003 musb_h_tx_flush_fifo 124: Could not flush host TX fifo: csr: 2003 musb_h_tx_flush_fifo 124: Could not flush host TX fifo: csr: 2003 musb_h_tx_flush_fifo 124: Could not flush host TX fifo: csr: 000a musb_h_ep0_irq 1221: no URB for end 0 hub 1-1:1.0: port 3 disabled by hub (EMI?), re-enabling...

usb 1-1.3: USB disconnect, address 3

root@10.0.0.245:~#

usb 1-1.3: new full speed USB device using musb_hdrc and address 5 usb 1-1.3: configuration #1 chosen from 1 choice ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Workaround : To recover from the error, just close and open the audio device. USB audio starts working.

 

 

Problem3 : USB audio with USB storage both in PIO mode and DMA mode give I/O errors  in DVR and enumeration and I/O errors in EVM.

 

Connect USB sound card with line-in and line-out. Connect USB hard drive.  Now, if USB audio ( aplay + arecord) is run along with USB hard disk read or write application, USB I/O errors and reset happens.

===================================================================

 

Please let me know if anybody has seen similar problems  and have workarounds, suggestions.

 

Thanks

George

  • 0
    TI__Expert 7435 points

    George,

    Could you try with the DaVinci Linux Stating tree hosted by Sneha on the Aarago?

    regards

    swami

  • 0 in reply to swami
    Prodigy 170 points

    Ok thanks, I will try and get back.

     

    George

  • 0 in reply to George K
    Prodigy 170 points

    Hello Swami , TI Community

    I have some updates on the USB problems.
    1. Ctrl-C crash. The reason for the crash I found out was unexpected dma interrupt after dma channel teardown is completed.
    In the channel abort function for a tx channel we do the following:
    * mask cppi channel interrupt
    * set channel number in tear down register when tear down ready bit is set
    * wait for completion ptr to become 0xfffffffc
    * flush fifo
    * clear cppi status words
    * write 0x1 and 0x0 to completion ptr register to deassert cppi channel interrupt
    * unmask cppi channel interrupt
    I noticed on unmasking cppi channel interrupt at this point the completion pointer becomes 0xfffffffc and the cppi channel interrupt asserts again.
    On returning back from abort function we enable system interrupts and cppi_completion isr starts and attempts to handle cppi channel interrupt where the cppi status words are invalid and there kernel crashes because of null pointer dereference.
    To work around this problem I removed unmasking of cppi channel interrupt from the abort function and instead that interrupt is unmasked every time we start a dma transfer i.e. just before writing the tx queue head pointer.

    Please let me know if this is a proper fix.


    2. Playback not working: Another problem which we were facing (I did not report this before) was that in DMA mode playback of any wave file on the USB sound card will stop after a few seconds. I figured that after a few packets of transfer dma completion interrupt stop asserting. I could not find the reason for this. I analyzed the cppi state words and other register contents when this happens but could not find any discrepancy.

    But I found a workaround after which I have not seen this problem in 2 days of long haul run. The USB sound card we are using has playback ISO endpoint which is asynchronous. (Refer to USB 2.0 spec, sec 5.12.4). For asynchronous sinks USB mandates a feedback end point through which device indicates the required data rate of the end point continuously. The feedback endpoint is ISO endpoint and has 3 bytes packet size. In the USB audio driver I disabled this feedback endpoint (commented the code which reads the descriptor to find the synch type of endpoint to enable the feedback pipe). So there is no IN transfer on this feedback pipe and playback is working fine. The data rate at which audio driver is sending packets in the playback endpoint is fixed and determined during enumeration.
    So my conclusion and comments:
    a. I think DMA is not able to handle playback ISO endpoint along with feedback ISO endpoint.
    b. I don't have USB hardware sniffer to analyze on the wire USB packet transfers which can help in debugging. I think there should be no problem in device side since in PIO mode playback is fine.
    c. I suspect few problems like the following: Is 3 byte transfer handled properly in DMA mode? Are we missing rmb(), wmb() call anywhere and ARM is doing out of order execution for writing to registers? Buffer descriptors not syncing to RAM? I tried reviewing the code but I couldn't review all the aspects of the code given the amount of code in the driver.
    d. Although this change helps us overcome this problem but this is not a solution. If we add another device tomorrow which has more ISO end points we can end up seeing similar problems.
    e. Please let me know if you need any more data points to solve this issue. I am willing to do more experiments on this.

    3. Simultaneous hard-disk and sound card use. After the above change I tried simultaneous use of hard disk and sound card through a USB hub. The write speeds we get is in tune to 300kBps and read speeds are about 5MBps. This is along with arecord/aplay.
    I see occasional USB device reset when arecord/aplay terminates. I have not debugged this problem but if you have any suggestions/fix please let me know.

    4. Back port to 2.6.18. The two changes done above fixes similar problems in the 2.6.18 kernel. But I see underruns in arecord/aplay when used along with hard disk access. And write speed to hard disk is extremely poor (~30kBps). So I have started back port of the staging tree driver to 2.6.18. Since there are lot of arch/platform changes across 2.6.18 to 2.6.32 I believe the back port is not straight forward. If you have some suggestions and possible caveats to be careful please let me know.

  • 0 in reply to George K
    Intellectual 810 points

    Hi George, I realize this is an old post but I wonder if you were successful with the backport of the USB driver from 32 to 2.6.18? I am seeing similar issues as you using 2.6.18. 

    Thanks,

    -Craig