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.

EDMA3 LLD and Linux PaRAM address inconsistency

Other Parts Discussed in Thread: OMAP-L138

Hello

I pointed out this in one or two or my previous topics as an additional information but this time it became a real problem. The situation is as follows:

I'm using McASP as a PCM transmitter and receiver on the DSP side of the OMAP-L138 system. EDMA configuration for McASP is done through EDMA3 LLD. In general I'm using 4 DMA channels and a significant number of Linking PaRam sets on the DSP to accomplish some data sorting for my PCM TX/RX. When I print what channels and their PaRAM set addresses I'm using on the DSP I see an inconsistency:
For DMA Channels all is in order: e.g. for one of McASP event channels numbered '1' I get an address of 0x1c04020 (base is 0x1c04000 and offset 0x20 since it is channel number '1' not '0').
For Linking Channels on the other hand I see something like this: channel number 64 (first one given to me by EDMA3_DRV_LINK_CHANNEL address is 0x1c04400 and should be 0x1c04800, since 64*0x20 is 0x800).

Normally I wouldn't bother, but when Linux uses EDMA for a transfer to/from MMC card it uses first free channels it sees - from 32 and on for linking purposes. As you probably have guessed those channels have PaRAM set addresses 0x1c04400 and on causing my PCM transfer to fail.

Is it because:

1. EDMA3 LLD for some reason numbers Linking Channels in a different way than Linux does (by a margin of 32 for OMAP-L138)? Moreover EDMA3 was not designed to work in parallel with Linux driver (or the other way around - Linux driver was not written to work in parallel with EMDA3)?
To support this I examined the source code of EDMA3 LLD and concluded that I'm getting the channel numbering from 64 since EDMA3_DRV_LINK_CH_MIN_VAL is set to 64, as well as EDMA3_MAX_DMA_CH (even though OMAP-L138 has 32 DMA channels for one EDMA instance). 64 is used as a channel number for the first linking channel for compability, but in fact PaRAM set addresses are counted as for a 32 DMA system?

2. There is a bug in EDMA3 LLD in assigning PaRAM set addresses for Linking Channels (since Linux does it really simple through a macro #define PARM_OFFSET(param_no)    (EDMA_PARM + ((param_no) << 5))?

Versions of software:

Linux version 2.6.32-rc6 (szymonk@szymonk) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #66 PREEMPT Tue Jun 8 12:13:36 CEST 2010
edma3_lld_01_10_00_01

I would appreciate your thoughts on that.

Regards
Szymon

  • Hi Szymon,

    The version of Linux kernel you are using did not have support for reserving channels for the DSP. Can you please pick up the latest 2.6.33-rc4 based 03.20.00.12 release?

    In the file arch/arm/mach-davinci/devices-da8xx.c, there are da850_dma{0|1}_rsv_{chans|slots} data structures which allow user to specify which DMA channels and slots are off-limits for ARM to use.

    Thanks,

    Sekhar

  • Thanks

    Could you briefly explain how should I populate the structure if I want, let's say, channel 20 and slot 20 to be used only by the DSP? The "offset, number" approach is not entirely clear to me.

    Regards. Szymon