Joel Nider | 4ad166c | 2012-01-15 17:49:26 +0200 | [diff] [blame] | 1 | Introduction |
| 2 | ============ |
| 3 | The TSPP (Transport stream packet processor) is a hardware accelerator |
| 4 | designed to process MPEG2 TS (transport stream) data. It is mainly used for |
| 5 | broadcast terrestrial services to off-load the host CPU from real-time |
| 6 | sensitive TS processing for high bandwidth streams (~20Mbps). Data is received |
| 7 | either via TSIF (Transport stream interface) or system memory. |
| 8 | The TSPP driver manages the TSIF 12Seg HW core, which consists of a TSPP, a |
| 9 | BAM (Bus access manager, used for DMA) and two TSIF inputs. |
| 10 | It is applicable to the TSIF 12Seg core found on select Qualcomm MSM chips. |
| 11 | |
| 12 | For more information on the TSIF interface, please refer to TSIF documentation |
| 13 | (Documentation/arm/msm/tsif.txt). |
| 14 | For more information on the BAM interface, please refer to SPS documentation |
| 15 | (Documentation/dma/sps/sps_architecture.txt). |
| 16 | |
| 17 | Hardware description |
| 18 | ==================== |
| 19 | The TSPP unit expands the capabilities of the TSIF interface by adding MPEG2 |
| 20 | stream processing such as: |
| 21 | - Elementary Stream PID filtering and de-multiplexing |
| 22 | - Several TSP processing operation modes: |
| 23 | - TSP Raw processing (with or w/o suffix) |
| 24 | - TSP PES assembly |
| 25 | - Error handling |
| 26 | - Multi2 decryption |
| 27 | |
| 28 | +-------------+ +------+ |
| 29 | +>|ARM subsystem| |Memory| |
| 30 | | +-------------+ +------+ |
| 31 | | | | |
| 32 | I| | | |
| 33 | R| ========================== System bus |
| 34 | Q| | |
| 35 | s| | TSIF 12Seg |
| 36 | | +-----------------------+ |
| 37 | | | +---+ | |
| 38 | | | |BAM| | |
| 39 | | | +---+ | GPIOs |
| 40 | | | | +------+--|-------- TSIF 0 clk |
| 41 | | | +----+ |TSIF 0|--|-------- TSIF 0 data |
| 42 | +-| | |-----+------+--|-------- TSIF 0 en |
| 43 | | |TSPP| | |
| 44 | | | |-----+------+--|-------- TSIF 1 clk |
| 45 | | +----+ |TSIF 1|--|-------- TSIF 1 data |
| 46 | | +------+--|-------- TSIF 1 en |
| 47 | +-----------------------+ |
| 48 | |
| 49 | The TSPP unit receives an MPEG2 transport stream either via the two TSIF |
| 50 | interfaces, or via system memory. |
| 51 | It uses the BAM interface to transfer data to and from system memory. |
| 52 | The ARM subsystem receives interrupts on various error conditions from TSPP |
| 53 | and TSIF units, and on data transfer events from the BAM. |
| 54 | |
| 55 | Software Description |
| 56 | ==================== |
| 57 | The TSPP driver is responsible for: |
| 58 | - TSPP/TSIF hardware configuration (using SPS driver to configure BAM |
| 59 | hardware) |
| 60 | - TSIF GPIO/Clocks configuration |
| 61 | - Memory resource management |
| 62 | - Handling TSIF/TSPP interrupts and BAM events |
| 63 | - TSPP Power management |
| 64 | |
| 65 | TSPP Terminology |
| 66 | ---------------- |
| 67 | Device - the TSPP hardware instance |
| 68 | - the device contains many streams |
| 69 | Stream: All data that is received from a particular TS packet source |
| 70 | - For example, MPEG2 Transport Stream from TSIF0 |
| 71 | - A stream can consist of many channels |
| 72 | Channel: A channel routes part of a stream to a specified memory location |
| 73 | - For example, video and audio can be routed to different memory locations |
| 74 | using different channels |
| 75 | - Channel contents are defined by filters |
| 76 | Filter: Enables TS packet filtering and routing according to PID (packet ID) |
| 77 | - The decision regarding which PIDs in the stream will be routed to a |
| 78 | channel is done via filters |
| 79 | - Several filters can be registered to the same channel |
| 80 | - Filters can pass TS packets as-is (Raw mode) or assemble them into PES |
| 81 | packets (PES mode) |
| 82 | - Groups of contiguous PIDs can be filtered together (i.e. PSI/SI 0x0-0x2F, |
| 83 | 1Seg PMTs 0x1FC8-0x1FCF) |
| 84 | - Filters can be used to discard packets (e.g. eliminate processing of |
| 85 | unwanted channels) |
| 86 | |
| 87 | Init flow: |
| 88 | ---------- |
| 89 | Driver registers BAM (via SPS driver) and initializes TSIF/TSPP hardware. |
| 90 | |
| 91 | Control path: |
| 92 | ------------- |
| 93 | 1. Client opens a TSPP stream and channel |
| 94 | 2. Client notifies the driver of the source stream (TSIF0/TSIF1/Memory) |
| 95 | - TSPP driver allocates memory for the channel (circular buffer) |
| 96 | - As the amount of memory varies according to stream bandwidth (which the |
| 97 | driver doesn't know), a client can hint to the driver about the required |
| 98 | memory or stream bandwidth |
| 99 | - TSPP driver configures TSIF/BAM hardware according to selected stream |
| 100 | 3. Client notifies the driver to filter a set of PIDs for the selected channel |
| 101 | - TSPP driver configures TSPP hardware filters accordingly |
| 102 | 4. Client can now read data received from the selected channel |
| 103 | |
| 104 | Optional: Scrambling keys can be configured for a filter to decrypt Multi2 |
| 105 | encrypted streams. The scrambling keys are received encrypted in-stream every |
| 106 | ~2 seconds. The client uses a smart card and master key to decrypt the |
| 107 | received scrambling keys. The master key remains inside the smart card and is |
| 108 | never revealed to software. |
| 109 | |
| 110 | Conceptual flow: |
| 111 | Client TSPP Driver SPS Driver Hardware |
| 112 | | | | | |
| 113 | | | Init TSIF/TSPP | | |
| 114 | | |---------------------------|------------------>| |
| 115 | | | Register BAM | | |
| 116 | | |-------------------------->| | |
| 117 | | | | | |
| 118 | | open(tspp.5) | | | |
| 119 | |-------------------------->| | | |
| 120 | | ioctl(tspp.5,SOURCE,TSIF0)| | | |
| 121 | |-------------------------->| | | |
| 122 | | | buff[0..N] = alloc() | | |
| 123 | | |----------> | | |
| 124 | | | Connect(TSPP,MEM) | | |
| 125 | | |-------------------------->| | |
| 126 | | | Transfer(buff[0..N]) | | |
| 127 | | |-------------------------->| | |
| 128 | | | | | |
| 129 | | | Configure TSIF0 | | |
| 130 | | |---------------------------|------------------>| |
| 131 | | | | | |
| 132 | | ioctl(tspp.5,FILTER,pid) | | | |
| 133 | |-------------------------->| | | |
| 134 | | | Configure TSPP filters | | |
| 135 | | |---------------------------|------------------>| |
| 136 | | | | | |
| 137 | | | | INT | |
| 138 | | | |<------------------| |
| 139 | | | notify(EOT,buff[x]) | | |
| 140 | | |<--------------------------| | |
| 141 | | | Transfer(buff[y]) | | |
| 142 | | |-------------------------->| | |
| 143 | | | | | |
| 144 | | read(tspp.5) | | | |
| 145 | |-------------------------->| | | |
| 146 | | | | | |
| 147 | |
| 148 | |
| 149 | Data path: |
| 150 | ---------- |
| 151 | The TSPP driver is not involved in data transfer, other than managing the |
| 152 | circular buffer pointers when a transfer is complete. Data loss can occur if |
| 153 | a client cannot keep up with stream bandwidth. |
| 154 | The driver does not notify the application if there is data loss. It is |
| 155 | assumed that the application will read data when the data is ready, and when |
| 156 | the application is able. |
| 157 | |
| 158 | API |
| 159 | === |
| 160 | int tspp_open_stream(tspp_device *dev, void *stream, void *channel, tspp_mode |
| 161 | mode); |
| 162 | int tspp_close_stream(tspp_device *dev, void *stream); |
| 163 | int tspp_open_channel(tspp_device *dev, int dest, int bufsize, void *channel); |
| 164 | int tspp_close_channel(tspp_device *dev, void *channel); |
| 165 | int tspp_register_filter(tspp_device *dev, void *channel, tspp_filter *filter); |
| 166 | int tspp_unregister_filter(tspp_device *dev, void *channel, int pid); |
| 167 | |
| 168 | Refer to chrdev implementation in kernel/drivers/misc/tspp.c for an example of |
| 169 | how to use this api. |
| 170 | |
| 171 | Each stream is represented by a chrdev device |
| 172 | 16 available devices: /dev/tspp00 - /dev/tspp15 |
| 173 | Each device implements these functions: |
| 174 | open() |
| 175 | close() |
| 176 | read() |
| 177 | ioctl() |
| 178 | |
| 179 | ioctl() contains several sub-functions: |
| 180 | 0: select source |
| 181 | 1: add filter |
| 182 | 2: remove filter |
| 183 | 3: set decryption keys |
| 184 | 4: set initial cbc values (IV) |
| 185 | 5: set system keys |
| 186 | 6: set buffer size |
| 187 | |
| 188 | You can refer to include/linux/tspp.h for the details on the structures |
| 189 | associated with these IOCTL calls. |
| 190 | |
| 191 | Design |
| 192 | ====== |
| 193 | Design is based on the existing TSIF driver, with added control functionality |
| 194 | for the extra hardware features. |
| 195 | |
| 196 | Power Management |
| 197 | =============== |
| 198 | TSPP driver prevents MSM from sleeping while TSPP hardware is active. |
| 199 | To achieve this, the driver holds the wake lock. When no channels are |
| 200 | configured to receive data, the driver stops the clocks to save power. |
| 201 | It will register for suspend/resume in the future. |
| 202 | |
| 203 | SMP/multi-core |
| 204 | ============== |
| 205 | Driver is fully SMP aware. |
| 206 | |
| 207 | Performance |
| 208 | =========== |
| 209 | Control flows are rare. |
| 210 | Data path only involves maintaining the circular buffer pointers. |
| 211 | |
| 212 | Interface |
| 213 | ========= |
| 214 | Driver exposes a char device interface to user-space for each channel. |
| 215 | Control transactions are performed via ioctl on the channel. Data is read as |
| 216 | any regular char device (blocking and non-blocking). Please see sequence |
| 217 | under software description for more info. |
| 218 | |
| 219 | Debugfs may be used for debug purposes. Through debugfs, all of the TSIF |
| 220 | registers can be accessed under /sys/kernel/debug/tsif0 and tsif1. The |
| 221 | TSPP registers are found under /sys/kernel/debug/tspp0. If you cannot |
| 222 | see these devices, then either the driver has been built without debugfs |
| 223 | support (check the define TSPP_USE_DEBUGFS in tspp.c) or the debugfs has |
| 224 | not been mounted correctly (or mounted in a different location). |
| 225 | |
| 226 | Driver Parameters |
| 227 | ================= |
| 228 | TSPP driver has target-specific parameters: |
| 229 | - Memory base addresses for TSIF/TSPP/BAM |
| 230 | - TSIF/TSPP/BAM IRQ numbers |
| 231 | - TSIF GPIO numbers |
| 232 | |
| 233 | Config Options |
| 234 | ============== |
| 235 | To enable the driver, set CONFIG_TSPP (=y or =m) in the appropriate |
| 236 | config file for the platform. |
| 237 | |
| 238 | Dependencies |
| 239 | ============ |
| 240 | The TSPP driver depends on the SPS driver to configure BAM hardware. |
| 241 | |
| 242 | User space utilities |
| 243 | ==================== |
| 244 | The TSPP test suite can be found in: |
| 245 | vendor/qcom/proprietary/kernel-tests/tspp |
| 246 | |
| 247 | Known Issues |
| 248 | ============ |
| 249 | Currently PES processing mode cannot be configured for streams in which the PES |
| 250 | length is 0. This is a HW limitation. |