Piteball
/
android_kernel_samsung_msm8976
mirror of https://github.com/team-infusion-developers/android_kernel_samsung_msm8976.git
1
1
Fork 0
Code Issues Projects Releases Wiki Activity

msm: broadcast: Remove unused TSC and TSPP2 drivers 

TSC and TSPP2 were HW blocks in MPQ8092 target which is
no longer supported. Remove TSC and TSPP2 drivers to
eliminate unused code.

Change-Id: Ibb55ae0d15b33ba5855bde69e78925d23def3c6b
Signed-off-by: Liron Kuch <lkuch@codeaurora.org>
This commit is contained in:
Liron Kuch 2015-09-06 11:19:39 +03:00 committed by Gerrit - the friendly Code Review server
parent c3abdef6e0
commit 921b60c4dc
5 changed files with 0 additions and 12925 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

398
Documentation/arm/msm/tsc.txt
View File

@ -1,398 +0,0 @@
Introduction
============
TSC Driver
The TSC (Transport Stream Controller) is a hardware block used in products such
as smart TVs, Set-top boxes and digital media adapters, and is responsible for
two main functionalities:
1. Mux function: enabling the routing of MPEG-2 transport streams (TS) received
from terrestrial/cable/satelite in order to support the different topologies of
the end product, as it may be deployed in many different topologies.
In addition, the active topology may change according to various factors such as
broadcast technology and/or conditional access system.
2. CI function: acting as a common interface, complying with both PC Card and
CI/+ specifications.
The TSC driver has two different interfaces, one for each function.
Hardware description
====================
The TSC HW contains the TSC core, and uses the VBIF unit (IOMMU) which is part
of the broadcast subsystem HW.
Mux function:
-------------
The TSC can receive transport streams from:
a. Two Transport Stream Interfaces (TSIFs) 0 or 1, connected to two external
demods or to external bridge.
b. One TSIF from an integrated demod.
The TSC can route TS from any of the above TSIFs to an external CICAM, using a
software configurable mux.
The TSC can route TS from any of the above TSIFs, and TS received from the CI
Conditional Access Mudule (CICAM) to two TSIF outputs (0 or 1), using two
software configurable muexes.
The CICAM input and outputs are also managed via two additional TSIFs: TSIF-out
to the CAM, and TSIF-in from the CAM.
CI function:
------------
The common interface is composed of:
1. Card detection logic: the TSC notifies the SW of any change in the card
detection status (via HW interrupt).
2. Control interface used to send/receive the CI messages (APDUs), supporting
data transmission in two formats:
a. Single byte transactions: to/from the attribute memory space of the CAM and
the command area of the CAM.
b. Buffer transactions: to/from the command area of the CAM, using a
configurable buffer size of 1k bytes-64k bytes. This enables transferring
large chunks of data between the CAM and applications.
The data buffer resides in the external memory and the interface to the
memory is done through BCSS VBIF.
The TSC uses PCMCIA interface to interact with the CAM.
The following diagram provides an overview of the TSC HW:
+-------------------------------------------------------------------------+
| |
| +------------------------------+ |
| +-----------+ | TSC Core --. | |
| |Ext. TSIF 0+------------+------------>| \ | +-----------+ |
| +-----------+ | +-----|------------>|Mux)----->TSPP TSIF 0| |
| +-----------+ | | +--|------------>| / | +-----------+ |
| |Ext. TSIF 1+------| | | +->--' | |
| +-----------+ | | | | | --. | |
| | | | +----------|->| \ | +-----------+ |
| +-----------+ | +--|--|-+--------|->|Mux)----->TSPP TSIF 1| |
| |Int. TSIF +---------+--|-|-+------|->| / | +-----------+ |
| +-----------+ | | | | +->--' | |
| | | | | | | |
| | | | | | | |
| |+------+(v-v-v--) | +-----+| |
| ||Card | \ Mux / | |CI/+ +---Data-Interface--+ |
| ||detect| `---' | +----++| | |
| |+-^-^--+ | | | | | |
| +--|-|-------|-------|-------|-+ +------+----+ |
| | | | | | | VBIF | |
| | | +-----v--+ +--+----+ | | | |
| | | |TSIF-Out| |TSIF-In| | +-----------+ |
| | | +-----+--+ +--^----+ | |
| | | | | | |
| ++-+-------v-------+-------++ |
| | CICAM | |
| | | |
| +---------------------------+ |
+-------------------------------------------------------------------------+
Software description
====================
The TSC Linux kernel driver manages the TSC core. It is a standard Linux
platform device driver. It can be configured as a loadable or built-in kernel
module. The driver is supported only in platforms that contain the TSC HW.
The TSC driver uses ION driver to control the IOMMU and map user-allocated
buffers to the TSC IOMMU domain.
The driver provides an abstraction of the TSC HW functionality for user-space
clients via two separate interfaces: tsc_mux and tsc_ci. These interfaces may
be used by upper layers to utilize the TSC HW for routing the TS and supporting
the Common Interface specification.
Driver initialization
---------------------
The driver's probe function is invoked if there is a matching device tree node.
The probe function gets the required memory resources (i.e., register address
spaces) and maps them to kernel space for the driver's use.
The probe function also requests the required IRQs, GPIOs and clocks, and gets
the TSC IOMMU domain. The probe function also disables the TSIFs input.
Finally, the function creates two character device drivers: "tsc_mux","tsc_ci".
See API description in interface section.
Data paths
-----------
The TSC does not process the TS data received from the TSIFs. It just manages
the routing of that data.
Control paths - Mux function
----------------------------
Example for routing the TS from external demod TSIF 0 to the CAM, and from the
CAM to TSIF 1 of the TSPP:
struct tsc_route tsif_cam = {TSC_SOURCE_EXTERNAL0, TSC_DEST_CICAM};
struct tsc_route cam_tspp = {TSC_SOURCE_CICAM, TSC_DEST_TSPP1};
int mux_fd, ret;
enum tsc_source tsif0 = TSC_SOURCE_EXTERNAL0;
enum tsc_source cam = TSC_SOURCE_CICAM;
/* opening Mux char device */
mux_fd = open("/dev/tsc_mux0");
/* Configure the CAM mux to route TS from external demod TSIF 0: */
ret = ioctl(mux_fd, TSC_CONFIG_ROUTE, &tsif_cam);
/* Configure the TSPP TSIF 1 mux to route TS from CAM: */
ret = ioctl(mux_fd, TSC_CONFIG_ROUTE, &cam_tspp);
/* Enabling the external demod TSIF 0, and the CAM TSIF-in and TSIF-out */
ret = ioctl(mux_fd, TSC_ENABLE_INPUT, &tsif0);
ret = ioctl(mux_fd, TSC_ENABLE_INPUT, &cam);
close(mux_fd);
Control paths - CI function
---------------------------
Example for writing a buffer to the CAM command area:
Assumptions:
1. The user allocated a buffer using ION driver and wrote to that buffer.
Also, retrieved the ion fd of that buffer and saved it to:
int buffer_fd;
2. The user already performed buffer size negotiation with the CAM according to
CI/+ specification, and had set the CAM size register with the buffer size. This
size is saved to: int size;
3. The user decided about the time the user wants to wait for the data
transmission.
struct tsc_buffer_mode buff_params = {buffer_fd, size, timeout};
int ret;
/* Perform a blocking write buffer transaction for at most timeout */
ret = ioctl(fd, TSC_WRITE_CAM_BUFFER, &buff_params);
/* ret indicate whether the transaction succeeded */
Example for SW reset to the CAM (according to CI/+ specification):
struct single_byte_mode cmd_params = {1, RS bit set, timeout};
struct single_byte_mode stat_params = {1, not initialize, timeout};
int ci_fd, ret;
u8 data;
/* opening CI char device */
ci_fd = open("/dev/tsc_ci0");
/* Setting the RS bit of the CAM command register */
ret = ioctl(ci_fd, TSC_WRITE_CAM_IO, &cmd_params);
/* Polling the FR bit of the CAM status register */
ret = ioctl(ci_fd, TSC_READ_CAM_IO, &stat_params);
data = stat_params.data;
while (data & FR_BIT_MASK) {
ret = ioctl(ci_fd, TSC_READ_CAM_IO, &stat_params);
data = stat_params.data;
}
close(ci_fd);
Design
======
The TSC driver is a regular Linux platform driver designed to support the
TSC HW available on specific SoCs.
The driver provides two user-space APIs: tsc_mux that allows the client full
control over the configuration of the TS routing, and tsc_ci that enables the
client to implement the Common Interface in front of the CAM. It does so while
encapsulating HW implementation details that are not relevant to the clients.
The driver enforces HW restrictions and checks for input parameters
validity, providing a success or failure return value for each API function:
0 upon success or negative value on failure. Errno parameter is set to indicate
the failure reason.
However, the driver does not enforce any high-level policy with regard to the
correct use of the TSC HW for various use-cases.
Power Management
================
The TSC driver prevents the CPU from sleeping while the HW is active by using
wakeup_source API. When there are no open devices the driver releases the wakeup
source. In a similar manner, the driver enables the HW clocks only when needed.
SMP/multi-core
==============
The driver uses a spinlock to protect accesses to its internal databases,
for synchronization between user control API and kernel interrupt handlers.
The driver uses a mutex for all the Mux operations to synchronize access to the
routing internal databases. The driver uses another mutex for all the CI
operations to synchronize data sent and received to and from the CAM.
Security
========
Although the TSC is the bridge the external conditional access module, it has no
security aspects. Any protection which is needed is performed by the upper
layers. For example, the messages which are written to the CAM are encrypted.
Thus the TSC accesses only non-protected, HLOS accessible memory regions.
Performance
===========
Control operations are not considered as performance critical.
Most of the control operations are assumed to be fairly uncommon.
Interface
=========
Kernel-space API
----------------
The TSC driver does not provide any kernel-space API, only a user-space API.
User-space API
----------------
Open: upper layer can open tsc_mux device and/or tsc_ci device.
Release: close the device and release all the allocated resources.
Poll: two different functions- one for Mux, one for CI. The Mux poll wait for
rate mismatch interrupt. The CI poll waits for card detection HW interrupt.
The rate mismatch interrupt is not cleared in the interrupt handler because it
will signal again all the time. Therefore it is cleared via a specific ioctl
that upper layer can use after the problem is solved. Additionally, the
interrupt is cleared when the card is removed.
ioctl: two functions, one for mux and one for ci. The ioctl are specified below.
TSC Mux - routing the TS:
-------------------------
enum tsc_source {
TSC_SOURCE_EXTERNAL0,
TSC_SOURCE_EXTERNAL1,
TSC_SOURCE_INTERNAL,
TSC_SOURCE_CICAM
};
enum tsc_dest {
TSC_DEST_TSPP0,
TSC_DEST_TSPP1,
TSC_DSET_CICAM
};
struct tsc_route {
enum tsc_source source;
enum tsc_dest dest;
};
#define TSC_CONFIG_ROUTE _IOW(TSC_IOCTL_BASE, 0, struct tsc_tspp_route)
#define TSC_ENABLE_INPUT _IOW(TSC_IOCTL_BASE, 1, enum tsc_source)
#define TSC_DISABLE_INPUT _IOW(TSC_IOCTL_BASE, 2, enum tsc_source)
These 3 IOCTLs control the 3 muxes that route the TS, and enable/disable the
TSIFs input.
TSC Mux - configuring the TSIFs:
--------------------------------
enum tsc_data_type {
TSC_DATA_TYPE_SERIAL,
TSC_DATA_TYPE_PARALLEL
};
enum tsc_receive_mode {
TSC_RECEIVE_MODE_START_VALID,
TSC_RECEIVE_MODE_START_ONLY,
TSC_RECEIVE_MODE_VALID_ONLY
};
struct tsc_tsif_params {
enum tsc_source source;
enum tsc_receive_mode receive_mode;
enum tsc_data_type data_type;
int clock_polarity;
int data_polarity;
int start_polarity;
int valid_polarity;
int error_polarity;
int data_swap;
int set_error;
};
#define TSC_SET_TSIF_CONFIG _IOW(TSC_IOCTL_BASE, 3, struct tsc_tsif_params)
This IOCTL enables configuring a specific TSIF with all possible configurations.
TSC Mux - clearing rate mismatch interrupt
------------------------------------------
#define TSC_CLEAR_RATE_MISMATCH_IRQ _IO(TSC_IOCTL_BASE, 4)
This IOCTL is used for clearing the interrupt, which is not done automatically
by the driver.
TSC CI - CAM configuration:
---------------------------
enum tsc_cam_personality {
TSC_CICAM_PERSONALITY_CI,
TSC_CICAM_PERSONALITY_CIPLUS,
TSC_CICAM_PERSONALITY_PCCARD,
TSC_CICAM_PERSONALITY_DISABLE
};
enum tsc_card_status {
TSC_CARD_STATUS_NOT_DETECTED,
TSC_CARD_STATUS_DETECTED,
TSC_CARD_STATUS_FAILURE
};
#define TSC_CICAM_SET_CLOCK _IOW(TSC_IOCTL_BASE, 5, int)
This IOCTL sets the clock rate of the TS from the TSC to the CAM
#define TSC_CAM_RESET _IO(TSC_IOCTL_BASE, 6)
This IOCTL performs HW reset to the CAM
#define TSC_CICAM_PERSONALITY_CHANGE \
_IOW(TSC_IOCTL_BASE, 7, enum tsc_cam_personality)
This IOCTL configures the PCMCIA pins according to the specified card type.
#define TSC_GET_CARD_STATUS _IOR(TSC_IOCTL_BASE, 8, enum tsc_card_status)
This IOCTL queries the card detection pins and returns their status.
TSC CI - Data transactions:
---------------------------
struct tsc_single_byte_mode {
u16 address;
u8 data;
int timeout; /* in msec */
};
struct tsc_buffer_mode {
int buffer_fd;
u16 buffer_size;
int timeout; /* in msec */
};
#define TSC_READ_CAM_MEMORY \
_IOWR(TSC_IOCTL_BASE, 9, struct tsc_single_byte_mode)
#define TSC_WRITE_CAM_MEMORY \
_IOW(TSC_IOCTL_BASE, 10, struct tsc_single_byte_mode)
#define TSC_READ_CAM_IO \
_IOWR(TSC_IOCTL_BASE, 11, struct tsc_single_byte_mode)
#define TSC_WRITE_CAM_IO \
_IOW(TSC_IOCTL_BASE, 12, struct tsc_single_byte_mode)
#define TSC_READ_CAM_BUFFER \
_IOWR(TSC_IOCTL_BASE, 13, struct tsc_buffer_mode)
#define TSC_WRITE_CAM_BUFFER \
_IOW(TSC_IOCTL_BASE, 14, struct tsc_buffer_mode)
These IOCTLs performs a read/write data transaction of the requested type.
Driver parameters
=================
The TSC module receives one parameter:
tsc_iommu_bypass - 0 for using the VBIF, 1 for not using it. Not using the VBIF
is a debug configuration.
Config options
==============
To enable the driver, set CONFIG_TSC to y (built-in) or m (kernel module)
in the kernel configuration menu.
Dependencies
============
The TSC driver uses the ION driver for IOMMU registration and buffer
mapping to BCSS VBIF.
User space utilities
====================
None.
Other
=====
None.
Known issues
============
None.
To do
=====
None.

497
Documentation/arm/msm/tspp2.txt
View File

@ -1,497 +0,0 @@
Introduction
============
TSPP2 Driver
The TSPP2 (Transport Stream Packet Processor v2) is a hardware accelerator
designed to process MPEG-2 Transport Stream (TS) data. It can be used to
process broadcast TV services. The TSPP2 HW processes the TS packets, offloads
the host CPU and supports the real-time processing requirements of such
services.
TS data can be received either from TSIF (Transport Stream Interface) input
or from memory input, to support playing live broadcasts as well as
playback from memory. Recording is also supported.
TSPP2 is a significantly different HW unit than the TSPP unit described in
Documentation/arm/msm/tspp.txt. The functionality is enhanced and the HW
design is different.
Hardware description
====================
The TSPP2 HW contains the TSPP2 core, a BAM (Bus Access Manager, used for DMA
operations) unit, and a VBIF unit (IOMMU).
The TSPP2 HW supports:
a. Up to two TSIF inputs and up to eight memory inputs.
b. Various TS packet sizes (188/192 bytes) and formats (timestamp location).
c. PID filtering.
d. Raw transmit operation for section filtering or recording.
e. Full PES and separated PES transmit operation for audio and video playback.
f. Decryption and re-encryption operations for secure transport streams.
g. PCR extraction.
h. Indexing - identifying patterns in video streams.
The following diagram provides an overview of the TSPP2 HW:
+------------------------------------------------------------------+
| |
| +-------------+ +--------------------+ |
| | TSIF 0 +---> TSPP2 Core | |
| +-------------+ | | |
| | +---------------+ | |
| +-------------+ | | | | |
| | TSIF 1 +---> | Source 0 | | |
| +-------------+ | | | | |
| | | | | |
| | | | | |
| | | +------------+| | +--------------+ |
| | | | Filter 0 +|---------> BAM pipe 3 | |
| | | +------------+| | +--------------+ |
| | | +------------+| | +--------------+ |
| +-------------+ | | | Filter 1 +|---------> BAM pipe 4 | |
| | BAM pipe 0 +---> | +------------+| | +--------------+ |
| +-------------+ | | | | | |
| +-------------+ | +---------------+ | +--------------+ |
| | BAM pipe 1 +--->--------------------|----| | |
| +-------------+ | | | VBIF | |
| +-------------+ | | | IOMMU | |
| | BAM pipe 2 +--->--------------------|----| | |
| +-------------+ +--------------------+ +--------------+ |
+------------------------------------------------------------------+
A source is configured to have either a TSIF input (TSIF 0 or 1) or a
memory input (a BAM pipe). One or more filters are attached to the source.
Each filter has a 13-bit PID and mask values to perform the PID filtering.
Additionally, one or more operations are added to each filter to achieve the
required functionality. Each operation has specific parameters. The operation's
output is usually placed in an output pipe.
The TSPP HW uses its own virtual address space, mapping memory buffer addresses
using the VBIF IOMMU.
Software description
====================
The TSPP2 Linux kernel driver manages the TSPP2 core. The TSPP2 driver utilizes
the SPS driver to configure and manage the BAM unit, which is used to perform
DMA operations and move TS data to/from system memory.
The TSPP2 driver uses the ION driver to control the IOMMU and map user-allocated
buffers to the TSPP2 IOMMU domain.
The TSPP2 is a standard Linux platform device driver. It can be configured as a
loadable or built-in kernel module. The driver is supported only in platforms
that contain the TSPP2 HW.
The driver provides an abstraction of the TSPP2 HW functionality for
kernel-space clients. For example, the dvb/demux kernel driver, which provides
an API for upper layers to perform TS de-multiplexing (including PID filtering,
recording, indexing etc.), uses the TSPP2 driver to utilize the TSPP2 HW and
offload the CPU, instead of doing all the required processing in SW.
For further information please refer to Documentation/dvb/qcom-mpq.txt.
Terminology
-----------
This section describes some of the software "objects" implemented by the driver.
a. TSPP2 device: an instance of the TSPP2 device representing the TSPP2 HW and
its capabilities. The client identifies a device instance according to a
device ID.
b. Indexing table: A TSPP2 device contains 4 indexing tables. These tables are
used to identify patterns in the video stream and report on them.
The client identifies an indexing table according to a table ID.
c. Pipe: a BAM pipe used for DMA operations. The TSPP2 HW has a BAM unit with
31 pipes. A pipe contains a memory buffer and a corresponding descriptor ring,
and is used as the output for TSPP2 data (e.g. PES payload, PES headers,
indexing information etc.). For memory inputs, a pipe is used as the input
buffer where data can be written to for TSPP2 processing. BAM Pipes are
managed by the TSPP2 driver using the SPS driver which controls BAM HW. The
client is responsible for buffer memory allocation, and can control many
BAM-related pipe parameters.
d. Source: a source object represents data "stream" from the TS input,
through the filters and operations that perform the processing on the TS data,
until the output. A source has the following properties:
- Either a TSIF or a memory input.
- For memory input: an input pipe.
- Source-related configuration (e.g., packet size and format).
- One or more PID filters. Each filter contains operations.
- One or more output pipes.
The client is responsible to configure the source object as needed using the
appropriate API. The client identifies a source using a source handle, which
the driver provides when opening a source for use.
e. Filter: a filter object represents a PID filter which is used to get only the
TS packets with specific PIDs and filter out all other TS packets in the stream.
The client adds filters to the source object to define the processing of data.
Each filter has a 13-bit PID value and bit-mask, so a filter can be used to
get TS packets with various PID values. Note, however, that it is highly
recommended to use each filter with a unique PID (i.e., 0x1FFF mask), and it is
mandatory that the PIDs handled by each source's filters are mutually exclusive
(i.e., the client must not configure two filters in the same source that handle
the same PID values). A filter has up to 16 operations that instruct the TSPP2
HW how to process the data. The client identifies a filter using a filter
handle, which the driver provides when opening a filter for use.
f. Operation: an operation object represents a basic building block describing
how data is processed. Operations are added to a filter and are performed on
the data received by this filter, in the order they were added. One or more
operations may be required to achieve the desired functionality. For example,
a "section filtering" functionality requires a raw transmit operation, while a
"recording" functionality requires a raw transmit operations as well as an
indexing operation (to support trick modes).
Driver initialization
---------------------
The driver's probe function is invoked if there is a matching device tree node
(or platform device). The probe function gets the required memory resources
(i.e., register address spaces) and maps them to kernel space for the
driver's use. The probe function also request the required IRQs and gets the
TSPP2 IOMMU domain. Finally, the probe function resets all HW registers to
appropriate default values, and resets all the required software structures.
See API description in Interface section.
Usage examples
--------------
Section filtering example - opening a Raw filter with data from TSIF0:
----------------------------------------------------------------------
u32 dev_id = 0;
u32 src_handle;
u32 pipe_handle;
u32 filter_handle;
u32 iova;
u32 vaddress;
struct tspp2_config cfg = {...};
struct tspp2_pipe_config_params pipe_config;
struct tspp2_pipe_pull_mode_params pull_params = {0, 0};
struct tspp2_operation raw_op;
struct sps_event_notify event;
struct sps_iovec desc;
/* Open TSPP2 device for use */
tspp2_device_open(dev_id);
/* Set global configuration */
tspp2_config_set(dev_id, &cfg);
/* Open source with TSIF0 input */
tspp2_src_open(dev_id, TSPP2_INPUT_TSIF0, &src_handle);
/* Set parsing options if needed, for example: */
tspp2_src_parsing_option_set(src_handle,
TSPP2_SRC_PARSING_OPT_CHECK_CONTINUITY, 1);
/* Assume normal sync byte, assume no need for scrambling configuration */
/* Set packet size and format: */
tspp2_src_packet_format_set(src_handle, TSPP2_PACKET_FORMAT_188_RAW);
/* Since this is TSIF input, flow control is in push mode */
/* Allocate memory for output pipe via ION – not shown here */
/* Open an output pipe for use */
pipe_config.ion_client = ...
pipe_config.buffer_handle = ...
pipe_config.buffer_size = ...
pipe_config.pipe_mode = TSPP2_SRC_PIPE_OUTPUT;
pipe_config.sps_cfg.descriptor_size = 188;
pipe_config.sps_cfg.setting = (SPS_O_AUTO_ENABLE | SPS_O_HYBRID |
SPS_O_OUT_OF_DESC | SPS_O_ACK_TRANSFERS);
pipe_config.sps_cfg.wakeup_events = SPS_O_OUT_OF_DESC;
pipe_config.sps_cfg.callback = ...
pipe_config.sps_cfg.user_info = ...
tspp2_pipe_open(dev_id, &pipe_config, &iova, &pipe_handle);
/* Attache the pipe to the source */
tspp2_src_pipe_attach(src_handle, pipe_handle, &pull_params);
/* Open a filter for PID 13 */
tspp2_filter_open(src_handle, 13, 0x1FFF, &filter_handle);
/* Add a raw transmit operation */
raw_op.type = TSPP2_OP_RAW_TRANSMIT;
raw_op.params.raw_transmit.input = TSPP2_OP_BUFFER_A;
raw_op.params.raw_transmit.timestamp_mode = TSPP2_OP_TIMESTAMP_NONE;
raw_op.params.raw_transmit.skip_ts_packets_with_errors = 0;
raw_op.params.raw_transmit.output_pipe_handle = pipe_handle;
tspp2_filter_operations_add(filter_handle, &raw_op, 1);
/* Enable filter and source to start getting data */
tspp2_filter_enable(filter_handle);
tspp2_source_enable(src_handle);
/*
* Data path: poll pipe (or get notifications from pipe via
* registered callback).
*/
tspp2_pipe_last_address_used_get(pipe_handle, &vaddress);
/* Process data... */
/* Get and release descriptors: */
tspp2_pipe_descriptor_get(pipe_handle, &desc);
tspp2_pipe_descriptor_put(pipe_handle, desc.addr, desc.size, ...);
/* Teardown: */
tspp2_src_disable(src_handle);
tspp2_filter_disable(filter_handle);
tspp2_filter_close(filter_handle);
tspp2_src_pipe_detach(src_handle, pipe_handle);
tspp2_pipe_close(pipe_handle);
tspp2_src_close(src_handle);
tspp2_device_close(dev_id);
Debug facilities
----------------
The TSPP2 driver supports several debug facilities via debugfs:
a. Ability to read the status of TSIF and TSPP2 HW registers via debugfs.
b. Ability to print HW statistics, error and performance counters via debugfs.
c. Ability to print SW status via debugfs.
Design
======
The TSPP2 driver is a regular Linux platform driver designed to support the
TSPP2 HW available on specific Qualcomm SoCs.
The driver provides an extensive kernel-space API to allow the client full
control over the configuration of the TSPP2 HW, while encapsulating HW
implementation details that are not relevant to the client.
The driver enforces HW restrictions and checks for input parameters
validity, providing a success or failure return value for each API function.
However, the driver does not enforce any high-level policy with regard to the
correct use of the TSPP2 HW for various use-cases.
Power Management
================
The TSPP2 driver prevents the CPU from sleeping while the HW is active by
using the wakeup_source API. When the HW is not active (i.e., no sources
configured), the driver indicates it is ready for system suspend by invoking
__pm_relax(). When the HW needs to be active (i.e., a source has been opened and
enabled), the driver invokes __pm_stay_awake().
In a similar manner, the driver enables the HW clocks only when needed.
The TSPP2 HW manages power saving automatically when the HW is not used.
No SW involvement is required.
SMP/multi-core
==============
The driver uses a mutex for mutual exclusion between kernel API calls.
A spinlock is used to protect accesses to its internal databases which can be
performed both from interrupt handler context and from API context.
Security
========
None.
Performance
===========
Control operations are not considered as performance critical.
Most of the control operations are assumed to be fairly uncommon.
Data-path operations involve only getting descriptors from the pipe and
releasing them back to the pipe for reuse.
Interface
=========
Kernel-space API
----------------
Control path API
-------------------
TSPP2 device open / close API:
------------------------------
int tspp2_device_open(u32 dev_id);
int tspp2_device_close(u32 dev_id);
Global configuration for the TSPP2 device:
------------------------------------------
int tspp2_config_set(u32 dev_id, const struct tspp2_config *cfg);
Set device global configuration.
int tspp2_config_get(u32 dev_id, struct tspp2_config *cfg);
Get current device global configuration.
Configure Indexing Tables:
--------------------------
int tspp2_indexing_prefix_set(u32 dev_id, u8 table_id, u32 value, u32 mask);
Set prefix value and mask of an indexing table.
int tspp2_indexing_patterns_add(u32 dev_id, u8 table_id, const u32 *values,
const u32 *masks, u8 patterns_num);
Add patterns to an indexing table.
int tspp2_indexing_patterns_clear(u32 dev_id, u8 table_id);
Clear all patterns of an indexing table
Opening and closing Pipes:
--------------------------
int tspp2_pipe_open(u32 dev_id, const struct tspp2_pipe_config_params *cfg,
u32 *iova, u32 *pipe_handle);
Open a pipe for use.
int tspp2_pipe_close(u32 pipe_handle);
Close an opened pipe.
Source configuration:
---------------------
int tspp2_src_open(u32 dev_id, enum tspp2_src_input input, u32 *src_handle);
Open a new source for use.
int tspp2_src_close(u32 src_handle);
Close an opened source.
int tspp2_src_parsing_option_set(u32 src_handle,
enum tspp2_src_parsing_option option, int value);
Set source parsing configuration option.
int tspp2_src_parsing_option_get(u32 src_handle,
enum tspp2_src_parsing_option option, int *value);
Get source parsing configuration option.
int tspp2_src_sync_byte_config_set(u32 src_handle, int check_sync_byte,
u8 sync_byte_value);
Set source sync byte configuration.
int tspp2_src_sync_byte_config_get(u32 src_handle, int *check_sync_byte,
u8 *sync_byte_value);
Get source sync byte configuration.
int tspp2_src_scrambling_config_set(u32 src_handle,
const struct tspp2_src_scrambling_config *cfg);
Set source scrambling configuration.
int tspp2_src_scrambling_config_get(u32 src_handle,
struct tspp2_src_scrambling_config *cfg);
Get source scrambling configuration.
int tspp2_src_packet_format_set(u32 src_handle,
enum tspp2_packet_format format);
Set source packet size and format.
int tspp2_src_pipe_attach(u32 src_handle, u32 pipe_handle,
const struct tspp2_pipe_pull_mode_params *cfg);
Attach a pipe to a source.
int tspp2_src_pipe_detach(u32 src_handle, u32 pipe_handle);
Detach a pipe from a source.
int tspp2_src_enable(u32 src_handle);
Enable source (start using it).
int tspp2_src_disable(u32 src_handle);
Disable source (stop using it).
int tspp2_src_filters_clear(u32 src_handle);
Clear all filters from a source.
Filter and Operation configuration:
-----------------------------------
int tspp2_filter_open(u32 src_handle, u16 pid, u16 mask, u32 *filter_handle);
Open a new filter and add it to a source.
int tspp2_filter_close(u32 filter_handle);
Close a filter.
int tspp2_filter_enable(u32 filter_handle);
Enable a filter.
int tspp2_filter_disable(u32 filter_handle);
Disable a filter.
int tspp2_filter_operations_set(u32 filter_handle,
const struct tspp2_operation *ops, u8 operations_num);
Set (add or update) operations to a filter.
int tspp2_filter_operations_clear(u32 filter_handle);
Clear all operations from a filter.
int tspp2_filter_current_scrambling_bits_get(u32 filter_handle,
u8 *scrambling_bits_value);
Get the current scrambling bits.
Events notifications registration:
----------------------------------
int tspp2_global_event_notification_register(u32 dev_id,
u32 global_event_bitmask,
void (*callback)(void *cookie),
void *cookie);
Get notified on a global event.
int tspp2_src_event_notification_register(u32 src_handle,
u32 src_event_bitmask,
void (*callback)(void *cookie),
void *cookie);
Get notified on a source event.
int tspp2_filter_event_notification_register(u32 filter_handle,
u32 filter_event_bitmask,
void (*callback)(void *cookie),
void *cookie);
Get notified on a filter event.
Data path API
----------------
int tspp2_pipe_descriptor_get(u32 pipe_handle, struct sps_iovec *desc);
Get a data descriptor from a pipe.
int tspp2_pipe_descriptor_put(u32 pipe_handle, u32 addr,
u32 size, u32 flags);
Put (release) a descriptor for reuse by the pipe.
int tspp2_pipe_last_address_used_get(u32 pipe_handle, u32 *address);
Get the last address the TSPP2 used.
int tspp2_data_write(u32 src_handle, u32 offset, u32 size);
Write (feed) data to a source.
User-space API
--------------
The TSPP2 driver does not provide any user-space API, only a kernel-space API.
The dvb/demux driver, which utilizes the TSPP2 driver (and HW), provides an
extensive user-space API, allowing upper layers to achieve complex demuxing
functionality.
For further information please refer to Documentation/dvb/qcom-mpq.txt.
Driver parameters
=================
The TSPP2 driver supports the following module parameter:
tspp2_iommu_bypass: Bypass VBIF/IOMMU and use physical buffer addresses
instead. This is mostly useful for debug purposes if something is wrong with
the IOMMU configuration. Default is false.
Platform-dependent parameters (e.g., IRQ numbers) are provided to the driver
via the device tree mechanism or the platform device data mechanism.
Config options
==============
To enable the driver, set CONFIG_TSPP2 to y (built-in) or m (kernel module)
in the kernel configuration menu.
Dependencies
============
a. The TSPP2 driver uses the SPS driver to control the BAM unit.
b. The TSPP2 driver uses the ION driver for IOMMU registration and buffer
mapping. The client is responsible to allocate memory buffers via ION.
User space utilities
====================
None.
Other
=====
None.
Known issues
============
None.
To do
=====
None.

2
drivers/media/platform/msm/broadcast/Makefile
View File

@ -3,9 +3,7 @@
#
obj-$(CONFIG_TSPP) += tspp.o
obj-$(CONFIG_TSPP2) += tspp2.o
obj-$(CONFIG_CI_BRIDGE_SPI) += ci-bridge-spi.o
obj-$(CONFIG_TSC) += tsc.o
obj-$(CONFIG_ENSIGMA_UCCP_330) += ensigma_uccp330.o
obj-$(CONFIG_DEMOD_WRAPPER) += demod_wrapper.o

3450
drivers/media/platform/msm/broadcast/tsc.c
View File

File diff suppressed because it is too large Load Diff

8578
drivers/media/platform/msm/broadcast/tspp2.c
View File

File diff suppressed because it is too large Load Diff