NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
Opening DSP Pools dynamically
END OF LIFE
DSP Link is still available for download, but no further releases or updates are planned. Please see IPC Software Options for details and alternatives.
Overview[edit]
One of the common issues encountered with the POOL module in DSP/BIOSTM Link, is the guideline that all pools must be opened before PROC_start
. This is a big limitation since all application buffer requirements must be known in advance, and prevents true multi-application support, and also results in consumption of extra memory.
This limitation is due to:
- In DSP/BIOS 5.3x, all pools are statically registered with DSP/BIOS through
POOL_config
structure. - All pools get automatically opened on DSP-side before main (as part of
POOL_init
in DSP/BIOS). The configuration within user-specified POOL_config structure gets used for this. - DSPLink shared memory pool is only configured from GPP-side. DSP-side simply opens the pool and polls to make sure that GPP-side has completed opening and configuring the pool shared memory.
- Due to this, DSPLink
SMAPOOL_open
call during BIOS initialization ends up hanging the system due to a handshake conflict between the DSPLink driver and the pool.
However, this limitation can be worked around by dynamically opening the DSP pools using the method detailed below.
Details[edit]
The procedure detailed in this section can be followed to enable opening shared pools after PROC_start
on the ARM-side. This does not require any change in DSPLink.
(Note that the code given below is only indicative. This code cannot be associated with anything in any actual DSPLink release. You will need to make similar changes in your actual application.)
- On the DSP-side, instead of specifying the actual pool configuration, use a dummy configuration. This ensures that BIOS boot-up in
POOL_init
does not hang waiting for the GPP-side pool to be opened.
<syntaxhighlight lang=c>
- define NUM_POOLS 1
/** ============================================================================
* @name MESSAGE_Pools * * @desc Array of pools. * ============================================================================ */
POOL_Obj MESSAGE_Pools [NUM_POOLS] = {
POOL_NOENTRY
} ;
/** ============================================================================
* @name POOL_config * * @desc POOL configuration information. * POOL_config is a required global variable. * ============================================================================ */
POOL_Config POOL_config = {MESSAGE_Pools, NUM_POOLS} ; </syntaxhighlight>
- After the GPP-side pool is opened (which may be after
PROC_start
), the application can notify the DSP-side (possibly throughNOTIFY_notify
, since NOTIFY module does not have any dependency on POOL). Note that the application must ensure that it does not attempt to use the POOL either directly or indirectly before the pool is opened on both GPP and DSP-sides.
- When the notification is received from GPP that the pool has been opened, the DSP-side application can now provide the actual configuration parameters and open the pool. This is to ensure that the DSP-side application does not spin waiting for the pool to be opened by GPP-side. With this method, the DSP-side can simply wait on a semaphore for the GPP-side pool to be opened, and the notification callback posts this semaphore. The pool can be opened on DSP-side by:
<syntaxhighlight lang=c> /* Define actual SMAPOOL parameters */ SMAPOOL_Params MESSAGE_PoolParams [NUM_POOLS] ;
/* Setup SMAPOOL parameters*/ MESSAGE_PoolParams [poolId].poolId = poolId ; MESSAGE_PoolParams [poolId].exactMatchReq = TRUE ;
/* Populate the global POOL configuration structure with actual POOL configuration.*/ MESSAGE_Pools [poolId].initFxn = SMAPOOL_init ; MESSAGE_Pools [poolId].fxns = (POOL_Fxns *) &SMAPOOL_FXNS ; MESSAGE_Pools [poolId].params = &(MESSAGE_PoolParams [poolId]) ; MESSAGE_Pools [poolId].object = NULL ;
/* Open the POOL dynamically */ status = POOL_open (poolId, &(MESSAGE_Pools [poolId])) ; </syntaxhighlight>
POOL_open
is defined as:
<syntaxhighlight lang=c>
- if !defined (POOL_open) /* To ensure no clash with future BIOS definition */
/** ============================================================================
* @name POOL_open * * @desc Macro over the allocator for opening a pool. * * @arg poolId * Pool id. * @arg params * Parameters for opening the pool. * * @see POOL_close * ============================================================================ */
- define POOL_open(poolId, params) \
(((POOL->allocators [poolId]).fxns->open) \ (&(POOL->allocators [poolId].object), \ params))
- endif /* if !defined (POOL_open) */
</syntaxhighlight>