Dma overview

Framework Components DMA Overview

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, a TI81XX device, this may be the M3, 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

• 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

• IRESMAN_EDMA3CHAN - A new IRES EDMA3 specific resource manager that manages all EDMA3 resources
  • This 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

• DMAN3 - (Note:- As of FC 3.23 DMAN3 is no longer supported) 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.

Co-existence issues

• (Note:- As of FC 3.23 DMAN3 is no longer supported) 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)
• (Note:- As of FC 3.23 DMAN3 is no longer supported) 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 (through IRES_EDMA3CHAN), 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 "regions" as compared to the algorithm, to avoid resource conflicts.

Functional library offerings

• ECPY - An IRES specific functional library that performs high performance memory to memory data transfers.
  • ECPY is used in conjunction with RMAN to perform high-speed memory transfers by algorithms that implement the IRES EDMA3CHAN interface.
  • As of writing this article (MFP 3.23) ECPY uses EDMA channels only, no QDMA channels are used.

• ACPY3 - (Note:- As of MFP 3.23 ACPY3 is no longer supported) 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)

Road Map for Framework Components

• Next generation FC will add new resources that will be managed by RMAN (i.e., new IRES resources)

Usage Suggestions

• As of the last update to this article (MFP 3.23) the recommendation is to use RMAN, IRES EDMA3CHAN for acquiring DMA resources. ECPY is to be used for performing DMA transfers.
• 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.

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 uses the EDMA3 LLD RM to obtain access to "available" EDMA3 resources on the system. RMAN IRES_EDMA3CHAN based libraries work on top of the EDMA3 LLD RM (all under the hood) 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 older releases (FC 2.21 and FC 2.22, see release notes for details), Framework Components had provided support for ARM codecs. In FC 2.X relases, we had RMAN and IRES support for ARM codecs that needed EDMA3 resource management. The top-level pictures remained 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. This support was available for DM355 and DM365 devices.

As of the last update to this article (MFP 3.23), no devices are supported by MFP that have ARM-side codecs requesting DMA resources.