Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.
Link Arbiter Daemon
|Software: Link Arbiter Daemon|
|Hardware supported||,|x|Supports hardware::x}}|
|Software environment(s)||,|x|Runs in software environment::x}}|
Link Arbiter Daemon (LAD) Overview
This topic is an overview of an entity called the Link Arbiter Daemon (LAD). The LAD enables multiple Linux processes to share a same instance of codec server (i.e. DSP image) that is loaded onto the DSP on a heterogeneous platform (e.g. DM644x or OMAP3530). It is distributed with Codec Engine (CE).
- 1 Link Arbiter Daemon (LAD) Overview
- 1.1 Summary
- 1.2 Requirements
- 1.3 Approach
- 1.4 Daemon Command Line Usage
- 1.5 Using LAD in a Codec-Engine-based application
- 1.6 LAD Commands (useful for non Codec-Engine based applications that use DSPLINK)
- 1.7 Limitations
- LAD is used only to request DSP startup/shutdown; in between, applications can make direct calls to DSPLink’s communication APIs (such as
- LAD also requires an "agreed upon" DSP executable, and Link configuration, acceptable to all ARM-side apps that will concurrently share DSP.
- LAD is provided as source, to enable integrator to define multiple LAD/Link configurations
- It includes limited error checks, and a basic recovery mechanism to detect if a client app terminates without disconnecting first
- CE 1.20 or later
- DSPLINK 1.40.05 P3 or later
The Link Arbiter Daemon (LAD) exists as a separate process. The driving requirement for this is Link's convention of "owner" of the DSP to be the first application to use it. To allow CE-based apps and other apps to come and go without ordering restrictions, neither of these apps can be the "owner", but an independent entity is required. (Note, the restriction of the "owner" process being the first to connect was lifted in later versions of DSP Link.)
The LAD is normally started before any application using DSP Link and/or Codec Engine are run.
LAD knows about pre-defined Link configurations, and can reference these by name in an array of
At startup, LAD creates a FIFO (named pipe) for listening for connection requests from other user-mode clients. When a connection request comes in, LAD opens a dedicated FIFO for sending responses to the client.
In the case above, we have an application called AVME which comes along first and starts up the DSP, followed later by a CE-based application, that simply connects to the running DSP.
Wrappers to simplify client communication with LAD reside in a ladclients package. These wrappers abstract and isolate the underlying implementation for communication with LAD, and LAD itself.
Meanwhile, for a CE-based application, these wrappers will be seamlessly called by CE's internal modules (either the OSAL or IPC, depending on the version of CE); the application's runtime is exactly the same, regardless if LAD is used or not. The decision on whether or not to use LAD for the application is a "system" decision, made at application config time, specified via the app's config script (details below).
At run-time, LAD processes command in FIFO order, and these commands run to completion before the next command is accepted. This serialization eliminates race conditions, such as LAD being in the middle of starting the DSP at request of one client, when another client requests a start of the DSP with a different server image.
Daemon Command Line Usage
The lad daemon takes up to 2, optional command line arguments.
The first argument is the path to the log file, if you want one generated. If you don't specify a full path, the log file is placed into /tmp/LAD.
The second argument is the string "verbose" if you want verbose output.
Using LAD in a Codec-Engine-based application
No change to the C code in a Codec-Engine-based application is necessary. To use the LAD, add the following lines to the CE configuration script:
osalGlobal.useLinkArbiter = true;
The link configuration to be used is specified via a new engine configuration parameter, for example:
Note, the Codec Engine Examples include an example demonstrating the use of LAD.
The name assigned to
linkCfg is matched against the names present in the LAD source file
ladconfig.c in the Codec Engine location
ti/dsplink/utils/lad. These names are contained in an array of
configName. You must choose one of the names present in that array. Those names correspond to similarly named structures (e.g., name
"user0" corresponds to structure
user0_LINKCFG_Config) that are defined in similarly named source files that contain DSPLINK configuration objects (e.g.,
user0_LINKCFG_Config for use with a DM6446 is defined in the file
Since the shipped
ladconfig.c contains references to 4 different DSPLINK configuration objects, the LAD executable can support loading codec servers that match any of those 4 different configurations, although only one codec server can be loaded at a time. The user is expected to modify LAD's DSPLINK configuration objects to match their codec server configuration, but keep in mind that one of those configurations as shipped in CE will likely match the "all_codecs" example codec server configuration.
After configuring the LAD, it is started as a separate Linux process before any DSPLINK-based application is run, by invoking the following commands:
echo export LAD environment variable to config source of server images export LAD_SERVERPATH=`pwd` echo Starting Link Arbiter Daemon using servers at $LAD_SERVERPATH ./lad.x470MV log.txt &
Codec Engine supplies a large amount of trace to assist in debugging and profiling. When LAD is configured into a system, there are potentially multiple processes involved, and as a result, there is ambiguity as to which process should be acquiring the DSP-side trace (since there can be more than one!). It's confusing if process A to gets trace from process B and vice-versa.
To disambiguate which process has the right to acquire the DSP-side trace, LAD-based systems can call
Server_connectTrace() right after
Engine_open(). This API tells Codec Engine that this process is entitled to acquire the DSP-side trace; if another process tried to
Server_connectTrace(), the request would be rejected. Users should also call
Server_disconnectTrace() when they want another process to be able to connect and gather trace.
LAD Commands (useful for non Codec-Engine based applications that use DSPLINK)
The following table lists LAD commands. Each command is invoked by the client, using the LAD client APIs.
|LAD Command||Wrapper Function||Args||Comments|
||LAD_ClientHandle * handle||Establishes new LAD client connection. LAD opens up a dedicated output FIFO for sending responses to the client. LAD sends first response (to connect request) to the client wrappers via the FIFO, with its assigned client ID|
||handle, cpuID, linkConfigId, imageName|| If the DSP is not currently in use: does |
||handle|| If DSP was previously started by this client: decrements reference count. If reference count not zero then returns "still running" success code. Else, calls |
||handle||If the handle corresponds to a current client connection: returns state of DSP. If DSP is started returns structure with: dsp state, linkConfigId, imageName, and # of clients who have successfully "started" the DSP.|
||handle||Removes this client connection to LAD. LAD and wrappers close their ends of the dedicated response FIFO.|
Startup Before Any Clients
LAD needs to be explicitly started before any client applications try to connect to the DSP. LAD can be launched from a terminal shell by invoking the LAD executable, e.g., lad.x470MV, as described above.
Only Support Independent Processes
LAD supports multi-application use cases where client applications exist as independent processes. Situations where processes are related (parent, child, siblings) have not been tested.
Single Per-Process Connection to LAD
Applications are allowed only a single connection to LAD. Once successfully connected, if the application tries to open another simultaneous connection the request will be denied, and
LAD_connect() will return
Maximum Number of Simultaneous Connections
The maximum number of simultaneous client connections to LAD is currently 16. Meaning, at most 16 client applications can be connected to LAD for DSP control at any given time.
Known Link Configurations
The maximum number of "known" Link configurations by LAD is currently four.
No Arguments to DSP's
When using LAD, no "command line" arguments can be passed to the DSP's
The basis for this constraint is that multiple apps might want to pass different arguments to the DSP's
main() routine. But when using LAD, only the app that is first to start the DSP would have its arguments interpreted by
main(), and all other apps attempting start later would not have their arguments interpreted because
main() will not run again until the DSP is shutdown. Therefore, to enforce consistency,
LAD_startupDsp() does not accept any arguments, and no arguments will be used when starting up the DSP.