1 files changed, 0 insertions, 70 deletions
diff --git a/drivers/staging/tidspbridge/Documentation/README b/drivers/staging/tidspbridge/Documentation/README
deleted file mode 100644
index df6d371161e0..000000000000
--- a/drivers/staging/tidspbridge/Documentation/README
+++ /dev/null
@@ -1,70 +0,0 @@
-                        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.