![Omar Ramirez Luna](/assets/img/avatar_default.png)
Add a README with a general overview of TI's DSP Bridge driver, a short explanations of how error codes are currently used, and a CONTRIBUTORS file with all past & present contributors. For additional information about TI's DSP Bridge, check out http://omapzoom.org/gf/project/omapbridge/docman/?subdir=3 Note: if by any chance we forgot to mention any contributor, please let us know and we will fix that. Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com> Signed-off-by: Kanigeri, Hari <h-kanigeri2@ti.com> Signed-off-by: Ameya Palande <ameya.palande@nokia.com> Signed-off-by: Guzman Lugo, Fernando <fernando.lugo@ti.com> Signed-off-by: Hebbar, Shivananda <x0hebbar@ti.com> Signed-off-by: Ramos Falcon, Ernesto <ernesto@ti.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Anna, Suman <s-anna@ti.com> Signed-off-by: Gupta, Ramesh <grgupta@ti.com> Signed-off-by: Gomez Castellanos, Ivan <ivan.gomez@ti.com> Signed-off-by: Andy Shevchenko <ext-andriy.shevchenko@nokia.com> Signed-off-by: Armando Uribe De Leon <x0095078@ti.com> Signed-off-by: Deepak Chitriki <deepak.chitriki@ti.com> Signed-off-by: Menon, Nishanth <nm@ti.com> Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
71 lines
3.6 KiB
Plaintext
71 lines
3.6 KiB
Plaintext
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.
|