|
|
|
This Linux Utils Release is targetted for the various DaVinci- and OMAP-based platforms running Linux, but is generally usable for any Linux-based system.
Introduction, CMEM, SDMA, EDMA, VICP, Documentation, What's New, Upgrade Info, Compatibility Information, Device Support, Validation Info, Known Issues, Examples, Version Information, Technical Support.
The Linux Utils utility package provides the ability for user-mode applications to access the CMEM, EDMA, SDMA, and VICP utility libraries.
The CMEM (Contiguous Memory) utility library provides the ability for user-mode applications to allocate and free blocks of physically contiguous memory. This is typically done to manage multimedia data buffers which will be worked on by multimedia algorithms, but the memory provided by this library can be used for any purpose.
The reason multimedia algorithms often require physically contiguous memory is that sometimes they're on another processor which may not contain an MMU (e.g. the C64P processor on a DM644x device), and/or Linux-based algorithms utilize hardware accelerators (e.g. DMA, image co-processors, etc) which don't access memory through an MMU.
The CMEM module consists of the following packages:
The CMEM module supports the following devices:
SDMA refers to the "System DMA" incorporated on the OMAP35x family of devices.
The SDMA utility library provides the ability for user-mode applications to request SDMA channels and operate on a channel using direct, memory-mapped access to the channel's DMA registers (Framework Components contains a layer named SCPY to manage this direct access). It also provides "blocking" support for waiting for the completion of a transfer on a particular channel.
Performing direct DMA register access helps to alleviate the overhead of initiating, and checking completion of, DMA transfers, since the usual method involves calling down into the Linux kernel somehow. Transfer completion checking is achieved by first querying an application status flag, and only when it is known that the transfer is NOT complete will a blocking kernel module call be made.
The SDMA module consists of the following packages:
The SDMA module supports the following devices:
EDMA refers to the "Enhanced DMA" incorporated on the Davinci family of C64+ devices.
The EDMA utility library provides the ability for user-mode applications to request EDMA channels and operate on a channel using direct, memory-mapped access to the channel's DMA registers (Framework Components contains a layer named ACPY3 to manage this direct access). It also provides "blocking" support for waiting for the completion of a transfer on a particular channel.
Performing direct DMA register access helps to alleviate the overhead of initiating, and checking completion of, DMA transfers, since the usual method involves calling down into the Linux kernel somehow. Transfer completion checking is achieved by first querying an application status flag, and only when it is known that the transfer is NOT complete will a blocking kernel module call be made.
The EDMA module consists of the following packages:
The EDMA module supports the following devices:
VICP refers to the "Video Image CoProcessing" subsystem incorporated on the Davinci family of C64+ devices.
The VICP utility library provides the ability for user-mode applications to request VICP channels and operate on a channel using direct, memory-mapped access to the channel's registers (Framework Components contains a layer named VICPSYNC to manage this direct access). It also provides "blocking" support for waiting for the completion of a transfer on a particular channel.
The main functionality of the VICP utility library is to provide access to the completion interrupts of various coprocessor resources. The VICP utility library provides access to specific "resources" that include:
The VICP module consists of the following packages:
The VICP module supports the following devices:
The following documentation is available:
Release notes from previous releases are also available in the relnotes_archive directory.
The following significant changes have been made since Linux Utils 2.00
| ID | Headline |
| ID | Headline |
| SDOCM00060312 | Allow sharing of Linux Utils VICP resources |
| ID | Headline |
| SDOCM00058845 | EDMA module in Linux Utils should not allow partial freeing of a multi-PaRAM EDMA_getResource() allocation |
| ID | Headline |
| ID | Headline |
| ID | Headline |
| SDOCM00058042 | CMEM should track buffer ownership through the file descriptor instead of the process descriptor |
| ID | Headline |
| SDOCM00057541 | Linux Utils IRQK module can crash kernel if an operation is requested on a resource that's already been released |
| SDOCM00057542 | Linux Utils EDMAK module does not have mutex locks around registration list manipulation |
| ID | Headline |
| SDOCM00056992 | CMEM should allow no memory block to be specified, so it can be used just for cache operations and virt-to-phys translations |
| ID | Headline |
| SDOCM00056304 | Linux Utils IRQK kernel module returns wrong value from irq handler function irqHandler() |
| ID | Headline |
| ID | Headline |
| SDOCM00054009 | Linux Utils 2.22.01 does not "export" insmod_rmmod_omapL137.sh |
| ID | Headline |
| SDOCM00045995 | Validate Linux Utils on 2.6.27 kernel |
| SDOCM00046045 | CMEM should track owner process of buffers and force-free owned buffers when process closes device file |
| SDOCM00055139 | LinuxUtils edmak should release all resources if processes that have requested resources are no longer running |
| ID | Headline |
| SDOCM00050455 | Create a makefile variable called RULES_MAKE to point to Rules.make |
| ID | Headline |
| SDSCM00019164 | Failure to insmod cmem results in misleading Codec Engine error messages |
| ID | Headline |
| SDSCM00019818 | cat /proc/cmem needs more than one page of memory to avoid buffer overflow |
| ID | Headline |
| SDSCM00023295 | CMEM needs insmod config parameter to support allowing kernel memory & CMEM memory to overlap |
| ID | Headline |
| SDSCM00019947 | CMEM causes Linux kernel Oops when insufficient memory exists for specified pools |
| ID | Headline |
| SDSCM00018886 | CMEM should allow an option not to partition its area into pools but to use it for allocation of arbitrarily-sized buffers |
The Linux Utils packages are available in the "packages/" subdirectory of the product. If you have a previous release of the Linux Utils (or CMEM) product, you can install this release next to it, and modify your application and/or server builds to use this newer release.
If you're using the DVEVM, this can be done by setting the CMEM_INSTALL_DIR variable in the Rules.make file at the top of the DVEVM distribution directory.
None
Note, if you're upgrading from a release earlier than Linux Utils 2.23, be sure to review the Upgrade section for each of the releases between your current release and this one. Previous release notes are available in the relnotes_archive directory.
The details provided below describe each package's compatibility with the previous release (Linux Utils 2.23).
Note, the Configuration Reference Guide contains further details about each package.
If migrating from a release prior to Linux Utils 2.23, consult previous releases available in the relnotes_archive directory.
Compatibility keys are intentionally independent of Marketing product numbers and are intended to:
Compatibility keys are composed of 3 comma-delimited numbers - M,S,R - where:
This release supports the following devices:
This release was validated against using the following components:
This release was validated in the following configurations:
The 2nd function parameter (int nParams) to EDMA_unregister() and EDMA_freeResource() is ignored, since it is no longer allowed to achieve "partial free" by passing fewer 'nParams' than was used with EDMA_getResource(). When freeing a resource, all 'nParam' that were allocated by EDMA_getResource() will be freed.
Linux Utils example apps and tests are provided in the ti/sdo/linuxutils/*/apps directory.
This product's version follows a version format, M.mm.pp.bb, where M is a single digit Major number, mm is 2 digit minor number, pp is a 2 digit patch number, and b is an unrestricted set of digits used as an incrementing build counter.
To support multiple side-by-side installations of the product, the product version is encoded in the top level directory, ex. linuxutils_2_24_03.
Subsequent releases of patch upgrades will be identified by the patch number, ex. Linux Utils 2.24.01 with directory linuxutils_2_24_01. Typically, these patches only include critical bug fixes.
For technical support, contact softwaresupport@ti.com
Check the following web site for updates: https://www-a.ti.com/downloads/sds_support/targetcontent/linuxutils/index.html
Last updated: July 16, 2009