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

edma memcpy DM6446

michaelchen
Prodigy 20 points

     I need to use EDMA to do mem copy in my application on EVMDM6446.  As DM355 has provided a kernel module dm350mmap for EDMA memcpy,
 which is in dvsdk/dm355_codecs/dm355mm/module, I think it is a good base for implementing DM6446 EDMA memcpy.
     I reviewed dm350mmap.c and don't think I should change anything.  After rebuilding the .ko for DM6446, I replace the demos/dm6446/utils/rszcopy
 with demos/dm355/utils/rszcopy, rebuilt the rszcopy and encodedecode demo. Unfortunately , runing encodedeocde on EVMDM6446 will hang up os.
 If I add some printk in dm350mmap.c for each ioctl call, encodedeocde will run ok but slowly.
 dm350mmap.c is developped for DM355,  but I can't find any code specific to DM355. Can anyone give me some hint? thanks.

  • 0
    TI__Mastermind 37340 points

    Please note that in DM6446, EDMA channel are shared between ARM and DSP; there is a Llinux EDMA driver under

    .../ti-davinci/arch/arm/mach-davinci/ 

    similarly there is a DMA manager for DSP (I believe is called DMAN);

    This means that if you decide to write your own; you will need to take the entire system into account to ensure there is no conflicts with the existing software.

  • 0 in reply to Juan Gonzales
    Prodigy 20 points

    Thank for your reply!

    but it does still not working.

    On the DSP side, I run loopbackCombo.x64P from DVSDK 1.30. From loopback.cfg,

    the EDMA used by DSP is :

    DMAN3.paRamBaseIndex = 78; DMAN3.numQdmaChannels = 8; DMAN3.qdmaChannels = [0,1,2,3,4,5,6,7]; DMAN3.numPaRamEntries = 48; DMAN3.numPaRamGroup[0] = 48; DMAN3.tccAllocationMaskL = 0; DMAN3.tccAllocationMaskH = 0xff; DMAN3.numTccGroup[0] = 8;

    On the ARM side, I modified dma.c :

    static unsigned int dm644x_param_entry_arm[] = { /* 0xFFFFFFFFu, 0xFFFFFFFFu, 0xFFFFFFFFu, 0xFFFFFFFFu */ /*orginal*/ 0xFFFFFFFFu, 0xFFFFFFFFu, 0x00000000u, 0x0u }; static unsigned char dm644x_qdma_channels_arm[EDMA_NUM_QDMA_CHAN_DWRDS] = { /* 0x00000010u */ /*orginal*/ 0x00000000u }; static unsigned int dm644x_tcc_arm[EDMA_NUM_DMA_CHAN_DWRDS] = { /* 0xFFFFFFFFu, 0xFFFFFFFFu */ /*orginal*/ 0xFFFFFFFFu, 0x0u }; static unsigned int dm644x_param_entry_reserved[] = { 0xFFFFFFFFu, 0xFFFFFFFFu, 0x0u, 0x0u };

    The encodedecode demo will still lock OS with my modified kernel. Buf if I added a printk in dm350mmap.c:dma_irq_handler, the demo will run ok. Could I get the conclusion that no EDMA conflication between DSP & ARM?

    BTW, does TI provide a user interface for EDMA on ARM or some example?

  • 0 in reply to michaelchen
    TI__Mastermind 37340 points

    Hi Michael,

    A few things about your post caught my attention.  It appears you are changing the EDMA channel allocation on DSP correct?  If so, this may be a bit dangerous, especially on the ARM side as some peripherals may be expecting a particular DMA channel (if I recall correctly).

    1) Did you change any DMA resource allocation on the DSP side?  I believe in the past, we had 7 of the 8 QDMA channels allocated to DSP side, leaving QDMA-0 for the ARM.  DSP side only used to 7 QDMA channels (1 thru 7).  Also, DSP had TCCs 32 thru 63 assigned to it; from your data above, it seems this is no longer the case, so I am curious if you made these changes or if this is part of the changes included in latest DVSDK.

    2) With regards to ARM side, it appears you have assigned all TCCs to ARM (conflict with DSP TCC allocation), hence I would definitely expect problems due to this.

    3) Also, you mention dm350mmap.c.  I need to double check this, but I believe this only applies to our DM35x family of parts and not to DM6446 which I thought you were using.  Are you sure you have your kernel configured for the right platform?

    4) Finally, I should mention that dma dirver interface in Linux is only used by other kernel drivers; there is no user-space interface for DMA channels on the ARM side.