Introduction

The EDMA IP in the ARxxxx SoCs can be programmed at a high-level using the EDMA driver software that allows hook-up with an operating system. The EDMA driver exposes programming of most features provided by the IP. Although the EDMA's user guide for ARxxxx SoCs is not available at present on the TI public web, because this IP is used in many other older TI parts, it can be referred to for example at the following url: http://www.ti.com/lit/ug/sprugs5b/sprugs5b.pdf

Following is a high level description of the APIs/features:

Query number of EDMA instances on the SoC.
Initialize a particular instance of EDMA to a known clean disabled state (a reset like state).
Open an instance of EDMA, which returns instance information such as number of transfer controllers on that instance.
Configure a channel to desired configuration and optionally enable channel. This includes PaRAM set choice and PaRAM set configuration. User can optionally supply call-back function for channel transfer completion indication.
Enable/disable a channel.
Configure a PaRAM set. Typically useful for linked PaRAMs.
Link PaRAM sets.
Chain channels.
Start transfer (manually-triggered) of a previously configured channel.
Wait until transfer is complete (used in the case when call-back in configuration is not provided).
APIs to set source or destination address of a PaRAM set, intended for some use cases on XWR16XX (DSP).
Error Monitoring configuration for error generation from CC (Channel Controller) and all TCs (Transfer Controllers). Corresponding error status query for processors on some devices in which error interrupts are not physically connected to the processor interrupt map (e.g EDMA instance #1 on xWR16xx's R4F (MSS)).
Status query.
Performance control.
Close an instance of EDMA.

Here a channel can be a DMA or QDMA channel.

Limitations

Unsupported Hardware features.

Following features of the EDMA hardware are presently NOT supported:

Programming of privilege level and privilege ID is not provided, these are assumed to be always highest privilege (default settings).
Querying of source active registers and destination FIFO register in EDMA TC (Transfer Controller) for advanced debugging not supported.

Unsupported Software features.

No resource management of any sort is provided e.g no DMA or QDMA channel resource management. User is required to do static or dynamic resource management outside of the driver. On XWR16xx/XWR18xx/XWR68xx, the driver software does not prevent both (R4F and C674) processors from operating the same physical EDMA instance, software instances are not shared among the processors (software instances are in local memories of processors). However, if both processors wish to operate on the same physical instance, then they must coordinate their activities outside the driver (say using mailbox messages) to ensure only one is operating on the same physical instance at a time (because read-modify-write operations would become inconsistent without multi-processor semaphores) and also coordinate resource management for resources like channels and transfer completion codes.

API

The EDMA API header file should be included in an application as follows:

#include <ti/drivers/edma/edma.h>

The documentation for all APIs can be referred by clicking at above file or by going to EDMA Driver External Functions. Example usage of the EDMA driver can be seen by referring to the EDMA unit test code located at

ti/drivers/edma/test/ti_rtos/main.c

EDMA Event Mapping Definitions.

Event mapping definitions for the 64 DMA channels can be referred to in the files:

ti/common/sys_common_*.h

with names:

*_REQ_*

For example (on XWR14xx):

#define EDMA_TPCC0_REQ_HWACC_0     (17U)

indicates that for instance 0 (CC0) of the EDMA, event number 17 (0-based) is tied to Hardware Accelerator's channel 0 in the SoC. During programming the channelId parameter when calling configuration API, these defines can be used depending on what is desired e.g the above example define when used means that when the Hardware Accelerator channel 0 output line fires, it will trigger the EDMA channel 17 that was configured using this define. Note the unit test code may not illustrate this because it picks particular numbers to test certain boundary conditions.

Channels that are not tied to any hardware event are available for general usage (e.g for chaining purposes), these channels are marked with the suffix:

FREE_<n>

For example:

EDMA_TPCC0_REQ_FREE_0

Caution

It may be important to disable channels after transfers are done. One case is: A QDMA channel with param X was programmed and transfer completed with a trigger word. Then the same param X that is associated with a DMA channel is used for the DMA channel configuration because it is free. When configure API is issued, it will only deal with DMA channel registers as the channel type is DMA and will leave the QDMA channel untouched (in this case enabled). When the param is configured for this DMA channel, it will prematurely trigger the QDMA channel when the trigger word that was left armed is attempted to be configured. Disabling the QDMA channel before the param associated with it is reused will prevent the problem.

Memory Footprint

The memory footprint of the driver depends on how many APIs are referred to by an application (all are not necessary for basic operation). The unit test code's generated memory map file may be used to get an estimate of the memory foot-print when most APIs are used.