Piteball/android_kernel_samsung_msm8976
1
1
Fork 0
mirror of https://github.com/team-infusion-developers/android_kernel_samsung_msm8976.git synced 2024-11-01 10:33:27 +00:00
Code Issues Projects Releases Wiki Activity

tspp: Add transport stream packet processor

Browse source 
Including:

commit 6bac783fae7e7c5a5bfc95e2cdc9b4f22ca53d44
Author: Hamad Kadmany <hkadmany@codeaurora.org>
Date:   Thu Dec 20 18:30:40 2012 +0200

    tspp: Disable read-complete interrupt

    Read-complete interrupt can be generated from TSPP HW for test
    purposes only. It is generated for each TS packet TSPP fetches from
    TSIF interface. Having it enabled cause great load of interrupts
    that are not used by the SW.

    Change-Id: If2038f184a8b0904fba3e1cca5e110fd9daa52d3
    Signed-off-by: Hamad Kadmany <hkadmany@codeaurora.org>

commit 81cee0596e3cdf8102bf8c8ef45e5f3a07fc8a4d
Author: Hamad Kadmany <hkadmany@codeaurora.org>
Date:   Thu Nov 29 14:15:57 2012 +0200

    tspp: Improve data-path handling

    Existing driver allocated BAM descriptor at fixed sizes each
    with interrupt flag set. Notification on data was received when
    the descriptor is fully consumed by the HW. The descriptor size
    on one hand need to be big enough so that we don't receive too much
    interrupts for high-bitrate streams, and on other hand needs
    to be small enough so that for low-bitrate stream we are not starved
    waiting for data for a long period of time.

    The change adds support of allocating small descriptors and set
    interrupt flags on part of descriptors. In addition, expiration
    timer is used so that if interrupt is not received after long period
    of time the timer handler reports back descriptors are already ready
    to be consumed. This allows low-rate of interrupts and
    handling of low-bitrate streams.

    As descriptors are smaller now (size of single TS packet), exposed
    API within SW demux that handles a single packet to save the function
    call to the API that handles multiple packets for efficiency. Information
    regarding the new buffer allocation was added to debugfs.

    CRs-Fixed: 420818
    Change-Id: I4bb05177774ab0e0bad0737ca1106a0c33f843ae
    Signed-off-by: Hamad Kadmany <hkadmany@codeaurora.org>

commit 44307d32e23a2bb2a190d88bb049cc34d1e20418
Author: Hamad Kadmany <hkadmany@codeaurora.org>
Date:   Sun Nov 25 09:49:51 2012 +0200

    misc: tspp: Enable notification of TSIF status and expose it in debugfs

    Enable TSIF status interrupt to expose the following
    information in debugfs:
    - stat_rx_chunks: Counts number of TS packets chunks received from HW.
    - stat_overflow: Counts number of times buffer has overflowed.
    - stat_lost_sync: Counts number of times TSIF lost sync with input.
    - stat_timeout: Counts number of times TSIF reached timeout
    waiting for packets.

    All counters can read and reset by writing to the respective file.

    Change-Id: I475c2c0845c85ac22ea720059fb28c4a588fedcf
    Signed-off-by: Hamad Kadmany <hkadmany@codeaurora.org>

commit 72b785570b265c6fcb4cb907c0c3a3a4b311f1f1
Author: Liron Kuch <lkuch@codeaurora.org>
Date:   Tue Oct 30 17:47:50 2012 +0200

    media: dvb: mpq: TSPP output buffer allocation by demux plugin

    The TSPP driver can allocate its output buffers internally or
    externally. External buffer allocation is required when Demux wishes
    to use the ION driver to allocate a physically contiguous buffer
    (e.g. to pass to TZ).
    This commit improves the TSPP driver support for external buffer
    allocation and implements the external memory allocation and free
    functions in the Demux driver.

    Change-Id: I71da4f18c090ef224c4fc7b23f55b9b3636be996
    Signed-off-by: Liron Kuch <lkuch@codeaurora.org>

commit 92705b3eb380826abf8ddefc25a8d210ffa64ff5
Author: Hamad Kadmany <hkadmany@codeaurora.org>
Date:   Tue Oct 23 14:15:41 2012 +0200

    tspp: Add option to inverse tsif signals

    TSIF signals (clock, data, enable and sync) may be configured
    to be inversed at TSPP unit input. This is useful in case
    TSIF signals from external units need to be inversed.

    Change-Id: Idd21948baccedc7499b31ed1d4df0f737538c870
    Signed-off-by: Hamad Kadmany <hkadmany@codeaurora.org>

commit 435ad8e2157eec5783a435f1e7ec47f67d759882
Author: Joel Nider <jnider@codeaurora.org>
Date:   Wed Dec 14 16:53:30 2011 +0200

    tspp: add kernel api for video demux component

    The demux is an in-kernel software component whose purpose is to take
    an incoming TSIF stream and split it into multiple output channels
    based on the PID field in each TS packet. Each output channel can be
    used for a different purpose, such as audio, video or channel
    information. In order to get good performance when moving such large
    data streams around, the demux was placed in kernel-space as to
    prevent copying memory buffers between kernel-space and user-space, at
    least at this early stage in processing the traffic. Originally the
    design of the TSPP driver was based on the earlier TSIF driver, so it
    contained only a user-space API.

    Change-Id: I22799eb19d9049e3635d5c589b02f999d9b8e1c7
    Signed-off-by: Joel Nider <jnider@codeaurora.org>

commit 6544f3e52c9c1707a5a8fa90d32f89d80dabb4b9
Author: Joel Nider <jnider@codeaurora.org>
Date:   Tue Jul 10 13:50:06 2012 +0300

    tspp: use new clock preparation functions

    Replace the clk_enable() with clk_prepare_enable() and replace
    clk_disable() with clk_disable_unprepare() functions.

    Change-Id: I63479090eccbeac46f091bf95faeb857139d23a4
    Signed-off-by: Joel Nider <jnider@codeaurora.org>

commit b9662ca49cfe619e076476dcf8297a4031f0c310
Author: Joel Nider <jnider@codeaurora.org>
Date:   Sun Jun 10 14:21:11 2012 +0300

    tspp: use device name when getting clock

    The new method for requesting clocks requires a driver to pass its
    device name for comparison to the list of available clocks.

    Change-Id: Ica5b09447de177beead90f8b7c721b84820fbdf7
    Signed-off-by: Joel Nider <jnider@codeaurora.org>

commit 5556a8524591e4d1c4c9188316551900e8b8382d
Author: Joel Nider <jnider@codeaurora.org>
Date:   Sun Oct 16 10:52:13 2011 +0200

    misc: tspp: adding TSPP driver files

    The TSPP driver manages the transport stream packet processor.  This core
    is used to offload the main CPU by handling MPEG TS packets, generally
    coming from a broadcast modem using the ISDB-T (or variant) protocol.

    Change-Id: Ia4c16dcce970ae0f52d8d17957a92fce34ecdb44
    Signed-off-by: Joel Nider <jnider@codeaurora.org>

Signed-off-by: David Brown <davidb@codeaurora.org>
This commit is contained in:
David Brown 2013-01-14 15:32:32 -08:00 committed by Stephen Boyd
parent b7a7545d59
commit 2bd7216ba8
6 changed files with 2363 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

250
Documentation/arm/msm/tspp.txt Normal file
View file

@ -0,0 +1,250 @@
Introduction
============
The TSPP (Transport stream packet processor) is a hardware accelerator
designed to process MPEG2 TS (transport stream) data. It is mainly used for
broadcast terrestrial services to off-load the host CPU from real-time
sensitive TS processing for high bandwidth streams (~20Mbps). Data is received
either via TSIF (Transport stream interface) or system memory.
The TSPP driver manages the TSIF 12Seg HW core, which consists of a TSPP, a
BAM (Bus access manager, used for DMA) and two TSIF inputs.
It is applicable to the TSIF 12Seg core found on select Qualcomm MSM chips.
For more information on the TSIF interface, please refer to TSIF documentation
(Documentation/arm/msm/tsif.txt).
For more information on the BAM interface, please refer to SPS documentation
(Documentation/dma/sps/sps_architecture.txt).
Hardware description
====================
The TSPP unit expands the capabilities of the TSIF interface by adding MPEG2
stream processing such as:
- Elementary Stream PID filtering and de-multiplexing
- Several TSP processing operation modes:
- TSP Raw processing (with or w/o suffix)
- TSP PES assembly
- Error handling
- Multi2 decryption
+-------------+ +------+
+>|ARM subsystem| |Memory|
| +-------------+ +------+
| | |
I| | |
R| ========================== System bus
Q| |
s| | TSIF 12Seg
| +-----------------------+
| | +---+ |
| | |BAM| |
| | +---+ | GPIOs
| | | +------+--|-------- TSIF 0 clk
| | +----+ |TSIF 0|--|-------- TSIF 0 data
+-| | |-----+------+--|-------- TSIF 0 en
| |TSPP| |
| | |-----+------+--|-------- TSIF 1 clk
| +----+ |TSIF 1|--|-------- TSIF 1 data
| +------+--|-------- TSIF 1 en
+-----------------------+
The TSPP unit receives an MPEG2 transport stream either via the two TSIF
interfaces, or via system memory.
It uses the BAM interface to transfer data to and from system memory.
The ARM subsystem receives interrupts on various error conditions from TSPP
and TSIF units, and on data transfer events from the BAM.
Software Description
====================
The TSPP driver is responsible for:
- TSPP/TSIF hardware configuration (using SPS driver to configure BAM
hardware)
- TSIF GPIO/Clocks configuration
- Memory resource management
- Handling TSIF/TSPP interrupts and BAM events
- TSPP Power management
TSPP Terminology
----------------
Device - the TSPP hardware instance
- the device contains many streams
Stream: All data that is received from a particular TS packet source
- For example, MPEG2 Transport Stream from TSIF0
- A stream can consist of many channels
Channel: A channel routes part of a stream to a specified memory location
- For example, video and audio can be routed to different memory locations
using different channels
- Channel contents are defined by filters
Filter: Enables TS packet filtering and routing according to PID (packet ID)
- The decision regarding which PIDs in the stream will be routed to a
channel is done via filters
- Several filters can be registered to the same channel
- Filters can pass TS packets as-is (Raw mode) or assemble them into PES
packets (PES mode)
- Groups of contiguous PIDs can be filtered together (i.e. PSI/SI 0x0-0x2F,
1Seg PMTs 0x1FC8-0x1FCF)
- Filters can be used to discard packets (e.g. eliminate processing of
unwanted channels)
Init flow:
----------
Driver registers BAM (via SPS driver) and initializes TSIF/TSPP hardware.
Control path:
-------------
1. Client opens a TSPP stream and channel
2. Client notifies the driver of the source stream (TSIF0/TSIF1/Memory)
- TSPP driver allocates memory for the channel (circular buffer)
- As the amount of memory varies according to stream bandwidth (which the
driver doesn't know), a client can hint to the driver about the required
memory or stream bandwidth
- TSPP driver configures TSIF/BAM hardware according to selected stream
3. Client notifies the driver to filter a set of PIDs for the selected channel
- TSPP driver configures TSPP hardware filters accordingly
4. Client can now read data received from the selected channel
Optional: Scrambling keys can be configured for a filter to decrypt Multi2
encrypted streams. The scrambling keys are received encrypted in-stream every
~2 seconds. The client uses a smart card and master key to decrypt the
received scrambling keys. The master key remains inside the smart card and is
never revealed to software.
Conceptual flow:
Client TSPP Driver SPS Driver Hardware
| | | |
| | Init TSIF/TSPP | |
| |---------------------------|------------------>|
| | Register BAM | |
| |-------------------------->| |
| | | |
| open(tspp.5) | | |
|-------------------------->| | |
| ioctl(tspp.5,SOURCE,TSIF0)| | |
|-------------------------->| | |
| | buff[0..N] = alloc() | |
| |----------> | |
| | Connect(TSPP,MEM) | |
| |-------------------------->| |
| | Transfer(buff[0..N]) | |
| |-------------------------->| |
| | | |
| | Configure TSIF0 | |
| |---------------------------|------------------>|
| | | |
| ioctl(tspp.5,FILTER,pid) | | |
|-------------------------->| | |
| | Configure TSPP filters | |
| |---------------------------|------------------>|
| | | |
| | | INT |
| | |<------------------|
| | notify(EOT,buff[x]) | |
| |<--------------------------| |
| | Transfer(buff[y]) | |
| |-------------------------->| |
| | | |
| read(tspp.5) | | |
|-------------------------->| | |
| | | |
Data path:
----------
The TSPP driver is not involved in data transfer, other than managing the
circular buffer pointers when a transfer is complete. Data loss can occur if
a client cannot keep up with stream bandwidth.
The driver does not notify the application if there is data loss. It is
assumed that the application will read data when the data is ready, and when
the application is able.
API
===
int tspp_open_stream(tspp_device *dev, void *stream, void *channel, tspp_mode
mode);
int tspp_close_stream(tspp_device *dev, void *stream);
int tspp_open_channel(tspp_device *dev, int dest, int bufsize, void *channel);
int tspp_close_channel(tspp_device *dev, void *channel);
int tspp_register_filter(tspp_device *dev, void *channel, tspp_filter *filter);
int tspp_unregister_filter(tspp_device *dev, void *channel, int pid);
Refer to chrdev implementation in kernel/drivers/misc/tspp.c for an example of
how to use this api.
Each stream is represented by a chrdev device
16 available devices: /dev/tspp00 - /dev/tspp15
Each device implements these functions:
open()
close()
read()
ioctl()
ioctl() contains several sub-functions:
0: select source
1: add filter
2: remove filter
3: set decryption keys
4: set initial cbc values (IV)
5: set system keys
6: set buffer size
You can refer to include/linux/tspp.h for the details on the structures
associated with these IOCTL calls.
Design
======
Design is based on the existing TSIF driver, with added control functionality
for the extra hardware features.
Power Management
===============
TSPP driver prevents MSM from sleeping while TSPP hardware is active.
To achieve this, the driver holds the wake lock. When no channels are
configured to receive data, the driver stops the clocks to save power.
It will register for suspend/resume in the future.
SMP/multi-core
==============
Driver is fully SMP aware.
Performance
===========
Control flows are rare.
Data path only involves maintaining the circular buffer pointers.
Interface
=========
Driver exposes a char device interface to user-space for each channel.
Control transactions are performed via ioctl on the channel. Data is read as
any regular char device (blocking and non-blocking). Please see sequence
under software description for more info.
Debugfs may be used for debug purposes. Through debugfs, all of the TSIF
registers can be accessed under /sys/kernel/debug/tsif0 and tsif1. The
TSPP registers are found under /sys/kernel/debug/tspp0. If you cannot
see these devices, then either the driver has been built without debugfs
support (check the define TSPP_USE_DEBUGFS in tspp.c) or the debugfs has
not been mounted correctly (or mounted in a different location).
Driver Parameters
=================
TSPP driver has target-specific parameters:
- Memory base addresses for TSIF/TSPP/BAM
- TSIF/TSPP/BAM IRQ numbers
- TSIF GPIO numbers
Config Options
==============
To enable the driver, set CONFIG_TSPP (=y or =m) in the appropriate
config file for the platform.
Dependencies
============
The TSPP driver depends on the SPS driver to configure BAM hardware.
User space utilities
====================
The TSPP test suite can be found in:
vendor/qcom/proprietary/kernel-tests/tspp
Known Issues
============
Currently PES processing mode cannot be configured for streams in which the PES
length is 0. This is a HW limitation.

8
drivers/misc/Kconfig
View file

@ -531,6 +531,14 @@ config SRAM
the genalloc API. It is supposed to be used for small on-chip SRAM
areas found on many SoCs.
config TSPP
depends on ARCH_MSM
tristate "TSPP (Transport Stream Packet Processor) Support"
---help---
Transport Stream Packet Processor is used to offload the
processing of MPEG transport streams from the main processor.
This can also be compiled as a loadable module.
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"

1
drivers/misc/Makefile
View file

@ -54,3 +54,4 @@ obj-$(CONFIG_INTEL_MEI) += mei/
obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
obj-$(CONFIG_SRAM) += sram.o
obj-$(CONFIG_TSPP) += tspp.o

2019
drivers/misc/tspp.c Normal file
View file

File diff suppressed because it is too large Load diff

1
include/uapi/linux/Kbuild
View file

@ -383,6 +383,7 @@ header-y += tiocl.h
header-y += tipc.h
header-y += tipc_config.h
header-y += toshiba.h
header-y += tspp.h
header-y += tty.h
header-y += tty_flags.h
header-y += types.h

84
include/uapi/linux/tspp.h Normal file
View file

@ -0,0 +1,84 @@
#ifndef _UAPI_TSPP_H_
#define _UAPI_TSPP_H_
#include <linux/ioctl.h>
#define TSPP_NUM_SYSTEM_KEYS 8
enum tspp_key_parity {
TSPP_KEY_PARITY_EVEN,
TSPP_KEY_PARITY_ODD
};
enum tspp_source {
TSPP_SOURCE_TSIF0,
TSPP_SOURCE_TSIF1,
TSPP_SOURCE_MEM,
TSPP_SOURCE_NONE = -1
};
enum tspp_mode {
TSPP_MODE_DISABLED,
TSPP_MODE_PES,
TSPP_MODE_RAW,
TSPP_MODE_RAW_NO_SUFFIX
};
struct tspp_filter {
int pid;
int mask;
enum tspp_mode mode;
int priority; /* 0 - 15 */
int decrypt;
enum tspp_source source;
};
struct tspp_select_source {
enum tspp_source source;
};
struct tspp_pid {
int pid;
};
struct tspp_key {
enum tspp_key_parity parity;
int lsb;
int msb;
};
struct tspp_iv {
int data[2];
};
struct tspp_system_keys {
int data[TSPP_NUM_SYSTEM_KEYS];
};
struct tspp_buffer {
int size;
};
/* defines for IOCTL functions */
/* read Documentation/ioctl-number.txt */
/* some random number to avoid coinciding with other ioctl numbers */
#define TSPP_IOCTL_BASE 0xAA
#define TSPP_IOCTL_SELECT_SOURCE \
_IOW(TSPP_IOCTL_BASE, 0, struct tspp_select_source)
#define TSPP_IOCTL_ADD_FILTER \
_IOW(TSPP_IOCTL_BASE, 1, struct tspp_filter)
#define TSPP_IOCTL_REMOVE_FILTER \
_IOW(TSPP_IOCTL_BASE, 2, struct tspp_pid)
#define TSPP_IOCTL_SET_KEY \
_IOW(TSPP_IOCTL_BASE, 3, struct tspp_key)
#define TSPP_IOCTL_SET_IV \
_IOW(TSPP_IOCTL_BASE, 4, struct tspp_iv)
#define TSPP_IOCTL_SET_SYSTEM_KEYS \
_IOW(TSPP_IOCTL_BASE, 5, struct tspp_system_keys)
#define TSPP_IOCTL_BUFFER_SIZE \
_IOW(TSPP_IOCTL_BASE, 6, struct tspp_buffer)
#define TSPP_IOCTL_LOOPBACK \
_IOW(TSPP_IOCTL_BASE, 0xFF, int)
#endif /* _UAPI_TSPP_H_ */