Migrating from DSPLink 1 61 to 1 61 03

From Texas Instruments Embedded Processors Wiki

Jump to: navigation, search

Translate this page to

Introduction

This page gives information for users attempting to move applications from DSPLink v1.61 to v1.61.03

New features in v1.61.03

Overview

Major feature additions in DSPLink v1.61.03 are:

Support for TSK and SWI modes on DSP-side
On Linux, support for kbuild based build for DSPLink kernel module on OMAP3530

Other minor enhancements include:

MSGQ_open and MSGQ_close callable from different threads
For DA8xx/OMAP-L1xx, configuration option to optionally unlock kick registers.
Increase in kernel thread priority for DSPLink DPCs
Defect fixes

Details of Major feature additions

Support for TSK and SWI modes on DSP-side

This release adds support for usage of TSK or SWI modes on DSP-side.

By default, the DSP-side of DSPLink uses SWIs for MSGQ and CHNL physical transports for communication with the peer transports on the GPP-side. Accordingly, the MPCS (Multi-processor critical section) protection uses SWI_disable/SWI_enable to protect from other local threads, since the DSPLink APIs need to be callable from SWI context.

In pure TSK-only systems, this release now supports applications that wish to reduce the scheduler disable latency. For this, the MPCS implementation supports usage of semaphore for protection from other local threads. Accordingly, the MSGQ and CHNL modules use TSK based servers instead of SWIs for communication with the peer transport on GPP. With this change, the scheduler disable latency gets reduced; however applications must not make any DSPLink calls from SWI context.

In both modes, DSPLink calls from HWI context continue to not be supported.

The choice of whether TSK mode or SWI mode is to be used, is selectable for each DSP in the system from the DSPLink static build configuration script dsplinkcfg.pl. If no specific option is specified, SWI mode is used by default.

On Linux, support for kbuild based build for DSPLink kernel module on OMAP3530

The DSPLink build system now supports kbuild based build system on OMAP3530 for the kernel module to enable usage with the PSP GIT release for OMAP3530. The user-side library (api) and sample applications on GPP shall continue to be built using the DSPLink build system.

For all other devices, the DSPLink build system shall continue to be used.

Please refer to the section on “Upgrade and compatibility information” for further details on application impact due to this change.

Upgrade and compatibility information

This section gives the details of backward compatibility and upgrade information for applications to move to DSPLink v1.61.03 from the previous release DSPLink 1.61.
DSPLink 1.61.03 is API and binary compatible with DSPLink 1.61. Other changes that are relevant to applications are listed below.

Command line option to enable TSK or SWI mode: Command line option is provided in dsplinkcfg.pl static configuration script to enable TSK mode instead SWI mode. To enable TSK mode, pass –DspTskMode = 1 option to dsplinkcfg.pl script during DSPLink build configuration. This is an optional argument. If not provided, the current default of DSP SWI mode is assumed.
On Linux, kernel build system support for OMAP3530: On Linux, Kbuild support is added for building the DSPLink kernel module on OMAP3530. The user-side library and sample applications shall continue to be built using the DSPLink build system.
- The Rules.mk file in $(DSPLINK)/gpp/src folder needs to be updated to point to the correct paths for the user’s build environment.
- Please refer to the section 9.4 of InstallGuide_Linux_OMAP3530.pdf to build the OMAP3530 using kernel build system. Application developers need to use the include path and defines from CURRENTCFG.mk.
- To build on OMAP3530, api folder must be built first before building the gpp/src. The binaries are copied into the appropriate folder similar to the DSPLink build system:

cd $(DSPLINK)/gpp/src 
cd api 
make –s [debug | release] 
cd .. 
make –s debug 
make –s release

- MSGQ_open and MSGQ_close callable from different threads: The DSPLink protection scheme for MSGQ has now been updated to allow calling MSGQ_close from a different thread than the one that had created the Message Queue using MSGQ_open. However, process level protection still continues, i.e. the Message Queue creation and deletion must happen from threads within the same process.
- For DA8xx/OMAP-L1xx, configuration option to optionally unlock kick registers: On GPP-side, the configuration file (CFG_<PLATFORM>.c) has been updated to use a DSP argument to indicate whether kick registers should be unlocked by DSPLink. The arg4 field of LINKCFG_dspObject is used for this purpose. On DA8xx, the default configuration does not unlock the registers (value 1). On OMAP-L1xx, the default configuration unlocks the registers (value 0) during PROC_attach.
- Increase in kernel thread priority for DSPLink DPCs: On Linux, the kernel thread priority for DPCs created by DSPLink has been increased through nice value of -10.

For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article Migrating from DSPLink 1 61 to 1 61 03 here.