0010-TI-DSP-BRIDGE-README.patch

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