Dma overview

From Texas Instruments Embedded Processors Wiki

Jump to: navigation, search

Translate this page to

Below is an overview of EDMA3 specific software that is available in Framework Components (FC) and also some information on what will be made available in future releases. The software in FC is often tailored for use by XDAIS algorithms, and therefore resides "wherever the algorithms reside" (e.g. on a DM644x device, this is typically the DSP, on a DM365 device, this is the ARM).

Note that special care must be taken when considering system-wide resource management. When multiple OS's are integrated onto a system (e.g. Linux and BIOS), often both drivers and codecs require DMA (and other) resources that may conflict. Often resources are partitioned ahead of time so that some are given to "CPU 1 resource managers" (e.g. Linux) and others to "CPU 2 resource managers" (e.g. FC/EDMA3LLD). A concrete example of this is the DM644x device which may run Linux on the ARM and BIOS/FC on the DSP, and both CPUs must share the EDMA3 peripheral.

Resource Manager offerings

DMAN3 - An EDMA3 device specific resource manager that manages only QDMA channels (not EDMA channels) along with TCCs and PaRams as resources.
- Algorithms requiring these resources, implement the IDMA3 interface, DMAN3 queries this interface to obtain resource requirements.
- DMAN3 grants resources in the form of IDMA3 logical handles.
- Configuration for DMAN3 resources is done in the ti.sdo.fc.dman3.DMAN3 module.

RMAN - A generic resource manager that is now used to manage all new resource types that will be managed by framework components.
- Algorithms implement the IRES interface to describe their resource requirements, RMAN queries this interface.
- RMAN talks to a specific resource manager for each IRES resource type (all provided as part of Framework Components) to grant resource requests of algorithms
- RMAN grants resources to requesting algorithms in the form of IRES resource handles.
- Framework Components support the following IRES resource types: EDMA3 , HDVICP (DM6467 Video accelerator), VICP (DM648, DM6446, DM355, DM365 Video imaging accelerator), ADDRSPACE
  - Some of the newer resource managers also manage resources on ARM (non-DSP) devices running Linux or no OS (CCS Simulator).

IRESMAN_EDMA3CHAN - A new IRES EDMA3 specific resource manager that manages all EDMA3 resources
- The new EDMA3 resource manager manages QDMA as well as EDMA channels, along with TCCs and PaRams as resources.
- This resource manager is plugged into RMAN to grant it IRES EDMA3 resource handles (IRES_EDMA3CHAN_Handle)
- The IRESMAN EDMA3CHAN uses the EDMA3 Low Level Resource Manager to manage EDMA3 resources for DSP devices (DM6446, DM6467, DM648, C6455, DM6437, OMAP 2430, 3430 etc).
  - Configuration of the Edma3 Low Level Resource manager used by new IRESMAN_EDMA3CHAN resource manager is done in the ti.sdo.fc.edma3.Settings module. (For details on configuration of IRESMAN_EDMA3CHAN, see Configure EDMA3RM

Co-existence issues

In FC release 2.10, DMAN3 and the new EDMA3 resource manager (called IRESMAN_EDMA3CHAN) can co-exist on a system by statically configuring each manager with its own set of non-overlapping EDMA3 hardware resources (i.e., non-overlapping PaRams, Tccs and QDMA channels)
As of FC release 2.20, DMAN3 has a new configuration option (.useExternalRM) that allows DMAN3 (on C64x+ devices only) to use the Edma3 low level resource manager as well, to obtain its resources (in the same way that IRES EDMA3 does). See DMAN3 Using External Resource Manager
- This allows algorithms implementing both the IRES_EDMA3CHAN interface, and those implementing the IDMA3 interface to co-exist on a system.
- However, whenever DMAN3 has its .useExternalRM switch turned on, the EDMA3 Low Level resource manager needs to be configured using the ti.sdo.fc.edma3.Settings module.
One co-existence issue that still remains is on systems where algorithms use the EDMA3 Low Level resource manager (either through IRES_EDMA3CHAN or DMAN3.useExternalRM), and the applications themselves acquire EDMA3 resources using the EDMA3 Low Level Driver handle directly. In this case, you would still have to partition your resources and have the applications obtain their resources from a different "region" as compared to the algorithm, to avoid resource conflicts.

Functional library offerings

ACPY3 - An IDMA3 specific functional library that performs high performance memory to memory data transfers
- ACPY3 is used in conjunction with DMAN3 to perform high-speed memory transfers, as the both understand the "IDMA3 logical handles"
- ACPY3 can be substituted by a custom library as long as it understands the "IDMA3 logical handle" (the "QdmaLibrary used by some codecs is an example of such a library)

No functional EDMA3 library exists to be used with the new RMAN-style EDMA3 resources (IRES_EDMA3CHAN_Handle)
- A custom library can be written that understands the "IRES EDMA3CHAN handle" to perform transfers. (for e.g., the "dmaLibrary" implemented by 6467 codecs team)

Road Map for Framework Components

Next generation FC will add new resources that will be managed by RMAN (i.e., new IRES resources)
There is a possibility that a new functional EDMA3 library will be added that understands the "IRES" type of EDMA3 resources. This might then replace and/or supplement the ACPY3 library that works with IDMA3 handles.

Usage Suggestions

If your codecs do NOT use EDMA channels (only QDMA channels) or if they use the ACPY3 library, you can continue to implement only the IDMA3 interface and configure DMAN3 for resource management.
If your codecs require EDMA channels as well as QDMA channels, then your codec needs to implement the IRES interface to describe the kind of resources it needs. It would also need to have its own functional library to actually perform the transfers. That library would need to interpret the IRES_EDMA3CHAN_Handle to discover what resources it has been granted. You would configure the ti.sdo.fc.edma3.Settings module to indicate what EDMA3 resources would be managed by RMAN/IRES.
If your codecs have a requirement for both the old IDMA3 interface (to be able to use the ACPY3 library) and the IRES_EDMA3CHAN interface (to be able to use some EDMA channels with a custom library), you would need to take care of both the above points. Also make sure that ti.sdo.fc.dman3.DMAN3 modules and ti.sdo.fc.edma3.Settings module are configured to manage non-overlapping EDMA3 resources. (Note, this restriction will be removed in future releases, where only the ti.sdo.fc.edma3.Settings module will need to be configured for both DMAN3 and IRES_EDMA3CHAN.)

Other

What is the EDMA3 Low Level Driver Package and what does it have to do with Framework Components.

The EDMA3 Low Level Driver (EDMA3 LLD) package has been developed by the PSP team in TI India for use by device drivers. It consists of both a functional library and a resource management library for the EDMA3 hardware

EDMA3 LLD Driver is the functional part of this package that is used by other peripheral drivers for submission and synchronizing of transfers.
EDMA3 LLD Resource Manager (EDMA3 LLD RM) is the resource management layer of this package that performs pure resource management of the EDMA3 hardware resources.

Framework Components is migrating to use the EDMA3 LLD RM to obtain access to "available" EDMA3 resources on the system. The new RMAN style IRES_EDMA3CHAN library already works on top of the EDMA3 LLD RM (all under the hood) to obtain "available" resources on the system. The DMAN3 library can also be configured to use the EDMA3 LLD RM to obtain "available" resources on the system .

The idea is that any entity (drivers, algorithms, applications) that requires access to EDMA3 hardware should negotiate its resources using this centralized EDMA3 LLD RM.

The ti.sdo.fc.edma3.Settings module configures the EDMA3 LLD RM for use by the RMAN/IRES_EDMA3CHAN

What about non-DSP, say ARM-side codecs that use EDMA3 resources from Framework Components.

In more recent releases (FC 2.21 and FC 2.22, see release notes for details), Framework Components has increased support for ARM codecs. As of FC 2.22, we have added RMAN and IRES support for ARM codecs that need EDMA3 resource management. The top-level pictures remains the same: codecs request EDMA3 resources through IRES_EDMA3CHAN interface. At the back-end, the IRES EDMA3CHAN, instead of using the EDMA3 Low Level Resource Manager, communicates with the Linux Support Package (LSP) via the ti.sdo.fc.edma3.Settings module, to obtain resources from the Linux kernel that are currently available. Currently, this support is available for DM355 and DM365 devices. See examples included with the Framework Components release to see how to configure these resource managers and have codecs request EDMA3 resources in a FC/CE framework.