#! | 70 lines | 58 code | 12 blank | 0 comment | 0 complexity | 1795fa9a139c80b66716bcf60687f375 MD5 | raw file
Possible License(s): GPL-2.0, LGPL-2.0, AGPL-1.0
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.