• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 547 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.

Kernel lock DMA enabled USB on am180x

kadir yasar
Intellectual 730 points
Other Parts Discussed in Thread: DA8XX

Hi

I have some problems with DMA enabled USB in kernel 2.6.37. After installing of cppi41dma.ko and g_cdc.ko modules, shell prompt does not return to user space. Everything is running in background even CDC(ethernet works) but i cannot use the shell. Without DMA, everything is Ok. I think there is a lock inside the kernel but i could not find it. And if i install the g_ether module instead of g_cdc when dma is enabled, there is no problem, but i need the CDC.

My kernel is http://arago-project.org/git/projects/?p=linux-davinci.git;a=shortlog;h=refs/heads/usb_pio_plus_dma

Thanks 

  • 0
    TI__Genius 9460 points

    Can you try below patch and see if this helps.

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=commitdiff;h=86273dddf0c73c232efd09630565f34f08943bdc

    The patch may not apply completely so ignore some part which doesn't apply to AM18x. The important one is relocation of spin_lock.

    Ajay

  • 0 in reply to Ajay
    Intellectual 730 points

    Hi Ajay 

    The patch could not solve the problem. Here is the output of installing modules:

    [:/root]# insmod modules/usb/cppi41dma.ko
    [:/root]# insmod modules/usb/da8xx.ko

    [ 115.615593] musb-hdrc musb-hdrc: dma type: dma-cppi41
    [ 115.621342] Waiting for USB PHY clock good...
    [ 115.650123] musb-hdrc musb-hdrc: USB OTG mode controller at fee00000 using DMA, IRQ 58

    [:/root]# insmod modules/usb/g_cdc.ko host_addr=00:dd:dc:eb:6d:f1 dev_addr=00:dc:c8:f7:75:05

    [ 127.699498] usb0: MAC 00:dc:c8:f7:75:05
    [ 127.703547] usb0: HOST MAC 00:dd:dc:eb:6d:f1
    [ 127.708605] g_cdc gadget: CDC Composite Gadget, version: King Kamehameha Day 2
    [ 127.716342] g_cdc gadget: g_cdc ready
    [ 127.720174] musb-hdrc musb-hdrc: MUSB HDRC host driver
    [ 127.725456] musb-hdrc musb-hdrc: new USB bus registered, assigned bus number 1
    [ 127.741695] hub 1-0:1.0: USB hub found
    [ 127.745565] hub 1-0:1.0: 1 port detected
    [ 127.749796] musb g_cdc gadget disconnected.
    [ 127.805275] USB is already Plugged
    [ 128.655548] g_cdc gadget: high speed config #1: CDC CompositeCM + ACM)
    [ 128.662430] musb-hdrc periph: enabled ep2in for int IN, dma, maxpacket 16
    [ 128.669317] musb-hdrc periph: enabled ep4in for int IN, dma, maxpacket 10
    [ 128.676164] musb-hdrc periph: enabled ep3in for bulk IN, dma, maxpacket 512
    [ 128.683184] musb-hdrc periph: enabled ep2out for bulk OUT, dma, maxpacket 512
    [:/root]#
    [:/root]#
    [ 133.918766] g_cdc gadget: high speed config #1: CDC Composite (ECM + ACM)
    [ 133.925649] musb-hdrc periph: enabled ep2in for int IN, dma, maxpacket 16
    [ 133.932534] musb-hdrc periph: enabled ep4in for int IN, dma, maxpacket 10
    [ 133.939382] musb-hdrc periph: enabled ep3in for bulk IN, dma, maxpacket 512
    [ 133.946402] musb-hdrc periph: enabled ep2out for bulk OUT, dma, maxpacket 512
    [ 134.069684] musb-hdrc periph: enabled ep1in for bulk IN, dma, maxpacket 512
    [ 134.076731] musb-hdrc periph: enabled ep1out for bulk OUT, dma, maxpacket 512

    (lock in here)

  • 0 in reply to kadir yasar
    TI__Genius 9460 points

    Ok. There have been recent updatesi in cppi41 dma driver and available for ti81xx platform at below link

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/TI814XPSP_04.01.00.07

    You may try to update your driver.

    Ajay

  • 0 in reply to Ajay
    Intellectual 730 points

    Hi Ajay

    I put some debug messages to txdma_completion_work() function in cppi41_dma.c, and i realized that musb_dma_completion(musb, index+1, 1) function is not called. Code goes to cond_resched() and green part is not executed. I suspect about tx_ch->txfifo_intr_enable, because it is 0x00 every time.

    while (1) {
                     for (index = 0; index < USB_CPPI41_NUM_CH; index++) {
                             void __iomem *epio;
                             u16 csr;
                             tx_ch = &cppi->tx_cppi_ch[index];
                             if (tx_ch->tx_complete) {
                                    if (!tx_ch->end_pt) {
                                             tx_ch->tx_complete = 0;
                                             tx_ch->count = 0;
                                             continue;
                                     }
                                     epio = tx_ch->end_pt->regs;
                                     csr = musb_readw(epio, MUSB_TXCSR);
                                     // tx_ch->txfifo_intr_enable = 0x00
                                     // csr = 0x3403
                                     // Execution goes into if state. and jumps to resched
                                     if (!tx_ch->txfifo_intr_enable &&  (csr & (MUSB_TXCSR_TXPKTRDY | MUSB_TXCSR_FIFONOTEMPTY))) {
                                             resched = 1;
                                     } else {
                                             if (tx_ch->count > 0) {
                                                     tx_ch->count--;
                                                     resched = 1;
                                                     continue;
                                             }
                                             tx_ch->channel.status =  MUSB_DMA_STATUS_FREE;
                                             tx_ch->tx_complete = 0;
                                             spin_lock_irqsave(&musb->lock, flags);
                                             musb_dma_completion(musb, index+1, 1);
                                             spin_unlock_irqrestore(&musb->lock, flags);
                                     }
                             }
                     }
                     if (resched) {
                             resched = 0;
                             cond_resched();
                     } else {
                             return ;
                     }
             }
  • 0 in reply to kadir yasar
    Intellectual 730 points

    Hi 

    I tried to install g_ether module instead of g_cdc when debug messages are opened. musb_dma_completion is done properly and TXCSR register contains 0x3404 value. In CDC mode, it contains 0x3403 value and it means dma queue is not empty (according to am180x trm). Any idea ?

    Thanks

  • 0 in reply to kadir yasar
    TI__Expert 7885 points

    As i understand you are not able to use console when g_cdc is inserted. Do you observe this issue once usb0 interface is up and connected to Linux PC. are you able to do ping b/w EVM and PC. Can you check using ramdisk file system and check you observe the same issue.

    Regards

    Ravi B

  • 0 in reply to Ravi B
    Intellectual 730 points

    Hi Ravi

    Yes, you are correct. i could not use the console when i insert the g_cdc module with DMA enabled. But background proccesses and kernel are running, everything seems to be OK, except for shell :) After installing the g_cdc module i can ping the (custom)board from a linux pc. It seems to be a userspace issue but not. because kernel loops in txdma_completion_work() function in cppi41_dma.c file. musb_dma_completion() cannot be executed due to sattus of TXCSR register. It is not about filesystem. my fs is flash filesystem. If i used NFS, of course it could not work due to CDC ethernet.

    Any Help?

    Thanks