/drivers/staging/tidspbridge/Documentation/README

 1                        Linux DSP/BIOS Bridge release
 2
 3DSP/BIOS Bridge overview
 4========================
 5
 6DSP/BIOS Bridge is designed for platforms that contain a GPP and one or more
 7attached DSPs.  The GPP is considered the master or "host" processor, and the
 8attached DSPs are processing resources that can be utilized by applications
 9and drivers running on the GPP.
10
11The abstraction that DSP/BIOS Bridge supplies, is a direct link between a GPP
12program and a DSP task.  This communication link is partitioned into two
13types of sub-links:  messaging (short, fixed-length packets) and data
14streaming (multiple, large buffers).  Each sub-link operates independently,
15and features in-order delivery of data, meaning that messages are delivered
16in the order they were submitted to the message link, and stream buffers are
17delivered in the order they were submitted to the stream link.
18
19In addition, a GPP client can specify what inputs and outputs a DSP task
20uses. DSP tasks typically use message objects for passing control and status
21information and stream objects for efficient streaming of real-time data.
22
23GPP Software Architecture
24=========================
25
26A GPP application communicates with its associated DSP task running on the
27DSP subsystem using the DSP/BIOS Bridge API. For example, a GPP audio
28application can use the API to pass messages to a DSP task that is managing
29data flowing from analog-to-digital converters (ADCs) to digital-to-analog
30converters (DACs).
31
32From the perspective of the GPP OS, the DSP is treated as just another
33peripheral device.   Most high level GPP OS typically support a device driver
34model, whereby applications can safely access and share a hardware peripheral
35through standard driver interfaces.  Therefore, to allow multiple GPP
36applications to share access to the DSP, the GPP side of DSP/BIOS Bridge
37implements a device driver for the DSP.
38
39Since driver interfaces are not always standard across GPP OS, and to provide
40some level of interoperability of application code using DSP/BIOS Bridge
41between GPP OS, DSP/BIOS Bridge provides a standard library of APIs which
42wrap calls into the device driver.   So, rather than calling GPP OS specific
43driver interfaces, applications (and even other device drivers) can use the
44standard API library directly.
45
46DSP Software Architecture
47=========================
48
49For DSP/BIOS, DSP/BIOS Bridge adds a device-independent streaming I/O (STRM)
50interface, a messaging interface (NODE), and a Resource Manager (RM) Server.
51The RM Server runs as a task of DSP/BIOS and is subservient to commands
52and queries from the GPP.  It executes commands to start and stop DSP signal
53processing nodes in response to GPP programs making requests through the
54(GPP-side) API.
55
56DSP tasks started by the RM Server are similar to any other DSP task with two
57important differences:  they must follow a specific task model consisting of
58three C-callable functions (node create, execute, and delete), with specific
59sets of arguments, and they have a pre-defined task environment established
60by the RM Server.
61
62Tasks started by the RM Server communicate using the STRM and NODE interfaces
63and act as servers for their corresponding GPP clients, performing signal
64processing functions as requested by messages sent by their GPP client.
65Typically, a DSP task moves data from source devices to sink devices using
66device independent I/O streams, performing application-specific processing
67and transformations on the data while it is moved.  For example, an audio
68task might perform audio decompression (ADPCM, MPEG, CELP) on data received
69from a GPP audio driver and then send the decompressed linear samples to a
70digital-to-analog converter.