Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit f190be7f authored by Kristina Martšenko's avatar Kristina Martšenko Committed by Greg Kroah-Hartman
Browse files

staging: tidspbridge: remove driver 



The driver has been broken and disabled for several kernel versions now.
It doesn't have a maintainer anymore, and most of the people who've
worked on it have moved on. There's also still a long list of issues in
the TODO file before it can be moved out of staging. Until someone can
put in the work to make the driver work again and move it out of
staging, remove it from the kernel.

Signed-off-by: default avatarKristina Martšenko <kristina.martsenko@gmail.com>
Cc: Omar Ramirez Luna <omar.ramirez@copitl.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
parent cb3aadae

MAINTAINERS

+0 −5
Original line number Diff line number Diff line
@@ -8624,11 +8624,6 @@ W: http://www.linux-speakup.org/ 
S:	Odd Fixes

F:	drivers/staging/speakup/



STAGING - TI DSP BRIDGE DRIVERS

M:	Omar Ramirez Luna <omar.ramirez@copitl.com>

S:	Odd Fixes

F:	drivers/staging/tidspbridge/



STAGING - USB ENE SM/MS CARD READER DRIVER

M:	Al Cho <acho@novell.com>

S:	Odd Fixes

drivers/staging/Kconfig

+0 −2
Original line number Diff line number Diff line
@@ -74,8 +74,6 @@ source "drivers/staging/iio/Kconfig" 


source "drivers/staging/xgifb/Kconfig"



source "drivers/staging/tidspbridge/Kconfig"



source "drivers/staging/quickstart/Kconfig"



source "drivers/staging/emxx_udc/Kconfig"

drivers/staging/Makefile

+0 −1
Original line number Diff line number Diff line
@@ -31,7 +31,6 @@ obj-$(CONFIG_VME_BUS) += vme/ 
obj-$(CONFIG_DX_SEP)            += sep/

obj-$(CONFIG_IIO)		+= iio/

obj-$(CONFIG_FB_XGI)		+= xgifb/

obj-$(CONFIG_TIDSPBRIDGE)	+= tidspbridge/

obj-$(CONFIG_ACPI_QUICKSTART)	+= quickstart/

obj-$(CONFIG_USB_EMXX)		+= emxx_udc/

obj-$(CONFIG_USB_ENESTORAGE)	+= keucr/

drivers/staging/tidspbridge/Documentation/CONTRIBUTORS

deleted100644 → 0
+0 −45
Original line number Diff line number Diff line 
TI DSP/Bridge Driver - Contributors File



The DSP/Bridge project wish to thank all of its contributors, current bridge

driver is the result of the work of all of them. If any name is accidentally

omitted, let us know by sending a mail to omar.ramirez@ti.com or

x095840@ti.com.



Please keep the following list in alphabetical order.



	Suman Anna

	Sripal Bagadia

	Felipe Balbi

	Ohad Ben-Cohen

	Phil Carmody

	Deepak Chitriki

	Felipe Contreras

	Hiroshi Doyu

	Seth Forshee

	Ivan Gomez Castellanos

	Mark Grosen

	Ramesh Gupta G

	Fernando Guzman Lugo

	Axel Haslam

	Janet Head

	Shivananda Hebbar

	Hari Kanigeri

	Tony Lindgren

	Antonio Luna

	Hari Nagalla

	Nishanth Menon

	Ameya Palande

	Vijay Pasam

	Gilbert Pitney

	Omar Ramirez Luna

	Ernesto Ramos

	Chris Ring

	Larry Schiefer

	Rebecca Schultz Zavin

	Bhavin Shah

	Andy Shevchenko

	Jeff Taylor

	Roman Tereshonkov

	Armando Uribe de Leon

	Nischal Varide

	Wenbiao Wang

drivers/staging/tidspbridge/Documentation/README

deleted100644 → 0
+0 −70
Original line number Diff line number Diff line 
                        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.