/drivers/staging/tidspbridge/Documentation/README
https://bitbucket.org/wisechild/galaxy-nexus · #! · 70 lines · 58 code · 12 blank · 0 comment · 0 complexity · 1795fa9a139c80b66716bcf60687f375 MD5 · raw file
- Linux DSP/BIOS Bridge release
- DSP/BIOS Bridge overview
- ========================
- DSP/BIOS Bridge is designed for platforms that contain a GPP and one or more
- attached DSPs. The GPP is considered the master or "host" processor, and the
- attached DSPs are processing resources that can be utilized by applications
- and drivers running on the GPP.
- The abstraction that DSP/BIOS Bridge supplies, is a direct link between a GPP
- program and a DSP task. This communication link is partitioned into two
- types of sub-links: messaging (short, fixed-length packets) and data
- streaming (multiple, large buffers). Each sub-link operates independently,
- and features in-order delivery of data, meaning that messages are delivered
- in the order they were submitted to the message link, and stream buffers are
- delivered in the order they were submitted to the stream link.
- In addition, a GPP client can specify what inputs and outputs a DSP task
- uses. DSP tasks typically use message objects for passing control and status
- information and stream objects for efficient streaming of real-time data.
- GPP Software Architecture
- =========================
- A GPP application communicates with its associated DSP task running on the
- DSP subsystem using the DSP/BIOS Bridge API. For example, a GPP audio
- application can use the API to pass messages to a DSP task that is managing
- data flowing from analog-to-digital converters (ADCs) to digital-to-analog
- converters (DACs).
- From the perspective of the GPP OS, the DSP is treated as just another
- peripheral device. Most high level GPP OS typically support a device driver
- model, whereby applications can safely access and share a hardware peripheral
- through standard driver interfaces. Therefore, to allow multiple GPP
- applications to share access to the DSP, the GPP side of DSP/BIOS Bridge
- implements a device driver for the DSP.
- Since driver interfaces are not always standard across GPP OS, and to provide
- some level of interoperability of application code using DSP/BIOS Bridge
- between GPP OS, DSP/BIOS Bridge provides a standard library of APIs which
- wrap calls into the device driver. So, rather than calling GPP OS specific
- driver interfaces, applications (and even other device drivers) can use the
- standard API library directly.
- DSP Software Architecture
- =========================
- For DSP/BIOS, DSP/BIOS Bridge adds a device-independent streaming I/O (STRM)
- interface, a messaging interface (NODE), and a Resource Manager (RM) Server.
- The RM Server runs as a task of DSP/BIOS and is subservient to commands
- and queries from the GPP. It executes commands to start and stop DSP signal
- processing nodes in response to GPP programs making requests through the
- (GPP-side) API.
- DSP tasks started by the RM Server are similar to any other DSP task with two
- important differences: they must follow a specific task model consisting of
- three C-callable functions (node create, execute, and delete), with specific
- sets of arguments, and they have a pre-defined task environment established
- by the RM Server.
- Tasks started by the RM Server communicate using the STRM and NODE interfaces
- and act as servers for their corresponding GPP clients, performing signal
- processing functions as requested by messages sent by their GPP client.
- Typically, a DSP task moves data from source devices to sink devices using
- device independent I/O streams, performing application-specific processing
- and transformations on the data while it is moved. For example, an audio
- task might perform audio decompression (ADPCM, MPEG, CELP) on data received
- from a GPP audio driver and then send the decompressed linear samples to a
- digital-to-analog converter.