Those documents don't really describe the driver API.
Instead, they contain development-specific information.
Yet, as the main index file describes the content of it as:
"how specific kernel subsystems work
from the point of view of a kernel developer"
It seems to be the better fit.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+The bttv driver
+===============
+
+bttv and sound mini howto
+-------------------------
+
+There are a lot of different bt848/849/878/879 based boards available.
+Making video work often is not a big deal, because this is handled
+completely by the bt8xx chip, which is common on all boards. But
+sound is handled in slightly different ways on each board.
+
+To handle the grabber boards correctly, there is a array tvcards[] in
+bttv-cards.c, which holds the information required for each board.
+Sound will work only, if the correct entry is used (for video it often
+makes no difference). The bttv driver prints a line to the kernel
+log, telling which card type is used. Like this one:
+
+.. code-block:: none
+
+ bttv0: model: BT848(Hauppauge old) [autodetected]
+
+You should verify this is correct. If it isn't, you have to pass the
+correct board type as insmod argument, "insmod bttv card=2" for
+example. The file CARDLIST has a list of valid arguments for card.
+If your card isn't listed there, you might check the source code for
+new entries which are not listed yet. If there isn't one for your
+card, you can check if one of the existing entries does work for you
+(just trial and error...).
+
+Some boards have an extra processor for sound to do stereo decoding
+and other nice features. The msp34xx chips are used by Hauppauge for
+example. If your board has one, you might have to load a helper
+module like msp3400.o to make sound work. If there isn't one for the
+chip used on your board: Bad luck. Start writing a new one. Well,
+you might want to check the video4linux mailing list archive first...
+
+Of course you need a correctly installed soundcard unless you have the
+speakers connected directly to the grabber board. Hint: check the
+mixer settings too. ALSA for example has everything muted by default.
+
+
+How sound works in detail
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Still doesn't work? Looks like some driver hacking is required.
+Below is a do-it-yourself description for you.
+
+The bt8xx chips have 32 general purpose pins, and registers to control
+these pins. One register is the output enable register
+(BT848_GPIO_OUT_EN), it says which pins are actively driven by the
+bt848 chip. Another one is the data register (BT848_GPIO_DATA), where
+you can get/set the status if these pins. They can be used for input
+and output.
+
+Most grabber board vendors use these pins to control an external chip
+which does the sound routing. But every board is a little different.
+These pins are also used by some companies to drive remote control
+receiver chips. Some boards use the i2c bus instead of the gpio pins
+to connect the mux chip.
+
+As mentioned above, there is a array which holds the required
+information for each known board. You basically have to create a new
+line for your board. The important fields are these two:
+
+.. code-block:: c
+
+ struct tvcard
+ {
+ [ ... ]
+ u32 gpiomask;
+ u32 audiomux[6]; /* Tuner, Radio, external, internal, mute, stereo */
+ };
+
+gpiomask specifies which pins are used to control the audio mux chip.
+The corresponding bits in the output enable register
+(BT848_GPIO_OUT_EN) will be set as these pins must be driven by the
+bt848 chip.
+
+The audiomux\[\] array holds the data values for the different inputs
+(i.e. which pins must be high/low for tuner/mute/...). This will be
+written to the data register (BT848_GPIO_DATA) to switch the audio
+mux.
+
+
+What you have to do is figure out the correct values for gpiomask and
+the audiomux array. If you have Windows and the drivers four your
+card installed, you might to check out if you can read these registers
+values used by the windows driver. A tool to do this is available
+from ftp://telepresence.dmem.strath.ac.uk/pub/bt848/winutil, but it
+doesn't work with bt878 boards according to some reports I received.
+Another one with bt878 support is available from
+http://btwincap.sourceforge.net/Files/btspy2.00.zip
+
+You might also dig around in the \*.ini files of the Windows applications.
+You can have a look at the board to see which of the gpio pins are
+connected at all and then start trial-and-error ...
+
+
+Starting with release 0.7.41 bttv has a number of insmod options to
+make the gpio debugging easier:
+
+.. code-block:: none
+
+ bttv_gpio=0/1 enable/disable gpio debug messages
+ gpiomask=n set the gpiomask value
+ audiomux=i,j,... set the values of the audiomux array
+ audioall=a set the values of the audiomux array (one
+ value for all array elements, useful to check
+ out which effect the particular value has).
+
+The messages printed with bttv_gpio=1 look like this:
+
+.. code-block:: none
+
+ bttv0: gpio: en=00000027, out=00000024 in=00ffffd8 [audio: off]
+
+ en = output _en_able register (BT848_GPIO_OUT_EN)
+ out = _out_put bits of the data register (BT848_GPIO_DATA),
+ i.e. BT848_GPIO_DATA & BT848_GPIO_OUT_EN
+ in = _in_put bits of the data register,
+ i.e. BT848_GPIO_DATA & ~BT848_GPIO_OUT_EN
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+Contributors
+============
+
+.. note::
+
+ This documentation is outdated. There are several other DVB contributors
+ that aren't listed below.
+
+Thanks go to the following people for patches and contributions:
+
+- Michael Hunold <m.hunold@gmx.de>
+
+ - for the initial saa7146 driver and its recent overhaul
+
+- Christian Theiss
+
+ - for his work on the initial Linux DVB driver
+
+- Marcus Metzler <mocm@metzlerbros.de> and
+ Ralph Metzler <rjkm@metzlerbros.de>
+
+ - for their continuing work on the DVB driver
+
+- Michael Holzt <kju@debian.org>
+
+ - for his contributions to the dvb-net driver
+
+- Diego Picciani <d.picciani@novacomp.it>
+
+ - for CyberLogin for Linux which allows logging onto EON
+ (in case you are wondering where CyberLogin is, EON changed its login
+ procedure and CyberLogin is no longer used.)
+
+- Martin Schaller <martin@smurf.franken.de>
+
+ - for patching the cable card decoder driver
+
+- Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>
+
+ - for various fixes regarding tuning, OSD and CI stuff and his work on VDR
+
+- Steve Brown <sbrown@cortland.com>
+
+ - for his AFC kernel thread
+
+- Christoph Martin <martin@uni-mainz.de>
+
+ - for his LIRC infrared handler
+
+- Andreas Oberritter <obi@linuxtv.org>,
+ Dennis Noermann <dennis.noermann@noernet.de>,
+ Felix Domke <tmbinc@elitedvb.net>,
+ Florian Schirmer <jolt@tuxbox.org>,
+ Ronny Strutz <3des@elitedvb.de>,
+ Wolfram Joost <dbox2@frokaschwei.de>
+ and all the other dbox2 people
+
+ - for many bugfixes in the generic DVB Core, frontend drivers and
+ their work on the dbox2 port of the DVB driver
+
+- Oliver Endriss <o.endriss@gmx.de>
+
+ - for many bugfixes
+
+- Andrew de Quincey <adq_dvb@lidskialf.net>
+
+ - for the tda1004x frontend driver, and various bugfixes
+
+- Peter Schildmann <peter.schildmann@web.de>
+
+ - for the driver for the Technisat SkyStar2 PCI DVB card
+
+- Vadim Catana <skystar@moldova.cc>,
+ Roberto Ragusa <r.ragusa@libero.it> and
+ Augusto Cardoso <augusto@carhil.net>
+
+ - for all the work for the FlexCopII chipset by B2C2,Inc.
+
+- Davor Emard <emard@softhome.net>
+
+ - for his work on the budget drivers, the demux code,
+ the module unloading problems, ...
+
+- Hans-Frieder Vogt <hfvogt@arcor.de>
+
+ - for his work on calculating and checking the crc's for the
+ TechnoTrend/Hauppauge DEC driver firmware
+
+- Michael Dreher <michael@5dot1.de> and
+ Andreas 'randy' Weinberger
+
+ - for the support of the Fujitsu-Siemens Activy budget DVB-S
+
+- Kenneth Aafløy <ke-aa@frisurf.no>
+
+ - for adding support for Typhoon DVB-S budget card
+
+- Ernst Peinlich <e.peinlich@inode.at>
+
+ - for tuning/DiSEqC support for the DEC 3000-s
+
+- Peter Beutner <p.beutner@gmx.net>
+
+ - for the IR code for the ttusb-dec driver
+
+- Wilson Michaels <wilsonmichaels@earthlink.net>
+
+ - for the lgdt330x frontend driver, and various bugfixes
+
+- Michael Krufky <mkrufky@linuxtv.org>
+
+ - for maintaining v4l/dvb inter-tree dependencies
+
+- Taylor Jacob <rtjacob@earthlink.net>
+
+ - for the nxt2002 frontend driver
+
+- Jean-Francois Thibert <jeanfrancois@sagetv.com>
+
+ - for the nxt2004 frontend driver
+
+- Kirk Lapray <kirk.lapray@gmail.com>
+
+ - for the or51211 and or51132 frontend drivers, and
+ for merging the nxt2002 and nxt2004 modules into a
+ single nxt200x frontend driver.
+
+(If you think you should be in this list, but you are not, drop a
+line to the DVB mailing list)
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+The cpia2 driver
+================
+
+Authors: Peter Pregler <Peter_Pregler@email.com>,
+Scott J. Bertin <scottbertin@yahoo.com>, and
+Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which
+this one was modelled from.
+
+
+Notes to developers
+~~~~~~~~~~~~~~~~~~~
+
+ - This is a driver version stripped of the 2.4 back compatibility
+ and old MJPEG ioctl API. See cpia2.sf.net for 2.4 support.
+
+Programmer's overview of cpia2 driver
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Cpia2 is the second generation video coprocessor from VLSI Vision Ltd (now a
+division of ST Microelectronics). There are two versions. The first is the
+STV0672, which is capable of up to 30 frames per second (fps) in frame sizes
+up to CIF, and 15 fps for VGA frames. The STV0676 is an improved version,
+which can handle up to 30 fps VGA. Both coprocessors can be attached to two
+CMOS sensors - the vvl6410 CIF sensor and the vvl6500 VGA sensor. These will
+be referred to as the 410 and the 500 sensors, or the CIF and VGA sensors.
+
+The two chipsets operate almost identically. The core is an 8051 processor,
+running two different versions of firmware. The 672 runs the VP4 video
+processor code, the 676 runs VP5. There are a few differences in register
+mappings for the two chips. In these cases, the symbols defined in the
+header files are marked with VP4 or VP5 as part of the symbol name.
+
+The cameras appear externally as three sets of registers. Setting register
+values is the only way to control the camera. Some settings are
+interdependant, such as the sequence required to power up the camera. I will
+try to make note of all of these cases.
+
+The register sets are called blocks. Block 0 is the system block. This
+section is always powered on when the camera is plugged in. It contains
+registers that control housekeeping functions such as powering up the video
+processor. The video processor is the VP block. These registers control
+how the video from the sensor is processed. Examples are timing registers,
+user mode (vga, qvga), scaling, cropping, framerates, and so on. The last
+block is the video compressor (VC). The video stream sent from the camera is
+compressed as Motion JPEG (JPEGA). The VC controls all of the compression
+parameters. Looking at the file cpia2_registers.h, you can get a full view
+of these registers and the possible values for most of them.
+
+One or more registers can be set or read by sending a usb control message to
+the camera. There are three modes for this. Block mode requests a number
+of contiguous registers. Random mode reads or writes random registers with
+a tuple structure containing address/value pairs. The repeat mode is only
+used by VP4 to load a firmware patch. It contains a starting address and
+a sequence of bytes to be written into a gpio port.
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+The cx2341x driver
+==================
+
+Memory at cx2341x chips
+-----------------------
+
+This section describes the cx2341x memory map and documents some of the
+register space.
+
+.. note:: the memory long words are little-endian ('intel format').
+
+.. warning::
+
+ This information was figured out from searching through the memory
+ and registers, this information may not be correct and is certainly
+ not complete, and was not derived from anything more than searching
+ through the memory space with commands like:
+
+ .. code-block:: none
+
+ ivtvctl -O min=0x02000000,max=0x020000ff
+
+ So take this as is, I'm always searching for more stuff, it's a large
+ register space :-).
+
+Memory Map
+~~~~~~~~~~
+
+The cx2341x exposes its entire 64M memory space to the PCI host via the PCI BAR0
+(Base Address Register 0). The addresses here are offsets relative to the
+address held in BAR0.
+
+.. code-block:: none
+
+ 0x00000000-0x00ffffff Encoder memory space
+ 0x00000000-0x0003ffff Encode.rom
+ ???-??? MPEG buffer(s)
+ ???-??? Raw video capture buffer(s)
+ ???-??? Raw audio capture buffer(s)
+ ???-??? Display buffers (6 or 9)
+
+ 0x01000000-0x01ffffff Decoder memory space
+ 0x01000000-0x0103ffff Decode.rom
+ ???-??? MPEG buffers(s)
+ 0x0114b000-0x0115afff Audio.rom (deprecated?)
+
+ 0x02000000-0x0200ffff Register Space
+
+Registers
+~~~~~~~~~
+
+The registers occupy the 64k space starting at the 0x02000000 offset from BAR0.
+All of these registers are 32 bits wide.
+
+.. code-block:: none
+
+ DMA Registers 0x000-0xff:
+
+ 0x00 - Control:
+ 0=reset/cancel, 1=read, 2=write, 4=stop
+ 0x04 - DMA status:
+ 1=read busy, 2=write busy, 4=read error, 8=write error, 16=link list error
+ 0x08 - pci DMA pointer for read link list
+ 0x0c - pci DMA pointer for write link list
+ 0x10 - read/write DMA enable:
+ 1=read enable, 2=write enable
+ 0x14 - always 0xffffffff, if set any lower instability occurs, 0x00 crashes
+ 0x18 - ??
+ 0x1c - always 0x20 or 32, smaller values slow down DMA transactions
+ 0x20 - always value of 0x780a010a
+ 0x24-0x3c - usually just random values???
+ 0x40 - Interrupt status
+ 0x44 - Write a bit here and shows up in Interrupt status 0x40
+ 0x48 - Interrupt Mask
+ 0x4C - always value of 0xfffdffff,
+ if changed to 0xffffffff DMA write interrupts break.
+ 0x50 - always 0xffffffff
+ 0x54 - always 0xffffffff (0x4c, 0x50, 0x54 seem like interrupt masks, are
+ 3 processors on chip, Java ones, VPU, SPU, APU, maybe these are the
+ interrupt masks???).
+ 0x60-0x7C - random values
+ 0x80 - first write linked list reg, for Encoder Memory addr
+ 0x84 - first write linked list reg, for pci memory addr
+ 0x88 - first write linked list reg, for length of buffer in memory addr
+ (|0x80000000 or this for last link)
+ 0x8c-0xdc - rest of write linked list reg, 8 sets of 3 total, DMA goes here
+ from linked list addr in reg 0x0c, firmware must push through or
+ something.
+ 0xe0 - first (and only) read linked list reg, for pci memory addr
+ 0xe4 - first (and only) read linked list reg, for Decoder memory addr
+ 0xe8 - first (and only) read linked list reg, for length of buffer
+ 0xec-0xff - Nothing seems to be in these registers, 0xec-f4 are 0x00000000.
+
+Memory locations for Encoder Buffers 0x700-0x7ff:
+
+These registers show offsets of memory locations pertaining to each
+buffer area used for encoding, have to shift them by <<1 first.
+
+- 0x07F8: Encoder SDRAM refresh
+- 0x07FC: Encoder SDRAM pre-charge
+
+Memory locations for Decoder Buffers 0x800-0x8ff:
+
+These registers show offsets of memory locations pertaining to each
+buffer area used for decoding, have to shift them by <<1 first.
+
+- 0x08F8: Decoder SDRAM refresh
+- 0x08FC: Decoder SDRAM pre-charge
+
+Other memory locations:
+
+- 0x2800: Video Display Module control
+- 0x2D00: AO (audio output?) control
+- 0x2D24: Bytes Flushed
+- 0x7000: LSB I2C write clock bit (inverted)
+- 0x7004: LSB I2C write data bit (inverted)
+- 0x7008: LSB I2C read clock bit
+- 0x700c: LSB I2C read data bit
+- 0x9008: GPIO get input state
+- 0x900c: GPIO set output state
+- 0x9020: GPIO direction (Bit7 (GPIO 0..7) - 0:input, 1:output)
+- 0x9050: SPU control
+- 0x9054: Reset HW blocks
+- 0x9058: VPU control
+- 0xA018: Bit6: interrupt pending?
+- 0xA064: APU command
+
+
+Interrupt Status Register
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The definition of the bits in the interrupt status register 0x0040, and the
+interrupt mask 0x0048. If a bit is cleared in the mask, then we want our ISR to
+execute.
+
+- bit 31 Encoder Start Capture
+- bit 30 Encoder EOS
+- bit 29 Encoder VBI capture
+- bit 28 Encoder Video Input Module reset event
+- bit 27 Encoder DMA complete
+- bit 24 Decoder audio mode change detection event (through event notification)
+- bit 22 Decoder data request
+- bit 20 Decoder DMA complete
+- bit 19 Decoder VBI re-insertion
+- bit 18 Decoder DMA err (linked-list bad)
+
+Missing documentation
+---------------------
+
+- Encoder API post(?)
+- Decoder API post(?)
+- Decoder VTRACE event
+
+
+The cx2341x firmware upload
+---------------------------
+
+This document describes how to upload the cx2341x firmware to the card.
+
+How to find
+~~~~~~~~~~~
+
+See the web pages of the various projects that uses this chip for information
+on how to obtain the firmware.
+
+The firmware stored in a Windows driver can be detected as follows:
+
+- Each firmware image is 256k bytes.
+- The 1st 32-bit word of the Encoder image is 0x0000da7
+- The 1st 32-bit word of the Decoder image is 0x00003a7
+- The 2nd 32-bit word of both images is 0xaa55bb66
+
+How to load
+~~~~~~~~~~~
+
+- Issue the FWapi command to stop the encoder if it is running. Wait for the
+ command to complete.
+- Issue the FWapi command to stop the decoder if it is running. Wait for the
+ command to complete.
+- Issue the I2C command to the digitizer to stop emitting VSYNC events.
+- Issue the FWapi command to halt the encoder's firmware.
+- Sleep for 10ms.
+- Issue the FWapi command to halt the decoder's firmware.
+- Sleep for 10ms.
+- Write 0x00000000 to register 0x2800 to stop the Video Display Module.
+- Write 0x00000005 to register 0x2D00 to stop the AO (audio output?).
+- Write 0x00000000 to register 0xA064 to ping? the APU.
+- Write 0xFFFFFFFE to register 0x9058 to stop the VPU.
+- Write 0xFFFFFFFF to register 0x9054 to reset the HW blocks.
+- Write 0x00000001 to register 0x9050 to stop the SPU.
+- Sleep for 10ms.
+- Write 0x0000001A to register 0x07FC to init the Encoder SDRAM's pre-charge.
+- Write 0x80000640 to register 0x07F8 to init the Encoder SDRAM's refresh to 1us.
+- Write 0x0000001A to register 0x08FC to init the Decoder SDRAM's pre-charge.
+- Write 0x80000640 to register 0x08F8 to init the Decoder SDRAM's refresh to 1us.
+- Sleep for 512ms. (600ms is recommended)
+- Transfer the encoder's firmware image to offset 0 in Encoder memory space.
+- Transfer the decoder's firmware image to offset 0 in Decoder memory space.
+- Use a read-modify-write operation to Clear bit 0 of register 0x9050 to
+ re-enable the SPU.
+- Sleep for 1 second.
+- Use a read-modify-write operation to Clear bits 3 and 0 of register 0x9058
+ to re-enable the VPU.
+- Sleep for 1 second.
+- Issue status API commands to both firmware images to verify.
+
+
+How to call the firmware API
+----------------------------
+
+The preferred calling convention is known as the firmware mailbox. The
+mailboxes are basically a fixed length array that serves as the call-stack.
+
+Firmware mailboxes can be located by searching the encoder and decoder memory
+for a 16 byte signature. That signature will be located on a 256-byte boundary.
+
+Signature:
+
+.. code-block:: none
+
+ 0x78, 0x56, 0x34, 0x12, 0x12, 0x78, 0x56, 0x34,
+ 0x34, 0x12, 0x78, 0x56, 0x56, 0x34, 0x12, 0x78
+
+The firmware implements 20 mailboxes of 20 32-bit words. The first 10 are
+reserved for API calls. The second 10 are used by the firmware for event
+notification.
+
+ ====== =================
+ Index Name
+ ====== =================
+ 0 Flags
+ 1 Command
+ 2 Return value
+ 3 Timeout
+ 4-19 Parameter/Result
+ ====== =================
+
+
+The flags are defined in the following table. The direction is from the
+perspective of the firmware.
+
+ ==== ========== ============================================
+ Bit Direction Purpose
+ ==== ========== ============================================
+ 2 O Firmware has processed the command.
+ 1 I Driver has finished setting the parameters.
+ 0 I Driver is using this mailbox.
+ ==== ========== ============================================
+
+The command is a 32-bit enumerator. The API specifics may be found in this
+chapter.
+
+The return value is a 32-bit enumerator. Only two values are currently defined:
+
+- 0=success
+- -1=command undefined.
+
+There are 16 parameters/results 32-bit fields. The driver populates these fields
+with values for all the parameters required by the call. The driver overwrites
+these fields with result values returned by the call.
+
+The timeout value protects the card from a hung driver thread. If the driver
+doesn't handle the completed call within the timeout specified, the firmware
+will reset that mailbox.
+
+To make an API call, the driver iterates over each mailbox looking for the
+first one available (bit 0 has been cleared). The driver sets that bit, fills
+in the command enumerator, the timeout value and any required parameters. The
+driver then sets the parameter ready bit (bit 1). The firmware scans the
+mailboxes for pending commands, processes them, sets the result code, populates
+the result value array with that call's return values and sets the call
+complete bit (bit 2). Once bit 2 is set, the driver should retrieve the results
+and clear all the flags. If the driver does not perform this task within the
+time set in the timeout register, the firmware will reset that mailbox.
+
+Event notifications are sent from the firmware to the host. The host tells the
+firmware which events it is interested in via an API call. That call tells the
+firmware which notification mailbox to use. The firmware signals the host via
+an interrupt. Only the 16 Results fields are used, the Flags, Command, Return
+value and Timeout words are not used.
+
+
+OSD firmware API description
+----------------------------
+
+.. note:: this API is part of the decoder firmware, so it's cx23415 only.
+
+
+
+CX2341X_OSD_GET_FRAMEBUFFER
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 65/0x41
+
+Description
+^^^^^^^^^^^
+
+Return base and length of contiguous OSD memory.
+
+Result[0]
+^^^^^^^^^
+
+OSD base address
+
+Result[1]
+^^^^^^^^^
+
+OSD length
+
+
+
+CX2341X_OSD_GET_PIXEL_FORMAT
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 66/0x42
+
+Description
+^^^^^^^^^^^
+
+Query OSD format
+
+Result[0]
+^^^^^^^^^
+
+0=8bit index
+1=16bit RGB 5:6:5
+2=16bit ARGB 1:5:5:5
+3=16bit ARGB 1:4:4:4
+4=32bit ARGB 8:8:8:8
+
+
+
+CX2341X_OSD_SET_PIXEL_FORMAT
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 67/0x43
+
+Description
+^^^^^^^^^^^
+
+Assign pixel format
+
+Param[0]
+^^^^^^^^
+
+- 0=8bit index
+- 1=16bit RGB 5:6:5
+- 2=16bit ARGB 1:5:5:5
+- 3=16bit ARGB 1:4:4:4
+- 4=32bit ARGB 8:8:8:8
+
+
+
+CX2341X_OSD_GET_STATE
+~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 68/0x44
+
+Description
+^^^^^^^^^^^
+
+Query OSD state
+
+Result[0]
+^^^^^^^^^
+
+- Bit 0 0=off, 1=on
+- Bits 1:2 alpha control
+- Bits 3:5 pixel format
+
+
+
+CX2341X_OSD_SET_STATE
+~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 69/0x45
+
+Description
+^^^^^^^^^^^
+
+OSD switch
+
+Param[0]
+^^^^^^^^
+
+0=off, 1=on
+
+
+
+CX2341X_OSD_GET_OSD_COORDS
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 70/0x46
+
+Description
+^^^^^^^^^^^
+
+Retrieve coordinates of OSD area blended with video
+
+Result[0]
+^^^^^^^^^
+
+OSD buffer address
+
+Result[1]
+^^^^^^^^^
+
+Stride in pixels
+
+Result[2]
+^^^^^^^^^
+
+Lines in OSD buffer
+
+Result[3]
+^^^^^^^^^
+
+Horizontal offset in buffer
+
+Result[4]
+^^^^^^^^^
+
+Vertical offset in buffer
+
+
+
+CX2341X_OSD_SET_OSD_COORDS
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 71/0x47
+
+Description
+^^^^^^^^^^^
+
+Assign the coordinates of the OSD area to blend with video
+
+Param[0]
+^^^^^^^^
+
+buffer address
+
+Param[1]
+^^^^^^^^
+
+buffer stride in pixels
+
+Param[2]
+^^^^^^^^
+
+lines in buffer
+
+Param[3]
+^^^^^^^^
+
+horizontal offset
+
+Param[4]
+^^^^^^^^
+
+vertical offset
+
+
+
+CX2341X_OSD_GET_SCREEN_COORDS
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 72/0x48
+
+Description
+^^^^^^^^^^^
+
+Retrieve OSD screen area coordinates
+
+Result[0]
+^^^^^^^^^
+
+top left horizontal offset
+
+Result[1]
+^^^^^^^^^
+
+top left vertical offset
+
+Result[2]
+^^^^^^^^^
+
+bottom right horizontal offset
+
+Result[3]
+^^^^^^^^^
+
+bottom right vertical offset
+
+
+
+CX2341X_OSD_SET_SCREEN_COORDS
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 73/0x49
+
+Description
+^^^^^^^^^^^
+
+Assign the coordinates of the screen area to blend with video
+
+Param[0]
+^^^^^^^^
+
+top left horizontal offset
+
+Param[1]
+^^^^^^^^
+
+top left vertical offset
+
+Param[2]
+^^^^^^^^
+
+bottom left horizontal offset
+
+Param[3]
+^^^^^^^^
+
+bottom left vertical offset
+
+
+
+CX2341X_OSD_GET_GLOBAL_ALPHA
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 74/0x4A
+
+Description
+^^^^^^^^^^^
+
+Retrieve OSD global alpha
+
+Result[0]
+^^^^^^^^^
+
+global alpha: 0=off, 1=on
+
+Result[1]
+^^^^^^^^^
+
+bits 0:7 global alpha
+
+
+
+CX2341X_OSD_SET_GLOBAL_ALPHA
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 75/0x4B
+
+Description
+^^^^^^^^^^^
+
+Update global alpha
+
+Param[0]
+^^^^^^^^
+
+global alpha: 0=off, 1=on
+
+Param[1]
+^^^^^^^^
+
+global alpha (8 bits)
+
+Param[2]
+^^^^^^^^
+
+local alpha: 0=on, 1=off
+
+
+
+CX2341X_OSD_SET_BLEND_COORDS
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 78/0x4C
+
+Description
+^^^^^^^^^^^
+
+Move start of blending area within display buffer
+
+Param[0]
+^^^^^^^^
+
+horizontal offset in buffer
+
+Param[1]
+^^^^^^^^
+
+vertical offset in buffer
+
+
+
+CX2341X_OSD_GET_FLICKER_STATE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 79/0x4F
+
+Description
+^^^^^^^^^^^
+
+Retrieve flicker reduction module state
+
+Result[0]
+^^^^^^^^^
+
+flicker state: 0=off, 1=on
+
+
+
+CX2341X_OSD_SET_FLICKER_STATE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 80/0x50
+
+Description
+^^^^^^^^^^^
+
+Set flicker reduction module state
+
+Param[0]
+^^^^^^^^
+
+State: 0=off, 1=on
+
+
+
+CX2341X_OSD_BLT_COPY
+~~~~~~~~~~~~~~~~~~~~
+
+Enum: 82/0x52
+
+Description
+^^^^^^^^^^^
+
+BLT copy
+
+Param[0]
+^^^^^^^^
+
+.. code-block:: none
+
+ '0000' zero
+ '0001' ~destination AND ~source
+ '0010' ~destination AND source
+ '0011' ~destination
+ '0100' destination AND ~source
+ '0101' ~source
+ '0110' destination XOR source
+ '0111' ~destination OR ~source
+ '1000' ~destination AND ~source
+ '1001' destination XNOR source
+ '1010' source
+ '1011' ~destination OR source
+ '1100' destination
+ '1101' destination OR ~source
+ '1110' destination OR source
+ '1111' one
+
+
+Param[1]
+^^^^^^^^
+
+Resulting alpha blending
+
+- '01' source_alpha
+- '10' destination_alpha
+- '11' source_alpha*destination_alpha+1
+ (zero if both source and destination alpha are zero)
+
+Param[2]
+^^^^^^^^
+
+.. code-block:: none
+
+ '00' output_pixel = source_pixel
+
+ '01' if source_alpha=0:
+ output_pixel = destination_pixel
+ if 256 > source_alpha > 1:
+ output_pixel = ((source_alpha + 1)*source_pixel +
+ (255 - source_alpha)*destination_pixel)/256
+
+ '10' if destination_alpha=0:
+ output_pixel = source_pixel
+ if 255 > destination_alpha > 0:
+ output_pixel = ((255 - destination_alpha)*source_pixel +
+ (destination_alpha + 1)*destination_pixel)/256
+
+ '11' if source_alpha=0:
+ source_temp = 0
+ if source_alpha=255:
+ source_temp = source_pixel*256
+ if 255 > source_alpha > 0:
+ source_temp = source_pixel*(source_alpha + 1)
+ if destination_alpha=0:
+ destination_temp = 0
+ if destination_alpha=255:
+ destination_temp = destination_pixel*256
+ if 255 > destination_alpha > 0:
+ destination_temp = destination_pixel*(destination_alpha + 1)
+ output_pixel = (source_temp + destination_temp)/256
+
+Param[3]
+^^^^^^^^
+
+width
+
+Param[4]
+^^^^^^^^
+
+height
+
+Param[5]
+^^^^^^^^
+
+destination pixel mask
+
+Param[6]
+^^^^^^^^
+
+destination rectangle start address
+
+Param[7]
+^^^^^^^^
+
+destination stride in dwords
+
+Param[8]
+^^^^^^^^
+
+source stride in dwords
+
+Param[9]
+^^^^^^^^
+
+source rectangle start address
+
+
+
+CX2341X_OSD_BLT_FILL
+~~~~~~~~~~~~~~~~~~~~
+
+Enum: 83/0x53
+
+Description
+^^^^^^^^^^^
+
+BLT fill color
+
+Param[0]
+^^^^^^^^
+
+Same as Param[0] on API 0x52
+
+Param[1]
+^^^^^^^^
+
+Same as Param[1] on API 0x52
+
+Param[2]
+^^^^^^^^
+
+Same as Param[2] on API 0x52
+
+Param[3]
+^^^^^^^^
+
+width
+
+Param[4]
+^^^^^^^^
+
+height
+
+Param[5]
+^^^^^^^^
+
+destination pixel mask
+
+Param[6]
+^^^^^^^^
+
+destination rectangle start address
+
+Param[7]
+^^^^^^^^
+
+destination stride in dwords
+
+Param[8]
+^^^^^^^^
+
+color fill value
+
+
+
+CX2341X_OSD_BLT_TEXT
+~~~~~~~~~~~~~~~~~~~~
+
+Enum: 84/0x54
+
+Description
+^^^^^^^^^^^
+
+BLT for 8 bit alpha text source
+
+Param[0]
+^^^^^^^^
+
+Same as Param[0] on API 0x52
+
+Param[1]
+^^^^^^^^
+
+Same as Param[1] on API 0x52
+
+Param[2]
+^^^^^^^^
+
+Same as Param[2] on API 0x52
+
+Param[3]
+^^^^^^^^
+
+width
+
+Param[4]
+^^^^^^^^
+
+height
+
+Param[5]
+^^^^^^^^
+
+destination pixel mask
+
+Param[6]
+^^^^^^^^
+
+destination rectangle start address
+
+Param[7]
+^^^^^^^^
+
+destination stride in dwords
+
+Param[8]
+^^^^^^^^
+
+source stride in dwords
+
+Param[9]
+^^^^^^^^
+
+source rectangle start address
+
+Param[10]
+^^^^^^^^^
+
+color fill value
+
+
+
+CX2341X_OSD_SET_FRAMEBUFFER_WINDOW
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 86/0x56
+
+Description
+^^^^^^^^^^^
+
+Positions the main output window on the screen. The coordinates must be
+such that the entire window fits on the screen.
+
+Param[0]
+^^^^^^^^
+
+window width
+
+Param[1]
+^^^^^^^^
+
+window height
+
+Param[2]
+^^^^^^^^
+
+top left window corner horizontal offset
+
+Param[3]
+^^^^^^^^
+
+top left window corner vertical offset
+
+
+
+CX2341X_OSD_SET_CHROMA_KEY
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 96/0x60
+
+Description
+^^^^^^^^^^^
+
+Chroma key switch and color
+
+Param[0]
+^^^^^^^^
+
+state: 0=off, 1=on
+
+Param[1]
+^^^^^^^^
+
+color
+
+
+
+CX2341X_OSD_GET_ALPHA_CONTENT_INDEX
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 97/0x61
+
+Description
+^^^^^^^^^^^
+
+Retrieve alpha content index
+
+Result[0]
+^^^^^^^^^
+
+alpha content index, Range 0:15
+
+
+
+CX2341X_OSD_SET_ALPHA_CONTENT_INDEX
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 98/0x62
+
+Description
+^^^^^^^^^^^
+
+Assign alpha content index
+
+Param[0]
+^^^^^^^^
+
+alpha content index, range 0:15
+
+
+Encoder firmware API description
+--------------------------------
+
+CX2341X_ENC_PING_FW
+~~~~~~~~~~~~~~~~~~~
+
+Enum: 128/0x80
+
+Description
+^^^^^^^^^^^
+
+Does nothing. Can be used to check if the firmware is responding.
+
+
+
+CX2341X_ENC_START_CAPTURE
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 129/0x81
+
+Description
+^^^^^^^^^^^
+
+Commences the capture of video, audio and/or VBI data. All encoding
+parameters must be initialized prior to this API call. Captures frames
+continuously or until a predefined number of frames have been captured.
+
+Param[0]
+^^^^^^^^
+
+Capture stream type:
+
+ - 0=MPEG
+ - 1=Raw
+ - 2=Raw passthrough
+ - 3=VBI
+
+
+Param[1]
+^^^^^^^^
+
+Bitmask:
+
+ - Bit 0 when set, captures YUV
+ - Bit 1 when set, captures PCM audio
+ - Bit 2 when set, captures VBI (same as param[0]=3)
+ - Bit 3 when set, the capture destination is the decoder
+ (same as param[0]=2)
+ - Bit 4 when set, the capture destination is the host
+
+.. note:: this parameter is only meaningful for RAW capture type.
+
+
+
+CX2341X_ENC_STOP_CAPTURE
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 130/0x82
+
+Description
+^^^^^^^^^^^
+
+Ends a capture in progress
+
+Param[0]
+^^^^^^^^
+
+- 0=stop at end of GOP (generates IRQ)
+- 1=stop immediate (no IRQ)
+
+Param[1]
+^^^^^^^^
+
+Stream type to stop, see param[0] of API 0x81
+
+Param[2]
+^^^^^^^^
+
+Subtype, see param[1] of API 0x81
+
+
+
+CX2341X_ENC_SET_AUDIO_ID
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 137/0x89
+
+Description
+^^^^^^^^^^^
+
+Assigns the transport stream ID of the encoded audio stream
+
+Param[0]
+^^^^^^^^
+
+Audio Stream ID
+
+
+
+CX2341X_ENC_SET_VIDEO_ID
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 139/0x8B
+
+Description
+^^^^^^^^^^^
+
+Set video transport stream ID
+
+Param[0]
+^^^^^^^^
+
+Video stream ID
+
+
+
+CX2341X_ENC_SET_PCR_ID
+~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 141/0x8D
+
+Description
+^^^^^^^^^^^
+
+Assigns the transport stream ID for PCR packets
+
+Param[0]
+^^^^^^^^
+
+PCR Stream ID
+
+
+
+CX2341X_ENC_SET_FRAME_RATE
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 143/0x8F
+
+Description
+^^^^^^^^^^^
+
+Set video frames per second. Change occurs at start of new GOP.
+
+Param[0]
+^^^^^^^^
+
+- 0=30fps
+- 1=25fps
+
+
+
+CX2341X_ENC_SET_FRAME_SIZE
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 145/0x91
+
+Description
+^^^^^^^^^^^
+
+Select video stream encoding resolution.
+
+Param[0]
+^^^^^^^^
+
+Height in lines. Default 480
+
+Param[1]
+^^^^^^^^
+
+Width in pixels. Default 720
+
+
+
+CX2341X_ENC_SET_BIT_RATE
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 149/0x95
+
+Description
+^^^^^^^^^^^
+
+Assign average video stream bitrate.
+
+Param[0]
+^^^^^^^^
+
+0=variable bitrate, 1=constant bitrate
+
+Param[1]
+^^^^^^^^
+
+bitrate in bits per second
+
+Param[2]
+^^^^^^^^
+
+peak bitrate in bits per second, divided by 400
+
+Param[3]
+^^^^^^^^
+
+Mux bitrate in bits per second, divided by 400. May be 0 (default).
+
+Param[4]
+^^^^^^^^
+
+Rate Control VBR Padding
+
+Param[5]
+^^^^^^^^
+
+VBV Buffer used by encoder
+
+.. note::
+
+ #) Param\[3\] and Param\[4\] seem to be always 0
+ #) Param\[5\] doesn't seem to be used.
+
+
+
+CX2341X_ENC_SET_GOP_PROPERTIES
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 151/0x97
+
+Description
+^^^^^^^^^^^
+
+Setup the GOP structure
+
+Param[0]
+^^^^^^^^
+
+GOP size (maximum is 34)
+
+Param[1]
+^^^^^^^^
+
+Number of B frames between the I and P frame, plus 1.
+For example: IBBPBBPBBPBB --> GOP size: 12, number of B frames: 2+1 = 3
+
+.. note::
+
+ GOP size must be a multiple of (B-frames + 1).
+
+
+
+CX2341X_ENC_SET_ASPECT_RATIO
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 153/0x99
+
+Description
+^^^^^^^^^^^
+
+Sets the encoding aspect ratio. Changes in the aspect ratio take effect
+at the start of the next GOP.
+
+Param[0]
+^^^^^^^^
+
+- '0000' forbidden
+- '0001' 1:1 square
+- '0010' 4:3
+- '0011' 16:9
+- '0100' 2.21:1
+- '0101' to '1111' reserved
+
+
+
+CX2341X_ENC_SET_DNR_FILTER_MODE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 155/0x9B
+
+Description
+^^^^^^^^^^^
+
+Assign Dynamic Noise Reduction operating mode
+
+Param[0]
+^^^^^^^^
+
+Bit0: Spatial filter, set=auto, clear=manual
+Bit1: Temporal filter, set=auto, clear=manual
+
+Param[1]
+^^^^^^^^
+
+Median filter:
+
+- 0=Disabled
+- 1=Horizontal
+- 2=Vertical
+- 3=Horiz/Vert
+- 4=Diagonal
+
+
+
+CX2341X_ENC_SET_DNR_FILTER_PROPS
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 157/0x9D
+
+Description
+^^^^^^^^^^^
+
+These Dynamic Noise Reduction filter values are only meaningful when
+the respective filter is set to "manual" (See API 0x9B)
+
+Param[0]
+^^^^^^^^
+
+Spatial filter: default 0, range 0:15
+
+Param[1]
+^^^^^^^^
+
+Temporal filter: default 0, range 0:31
+
+
+
+CX2341X_ENC_SET_CORING_LEVELS
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 159/0x9F
+
+Description
+^^^^^^^^^^^
+
+Assign Dynamic Noise Reduction median filter properties.
+
+Param[0]
+^^^^^^^^
+
+Threshold above which the luminance median filter is enabled.
+Default: 0, range 0:255
+
+Param[1]
+^^^^^^^^
+
+Threshold below which the luminance median filter is enabled.
+Default: 255, range 0:255
+
+Param[2]
+^^^^^^^^
+
+Threshold above which the chrominance median filter is enabled.
+Default: 0, range 0:255
+
+Param[3]
+^^^^^^^^
+
+Threshold below which the chrominance median filter is enabled.
+Default: 255, range 0:255
+
+
+
+CX2341X_ENC_SET_SPATIAL_FILTER_TYPE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 161/0xA1
+
+Description
+^^^^^^^^^^^
+
+Assign spatial prefilter parameters
+
+Param[0]
+^^^^^^^^
+
+Luminance filter
+
+- 0=Off
+- 1=1D Horizontal
+- 2=1D Vertical
+- 3=2D H/V Separable (default)
+- 4=2D Symmetric non-separable
+
+Param[1]
+^^^^^^^^
+
+Chrominance filter
+
+- 0=Off
+- 1=1D Horizontal (default)
+
+
+
+CX2341X_ENC_SET_VBI_LINE
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 183/0xB7
+
+Description
+^^^^^^^^^^^
+
+Selects VBI line number.
+
+Param[0]
+^^^^^^^^
+
+- Bits 0:4 line number
+- Bit 31 0=top_field, 1=bottom_field
+- Bits 0:31 all set specifies "all lines"
+
+Param[1]
+^^^^^^^^
+
+VBI line information features: 0=disabled, 1=enabled
+
+Param[2]
+^^^^^^^^
+
+Slicing: 0=None, 1=Closed Caption
+Almost certainly not implemented. Set to 0.
+
+Param[3]
+^^^^^^^^
+
+Luminance samples in this line.
+Almost certainly not implemented. Set to 0.
+
+Param[4]
+^^^^^^^^
+
+Chrominance samples in this line
+Almost certainly not implemented. Set to 0.
+
+
+
+CX2341X_ENC_SET_STREAM_TYPE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 185/0xB9
+
+Description
+^^^^^^^^^^^
+
+Assign stream type
+
+.. note::
+
+ Transport stream is not working in recent firmwares.
+ And in older firmwares the timestamps in the TS seem to be
+ unreliable.
+
+Param[0]
+^^^^^^^^
+
+- 0=Program stream
+- 1=Transport stream
+- 2=MPEG1 stream
+- 3=PES A/V stream
+- 5=PES Video stream
+- 7=PES Audio stream
+- 10=DVD stream
+- 11=VCD stream
+- 12=SVCD stream
+- 13=DVD_S1 stream
+- 14=DVD_S2 stream
+
+
+
+CX2341X_ENC_SET_OUTPUT_PORT
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 187/0xBB
+
+Description
+^^^^^^^^^^^
+
+Assign stream output port. Normally 0 when the data is copied through
+the PCI bus (DMA), and 1 when the data is streamed to another chip
+(pvrusb and cx88-blackbird).
+
+Param[0]
+^^^^^^^^
+
+- 0=Memory (default)
+- 1=Streaming
+- 2=Serial
+
+Param[1]
+^^^^^^^^
+
+Unknown, but leaving this to 0 seems to work best. Indications are that
+this might have to do with USB support, although passing anything but 0
+only breaks things.
+
+
+
+CX2341X_ENC_SET_AUDIO_PROPERTIES
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 189/0xBD
+
+Description
+^^^^^^^^^^^
+
+Set audio stream properties, may be called while encoding is in progress.
+
+.. note::
+
+ All bitfields are consistent with ISO11172 documentation except
+ bits 2:3 which ISO docs define as:
+
+ - '11' Layer I
+ - '10' Layer II
+ - '01' Layer III
+ - '00' Undefined
+
+ This discrepancy may indicate a possible error in the documentation.
+ Testing indicated that only Layer II is actually working, and that
+ the minimum bitrate should be 192 kbps.
+
+Param[0]
+^^^^^^^^
+
+Bitmask:
+
+.. code-block:: none
+
+ 0:1 '00' 44.1Khz
+ '01' 48Khz
+ '10' 32Khz
+ '11' reserved
+
+ 2:3 '01'=Layer I
+ '10'=Layer II
+
+ 4:7 Bitrate:
+ Index | Layer I | Layer II
+ ------+-------------+------------
+ '0000' | free format | free format
+ '0001' | 32 kbit/s | 32 kbit/s
+ '0010' | 64 kbit/s | 48 kbit/s
+ '0011' | 96 kbit/s | 56 kbit/s
+ '0100' | 128 kbit/s | 64 kbit/s
+ '0101' | 160 kbit/s | 80 kbit/s
+ '0110' | 192 kbit/s | 96 kbit/s
+ '0111' | 224 kbit/s | 112 kbit/s
+ '1000' | 256 kbit/s | 128 kbit/s
+ '1001' | 288 kbit/s | 160 kbit/s
+ '1010' | 320 kbit/s | 192 kbit/s
+ '1011' | 352 kbit/s | 224 kbit/s
+ '1100' | 384 kbit/s | 256 kbit/s
+ '1101' | 416 kbit/s | 320 kbit/s
+ '1110' | 448 kbit/s | 384 kbit/s
+
+ .. note::
+
+ For Layer II, not all combinations of total bitrate
+ and mode are allowed. See ISO11172-3 3-Annex B,
+ Table 3-B.2
+
+ 8:9 '00'=Stereo
+ '01'=JointStereo
+ '10'=Dual
+ '11'=Mono
+
+ .. note::
+
+ The cx23415 cannot decode Joint Stereo properly.
+
+ 10:11 Mode Extension used in joint_stereo mode.
+ In Layer I and II they indicate which subbands are in
+ intensity_stereo. All other subbands are coded in stereo.
+ '00' subbands 4-31 in intensity_stereo, bound==4
+ '01' subbands 8-31 in intensity_stereo, bound==8
+ '10' subbands 12-31 in intensity_stereo, bound==12
+ '11' subbands 16-31 in intensity_stereo, bound==16
+
+ 12:13 Emphasis:
+ '00' None
+ '01' 50/15uS
+ '10' reserved
+ '11' CCITT J.17
+
+ 14 CRC:
+ '0' off
+ '1' on
+
+ 15 Copyright:
+ '0' off
+ '1' on
+
+ 16 Generation:
+ '0' copy
+ '1' original
+
+
+
+CX2341X_ENC_HALT_FW
+~~~~~~~~~~~~~~~~~~~
+
+Enum: 195/0xC3
+
+Description
+^^^^^^^^^^^
+
+The firmware is halted and no further API calls are serviced until the
+firmware is uploaded again.
+
+
+
+CX2341X_ENC_GET_VERSION
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 196/0xC4
+
+Description
+^^^^^^^^^^^
+
+Returns the version of the encoder firmware.
+
+Result[0]
+^^^^^^^^^
+
+Version bitmask:
+- Bits 0:15 build
+- Bits 16:23 minor
+- Bits 24:31 major
+
+
+
+CX2341X_ENC_SET_GOP_CLOSURE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 197/0xC5
+
+Description
+^^^^^^^^^^^
+
+Assigns the GOP open/close property.
+
+Param[0]
+^^^^^^^^
+
+- 0=Open
+- 1=Closed
+
+
+
+CX2341X_ENC_GET_SEQ_END
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 198/0xC6
+
+Description
+^^^^^^^^^^^
+
+Obtains the sequence end code of the encoder's buffer. When a capture
+is started a number of interrupts are still generated, the last of
+which will have Result[0] set to 1 and Result[1] will contain the size
+of the buffer.
+
+Result[0]
+^^^^^^^^^
+
+State of the transfer (1 if last buffer)
+
+Result[1]
+^^^^^^^^^
+
+If Result[0] is 1, this contains the size of the last buffer, undefined
+otherwise.
+
+
+
+CX2341X_ENC_SET_PGM_INDEX_INFO
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 199/0xC7
+
+Description
+^^^^^^^^^^^
+
+Sets the Program Index Information.
+The information is stored as follows:
+
+.. code-block:: c
+
+ struct info {
+ u32 length; // Length of this frame
+ u32 offset_low; // Offset in the file of the
+ u32 offset_high; // start of this frame
+ u32 mask1; // Bits 0-2 are the type mask:
+ // 1=I, 2=P, 4=B
+ // 0=End of Program Index, other fields
+ // are invalid.
+ u32 pts; // The PTS of the frame
+ u32 mask2; // Bit 0 is bit 32 of the pts.
+ };
+ u32 table_ptr;
+ struct info index[400];
+
+The table_ptr is the encoder memory address in the table were
+*new* entries will be written.
+
+.. note:: This is a ringbuffer, so the table_ptr will wraparound.
+
+Param[0]
+^^^^^^^^
+
+Picture Mask:
+- 0=No index capture
+- 1=I frames
+- 3=I,P frames
+- 7=I,P,B frames
+
+(Seems to be ignored, it always indexes I, P and B frames)
+
+Param[1]
+^^^^^^^^
+
+Elements requested (up to 400)
+
+Result[0]
+^^^^^^^^^
+
+Offset in the encoder memory of the start of the table.
+
+Result[1]
+^^^^^^^^^
+
+Number of allocated elements up to a maximum of Param[1]
+
+
+
+CX2341X_ENC_SET_VBI_CONFIG
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 200/0xC8
+
+Description
+^^^^^^^^^^^
+
+Configure VBI settings
+
+Param[0]
+^^^^^^^^
+
+Bitmap:
+
+.. code-block:: none
+
+ 0 Mode '0' Sliced, '1' Raw
+ 1:3 Insertion:
+ '000' insert in extension & user data
+ '001' insert in private packets
+ '010' separate stream and user data
+ '111' separate stream and private data
+ 8:15 Stream ID (normally 0xBD)
+
+Param[1]
+^^^^^^^^
+
+Frames per interrupt (max 8). Only valid in raw mode.
+
+Param[2]
+^^^^^^^^
+
+Total raw VBI frames. Only valid in raw mode.
+
+Param[3]
+^^^^^^^^
+
+Start codes
+
+Param[4]
+^^^^^^^^
+
+Stop codes
+
+Param[5]
+^^^^^^^^
+
+Lines per frame
+
+Param[6]
+^^^^^^^^
+
+Byte per line
+
+Result[0]
+^^^^^^^^^
+
+Observed frames per interrupt in raw mode only. Rage 1 to Param[1]
+
+Result[1]
+^^^^^^^^^
+
+Observed number of frames in raw mode. Range 1 to Param[2]
+
+Result[2]
+^^^^^^^^^
+
+Memory offset to start or raw VBI data
+
+
+
+CX2341X_ENC_SET_DMA_BLOCK_SIZE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 201/0xC9
+
+Description
+^^^^^^^^^^^
+
+Set DMA transfer block size
+
+Param[0]
+^^^^^^^^
+
+DMA transfer block size in bytes or frames. When unit is bytes,
+supported block sizes are 2^7, 2^8 and 2^9 bytes.
+
+Param[1]
+^^^^^^^^
+
+Unit: 0=bytes, 1=frames
+
+
+
+CX2341X_ENC_GET_PREV_DMA_INFO_MB_10
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 202/0xCA
+
+Description
+^^^^^^^^^^^
+
+Returns information on the previous DMA transfer in conjunction with
+bit 27 of the interrupt mask. Uses mailbox 10.
+
+Result[0]
+^^^^^^^^^
+
+Type of stream
+
+Result[1]
+^^^^^^^^^
+
+Address Offset
+
+Result[2]
+^^^^^^^^^
+
+Maximum size of transfer
+
+
+
+CX2341X_ENC_GET_PREV_DMA_INFO_MB_9
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 203/0xCB
+
+Description
+^^^^^^^^^^^
+
+Returns information on the previous DMA transfer in conjunction with
+bit 27 or 18 of the interrupt mask. Uses mailbox 9.
+
+Result[0]
+^^^^^^^^^
+
+Status bits:
+- 0 read completed
+- 1 write completed
+- 2 DMA read error
+- 3 DMA write error
+- 4 Scatter-Gather array error
+
+Result[1]
+^^^^^^^^^
+
+DMA type
+
+Result[2]
+^^^^^^^^^
+
+Presentation Time Stamp bits 0..31
+
+Result[3]
+^^^^^^^^^
+
+Presentation Time Stamp bit 32
+
+
+
+CX2341X_ENC_SCHED_DMA_TO_HOST
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 204/0xCC
+
+Description
+^^^^^^^^^^^
+
+Setup DMA to host operation
+
+Param[0]
+^^^^^^^^
+
+Memory address of link list
+
+Param[1]
+^^^^^^^^
+
+Length of link list (wtf: what units ???)
+
+Param[2]
+^^^^^^^^
+
+DMA type (0=MPEG)
+
+
+
+CX2341X_ENC_INITIALIZE_INPUT
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 205/0xCD
+
+Description
+^^^^^^^^^^^
+
+Initializes the video input
+
+
+
+CX2341X_ENC_SET_FRAME_DROP_RATE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 208/0xD0
+
+Description
+^^^^^^^^^^^
+
+For each frame captured, skip specified number of frames.
+
+Param[0]
+^^^^^^^^
+
+Number of frames to skip
+
+
+
+CX2341X_ENC_PAUSE_ENCODER
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 210/0xD2
+
+Description
+^^^^^^^^^^^
+
+During a pause condition, all frames are dropped instead of being encoded.
+
+Param[0]
+^^^^^^^^
+
+- 0=Pause encoding
+- 1=Continue encoding
+
+
+
+CX2341X_ENC_REFRESH_INPUT
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 211/0xD3
+
+Description
+^^^^^^^^^^^
+
+Refreshes the video input
+
+
+
+CX2341X_ENC_SET_COPYRIGHT
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 212/0xD4
+
+Description
+^^^^^^^^^^^
+
+Sets stream copyright property
+
+Param[0]
+^^^^^^^^
+
+
+- 0=Stream is not copyrighted
+- 1=Stream is copyrighted
+
+
+
+CX2341X_ENC_SET_EVENT_NOTIFICATION
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 213/0xD5
+
+Description
+^^^^^^^^^^^
+
+Setup firmware to notify the host about a particular event. Host must
+unmask the interrupt bit.
+
+Param[0]
+^^^^^^^^
+
+Event (0=refresh encoder input)
+
+Param[1]
+^^^^^^^^
+
+Notification 0=disabled 1=enabled
+
+Param[2]
+^^^^^^^^
+
+Interrupt bit
+
+Param[3]
+^^^^^^^^
+
+Mailbox slot, -1 if no mailbox required.
+
+
+
+CX2341X_ENC_SET_NUM_VSYNC_LINES
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 214/0xD6
+
+Description
+^^^^^^^^^^^
+
+Depending on the analog video decoder used, this assigns the number
+of lines for field 1 and 2.
+
+Param[0]
+^^^^^^^^
+
+Field 1 number of lines:
+- 0x00EF for SAA7114
+- 0x00F0 for SAA7115
+- 0x0105 for Micronas
+
+Param[1]
+^^^^^^^^
+
+Field 2 number of lines:
+- 0x00EF for SAA7114
+- 0x00F0 for SAA7115
+- 0x0106 for Micronas
+
+
+
+CX2341X_ENC_SET_PLACEHOLDER
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 215/0xD7
+
+Description
+^^^^^^^^^^^
+
+Provides a mechanism of inserting custom user data in the MPEG stream.
+
+Param[0]
+^^^^^^^^
+
+- 0=extension & user data
+- 1=private packet with stream ID 0xBD
+
+Param[1]
+^^^^^^^^
+
+Rate at which to insert data, in units of frames (for private packet)
+or GOPs (for ext. & user data)
+
+Param[2]
+^^^^^^^^
+
+Number of data DWORDs (below) to insert
+
+Param[3]
+^^^^^^^^
+
+Custom data 0
+
+Param[4]
+^^^^^^^^
+
+Custom data 1
+
+Param[5]
+^^^^^^^^
+
+Custom data 2
+
+Param[6]
+^^^^^^^^
+
+Custom data 3
+
+Param[7]
+^^^^^^^^
+
+Custom data 4
+
+Param[8]
+^^^^^^^^
+
+Custom data 5
+
+Param[9]
+^^^^^^^^
+
+Custom data 6
+
+Param[10]
+^^^^^^^^^
+
+Custom data 7
+
+Param[11]
+^^^^^^^^^
+
+Custom data 8
+
+
+
+CX2341X_ENC_MUTE_VIDEO
+~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 217/0xD9
+
+Description
+^^^^^^^^^^^
+
+Video muting
+
+Param[0]
+^^^^^^^^
+
+Bit usage:
+
+.. code-block:: none
+
+ 0 '0'=video not muted
+ '1'=video muted, creates frames with the YUV color defined below
+ 1:7 Unused
+ 8:15 V chrominance information
+ 16:23 U chrominance information
+ 24:31 Y luminance information
+
+
+
+CX2341X_ENC_MUTE_AUDIO
+~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 218/0xDA
+
+Description
+^^^^^^^^^^^
+
+Audio muting
+
+Param[0]
+^^^^^^^^
+
+- 0=audio not muted
+- 1=audio muted (produces silent mpeg audio stream)
+
+
+
+CX2341X_ENC_SET_VERT_CROP_LINE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 219/0xDB
+
+Description
+^^^^^^^^^^^
+
+Something to do with 'Vertical Crop Line'
+
+Param[0]
+^^^^^^^^
+
+If saa7114 and raw VBI capture and 60 Hz, then set to 10001.
+Else 0.
+
+
+
+CX2341X_ENC_MISC
+~~~~~~~~~~~~~~~~
+
+Enum: 220/0xDC
+
+Description
+^^^^^^^^^^^
+
+Miscellaneous actions. Not known for 100% what it does. It's really a
+sort of ioctl call. The first parameter is a command number, the second
+the value.
+
+Param[0]
+^^^^^^^^
+
+Command number:
+
+.. code-block:: none
+
+ 1=set initial SCR value when starting encoding (works).
+ 2=set quality mode (apparently some test setting).
+ 3=setup advanced VIM protection handling.
+ Always 1 for the cx23416 and 0 for cx23415.
+ 4=generate DVD compatible PTS timestamps
+ 5=USB flush mode
+ 6=something to do with the quantization matrix
+ 7=set navigation pack insertion for DVD: adds 0xbf (private stream 2)
+ packets to the MPEG. The size of these packets is 2048 bytes (including
+ the header of 6 bytes: 0x000001bf + length). The payload is zeroed and
+ it is up to the application to fill them in. These packets are apparently
+ inserted every four frames.
+ 8=enable scene change detection (seems to be a failure)
+ 9=set history parameters of the video input module
+ 10=set input field order of VIM
+ 11=set quantization matrix
+ 12=reset audio interface after channel change or input switch (has no argument).
+ Needed for the cx2584x, not needed for the mspx4xx, but it doesn't seem to
+ do any harm calling it regardless.
+ 13=set audio volume delay
+ 14=set audio delay
+
+
+Param[1]
+^^^^^^^^
+
+Command value.
+
+Decoder firmware API description
+--------------------------------
+
+.. note:: this API is part of the decoder firmware, so it's cx23415 only.
+
+
+
+CX2341X_DEC_PING_FW
+~~~~~~~~~~~~~~~~~~~
+
+Enum: 0/0x00
+
+Description
+^^^^^^^^^^^
+
+This API call does nothing. It may be used to check if the firmware
+is responding.
+
+
+
+CX2341X_DEC_START_PLAYBACK
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 1/0x01
+
+Description
+^^^^^^^^^^^
+
+Begin or resume playback.
+
+Param[0]
+^^^^^^^^
+
+0 based frame number in GOP to begin playback from.
+
+Param[1]
+^^^^^^^^
+
+Specifies the number of muted audio frames to play before normal
+audio resumes. (This is not implemented in the firmware, leave at 0)
+
+
+
+CX2341X_DEC_STOP_PLAYBACK
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 2/0x02
+
+Description
+^^^^^^^^^^^
+
+Ends playback and clears all decoder buffers. If PTS is not zero,
+playback stops at specified PTS.
+
+Param[0]
+^^^^^^^^
+
+Display 0=last frame, 1=black
+
+.. note::
+
+ this takes effect immediately, so if you want to wait for a PTS,
+ then use '0', otherwise the screen goes to black at once.
+ You can call this later (even if there is no playback) with a 1 value
+ to set the screen to black.
+
+Param[1]
+^^^^^^^^
+
+PTS low
+
+Param[2]
+^^^^^^^^
+
+PTS high
+
+
+
+CX2341X_DEC_SET_PLAYBACK_SPEED
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 3/0x03
+
+Description
+^^^^^^^^^^^
+
+Playback stream at speed other than normal. There are two modes of
+operation:
+
+ - Smooth: host transfers entire stream and firmware drops unused
+ frames.
+ - Coarse: host drops frames based on indexing as required to achieve
+ desired speed.
+
+Param[0]
+^^^^^^^^
+
+.. code-block:: none
+
+ Bitmap:
+ 0:7 0 normal
+ 1 fast only "1.5 times"
+ n nX fast, 1/nX slow
+ 30 Framedrop:
+ '0' during 1.5 times play, every other B frame is dropped
+ '1' during 1.5 times play, stream is unchanged (bitrate
+ must not exceed 8mbps)
+ 31 Speed:
+ '0' slow
+ '1' fast
+
+.. note::
+
+ n is limited to 2. Anything higher does not result in
+ faster playback. Instead the host should start dropping frames.
+
+Param[1]
+^^^^^^^^
+
+Direction: 0=forward, 1=reverse
+
+.. note::
+
+ to make reverse playback work you have to write full GOPs in
+ reverse order.
+
+Param[2]
+^^^^^^^^
+
+.. code-block:: none
+
+ Picture mask:
+ 1=I frames
+ 3=I, P frames
+ 7=I, P, B frames
+
+Param[3]
+^^^^^^^^
+
+B frames per GOP (for reverse play only)
+
+.. note::
+
+ for reverse playback the Picture Mask should be set to I or I, P.
+ Adding B frames to the mask will result in corrupt video. This field
+ has to be set to the correct value in order to keep the timing correct.
+
+Param[4]
+^^^^^^^^
+
+Mute audio: 0=disable, 1=enable
+
+Param[5]
+^^^^^^^^
+
+Display 0=frame, 1=field
+
+Param[6]
+^^^^^^^^
+
+Specifies the number of muted audio frames to play before normal audio
+resumes. (Not implemented in the firmware, leave at 0)
+
+
+
+CX2341X_DEC_STEP_VIDEO
+~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 5/0x05
+
+Description
+^^^^^^^^^^^
+
+Each call to this API steps the playback to the next unit defined below
+in the current playback direction.
+
+Param[0]
+^^^^^^^^
+
+0=frame, 1=top field, 2=bottom field
+
+
+
+CX2341X_DEC_SET_DMA_BLOCK_SIZE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 8/0x08
+
+Description
+^^^^^^^^^^^
+
+Set DMA transfer block size. Counterpart to API 0xC9
+
+Param[0]
+^^^^^^^^
+
+DMA transfer block size in bytes. A different size may be specified
+when issuing the DMA transfer command.
+
+
+
+CX2341X_DEC_GET_XFER_INFO
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 9/0x09
+
+Description
+^^^^^^^^^^^
+
+This API call may be used to detect an end of stream condition.
+
+Result[0]
+^^^^^^^^^
+
+Stream type
+
+Result[1]
+^^^^^^^^^
+
+Address offset
+
+Result[2]
+^^^^^^^^^
+
+Maximum bytes to transfer
+
+Result[3]
+^^^^^^^^^
+
+Buffer fullness
+
+
+
+CX2341X_DEC_GET_DMA_STATUS
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 10/0x0A
+
+Description
+^^^^^^^^^^^
+
+Status of the last DMA transfer
+
+Result[0]
+^^^^^^^^^
+
+Bit 1 set means transfer complete
+Bit 2 set means DMA error
+Bit 3 set means linked list error
+
+Result[1]
+^^^^^^^^^
+
+DMA type: 0=MPEG, 1=OSD, 2=YUV
+
+
+
+CX2341X_DEC_SCHED_DMA_FROM_HOST
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 11/0x0B
+
+Description
+^^^^^^^^^^^
+
+Setup DMA from host operation. Counterpart to API 0xCC
+
+Param[0]
+^^^^^^^^
+
+Memory address of link list
+
+Param[1]
+^^^^^^^^
+
+Total # of bytes to transfer
+
+Param[2]
+^^^^^^^^
+
+DMA type (0=MPEG, 1=OSD, 2=YUV)
+
+
+
+CX2341X_DEC_PAUSE_PLAYBACK
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 13/0x0D
+
+Description
+^^^^^^^^^^^
+
+Freeze playback immediately. In this mode, when internal buffers are
+full, no more data will be accepted and data request IRQs will be
+masked.
+
+Param[0]
+^^^^^^^^
+
+Display: 0=last frame, 1=black
+
+
+
+CX2341X_DEC_HALT_FW
+~~~~~~~~~~~~~~~~~~~
+
+Enum: 14/0x0E
+
+Description
+^^^^^^^^^^^
+
+The firmware is halted and no further API calls are serviced until
+the firmware is uploaded again.
+
+
+
+CX2341X_DEC_SET_STANDARD
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 16/0x10
+
+Description
+^^^^^^^^^^^
+
+Selects display standard
+
+Param[0]
+^^^^^^^^
+
+0=NTSC, 1=PAL
+
+
+
+CX2341X_DEC_GET_VERSION
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 17/0x11
+
+Description
+^^^^^^^^^^^
+
+Returns decoder firmware version information
+
+Result[0]
+^^^^^^^^^
+
+Version bitmask:
+ - Bits 0:15 build
+ - Bits 16:23 minor
+ - Bits 24:31 major
+
+
+
+CX2341X_DEC_SET_STREAM_INPUT
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 20/0x14
+
+Description
+^^^^^^^^^^^
+
+Select decoder stream input port
+
+Param[0]
+^^^^^^^^
+
+0=memory (default), 1=streaming
+
+
+
+CX2341X_DEC_GET_TIMING_INFO
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 21/0x15
+
+Description
+^^^^^^^^^^^
+
+Returns timing information from start of playback
+
+Result[0]
+^^^^^^^^^
+
+Frame count by decode order
+
+Result[1]
+^^^^^^^^^
+
+Video PTS bits 0:31 by display order
+
+Result[2]
+^^^^^^^^^
+
+Video PTS bit 32 by display order
+
+Result[3]
+^^^^^^^^^
+
+SCR bits 0:31 by display order
+
+Result[4]
+^^^^^^^^^
+
+SCR bit 32 by display order
+
+
+
+CX2341X_DEC_SET_AUDIO_MODE
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 22/0x16
+
+Description
+^^^^^^^^^^^
+
+Select audio mode
+
+Param[0]
+^^^^^^^^
+
+Dual mono mode action
+ 0=Stereo, 1=Left, 2=Right, 3=Mono, 4=Swap, -1=Unchanged
+
+Param[1]
+^^^^^^^^
+
+Stereo mode action:
+ 0=Stereo, 1=Left, 2=Right, 3=Mono, 4=Swap, -1=Unchanged
+
+
+
+CX2341X_DEC_SET_EVENT_NOTIFICATION
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 23/0x17
+
+Description
+^^^^^^^^^^^
+
+Setup firmware to notify the host about a particular event.
+Counterpart to API 0xD5
+
+Param[0]
+^^^^^^^^
+
+Event:
+ - 0=Audio mode change between mono, (joint) stereo and dual channel.
+ - 3=Decoder started
+ - 4=Unknown: goes off 10-15 times per second while decoding.
+ - 5=Some sync event: goes off once per frame.
+
+Param[1]
+^^^^^^^^
+
+Notification 0=disabled, 1=enabled
+
+Param[2]
+^^^^^^^^
+
+Interrupt bit
+
+Param[3]
+^^^^^^^^
+
+Mailbox slot, -1 if no mailbox required.
+
+
+
+CX2341X_DEC_SET_DISPLAY_BUFFERS
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 24/0x18
+
+Description
+^^^^^^^^^^^
+
+Number of display buffers. To decode all frames in reverse playback you
+must use nine buffers.
+
+Param[0]
+^^^^^^^^
+
+0=six buffers, 1=nine buffers
+
+
+
+CX2341X_DEC_EXTRACT_VBI
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 25/0x19
+
+Description
+^^^^^^^^^^^
+
+Extracts VBI data
+
+Param[0]
+^^^^^^^^
+
+0=extract from extension & user data, 1=extract from private packets
+
+Result[0]
+^^^^^^^^^
+
+VBI table location
+
+Result[1]
+^^^^^^^^^
+
+VBI table size
+
+
+
+CX2341X_DEC_SET_DECODER_SOURCE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 26/0x1A
+
+Description
+^^^^^^^^^^^
+
+Selects decoder source. Ensure that the parameters passed to this
+API match the encoder settings.
+
+Param[0]
+^^^^^^^^
+
+Mode: 0=MPEG from host, 1=YUV from encoder, 2=YUV from host
+
+Param[1]
+^^^^^^^^
+
+YUV picture width
+
+Param[2]
+^^^^^^^^
+
+YUV picture height
+
+Param[3]
+^^^^^^^^
+
+Bitmap: see Param[0] of API 0xBD
+
+
+
+CX2341X_DEC_SET_PREBUFFERING
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Enum: 30/0x1E
+
+Description
+^^^^^^^^^^^
+
+Decoder prebuffering, when enabled up to 128KB are buffered for
+streams <8mpbs or 640KB for streams >8mbps
+
+Param[0]
+^^^^^^^^
+
+0=off, 1=on
+
+PVR350 Video decoder registers 0x02002800 -> 0x02002B00
+-------------------------------------------------------
+
+Author: Ian Armstrong <ian@iarmst.demon.co.uk>
+
+Version: v0.4
+
+Date: 12 March 2007
+
+
+This list has been worked out through trial and error. There will be mistakes
+and omissions. Some registers have no obvious effect so it's hard to say what
+they do, while others interact with each other, or require a certain load
+sequence. Horizontal filter setup is one example, with six registers working
+in unison and requiring a certain load sequence to correctly configure. The
+indexed colour palette is much easier to set at just two registers, but again
+it requires a certain load sequence.
+
+Some registers are fussy about what they are set to. Load in a bad value & the
+decoder will fail. A firmware reload will often recover, but sometimes a reset
+is required. For registers containing size information, setting them to 0 is
+generally a bad idea. For other control registers i.e. 2878, you'll only find
+out what values are bad when it hangs.
+
+.. code-block:: none
+
+ --------------------------------------------------------------------------------
+ 2800
+ bit 0
+ Decoder enable
+ 0 = disable
+ 1 = enable
+ --------------------------------------------------------------------------------
+ 2804
+ bits 0:31
+ Decoder horizontal Y alias register 1
+ ---------------
+ 2808
+ bits 0:31
+ Decoder horizontal Y alias register 2
+ ---------------
+ 280C
+ bits 0:31
+ Decoder horizontal Y alias register 3
+ ---------------
+ 2810
+ bits 0:31
+ Decoder horizontal Y alias register 4
+ ---------------
+ 2814
+ bits 0:31
+ Decoder horizontal Y alias register 5
+ ---------------
+ 2818
+ bits 0:31
+ Decoder horizontal Y alias trigger
+
+ These six registers control the horizontal aliasing filter for the Y plane.
+ The first five registers must all be loaded before accessing the trigger
+ (2818), as this register actually clocks the data through for the first
+ five.
+
+ To correctly program set the filter, this whole procedure must be done 16
+ times. The actual register contents are copied from a lookup-table in the
+ firmware which contains 4 different filter settings.
+
+ --------------------------------------------------------------------------------
+ 281C
+ bits 0:31
+ Decoder horizontal UV alias register 1
+ ---------------
+ 2820
+ bits 0:31
+ Decoder horizontal UV alias register 2
+ ---------------
+ 2824
+ bits 0:31
+ Decoder horizontal UV alias register 3
+ ---------------
+ 2828
+ bits 0:31
+ Decoder horizontal UV alias register 4
+ ---------------
+ 282C
+ bits 0:31
+ Decoder horizontal UV alias register 5
+ ---------------
+ 2830
+ bits 0:31
+ Decoder horizontal UV alias trigger
+
+ These six registers control the horizontal aliasing for the UV plane.
+ Operation is the same as the Y filter, with 2830 being the trigger
+ register.
+
+ --------------------------------------------------------------------------------
+ 2834
+ bits 0:15
+ Decoder Y source width in pixels
+
+ bits 16:31
+ Decoder Y destination width in pixels
+ ---------------
+ 2838
+ bits 0:15
+ Decoder UV source width in pixels
+
+ bits 16:31
+ Decoder UV destination width in pixels
+
+ NOTE: For both registers, the resulting image must be fully visible on
+ screen. If the image exceeds the right edge both the source and destination
+ size must be adjusted to reflect the visible portion. For the source width,
+ you must take into account the scaling when calculating the new value.
+ --------------------------------------------------------------------------------
+
+ 283C
+ bits 0:31
+ Decoder Y horizontal scaling
+ Normally = Reg 2854 >> 2
+ ---------------
+ 2840
+ bits 0:31
+ Decoder ?? unknown - horizontal scaling
+ Usually 0x00080514
+ ---------------
+ 2844
+ bits 0:31
+ Decoder UV horizontal scaling
+ Normally = Reg 2854 >> 2
+ ---------------
+ 2848
+ bits 0:31
+ Decoder ?? unknown - horizontal scaling
+ Usually 0x00100514
+ ---------------
+ 284C
+ bits 0:31
+ Decoder ?? unknown - Y plane
+ Usually 0x00200020
+ ---------------
+ 2850
+ bits 0:31
+ Decoder ?? unknown - UV plane
+ Usually 0x00200020
+ ---------------
+ 2854
+ bits 0:31
+ Decoder 'master' value for horizontal scaling
+ ---------------
+ 2858
+ bits 0:31
+ Decoder ?? unknown
+ Usually 0
+ ---------------
+ 285C
+ bits 0:31
+ Decoder ?? unknown
+ Normally = Reg 2854 >> 1
+ ---------------
+ 2860
+ bits 0:31
+ Decoder ?? unknown
+ Usually 0
+ ---------------
+ 2864
+ bits 0:31
+ Decoder ?? unknown
+ Normally = Reg 2854 >> 1
+ ---------------
+ 2868
+ bits 0:31
+ Decoder ?? unknown
+ Usually 0
+
+ Most of these registers either control horizontal scaling, or appear linked
+ to it in some way. Register 2854 contains the 'master' value & the other
+ registers can be calculated from that one. You must also remember to
+ correctly set the divider in Reg 2874.
+
+ To enlarge:
+ Reg 2854 = (source_width * 0x00200000) / destination_width
+ Reg 2874 = No divide
+
+ To reduce from full size down to half size:
+ Reg 2854 = (source_width/2 * 0x00200000) / destination width
+ Reg 2874 = Divide by 2
+
+ To reduce from half size down to quarter size:
+ Reg 2854 = (source_width/4 * 0x00200000) / destination width
+ Reg 2874 = Divide by 4
+
+ The result is always rounded up.
+
+ --------------------------------------------------------------------------------
+ 286C
+ bits 0:15
+ Decoder horizontal Y buffer offset
+
+ bits 15:31
+ Decoder horizontal UV buffer offset
+
+ Offset into the video image buffer. If the offset is gradually incremented,
+ the on screen image will move left & wrap around higher up on the right.
+
+ --------------------------------------------------------------------------------
+ 2870
+ bits 0:15
+ Decoder horizontal Y output offset
+
+ bits 16:31
+ Decoder horizontal UV output offset
+
+ Offsets the actual video output. Controls output alignment of the Y & UV
+ planes. The higher the value, the greater the shift to the left. Use
+ reg 2890 to move the image right.
+
+ --------------------------------------------------------------------------------
+ 2874
+ bits 0:1
+ Decoder horizontal Y output size divider
+ 00 = No divide
+ 01 = Divide by 2
+ 10 = Divide by 3
+
+ bits 4:5
+ Decoder horizontal UV output size divider
+ 00 = No divide
+ 01 = Divide by 2
+ 10 = Divide by 3
+
+ bit 8
+ Decoder ?? unknown
+ 0 = Normal
+ 1 = Affects video output levels
+
+ bit 16
+ Decoder ?? unknown
+ 0 = Normal
+ 1 = Disable horizontal filter
+
+ --------------------------------------------------------------------------------
+ 2878
+ bit 0
+ ?? unknown
+
+ bit 1
+ osd on/off
+ 0 = osd off
+ 1 = osd on
+
+ bit 2
+ Decoder + osd video timing
+ 0 = NTSC
+ 1 = PAL
+
+ bits 3:4
+ ?? unknown
+
+ bit 5
+ Decoder + osd
+ Swaps upper & lower fields
+
+ --------------------------------------------------------------------------------
+ 287C
+ bits 0:10
+ Decoder & osd ?? unknown
+ Moves entire screen horizontally. Starts at 0x005 with the screen
+ shifted heavily to the right. Incrementing in steps of 0x004 will
+ gradually shift the screen to the left.
+
+ bits 11:31
+ ?? unknown
+
+ Normally contents are 0x00101111 (NTSC) or 0x1010111d (PAL)
+
+ --------------------------------------------------------------------------------
+ 2880 -------- ?? unknown
+ 2884 -------- ?? unknown
+ --------------------------------------------------------------------------------
+ 2888
+ bit 0
+ Decoder + osd ?? unknown
+ 0 = Normal
+ 1 = Misaligned fields (Correctable through 289C & 28A4)
+
+ bit 4
+ ?? unknown
+
+ bit 8
+ ?? unknown
+
+ Warning: Bad values will require a firmware reload to recover.
+ Known to be bad are 0x000,0x011,0x100,0x111
+ --------------------------------------------------------------------------------
+ 288C
+ bits 0:15
+ osd ?? unknown
+ Appears to affect the osd position stability. The higher the value the
+ more unstable it becomes. Decoder output remains stable.
+
+ bits 16:31
+ osd ?? unknown
+ Same as bits 0:15
+
+ --------------------------------------------------------------------------------
+ 2890
+ bits 0:11
+ Decoder output horizontal offset.
+
+ Horizontal offset moves the video image right. A small left shift is
+ possible, but it's better to use reg 2870 for that due to its greater
+ range.
+
+ NOTE: Video corruption will occur if video window is shifted off the right
+ edge. To avoid this read the notes for 2834 & 2838.
+ --------------------------------------------------------------------------------
+ 2894
+ bits 0:23
+ Decoder output video surround colour.
+
+ Contains the colour (in yuv) used to fill the screen when the video is
+ running in a window.
+ --------------------------------------------------------------------------------
+ 2898
+ bits 0:23
+ Decoder video window colour
+ Contains the colour (in yuv) used to fill the video window when the
+ video is turned off.
+
+ bit 24
+ Decoder video output
+ 0 = Video on
+ 1 = Video off
+
+ bit 28
+ Decoder plane order
+ 0 = Y,UV
+ 1 = UV,Y
+
+ bit 29
+ Decoder second plane byte order
+ 0 = Normal (UV)
+ 1 = Swapped (VU)
+
+ In normal usage, the first plane is Y & the second plane is UV. Though the
+ order of the planes can be swapped, only the byte order of the second plane
+ can be swapped. This isn't much use for the Y plane, but can be useful for
+ the UV plane.
+
+ --------------------------------------------------------------------------------
+ 289C
+ bits 0:15
+ Decoder vertical field offset 1
+
+ bits 16:31
+ Decoder vertical field offset 2
+
+ Controls field output vertical alignment. The higher the number, the lower
+ the image on screen. Known starting values are 0x011E0017 (NTSC) &
+ 0x01500017 (PAL)
+ --------------------------------------------------------------------------------
+ 28A0
+ bits 0:15
+ Decoder & osd width in pixels
+
+ bits 16:31
+ Decoder & osd height in pixels
+
+ All output from the decoder & osd are disabled beyond this area. Decoder
+ output will simply go black outside of this region. If the osd tries to
+ exceed this area it will become corrupt.
+ --------------------------------------------------------------------------------
+ 28A4
+ bits 0:11
+ osd left shift.
+
+ Has a range of 0x770->0x7FF. With the exception of 0, any value outside of
+ this range corrupts the osd.
+ --------------------------------------------------------------------------------
+ 28A8
+ bits 0:15
+ osd vertical field offset 1
+
+ bits 16:31
+ osd vertical field offset 2
+
+ Controls field output vertical alignment. The higher the number, the lower
+ the image on screen. Known starting values are 0x011E0017 (NTSC) &
+ 0x01500017 (PAL)
+ --------------------------------------------------------------------------------
+ 28AC -------- ?? unknown
+ |
+ V
+ 28BC -------- ?? unknown
+ --------------------------------------------------------------------------------
+ 28C0
+ bit 0
+ Current output field
+ 0 = first field
+ 1 = second field
+
+ bits 16:31
+ Current scanline
+ The scanline counts from the top line of the first field
+ through to the last line of the second field.
+ --------------------------------------------------------------------------------
+ 28C4 -------- ?? unknown
+ |
+ V
+ 28F8 -------- ?? unknown
+ --------------------------------------------------------------------------------
+ 28FC
+ bit 0
+ ?? unknown
+ 0 = Normal
+ 1 = Breaks decoder & osd output
+ --------------------------------------------------------------------------------
+ 2900
+ bits 0:31
+ Decoder vertical Y alias register 1
+ ---------------
+ 2904
+ bits 0:31
+ Decoder vertical Y alias register 2
+ ---------------
+ 2908
+ bits 0:31
+ Decoder vertical Y alias trigger
+
+ These three registers control the vertical aliasing filter for the Y plane.
+ Operation is similar to the horizontal Y filter (2804). The only real
+ difference is that there are only two registers to set before accessing
+ the trigger register (2908). As for the horizontal filter, the values are
+ taken from a lookup table in the firmware, and the procedure must be
+ repeated 16 times to fully program the filter.
+ --------------------------------------------------------------------------------
+ 290C
+ bits 0:31
+ Decoder vertical UV alias register 1
+ ---------------
+ 2910
+ bits 0:31
+ Decoder vertical UV alias register 2
+ ---------------
+ 2914
+ bits 0:31
+ Decoder vertical UV alias trigger
+
+ These three registers control the vertical aliasing filter for the UV
+ plane. Operation is the same as the Y filter, with 2914 being the trigger.
+ --------------------------------------------------------------------------------
+ 2918
+ bits 0:15
+ Decoder Y source height in pixels
+
+ bits 16:31
+ Decoder Y destination height in pixels
+ ---------------
+ 291C
+ bits 0:15
+ Decoder UV source height in pixels divided by 2
+
+ bits 16:31
+ Decoder UV destination height in pixels
+
+ NOTE: For both registers, the resulting image must be fully visible on
+ screen. If the image exceeds the bottom edge both the source and
+ destination size must be adjusted to reflect the visible portion. For the
+ source height, you must take into account the scaling when calculating the
+ new value.
+ --------------------------------------------------------------------------------
+ 2920
+ bits 0:31
+ Decoder Y vertical scaling
+ Normally = Reg 2930 >> 2
+ ---------------
+ 2924
+ bits 0:31
+ Decoder Y vertical scaling
+ Normally = Reg 2920 + 0x514
+ ---------------
+ 2928
+ bits 0:31
+ Decoder UV vertical scaling
+ When enlarging = Reg 2930 >> 2
+ When reducing = Reg 2930 >> 3
+ ---------------
+ 292C
+ bits 0:31
+ Decoder UV vertical scaling
+ Normally = Reg 2928 + 0x514
+ ---------------
+ 2930
+ bits 0:31
+ Decoder 'master' value for vertical scaling
+ ---------------
+ 2934
+ bits 0:31
+ Decoder ?? unknown - Y vertical scaling
+ ---------------
+ 2938
+ bits 0:31
+ Decoder Y vertical scaling
+ Normally = Reg 2930
+ ---------------
+ 293C
+ bits 0:31
+ Decoder ?? unknown - Y vertical scaling
+ ---------------
+ 2940
+ bits 0:31
+ Decoder UV vertical scaling
+ When enlarging = Reg 2930 >> 1
+ When reducing = Reg 2930
+ ---------------
+ 2944
+ bits 0:31
+ Decoder ?? unknown - UV vertical scaling
+ ---------------
+ 2948
+ bits 0:31
+ Decoder UV vertical scaling
+ Normally = Reg 2940
+ ---------------
+ 294C
+ bits 0:31
+ Decoder ?? unknown - UV vertical scaling
+
+ Most of these registers either control vertical scaling, or appear linked
+ to it in some way. Register 2930 contains the 'master' value & all other
+ registers can be calculated from that one. You must also remember to
+ correctly set the divider in Reg 296C
+
+ To enlarge:
+ Reg 2930 = (source_height * 0x00200000) / destination_height
+ Reg 296C = No divide
+
+ To reduce from full size down to half size:
+ Reg 2930 = (source_height/2 * 0x00200000) / destination height
+ Reg 296C = Divide by 2
+
+ To reduce from half down to quarter.
+ Reg 2930 = (source_height/4 * 0x00200000) / destination height
+ Reg 296C = Divide by 4
+
+ --------------------------------------------------------------------------------
+ 2950
+ bits 0:15
+ Decoder Y line index into display buffer, first field
+
+ bits 16:31
+ Decoder Y vertical line skip, first field
+ --------------------------------------------------------------------------------
+ 2954
+ bits 0:15
+ Decoder Y line index into display buffer, second field
+
+ bits 16:31
+ Decoder Y vertical line skip, second field
+ --------------------------------------------------------------------------------
+ 2958
+ bits 0:15
+ Decoder UV line index into display buffer, first field
+
+ bits 16:31
+ Decoder UV vertical line skip, first field
+ --------------------------------------------------------------------------------
+ 295C
+ bits 0:15
+ Decoder UV line index into display buffer, second field
+
+ bits 16:31
+ Decoder UV vertical line skip, second field
+ --------------------------------------------------------------------------------
+ 2960
+ bits 0:15
+ Decoder destination height minus 1
+
+ bits 16:31
+ Decoder destination height divided by 2
+ --------------------------------------------------------------------------------
+ 2964
+ bits 0:15
+ Decoder Y vertical offset, second field
+
+ bits 16:31
+ Decoder Y vertical offset, first field
+
+ These two registers shift the Y plane up. The higher the number, the
+ greater the shift.
+ --------------------------------------------------------------------------------
+ 2968
+ bits 0:15
+ Decoder UV vertical offset, second field
+
+ bits 16:31
+ Decoder UV vertical offset, first field
+
+ These two registers shift the UV plane up. The higher the number, the
+ greater the shift.
+ --------------------------------------------------------------------------------
+ 296C
+ bits 0:1
+ Decoder vertical Y output size divider
+ 00 = No divide
+ 01 = Divide by 2
+ 10 = Divide by 4
+
+ bits 8:9
+ Decoder vertical UV output size divider
+ 00 = No divide
+ 01 = Divide by 2
+ 10 = Divide by 4
+ --------------------------------------------------------------------------------
+ 2970
+ bit 0
+ Decoder ?? unknown
+ 0 = Normal
+ 1 = Affect video output levels
+
+ bit 16
+ Decoder ?? unknown
+ 0 = Normal
+ 1 = Disable vertical filter
+
+ --------------------------------------------------------------------------------
+ 2974 -------- ?? unknown
+ |
+ V
+ 29EF -------- ?? unknown
+ --------------------------------------------------------------------------------
+ 2A00
+ bits 0:2
+ osd colour mode
+ 000 = 8 bit indexed
+ 001 = 16 bit (565)
+ 010 = 15 bit (555)
+ 011 = 12 bit (444)
+ 100 = 32 bit (8888)
+
+ bits 4:5
+ osd display bpp
+ 01 = 8 bit
+ 10 = 16 bit
+ 11 = 32 bit
+
+ bit 8
+ osd global alpha
+ 0 = Off
+ 1 = On
+
+ bit 9
+ osd local alpha
+ 0 = Off
+ 1 = On
+
+ bit 10
+ osd colour key
+ 0 = Off
+ 1 = On
+
+ bit 11
+ osd ?? unknown
+ Must be 1
+
+ bit 13
+ osd colour space
+ 0 = ARGB
+ 1 = AYVU
+
+ bits 16:31
+ osd ?? unknown
+ Must be 0x001B (some kind of buffer pointer ?)
+
+ When the bits-per-pixel is set to 8, the colour mode is ignored and
+ assumed to be 8 bit indexed. For 16 & 32 bits-per-pixel the colour depth
+ is honoured, and when using a colour depth that requires fewer bytes than
+ allocated the extra bytes are used as padding. So for a 32 bpp with 8 bit
+ index colour, there are 3 padding bytes per pixel. It's also possible to
+ select 16bpp with a 32 bit colour mode. This results in the pixel width
+ being doubled, but the color key will not work as expected in this mode.
+
+ Colour key is as it suggests. You designate a colour which will become
+ completely transparent. When using 565, 555 or 444 colour modes, the
+ colour key is always 16 bits wide. The colour to key on is set in Reg 2A18.
+
+ Local alpha works differently depending on the colour mode. For 32bpp & 8
+ bit indexed, local alpha is a per-pixel 256 step transparency, with 0 being
+ transparent and 255 being solid. For the 16bpp modes 555 & 444, the unused
+ bit(s) act as a simple transparency switch, with 0 being solid & 1 being
+ fully transparent. There is no local alpha support for 16bit 565.
+
+ Global alpha is a 256 step transparency that applies to the entire osd,
+ with 0 being transparent & 255 being solid.
+
+ It's possible to combine colour key, local alpha & global alpha.
+ --------------------------------------------------------------------------------
+ 2A04
+ bits 0:15
+ osd x coord for left edge
+
+ bits 16:31
+ osd y coord for top edge
+ ---------------
+ 2A08
+ bits 0:15
+ osd x coord for right edge
+
+ bits 16:31
+ osd y coord for bottom edge
+
+ For both registers, (0,0) = top left corner of the display area. These
+ registers do not control the osd size, only where it's positioned & how
+ much is visible. The visible osd area cannot exceed the right edge of the
+ display, otherwise the osd will become corrupt. See reg 2A10 for
+ setting osd width.
+ --------------------------------------------------------------------------------
+ 2A0C
+ bits 0:31
+ osd buffer index
+
+ An index into the osd buffer. Slowly incrementing this moves the osd left,
+ wrapping around onto the right edge
+ --------------------------------------------------------------------------------
+ 2A10
+ bits 0:11
+ osd buffer 32 bit word width
+
+ Contains the width of the osd measured in 32 bit words. This means that all
+ colour modes are restricted to a byte width which is divisible by 4.
+ --------------------------------------------------------------------------------
+ 2A14
+ bits 0:15
+ osd height in pixels
+
+ bits 16:32
+ osd line index into buffer
+ osd will start displaying from this line.
+ --------------------------------------------------------------------------------
+ 2A18
+ bits 0:31
+ osd colour key
+
+ Contains the colour value which will be transparent.
+ --------------------------------------------------------------------------------
+ 2A1C
+ bits 0:7
+ osd global alpha
+
+ Contains the global alpha value (equiv ivtvfbctl --alpha XX)
+ --------------------------------------------------------------------------------
+ 2A20 -------- ?? unknown
+ |
+ V
+ 2A2C -------- ?? unknown
+ --------------------------------------------------------------------------------
+ 2A30
+ bits 0:7
+ osd colour to change in indexed palette
+ ---------------
+ 2A34
+ bits 0:31
+ osd colour for indexed palette
+
+ To set the new palette, first load the index of the colour to change into
+ 2A30, then load the new colour into 2A34. The full palette is 256 colours,
+ so the index range is 0x00-0xFF
+ --------------------------------------------------------------------------------
+ 2A38 -------- ?? unknown
+ 2A3C -------- ?? unknown
+ --------------------------------------------------------------------------------
+ 2A40
+ bits 0:31
+ osd ?? unknown
+
+ Affects overall brightness, wrapping around to black
+ --------------------------------------------------------------------------------
+ 2A44
+ bits 0:31
+ osd ?? unknown
+
+ Green tint
+ --------------------------------------------------------------------------------
+ 2A48
+ bits 0:31
+ osd ?? unknown
+
+ Red tint
+ --------------------------------------------------------------------------------
+ 2A4C
+ bits 0:31
+ osd ?? unknown
+
+ Affects overall brightness, wrapping around to black
+ --------------------------------------------------------------------------------
+ 2A50
+ bits 0:31
+ osd ?? unknown
+
+ Colour shift
+ --------------------------------------------------------------------------------
+ 2A54
+ bits 0:31
+ osd ?? unknown
+
+ Colour shift
+ --------------------------------------------------------------------------------
+ 2A58 -------- ?? unknown
+ |
+ V
+ 2AFC -------- ?? unknown
+ --------------------------------------------------------------------------------
+ 2B00
+ bit 0
+ osd filter control
+ 0 = filter off
+ 1 = filter on
+
+ bits 1:4
+ osd ?? unknown
+
+ --------------------------------------------------------------------------------
+
+The cx231xx DMA engine
+----------------------
+
+
+This page describes the structures and procedures used by the cx2341x DMA
+engine.
+
+Introduction
+~~~~~~~~~~~~
+
+The cx2341x PCI interface is busmaster capable. This means it has a DMA
+engine to efficiently transfer large volumes of data between the card and main
+memory without requiring help from a CPU. Like most hardware, it must operate
+on contiguous physical memory. This is difficult to come by in large quantities
+on virtual memory machines.
+
+Therefore, it also supports a technique called "scatter-gather". The card can
+transfer multiple buffers in one operation. Instead of allocating one large
+contiguous buffer, the driver can allocate several smaller buffers.
+
+In practice, I've seen the average transfer to be roughly 80K, but transfers
+above 128K were not uncommon, particularly at startup. The 128K figure is
+important, because that is the largest block that the kernel can normally
+allocate. Even still, 128K blocks are hard to come by, so the driver writer is
+urged to choose a smaller block size and learn the scatter-gather technique.
+
+Mailbox #10 is reserved for DMA transfer information.
+
+Note: the hardware expects little-endian data ('intel format').
+
+Flow
+~~~~
+
+This section describes, in general, the order of events when handling DMA
+transfers. Detailed information follows this section.
+
+- The card raises the Encoder interrupt.
+- The driver reads the transfer type, offset and size from Mailbox #10.
+- The driver constructs the scatter-gather array from enough free dma buffers
+ to cover the size.
+- The driver schedules the DMA transfer via the ScheduleDMAtoHost API call.
+- The card raises the DMA Complete interrupt.
+- The driver checks the DMA status register for any errors.
+- The driver post-processes the newly transferred buffers.
+
+NOTE! It is possible that the Encoder and DMA Complete interrupts get raised
+simultaneously. (End of the last, start of the next, etc.)
+
+Mailbox #10
+~~~~~~~~~~~
+
+The Flags, Command, Return Value and Timeout fields are ignored.
+
+- Name: Mailbox #10
+- Results[0]: Type: 0: MPEG.
+- Results[1]: Offset: The position relative to the card's memory space.
+- Results[2]: Size: The exact number of bytes to transfer.
+
+My speculation is that since the StartCapture API has a capture type of "RAW"
+available, that the type field will have other values that correspond to YUV
+and PCM data.
+
+Scatter-Gather Array
+~~~~~~~~~~~~~~~~~~~~
+
+The scatter-gather array is a contiguously allocated block of memory that
+tells the card the source and destination of each data-block to transfer.
+Card "addresses" are derived from the offset supplied by Mailbox #10. Host
+addresses are the physical memory location of the target DMA buffer.
+
+Each S-G array element is a struct of three 32-bit words. The first word is
+the source address, the second is the destination address. Both take up the
+entire 32 bits. The lowest 18 bits of the third word is the transfer byte
+count. The high-bit of the third word is the "last" flag. The last-flag tells
+the card to raise the DMA_DONE interrupt. From hard personal experience, if
+you forget to set this bit, the card will still "work" but the stream will
+most likely get corrupted.
+
+The transfer count must be a multiple of 256. Therefore, the driver will need
+to track how much data in the target buffer is valid and deal with it
+accordingly.
+
+Array Element:
+
+- 32-bit Source Address
+- 32-bit Destination Address
+- 14-bit reserved (high bit is the last flag)
+- 18-bit byte count
+
+DMA Transfer Status
+~~~~~~~~~~~~~~~~~~~
+
+Register 0x0004 holds the DMA Transfer Status:
+
+- bit 0: read completed
+- bit 1: write completed
+- bit 2: DMA read error
+- bit 3: DMA write error
+- bit 4: Scatter-Gather array error
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+The cx88 driver
+===============
+
+Author: Gerd Hoffmann
+
+Documentation missing at the cx88 datasheet
+-------------------------------------------
+
+MO_OUTPUT_FORMAT (0x310164)
+
+.. code-block:: none
+
+ Previous default from DScaler: 0x1c1f0008
+ Digit 8: 31-28
+ 28: PREVREMOD = 1
+
+ Digit 7: 27-24 (0xc = 12 = b1100 )
+ 27: COMBALT = 1
+ 26: PAL_INV_PHASE
+ (DScaler apparently set this to 1, resulted in sucky picture)
+
+ Digits 6,5: 23-16
+ 25-16: COMB_RANGE = 0x1f [default] (9 bits -> max 512)
+
+ Digit 4: 15-12
+ 15: DISIFX = 0
+ 14: INVCBF = 0
+ 13: DISADAPT = 0
+ 12: NARROWADAPT = 0
+
+ Digit 3: 11-8
+ 11: FORCE2H
+ 10: FORCEREMD
+ 9: NCHROMAEN
+ 8: NREMODEN
+
+ Digit 2: 7-4
+ 7-6: YCORE
+ 5-4: CCORE
+
+ Digit 1: 3-0
+ 3: RANGE = 1
+ 2: HACTEXT
+ 1: HSFMT
+
+0x47 is the sync byte for MPEG-2 transport stream packets.
+Datasheet incorrectly states to use 47 decimal. 188 is the length.
+All DVB compliant frontends output packets with this start code.
+
+Hauppauge WinTV cx88 IR information
+-----------------------------------
+
+The controls for the mux are GPIO [0,1] for source, and GPIO 2 for muting.
+
+====== ======== =================================================
+GPIO0 GPIO1
+====== ======== =================================================
+ 0 0 TV Audio
+ 1 0 FM radio
+ 0 1 Line-In
+ 1 1 Mono tuner bypass or CD passthru (tuner specific)
+====== ======== =================================================
+
+GPIO 16(I believe) is tied to the IR port (if present).
+
+
+From the data sheet:
+
+- Register 24'h20004 PCI Interrupt Status
+
+ - bit [18] IR_SMP_INT Set when 32 input samples have been collected over
+ - gpio[16] pin into GP_SAMPLE register.
+
+What's missing from the data sheet:
+
+- Setup 4KHz sampling rate (roughly 2x oversampled; good enough for our RC5
+ compat remote)
+- set register 0x35C050 to 0xa80a80
+- enable sampling
+- set register 0x35C054 to 0x5
+- enable the IRQ bit 18 in the interrupt mask register (and
+ provide for a handler)
+
+GP_SAMPLE register is at 0x35C058
+
+Bits are then right shifted into the GP_SAMPLE register at the specified
+rate; you get an interrupt when a full DWORD is received.
+You need to recover the actual RC5 bits out of the (oversampled) IR sensor
+bits. (Hint: look for the 0/1and 1/0 crossings of the RC5 bi-phase data) An
+actual raw RC5 code will span 2-3 DWORDS, depending on the actual alignment.
+
+I'm pretty sure when no IR signal is present the receiver is always in a
+marking state(1); but stray light, etc can cause intermittent noise values
+as well. Remember, this is a free running sample of the IR receiver state
+over time, so don't assume any sample starts at any particular place.
+
+Additional info
+~~~~~~~~~~~~~~~
+
+This data sheet (google search) seems to have a lovely description of the
+RC5 basics:
+http://www.atmel.com/dyn/resources/prod_documents/doc2817.pdf
+
+This document has more data:
+http://www.nenya.be/beor/electronics/rc5.htm
+
+This document has a how to decode a bi-phase data stream:
+http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt
+
+This document has still more info:
+http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+The VPBE V4L2 driver design
+===========================
+
+File partitioning
+-----------------
+
+ V4L2 display device driver
+ drivers/media/platform/davinci/vpbe_display.c
+ drivers/media/platform/davinci/vpbe_display.h
+
+ VPBE display controller
+ drivers/media/platform/davinci/vpbe.c
+ drivers/media/platform/davinci/vpbe.h
+
+ VPBE venc sub device driver
+ drivers/media/platform/davinci/vpbe_venc.c
+ drivers/media/platform/davinci/vpbe_venc.h
+ drivers/media/platform/davinci/vpbe_venc_regs.h
+
+ VPBE osd driver
+ drivers/media/platform/davinci/vpbe_osd.c
+ drivers/media/platform/davinci/vpbe_osd.h
+ drivers/media/platform/davinci/vpbe_osd_regs.h
+
+To be done
+----------
+
+vpbe display controller
+ - Add support for external encoders.
+ - add support for selecting external encoder as default at probe time.
+
+vpbe venc sub device
+ - add timings for supporting ths8200
+ - add support for LogicPD LCD.
+
+FB drivers
+ - Add support for fbdev drivers.- Ready and part of subsequent patches.
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+Idea behind the dvb-usb-framework
+=================================
+
+.. note::
+
+ #) This documentation is outdated. Please check at the DVB wiki
+ at https://linuxtv.org/wiki for more updated info.
+
+ #) **deprecated:** Newer DVB USB drivers should use the dvb-usb-v2 framework.
+
+In March 2005 I got the new Twinhan USB2.0 DVB-T device. They provided specs
+and a firmware.
+
+Quite keen I wanted to put the driver (with some quirks of course) into dibusb.
+After reading some specs and doing some USB snooping, it realized, that the
+dibusb-driver would be a complete mess afterwards. So I decided to do it in a
+different way: With the help of a dvb-usb-framework.
+
+The framework provides generic functions (mostly kernel API calls), such as:
+
+- Transport Stream URB handling in conjunction with dvb-demux-feed-control
+ (bulk and isoc are supported)
+- registering the device for the DVB-API
+- registering an I2C-adapter if applicable
+- remote-control/input-device handling
+- firmware requesting and loading (currently just for the Cypress USB
+ controllers)
+- other functions/methods which can be shared by several drivers (such as
+ functions for bulk-control-commands)
+- TODO: a I2C-chunker. It creates device-specific chunks of register-accesses
+ depending on length of a register and the number of values that can be
+ multi-written and multi-read.
+
+The source code of the particular DVB USB devices does just the communication
+with the device via the bus. The connection between the DVB-API-functionality
+is done via callbacks, assigned in a static device-description (struct
+dvb_usb_device) each device-driver has to have.
+
+For an example have a look in drivers/media/usb/dvb-usb/vp7045*.
+
+Objective is to migrate all the usb-devices (dibusb, cinergyT2, maybe the
+ttusb; flexcop-usb already benefits from the generic flexcop-device) to use
+the dvb-usb-lib.
+
+TODO: dynamic enabling and disabling of the pid-filter in regard to number of
+feeds requested.
+
+Supported devices
+-----------------
+
+See the LinuxTV DVB Wiki at https://linuxtv.org for a complete list of
+cards/drivers/firmwares:
+https://linuxtv.org/wiki/index.php/DVB_USB
+
+0. History & News:
+
+ 2005-06-30
+
+ - added support for WideView WT-220U (Thanks to Steve Chang)
+
+ 2005-05-30
+
+ - added basic isochronous support to the dvb-usb-framework
+ - added support for Conexant Hybrid reference design and Nebula
+ DigiTV USB
+
+ 2005-04-17
+
+ - all dibusb devices ported to make use of the dvb-usb-framework
+
+ 2005-04-02
+
+ - re-enabled and improved remote control code.
+
+ 2005-03-31
+
+ - ported the Yakumo/Hama/Typhoon DVB-T USB2.0 device to dvb-usb.
+
+ 2005-03-30
+
+ - first commit of the dvb-usb-module based on the dibusb-source.
+ First device is a new driver for the
+ TwinhanDTV Alpha / MagicBox II USB2.0-only DVB-T device.
+ - (change from dvb-dibusb to dvb-usb)
+
+ 2005-03-28
+
+ - added support for the AVerMedia AverTV DVB-T USB2.0 device
+ (Thanks to Glen Harris and Jiun-Kuei Jung, AVerMedia)
+
+ 2005-03-14
+
+ - added support for the Typhoon/Yakumo/HAMA DVB-T mobile USB2.0
+
+ 2005-02-11
+
+ - added support for the KWorld/ADSTech Instant DVB-T USB2.0.
+ Thanks a lot to Joachim von Caron
+
+ 2005-02-02
+ - added support for the Hauppauge Win-TV Nova-T USB2
+
+ 2005-01-31
+ - distorted streaming is gone for USB1.1 devices
+
+ 2005-01-13
+
+ - moved the mirrored pid_filter_table back to dvb-dibusb
+ first almost working version for HanfTek UMT-010
+ found out, that Yakumo/HAMA/Typhoon are predecessors of the HanfTek UMT-010
+
+ 2005-01-10
+
+ - refactoring completed, now everything is very delightful
+
+ - tuner quirks for some weird devices (Artec T1 AN2235 device has sometimes a
+ Panasonic Tuner assembled). Tunerprobing implemented.
+ Thanks a lot to Gunnar Wittich.
+
+ 2004-12-29
+
+ - after several days of struggling around bug of no returning URBs fixed.
+
+ 2004-12-26
+
+ - refactored the dibusb-driver, split into separate files
+ - i2c-probing enabled
+
+ 2004-12-06
+
+ - possibility for demod i2c-address probing
+ - new usb IDs (Compro, Artec)
+
+ 2004-11-23
+
+ - merged changes from DiB3000MC_ver2.1
+ - revised the debugging
+ - possibility to deliver the complete TS for USB2.0
+
+ 2004-11-21
+
+ - first working version of the dib3000mc/p frontend driver.
+
+ 2004-11-12
+
+ - added additional remote control keys. Thanks to Uwe Hanke.
+
+ 2004-11-07
+
+ - added remote control support. Thanks to David Matthews.
+
+ 2004-11-05
+
+ - added support for a new devices (Grandtec/Avermedia/Artec)
+ - merged my changes (for dib3000mb/dibusb) to the FE_REFACTORING, because it became HEAD
+ - moved transfer control (pid filter, fifo control) from usb driver to frontend, it seems
+ better settled there (added xfer_ops-struct)
+ - created a common files for frontends (mc/p/mb)
+
+ 2004-09-28
+
+ - added support for a new device (Unknown, vendor ID is Hyper-Paltek)
+
+ 2004-09-20
+
+ - added support for a new device (Compro DVB-U2000), thanks
+ to Amaury Demol for reporting
+ - changed usb TS transfer method (several urbs, stopping transfer
+ before setting a new pid)
+
+ 2004-09-13
+
+ - added support for a new device (Artec T1 USB TVBOX), thanks
+ to Christian Motschke for reporting
+
+ 2004-09-05
+
+ - released the dibusb device and dib3000mb-frontend driver
+ (old news for vp7041.c)
+
+ 2004-07-15
+
+ - found out, by accident, that the device has a TUA6010XS for PLL
+
+ 2004-07-12
+
+ - figured out, that the driver should also work with the
+ CTS Portable (Chinese Television System)
+
+ 2004-07-08
+
+ - firmware-extraction-2.422-problem solved, driver is now working
+ properly with firmware extracted from 2.422
+ - #if for 2.6.4 (dvb), compile issue
+ - changed firmware handling, see vp7041.txt sec 1.1
+
+ 2004-07-02
+
+ - some tuner modifications, v0.1, cleanups, first public
+
+ 2004-06-28
+
+ - now using the dvb_dmx_swfilter_packets, everything runs fine now
+
+ 2004-06-27
+
+ - able to watch and switching channels (pre-alpha)
+ - no section filtering yet
+
+ 2004-06-06
+
+ - first TS received, but kernel oops :/
+
+ 2004-05-14
+
+ - firmware loader is working
+
+ 2004-05-11
+
+ - start writing the driver
+
+How to use?
+-----------
+
+Firmware
+~~~~~~~~
+
+Most of the USB drivers need to download a firmware to the device before start
+working.
+
+Have a look at the Wikipage for the DVB-USB-drivers to find out, which firmware
+you need for your device:
+
+https://linuxtv.org/wiki/index.php/DVB_USB
+
+Compiling
+~~~~~~~~~
+
+Since the driver is in the linux kernel, activating the driver in
+your favorite config-environment should sufficient. I recommend
+to compile the driver as module. Hotplug does the rest.
+
+If you use dvb-kernel enter the build-2.6 directory run 'make' and 'insmod.sh
+load' afterwards.
+
+Loading the drivers
+~~~~~~~~~~~~~~~~~~~
+
+Hotplug is able to load the driver, when it is needed (because you plugged
+in the device).
+
+If you want to enable debug output, you have to load the driver manually and
+from within the dvb-kernel cvs repository.
+
+first have a look, which debug level are available:
+
+.. code-block:: none
+
+ # modinfo dvb-usb
+ # modinfo dvb-usb-vp7045
+
+ etc.
+
+.. code-block:: none
+
+ modprobe dvb-usb debug=<level>
+ modprobe dvb-usb-vp7045 debug=<level>
+ etc.
+
+should do the trick.
+
+When the driver is loaded successfully, the firmware file was in
+the right place and the device is connected, the "Power"-LED should be
+turned on.
+
+At this point you should be able to start a dvb-capable application. I'm use
+(t|s)zap, mplayer and dvbscan to test the basics. VDR-xine provides the
+long-term test scenario.
+
+Known problems and bugs
+-----------------------
+
+- Don't remove the USB device while running an DVB application, your system
+ will go crazy or die most likely.
+
+Adding support for devices
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TODO
+
+USB1.1 Bandwidth limitation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A lot of the currently supported devices are USB1.1 and thus they have a
+maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub.
+This is not enough for receiving the complete transport stream of a
+DVB-T channel (which is about 16 MBit/s). Normally this is not a
+problem, if you only want to watch TV (this does not apply for HDTV),
+but watching a channel while recording another channel on the same
+frequency simply does not work very well. This applies to all USB1.1
+DVB-T devices, not just the dvb-usb-devices)
+
+The bug, where the TS is distorted by a heavy usage of the device is gone
+definitely. All dvb-usb-devices I was using (Twinhan, Kworld, DiBcom) are
+working like charm now with VDR. Sometimes I even was able to record a channel
+and watch another one.
+
+Comments
+~~~~~~~~
+
+Patches, comments and suggestions are very very welcome.
+
+3. Acknowledgements
+-------------------
+
+ Amaury Demol (Amaury.Demol@parrot.com) and Francois Kanounnikoff from DiBcom for
+ providing specs, code and help, on which the dvb-dibusb, dib3000mb and
+ dib3000mc are based.
+
+ David Matthews for identifying a new device type (Artec T1 with AN2235)
+ and for extending dibusb with remote control event handling. Thank you.
+
+ Alex Woods for frequently answering question about usb and dvb
+ stuff, a big thank you.
+
+ Bernd Wagner for helping with huge bug reports and discussions.
+
+ Gunnar Wittich and Joachim von Caron for their trust for providing
+ root-shells on their machines to implement support for new devices.
+
+ Allan Third and Michael Hutchinson for their help to write the Nebula
+ digitv-driver.
+
+ Glen Harris for bringing up, that there is a new dibusb-device and Jiun-Kuei
+ Jung from AVerMedia who kindly provided a special firmware to get the device
+ up and running in Linux.
+
+ Jennifer Chen, Jeff and Jack from Twinhan for kindly supporting by
+ writing the vp7045-driver.
+
+ Steve Chang from WideView for providing information for new devices and
+ firmware files.
+
+ Michael Paxton for submitting remote control keymaps.
+
+ Some guys on the linux-dvb mailing list for encouraging me.
+
+ Peter Schildmann >peter.schildmann-nospam-at-web.de< for his
+ user-level firmware loader, which saves a lot of time
+ (when writing the vp7041 driver)
+
+ Ulf Hermenau for helping me out with traditional chinese.
+
+ André Smoktun and Christian Frömmel for supporting me with
+ hardware and listening to my problems very patiently.
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: <isonum.txt>
+
+The Samsung S5P/EXYNOS4 FIMC driver
+===================================
+
+Copyright |copy| 2012 - 2013 Samsung Electronics Co., Ltd.
+
+Files partitioning
+------------------
+
+- media device driver
+
+ drivers/media/platform/exynos4-is/media-dev.[ch]
+
+- camera capture video device driver
+
+ drivers/media/platform/exynos4-is/fimc-capture.c
+
+- MIPI-CSI2 receiver subdev
+
+ drivers/media/platform/exynos4-is/mipi-csis.[ch]
+
+- video post-processor (mem-to-mem)
+
+ drivers/media/platform/exynos4-is/fimc-core.c
+
+- common files
+
+ drivers/media/platform/exynos4-is/fimc-core.h
+ drivers/media/platform/exynos4-is/fimc-reg.h
+ drivers/media/platform/exynos4-is/regs-fimc.h
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+****************
+Frontend drivers
+****************
+
+Frontend attach headers
+***********************
+
+.. Keep it on alphabetic order
+
+.. kernel-doc:: drivers/media/dvb-frontends/a8293.h
+.. kernel-doc:: drivers/media/dvb-frontends/af9013.h
+.. kernel-doc:: drivers/media/dvb-frontends/ascot2e.h
+.. kernel-doc:: drivers/media/dvb-frontends/cxd2820r.h
+.. kernel-doc:: drivers/media/dvb-frontends/drxk.h
+.. kernel-doc:: drivers/media/dvb-frontends/dvb-pll.h
+.. kernel-doc:: drivers/media/dvb-frontends/helene.h
+.. kernel-doc:: drivers/media/dvb-frontends/horus3a.h
+.. kernel-doc:: drivers/media/dvb-frontends/ix2505v.h
+.. kernel-doc:: drivers/media/dvb-frontends/m88ds3103.h
+.. kernel-doc:: drivers/media/dvb-frontends/mb86a20s.h
+.. kernel-doc:: drivers/media/dvb-frontends/mn88472.h
+.. kernel-doc:: drivers/media/dvb-frontends/rtl2830.h
+.. kernel-doc:: drivers/media/dvb-frontends/rtl2832.h
+.. kernel-doc:: drivers/media/dvb-frontends/rtl2832_sdr.h
+.. kernel-doc:: drivers/media/dvb-frontends/stb6000.h
+.. kernel-doc:: drivers/media/dvb-frontends/tda10071.h
+.. kernel-doc:: drivers/media/dvb-frontends/tda826x.h
+.. kernel-doc:: drivers/media/dvb-frontends/zd1301_demod.h
+.. kernel-doc:: drivers/media/dvb-frontends/zl10036.h
+
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: <isonum.txt>
+
+################################################
+Video4Linux (V4L) driver-specific documentation
+################################################
+
+.. only:: html
+
+ .. class:: toc-title
+
+ Table of Contents
+
+.. toctree::
+ :maxdepth: 5
+
+ bttv-devel
+ cpia2_devel
+ cx2341x-devel
+ cx88-devel
+ davinci-vpbe-devel
+ fimc-devel
+ pvrusb2
+ pxa_camera
+ radiotrack
+ saa7134-devel
+ sh_mobile_ceu_camera
+ tuners
+ vimc-devel
+
+
+##############################################
+Linux Digital TV driver-specific documentation
+##############################################
+
+**Copyright** |copy| 2001-2016 : LinuxTV Developers
+
+This documentation is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by the Free
+Software Foundation version 2 of the License.
+
+This program is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+more details.
+
+For more details see the file COPYING in the source distribution of Linux.
+
+.. only:: html
+
+ .. class:: toc-title
+
+ Table of Contents
+
+.. toctree::
+ :maxdepth: 5
+
+ dvb-usb
+ frontends
+ contributors
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+The pvrusb2 driver
+==================
+
+Author: Mike Isely <isely@pobox.com>
+
+Background
+----------
+
+This driver is intended for the "Hauppauge WinTV PVR USB 2.0", which
+is a USB 2.0 hosted TV Tuner. This driver is a work in progress.
+Its history started with the reverse-engineering effort by Björn
+Danielsson <pvrusb2@dax.nu> whose web page can be found here:
+http://pvrusb2.dax.nu/
+
+From there Aurelien Alleaume <slts@free.fr> began an effort to
+create a video4linux compatible driver. I began with Aurelien's
+last known snapshot and evolved the driver to the state it is in
+here.
+
+More information on this driver can be found at:
+http://www.isely.net/pvrusb2.html
+
+
+This driver has a strong separation of layers. They are very
+roughly:
+
+1. Low level wire-protocol implementation with the device.
+
+2. I2C adaptor implementation and corresponding I2C client drivers
+ implemented elsewhere in V4L.
+
+3. High level hardware driver implementation which coordinates all
+ activities that ensure correct operation of the device.
+
+4. A "context" layer which manages instancing of driver, setup,
+ tear-down, arbitration, and interaction with high level
+ interfaces appropriately as devices are hotplugged in the
+ system.
+
+5. High level interfaces which glue the driver to various published
+ Linux APIs (V4L, sysfs, maybe DVB in the future).
+
+The most important shearing layer is between the top 2 layers. A
+lot of work went into the driver to ensure that any kind of
+conceivable API can be laid on top of the core driver. (Yes, the
+driver internally leverages V4L to do its work but that really has
+nothing to do with the API published by the driver to the outside
+world.) The architecture allows for different APIs to
+simultaneously access the driver. I have a strong sense of fairness
+about APIs and also feel that it is a good design principle to keep
+implementation and interface isolated from each other. Thus while
+right now the V4L high level interface is the most complete, the
+sysfs high level interface will work equally well for similar
+functions, and there's no reason I see right now why it shouldn't be
+possible to produce a DVB high level interface that can sit right
+alongside V4L.
+
+Building
+--------
+
+To build these modules essentially amounts to just running "Make",
+but you need the kernel source tree nearby and you will likely also
+want to set a few controlling environment variables first in order
+to link things up with that source tree. Please see the Makefile
+here for comments that explain how to do that.
+
+Source file list / functional overview
+--------------------------------------
+
+(Note: The term "module" used below generally refers to loosely
+defined functional units within the pvrusb2 driver and bears no
+relation to the Linux kernel's concept of a loadable module.)
+
+pvrusb2-audio.[ch] - This is glue logic that resides between this
+ driver and the msp3400.ko I2C client driver (which is found
+ elsewhere in V4L).
+
+pvrusb2-context.[ch] - This module implements the context for an
+ instance of the driver. Everything else eventually ties back to
+ or is otherwise instanced within the data structures implemented
+ here. Hotplugging is ultimately coordinated here. All high level
+ interfaces tie into the driver through this module. This module
+ helps arbitrate each interface's access to the actual driver core,
+ and is designed to allow concurrent access through multiple
+ instances of multiple interfaces (thus you can for example change
+ the tuner's frequency through sysfs while simultaneously streaming
+ video through V4L out to an instance of mplayer).
+
+pvrusb2-debug.h - This header defines a printk() wrapper and a mask
+ of debugging bit definitions for the various kinds of debug
+ messages that can be enabled within the driver.
+
+pvrusb2-debugifc.[ch] - This module implements a crude command line
+ oriented debug interface into the driver. Aside from being part
+ of the process for implementing manual firmware extraction (see
+ the pvrusb2 web site mentioned earlier), probably I'm the only one
+ who has ever used this. It is mainly a debugging aid.
+
+pvrusb2-eeprom.[ch] - This is glue logic that resides between this
+ driver the tveeprom.ko module, which is itself implemented
+ elsewhere in V4L.
+
+pvrusb2-encoder.[ch] - This module implements all protocol needed to
+ interact with the Conexant mpeg2 encoder chip within the pvrusb2
+ device. It is a crude echo of corresponding logic in ivtv,
+ however the design goals (strict isolation) and physical layer
+ (proxy through USB instead of PCI) are enough different that this
+ implementation had to be completely different.
+
+pvrusb2-hdw-internal.h - This header defines the core data structure
+ in the driver used to track ALL internal state related to control
+ of the hardware. Nobody outside of the core hardware-handling
+ modules should have any business using this header. All external
+ access to the driver should be through one of the high level
+ interfaces (e.g. V4L, sysfs, etc), and in fact even those high
+ level interfaces are restricted to the API defined in
+ pvrusb2-hdw.h and NOT this header.
+
+pvrusb2-hdw.h - This header defines the full internal API for
+ controlling the hardware. High level interfaces (e.g. V4L, sysfs)
+ will work through here.
+
+pvrusb2-hdw.c - This module implements all the various bits of logic
+ that handle overall control of a specific pvrusb2 device.
+ (Policy, instantiation, and arbitration of pvrusb2 devices fall
+ within the jurisdiction of pvrusb-context not here).
+
+pvrusb2-i2c-chips-\*.c - These modules implement the glue logic to
+ tie together and configure various I2C modules as they attach to
+ the I2C bus. There are two versions of this file. The "v4l2"
+ version is intended to be used in-tree alongside V4L, where we
+ implement just the logic that makes sense for a pure V4L
+ environment. The "all" version is intended for use outside of
+ V4L, where we might encounter other possibly "challenging" modules
+ from ivtv or older kernel snapshots (or even the support modules
+ in the standalone snapshot).
+
+pvrusb2-i2c-cmd-v4l1.[ch] - This module implements generic V4L1
+ compatible commands to the I2C modules. It is here where state
+ changes inside the pvrusb2 driver are translated into V4L1
+ commands that are in turn send to the various I2C modules.
+
+pvrusb2-i2c-cmd-v4l2.[ch] - This module implements generic V4L2
+ compatible commands to the I2C modules. It is here where state
+ changes inside the pvrusb2 driver are translated into V4L2
+ commands that are in turn send to the various I2C modules.
+
+pvrusb2-i2c-core.[ch] - This module provides an implementation of a
+ kernel-friendly I2C adaptor driver, through which other external
+ I2C client drivers (e.g. msp3400, tuner, lirc) may connect and
+ operate corresponding chips within the pvrusb2 device. It is
+ through here that other V4L modules can reach into this driver to
+ operate specific pieces (and those modules are in turn driven by
+ glue logic which is coordinated by pvrusb2-hdw, doled out by
+ pvrusb2-context, and then ultimately made available to users
+ through one of the high level interfaces).
+
+pvrusb2-io.[ch] - This module implements a very low level ring of
+ transfer buffers, required in order to stream data from the
+ device. This module is *very* low level. It only operates the
+ buffers and makes no attempt to define any policy or mechanism for
+ how such buffers might be used.
+
+pvrusb2-ioread.[ch] - This module layers on top of pvrusb2-io.[ch]
+ to provide a streaming API usable by a read() system call style of
+ I/O. Right now this is the only layer on top of pvrusb2-io.[ch],
+ however the underlying architecture here was intended to allow for
+ other styles of I/O to be implemented with additional modules, like
+ mmap()'ed buffers or something even more exotic.
+
+pvrusb2-main.c - This is the top level of the driver. Module level
+ and USB core entry points are here. This is our "main".
+
+pvrusb2-sysfs.[ch] - This is the high level interface which ties the
+ pvrusb2 driver into sysfs. Through this interface you can do
+ everything with the driver except actually stream data.
+
+pvrusb2-tuner.[ch] - This is glue logic that resides between this
+ driver and the tuner.ko I2C client driver (which is found
+ elsewhere in V4L).
+
+pvrusb2-util.h - This header defines some common macros used
+ throughout the driver. These macros are not really specific to
+ the driver, but they had to go somewhere.
+
+pvrusb2-v4l2.[ch] - This is the high level interface which ties the
+ pvrusb2 driver into video4linux. It is through here that V4L
+ applications can open and operate the driver in the usual V4L
+ ways. Note that **ALL** V4L functionality is published only
+ through here and nowhere else.
+
+pvrusb2-video-\*.[ch] - This is glue logic that resides between this
+ driver and the saa711x.ko I2C client driver (which is found
+ elsewhere in V4L). Note that saa711x.ko used to be known as
+ saa7115.ko in ivtv. There are two versions of this; one is
+ selected depending on the particular saa711[5x].ko that is found.
+
+pvrusb2.h - This header contains compile time tunable parameters
+ (and at the moment the driver has very little that needs to be
+ tuned).
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+PXA-Camera Host Driver
+======================
+
+Author: Robert Jarzmik <robert.jarzmik@free.fr>
+
+Constraints
+-----------
+
+a) Image size for YUV422P format
+ All YUV422P images are enforced to have width x height % 16 = 0.
+ This is due to DMA constraints, which transfers only planes of 8 byte
+ multiples.
+
+
+Global video workflow
+---------------------
+
+a) QCI stopped
+ Initially, the QCI interface is stopped.
+ When a buffer is queued (pxa_videobuf_ops->buf_queue), the QCI starts.
+
+b) QCI started
+ More buffers can be queued while the QCI is started without halting the
+ capture. The new buffers are "appended" at the tail of the DMA chain, and
+ smoothly captured one frame after the other.
+
+ Once a buffer is filled in the QCI interface, it is marked as "DONE" and
+ removed from the active buffers list. It can be then requeud or dequeued by
+ userland application.
+
+ Once the last buffer is filled in, the QCI interface stops.
+
+c) Capture global finite state machine schema
+
+.. code-block:: none
+
+ +----+ +---+ +----+
+ | DQ | | Q | | DQ |
+ | v | v | v
+ +-----------+ +------------------------+
+ | STOP | | Wait for capture start |
+ +-----------+ Q +------------------------+
+ +-> | QCI: stop | ------------------> | QCI: run | <------------+
+ | | DMA: stop | | DMA: stop | |
+ | +-----------+ +-----> +------------------------+ |
+ | / | |
+ | / +---+ +----+ | |
+ |capture list empty / | Q | | DQ | | QCI Irq EOF |
+ | / | v | v v |
+ | +--------------------+ +----------------------+ |
+ | | DMA hotlink missed | | Capture running | |
+ | +--------------------+ +----------------------+ |
+ | | QCI: run | +-----> | QCI: run | <-+ |
+ | | DMA: stop | / | DMA: run | | |
+ | +--------------------+ / +----------------------+ | Other |
+ | ^ /DMA still | | channels |
+ | | capture list / running | DMA Irq End | not |
+ | | not empty / | | finished |
+ | | / v | yet |
+ | +----------------------+ +----------------------+ | |
+ | | Videobuf released | | Channel completed | | |
+ | +----------------------+ +----------------------+ | |
+ +-- | QCI: run | | QCI: run | --+ |
+ | DMA: run | | DMA: run | |
+ +----------------------+ +----------------------+ |
+ ^ / | |
+ | no overrun / | overrun |
+ | / v |
+ +--------------------+ / +----------------------+ |
+ | Frame completed | / | Frame overran | |
+ +--------------------+ <-----+ +----------------------+ restart frame |
+ | QCI: run | | QCI: stop | --------------+
+ | DMA: run | | DMA: stop |
+ +--------------------+ +----------------------+
+
+ Legend: - each box is a FSM state
+ - each arrow is the condition to transition to another state
+ - an arrow with a comment is a mandatory transition (no condition)
+ - arrow "Q" means : a buffer was enqueued
+ - arrow "DQ" means : a buffer was dequeued
+ - "QCI: stop" means the QCI interface is not enabled
+ - "DMA: stop" means all 3 DMA channels are stopped
+ - "DMA: run" means at least 1 DMA channel is still running
+
+DMA usage
+---------
+
+a) DMA flow
+ - first buffer queued for capture
+ Once a first buffer is queued for capture, the QCI is started, but data
+ transfer is not started. On "End Of Frame" interrupt, the irq handler
+ starts the DMA chain.
+ - capture of one videobuffer
+ The DMA chain starts transferring data into videobuffer RAM pages.
+ When all pages are transferred, the DMA irq is raised on "ENDINTR" status
+ - finishing one videobuffer
+ The DMA irq handler marks the videobuffer as "done", and removes it from
+ the active running queue
+ Meanwhile, the next videobuffer (if there is one), is transferred by DMA
+ - finishing the last videobuffer
+ On the DMA irq of the last videobuffer, the QCI is stopped.
+
+b) DMA prepared buffer will have this structure
+
+.. code-block:: none
+
+ +------------+-----+---------------+-----------------+
+ | desc-sg[0] | ... | desc-sg[last] | finisher/linker |
+ +------------+-----+---------------+-----------------+
+
+This structure is pointed by dma->sg_cpu.
+The descriptors are used as follows:
+
+- desc-sg[i]: i-th descriptor, transferring the i-th sg
+ element to the video buffer scatter gather
+- finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
+- linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0
+
+For the next schema, let's assume d0=desc-sg[0] .. dN=desc-sg[N],
+"f" stands for finisher and "l" for linker.
+A typical running chain is :
+
+.. code-block:: none
+
+ Videobuffer 1 Videobuffer 2
+ +---------+----+---+ +----+----+----+---+
+ | d0 | .. | dN | l | | d0 | .. | dN | f |
+ +---------+----+-|-+ ^----+----+----+---+
+ | |
+ +----+
+
+After the chaining is finished, the chain looks like :
+
+.. code-block:: none
+
+ Videobuffer 1 Videobuffer 2 Videobuffer 3
+ +---------+----+---+ +----+----+----+---+ +----+----+----+---+
+ | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
+ +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
+ | | | |
+ +----+ +----+
+ new_link
+
+c) DMA hot chaining timeslice issue
+
+As DMA chaining is done while DMA _is_ running, the linking may be done
+while the DMA jumps from one Videobuffer to another. On the schema, that
+would be a problem if the following sequence is encountered :
+
+- DMA chain is Videobuffer1 + Videobuffer2
+- pxa_videobuf_queue() is called to queue Videobuffer3
+- DMA controller finishes Videobuffer2, and DMA stops
+
+.. code-block:: none
+
+ =>
+ Videobuffer 1 Videobuffer 2
+ +---------+----+---+ +----+----+----+---+
+ | d0 | .. | dN | l | | d0 | .. | dN | f |
+ +---------+----+-|-+ ^----+----+----+-^-+
+ | | |
+ +----+ +-- DMA DDADR loads DDADR_STOP
+
+- pxa_dma_add_tail_buf() is called, the Videobuffer2 "finisher" is
+ replaced by a "linker" to Videobuffer3 (creation of new_link)
+- pxa_videobuf_queue() finishes
+- the DMA irq handler is called, which terminates Videobuffer2
+- Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!)
+
+.. code-block:: none
+
+ Videobuffer 1 Videobuffer 2 Videobuffer 3
+ +---------+----+---+ +----+----+----+---+ +----+----+----+---+
+ | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
+ +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
+ | | | |
+ +----+ +----+
+ new_link
+ DMA DDADR still is DDADR_STOP
+
+- pxa_camera_check_link_miss() is called
+ This checks if the DMA is finished and a buffer is still on the
+ pcdev->capture list. If that's the case, the capture will be restarted,
+ and Videobuffer3 is scheduled on DMA chain.
+- the DMA irq handler finishes
+
+.. note::
+
+ If DMA stops just after pxa_camera_check_link_miss() reads DDADR()
+ value, we have the guarantee that the DMA irq handler will be called back
+ when the DMA will finish the buffer, and pxa_camera_check_link_miss() will
+ be called again, to reschedule Videobuffer3.
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+The Radiotrack radio driver
+===========================
+
+Author: Stephen M. Benoit <benoits@servicepro.com>
+
+Date: Dec 14, 1996
+
+ACKNOWLEDGMENTS
+----------------
+
+This document was made based on 'C' code for Linux from Gideon le Grange
+(legrang@active.co.za or legrang@cs.sun.ac.za) in 1994, and elaborations from
+Frans Brinkman (brinkman@esd.nl) in 1996. The results reported here are from
+experiments that the author performed on his own setup, so your mileage may
+vary... I make no guarantees, claims or warranties to the suitability or
+validity of this information. No other documentation on the AIMS
+Lab (http://www.aimslab.com/) RadioTrack card was made available to the
+author. This document is offered in the hopes that it might help users who
+want to use the RadioTrack card in an environment other than MS Windows.
+
+WHY THIS DOCUMENT?
+------------------
+
+I have a RadioTrack card from back when I ran an MS-Windows platform. After
+converting to Linux, I found Gideon le Grange's command-line software for
+running the card, and found that it was good! Frans Brinkman made a
+comfortable X-windows interface, and added a scanning feature. For hack
+value, I wanted to see if the tuner could be tuned beyond the usual FM radio
+broadcast band, so I could pick up the audio carriers from North American
+broadcast TV channels, situated just below and above the 87.0-109.0 MHz range.
+I did not get much success, but I learned about programming ioports under
+Linux and gained some insights about the hardware design used for the card.
+
+So, without further delay, here are the details.
+
+
+PHYSICAL DESCRIPTION
+--------------------
+
+The RadioTrack card is an ISA 8-bit FM radio card. The radio frequency (RF)
+input is simply an antenna lead, and the output is a power audio signal
+available through a miniature phone plug. Its RF frequencies of operation are
+more or less limited from 87.0 to 109.0 MHz (the commercial FM broadcast
+band). Although the registers can be programmed to request frequencies beyond
+these limits, experiments did not give promising results. The variable
+frequency oscillator (VFO) that demodulates the intermediate frequency (IF)
+signal probably has a small range of useful frequencies, and wraps around or
+gets clipped beyond the limits mentioned above.
+
+
+CONTROLLING THE CARD WITH IOPORT
+--------------------------------
+
+The RadioTrack (base) ioport is configurable for 0x30c or 0x20c. Only one
+ioport seems to be involved. The ioport decoding circuitry must be pretty
+simple, as individual ioport bits are directly matched to specific functions
+(or blocks) of the radio card. This way, many functions can be changed in
+parallel with one write to the ioport. The only feedback available through
+the ioports appears to be the "Stereo Detect" bit.
+
+The bits of the ioport are arranged as follows:
+
+.. code-block:: none
+
+ MSb LSb
+ +------+------+------+--------+--------+-------+---------+--------+
+ | VolA | VolB | ???? | Stereo | Radio | TuneA | TuneB | Tune |
+ | (+) | (-) | | Detect | Audio | (bit) | (latch) | Update |
+ | | | | Enable | Enable | | | Enable |
+ +------+------+------+--------+--------+-------+---------+--------+
+
+
+==== ==== =================================
+VolA VolB Description
+==== ==== =================================
+0 0 audio mute
+0 1 volume + (some delay required)
+1 0 volume - (some delay required)
+1 1 stay at present volume
+==== ==== =================================
+
+==================== ===========
+Stereo Detect Enable Description
+==================== ===========
+0 No Detect
+1 Detect
+==================== ===========
+
+Results available by reading ioport >60 msec after last port write.
+
+ 0xff ==> no stereo detected, 0xfd ==> stereo detected.
+
+============================= =============================
+Radio to Audio (path) Enable Description
+============================= =============================
+0 Disable path (silence)
+1 Enable path (audio produced)
+============================= =============================
+
+===== ===== ==================
+TuneA TuneB Description
+===== ===== ==================
+0 0 "zero" bit phase 1
+0 1 "zero" bit phase 2
+1 0 "one" bit phase 1
+1 1 "one" bit phase 2
+===== ===== ==================
+
+
+24-bit code, where bits = (freq*40) + 10486188.
+The Most Significant 11 bits must be 1010 xxxx 0x0 to be valid.
+The bits are shifted in LSb first.
+
+================== ===========================
+Tune Update Enable Description
+================== ===========================
+0 Tuner held constant
+1 Tuner updating in progress
+================== ===========================
+
+
+PROGRAMMING EXAMPLES
+--------------------
+
+.. code-block:: none
+
+ Default: BASE <-- 0xc8 (current volume, no stereo detect,
+ radio enable, tuner adjust disable)
+
+ Card Off: BASE <-- 0x00 (audio mute, no stereo detect,
+ radio disable, tuner adjust disable)
+
+ Card On: BASE <-- 0x00 (see "Card Off", clears any unfinished business)
+ BASE <-- 0xc8 (see "Default")
+
+ Volume Down: BASE <-- 0x48 (volume down, no stereo detect,
+ radio enable, tuner adjust disable)
+ wait 10 msec
+ BASE <-- 0xc8 (see "Default")
+
+ Volume Up: BASE <-- 0x88 (volume up, no stereo detect,
+ radio enable, tuner adjust disable)
+ wait 10 msec
+ BASE <-- 0xc8 (see "Default")
+
+ Check Stereo: BASE <-- 0xd8 (current volume, stereo detect,
+ radio enable, tuner adjust disable)
+ wait 100 msec
+ x <-- BASE (read ioport)
+ BASE <-- 0xc8 (see "Default")
+
+ x=0xff ==> "not stereo", x=0xfd ==> "stereo detected"
+
+ Set Frequency: code = (freq*40) + 10486188
+ foreach of the 24 bits in code,
+ (from Least to Most Significant):
+ to write a "zero" bit,
+ BASE <-- 0x01 (audio mute, no stereo detect, radio
+ disable, "zero" bit phase 1, tuner adjust)
+ BASE <-- 0x03 (audio mute, no stereo detect, radio
+ disable, "zero" bit phase 2, tuner adjust)
+ to write a "one" bit,
+ BASE <-- 0x05 (audio mute, no stereo detect, radio
+ disable, "one" bit phase 1, tuner adjust)
+ BASE <-- 0x07 (audio mute, no stereo detect, radio
+ disable, "one" bit phase 2, tuner adjust)
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+The saa7134 driver
+==================
+
+Author Gerd Hoffmann
+
+
+Card Variations:
+----------------
+
+Cards can use either of these two crystals (xtal):
+
+- 32.11 MHz -> .audio_clock=0x187de7
+- 24.576MHz -> .audio_clock=0x200000 (xtal * .audio_clock = 51539600)
+
+Some details about 30/34/35:
+
+- saa7130 - low-price chip, doesn't have mute, that is why all those
+ cards should have .mute field defined in their tuner structure.
+
+- saa7134 - usual chip
+
+- saa7133/35 - saa7135 is probably a marketing decision, since all those
+ chips identifies itself as 33 on pci.
+
+LifeView GPIOs
+--------------
+
+This section was authored by: Peter Missel <peter.missel@onlinehome.de>
+
+- LifeView FlyTV Platinum FM (LR214WF)
+
+ - GP27 MDT2005 PB4 pin 10
+ - GP26 MDT2005 PB3 pin 9
+ - GP25 MDT2005 PB2 pin 8
+ - GP23 MDT2005 PB1 pin 7
+ - GP22 MDT2005 PB0 pin 6
+ - GP21 MDT2005 PB5 pin 11
+ - GP20 MDT2005 PB6 pin 12
+ - GP19 MDT2005 PB7 pin 13
+ - nc MDT2005 PA3 pin 2
+ - Remote MDT2005 PA2 pin 1
+ - GP18 MDT2005 PA1 pin 18
+ - nc MDT2005 PA0 pin 17 strap low
+ - GP17 Strap "GP7"=High
+ - GP16 Strap "GP6"=High
+
+ - 0=Radio 1=TV
+ - Drives SA630D ENCH1 and HEF4052 A1 pinsto do FM radio through
+ SIF input
+
+ - GP15 nc
+ - GP14 nc
+ - GP13 nc
+ - GP12 Strap "GP5" = High
+ - GP11 Strap "GP4" = High
+ - GP10 Strap "GP3" = High
+ - GP09 Strap "GP2" = Low
+ - GP08 Strap "GP1" = Low
+ - GP07.00 nc
+
+Credits
+-------
+
+andrew.stevens@philips.com + werner.leeb@philips.com for providing
+saa7134 hardware specs and sample board.
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+Cropping and Scaling algorithm, used in the sh_mobile_ceu_camera driver
+=======================================================================
+
+Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+
+Terminology
+-----------
+
+sensor scales: horizontal and vertical scales, configured by the sensor driver
+host scales: -"- host driver
+combined scales: sensor_scale * host_scale
+
+
+Generic scaling / cropping scheme
+---------------------------------
+
+.. code-block:: none
+
+ -1--
+ |
+ -2-- -\
+ | --\
+ | --\
+ +-5-- . -- -3-- -\
+ | `... -\
+ | `... -4-- . - -7..
+ | `.
+ | `. .6--
+ |
+ | . .6'-
+ | .´
+ | ... -4'- .´
+ | ...´ - -7'.
+ +-5'- .´ -/
+ | -- -3'- -/
+ | --/
+ | --/
+ -2'- -/
+ |
+ |
+ -1'-
+
+In the above chart minuses and slashes represent "real" data amounts, points and
+accents represent "useful" data, basically, CEU scaled and cropped output,
+mapped back onto the client's source plane.
+
+Such a configuration can be produced by user requests:
+
+S_CROP(left / top = (5) - (1), width / height = (5') - (5))
+S_FMT(width / height = (6') - (6))
+
+Here:
+
+(1) to (1') - whole max width or height
+(1) to (2) - sensor cropped left or top
+(2) to (2') - sensor cropped width or height
+(3) to (3') - sensor scale
+(3) to (4) - CEU cropped left or top
+(4) to (4') - CEU cropped width or height
+(5) to (5') - reverse sensor scale applied to CEU cropped width or height
+(2) to (5) - reverse sensor scale applied to CEU cropped left or top
+(6) to (6') - CEU scale - user window
+
+
+S_FMT
+-----
+
+Do not touch input rectangle - it is already optimal.
+
+1. Calculate current sensor scales:
+
+ scale_s = ((2') - (2)) / ((3') - (3))
+
+2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
+current sensor scales onto input window - this is user S_CROP:
+
+ width_u = (5') - (5) = ((4') - (4)) * scale_s
+
+3. Calculate new combined scales from "effective" input window to requested user
+window:
+
+ scale_comb = width_u / ((6') - (6))
+
+4. Calculate sensor output window by applying combined scales to real input
+window:
+
+ width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb
+
+5. Apply iterative sensor S_FMT for sensor output window.
+
+ subdev->video_ops->s_fmt(.width = width_s_out)
+
+6. Retrieve sensor output window (g_fmt)
+
+7. Calculate new sensor scales:
+
+ scale_s_new = ((3')_new - (3)_new) / ((2') - (2))
+
+8. Calculate new CEU crop - apply sensor scales to previously calculated
+"effective" crop:
+
+ width_ceu = (4')_new - (4)_new = width_u / scale_s_new
+ left_ceu = (4)_new - (3)_new = ((5) - (2)) / scale_s_new
+
+9. Use CEU cropping to crop to the new window:
+
+ ceu_crop(.width = width_ceu, .left = left_ceu)
+
+10. Use CEU scaling to scale to the requested user window:
+
+ scale_ceu = width_ceu / width
+
+
+S_CROP
+------
+
+The :ref:`V4L2 crop API <crop-scale>` says:
+
+"...specification does not define an origin or units. However by convention
+drivers should horizontally count unscaled samples relative to 0H."
+
+We choose to follow the advise and interpret cropping units as client input
+pixels.
+
+Cropping is performed in the following 6 steps:
+
+1. Request exactly user rectangle from the sensor.
+
+2. If smaller - iterate until a larger one is obtained. Result: sensor cropped
+ to 2 : 2', target crop 5 : 5', current output format 6' - 6.
+
+3. In the previous step the sensor has tried to preserve its output frame as
+ good as possible, but it could have changed. Retrieve it again.
+
+4. Sensor scaled to 3 : 3'. Sensor's scale is (2' - 2) / (3' - 3). Calculate
+ intermediate window: 4' - 4 = (5' - 5) * (3' - 3) / (2' - 2)
+
+5. Calculate and apply host scale = (6' - 6) / (4' - 4)
+
+6. Calculate and apply host crop: 6 - 7 = (5 - 2) * (6' - 6) / (5' - 5)
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+Tuner drivers
+=============
+
+Simple tuner Programming
+------------------------
+
+There are some flavors of Tuner programming APIs.
+These differ mainly by the bandswitch byte.
+
+- L= LG_API (VHF_LO=0x01, VHF_HI=0x02, UHF=0x08, radio=0x04)
+- P= PHILIPS_API (VHF_LO=0xA0, VHF_HI=0x90, UHF=0x30, radio=0x04)
+- T= TEMIC_API (VHF_LO=0x02, VHF_HI=0x04, UHF=0x01)
+- A= ALPS_API (VHF_LO=0x14, VHF_HI=0x12, UHF=0x11)
+- M= PHILIPS_MK3 (VHF_LO=0x01, VHF_HI=0x02, UHF=0x04, radio=0x19)
+
+Tuner Manufacturers
+-------------------
+
+- SAMSUNG Tuner identification: (e.g. TCPM9091PD27)
+
+.. code-block:: none
+
+ TCP [ABCJLMNQ] 90[89][125] [DP] [ACD] 27 [ABCD]
+ [ABCJLMNQ]:
+ A= BG+DK
+ B= BG
+ C= I+DK
+ J= NTSC-Japan
+ L= Secam LL
+ M= BG+I+DK
+ N= NTSC
+ Q= BG+I+DK+LL
+ [89]: ?
+ [125]:
+ 2: No FM
+ 5: With FM
+ [DP]:
+ D= NTSC
+ P= PAL
+ [ACD]:
+ A= F-connector
+ C= Phono connector
+ D= Din Jack
+ [ABCD]:
+ 3-wire/I2C tuning, 2-band/3-band
+
+These Tuners are PHILIPS_API compatible.
+
+Philips Tuner identification: (e.g. FM1216MF)
+
+.. code-block:: none
+
+ F[IRMQ]12[1345]6{MF|ME|MP}
+ F[IRMQ]:
+ FI12x6: Tuner Series
+ FR12x6: Tuner + Radio IF
+ FM12x6: Tuner + FM
+ FQ12x6: special
+ FMR12x6: special
+ TD15xx: Digital Tuner ATSC
+ 12[1345]6:
+ 1216: PAL BG
+ 1236: NTSC
+ 1246: PAL I
+ 1256: Pal DK
+ {MF|ME|MP}
+ MF: BG LL w/ Secam (Multi France)
+ ME: BG DK I LL (Multi Europe)
+ MP: BG DK I (Multi PAL)
+ MR: BG DK M (?)
+ MG: BG DKI M (?)
+ MK2 series PHILIPS_API, most tuners are compatible to this one !
+ MK3 series introduced in 2002 w/ PHILIPS_MK3_API
+
+Temic Tuner identification: (.e.g 4006FH5)
+
+.. code-block:: none
+
+ 4[01][0136][269]F[HYNR]5
+ 40x2: Tuner (5V/33V), TEMIC_API.
+ 40x6: Tuner 5V
+ 41xx: Tuner compact
+ 40x9: Tuner+FM compact
+ [0136]
+ xx0x: PAL BG
+ xx1x: Pal DK, Secam LL
+ xx3x: NTSC
+ xx6x: PAL I
+ F[HYNR]5
+ FH5: Pal BG
+ FY5: others
+ FN5: multistandard
+ FR5: w/ FM radio
+ 3X xxxx: order number with specific connector
+ Note: Only 40x2 series has TEMIC_API, all newer tuners have PHILIPS_API.
+
+LG Innotek Tuner:
+
+- TPI8NSR11 : NTSC J/M (TPI8NSR01 w/FM) (P,210/497)
+- TPI8PSB11 : PAL B/G (TPI8PSB01 w/FM) (P,170/450)
+- TAPC-I701 : PAL I (TAPC-I001 w/FM) (P,170/450)
+- TPI8PSB12 : PAL D/K+B/G (TPI8PSB02 w/FM) (P,170/450)
+- TAPC-H701P: NTSC_JP (TAPC-H001P w/FM) (L,170/450)
+- TAPC-G701P: PAL B/G (TAPC-G001P w/FM) (L,170/450)
+- TAPC-W701P: PAL I (TAPC-W001P w/FM) (L,170/450)
+- TAPC-Q703P: PAL D/K (TAPC-Q001P w/FM) (L,170/450)
+- TAPC-Q704P: PAL D/K+I (L,170/450)
+- TAPC-G702P: PAL D/K+B/G (L,170/450)
+
+- TADC-H002F: NTSC (L,175/410?; 2-B, C-W+11, W+12-69)
+- TADC-M201D: PAL D/K+B/G+I (L,143/425) (sound control at I2C address 0xc8)
+- TADC-T003F: NTSC Taiwan (L,175/410?; 2-B, C-W+11, W+12-69)
+
+Suffix:
+ - P= Standard phono female socket
+ - D= IEC female socket
+ - F= F-connector
+
+Other Tuners:
+
+- TCL2002MB-1 : PAL BG + DK =TUNER_LG_PAL_NEW_TAPC
+- TCL2002MB-1F: PAL BG + DK w/FM =PHILIPS_PAL
+- TCL2002MI-2 : PAL I = ??
+
+ALPS Tuners:
+
+- Most are LG_API compatible
+- TSCH6 has ALPS_API (TSCH5 ?)
+- TSBE1 has extra API 05,02,08 Control_byte=0xCB Source:[#f1]_
+
+.. [#f1] conexant100029b-PCI-Decoder-ApplicationNote.pdf
--- /dev/null
+.. SPDX-License-Identifier: GPL-2.0
+
+The Virtual Media Controller Driver (vimc)
+==========================================
+
+Source code documentation
+-------------------------
+
+vimc-streamer
+~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/media/platform/vimc/vimc-streamer.h
+ :internal:
+
+.. kernel-doc:: drivers/media/platform/vimc/vimc-streamer.c
mc-core
cec-core
csi2
+
+ drivers/index
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-Contributors
-============
-
-.. note::
-
- This documentation is outdated. There are several other DVB contributors
- that aren't listed below.
-
-Thanks go to the following people for patches and contributions:
-
-- Michael Hunold <m.hunold@gmx.de>
-
- - for the initial saa7146 driver and its recent overhaul
-
-- Christian Theiss
-
- - for his work on the initial Linux DVB driver
-
-- Marcus Metzler <mocm@metzlerbros.de> and
- Ralph Metzler <rjkm@metzlerbros.de>
-
- - for their continuing work on the DVB driver
-
-- Michael Holzt <kju@debian.org>
-
- - for his contributions to the dvb-net driver
-
-- Diego Picciani <d.picciani@novacomp.it>
-
- - for CyberLogin for Linux which allows logging onto EON
- (in case you are wondering where CyberLogin is, EON changed its login
- procedure and CyberLogin is no longer used.)
-
-- Martin Schaller <martin@smurf.franken.de>
-
- - for patching the cable card decoder driver
-
-- Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>
-
- - for various fixes regarding tuning, OSD and CI stuff and his work on VDR
-
-- Steve Brown <sbrown@cortland.com>
-
- - for his AFC kernel thread
-
-- Christoph Martin <martin@uni-mainz.de>
-
- - for his LIRC infrared handler
-
-- Andreas Oberritter <obi@linuxtv.org>,
- Dennis Noermann <dennis.noermann@noernet.de>,
- Felix Domke <tmbinc@elitedvb.net>,
- Florian Schirmer <jolt@tuxbox.org>,
- Ronny Strutz <3des@elitedvb.de>,
- Wolfram Joost <dbox2@frokaschwei.de>
- and all the other dbox2 people
-
- - for many bugfixes in the generic DVB Core, frontend drivers and
- their work on the dbox2 port of the DVB driver
-
-- Oliver Endriss <o.endriss@gmx.de>
-
- - for many bugfixes
-
-- Andrew de Quincey <adq_dvb@lidskialf.net>
-
- - for the tda1004x frontend driver, and various bugfixes
-
-- Peter Schildmann <peter.schildmann@web.de>
-
- - for the driver for the Technisat SkyStar2 PCI DVB card
-
-- Vadim Catana <skystar@moldova.cc>,
- Roberto Ragusa <r.ragusa@libero.it> and
- Augusto Cardoso <augusto@carhil.net>
-
- - for all the work for the FlexCopII chipset by B2C2,Inc.
-
-- Davor Emard <emard@softhome.net>
-
- - for his work on the budget drivers, the demux code,
- the module unloading problems, ...
-
-- Hans-Frieder Vogt <hfvogt@arcor.de>
-
- - for his work on calculating and checking the crc's for the
- TechnoTrend/Hauppauge DEC driver firmware
-
-- Michael Dreher <michael@5dot1.de> and
- Andreas 'randy' Weinberger
-
- - for the support of the Fujitsu-Siemens Activy budget DVB-S
-
-- Kenneth Aafløy <ke-aa@frisurf.no>
-
- - for adding support for Typhoon DVB-S budget card
-
-- Ernst Peinlich <e.peinlich@inode.at>
-
- - for tuning/DiSEqC support for the DEC 3000-s
-
-- Peter Beutner <p.beutner@gmx.net>
-
- - for the IR code for the ttusb-dec driver
-
-- Wilson Michaels <wilsonmichaels@earthlink.net>
-
- - for the lgdt330x frontend driver, and various bugfixes
-
-- Michael Krufky <mkrufky@linuxtv.org>
-
- - for maintaining v4l/dvb inter-tree dependencies
-
-- Taylor Jacob <rtjacob@earthlink.net>
-
- - for the nxt2002 frontend driver
-
-- Jean-Francois Thibert <jeanfrancois@sagetv.com>
-
- - for the nxt2004 frontend driver
-
-- Kirk Lapray <kirk.lapray@gmail.com>
-
- - for the or51211 and or51132 frontend drivers, and
- for merging the nxt2002 and nxt2004 modules into a
- single nxt200x frontend driver.
-
-(If you think you should be in this list, but you are not, drop a
-line to the DVB mailing list)
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-Idea behind the dvb-usb-framework
-=================================
-
-.. note::
-
- #) This documentation is outdated. Please check at the DVB wiki
- at https://linuxtv.org/wiki for more updated info.
-
- #) **deprecated:** Newer DVB USB drivers should use the dvb-usb-v2 framework.
-
-In March 2005 I got the new Twinhan USB2.0 DVB-T device. They provided specs
-and a firmware.
-
-Quite keen I wanted to put the driver (with some quirks of course) into dibusb.
-After reading some specs and doing some USB snooping, it realized, that the
-dibusb-driver would be a complete mess afterwards. So I decided to do it in a
-different way: With the help of a dvb-usb-framework.
-
-The framework provides generic functions (mostly kernel API calls), such as:
-
-- Transport Stream URB handling in conjunction with dvb-demux-feed-control
- (bulk and isoc are supported)
-- registering the device for the DVB-API
-- registering an I2C-adapter if applicable
-- remote-control/input-device handling
-- firmware requesting and loading (currently just for the Cypress USB
- controllers)
-- other functions/methods which can be shared by several drivers (such as
- functions for bulk-control-commands)
-- TODO: a I2C-chunker. It creates device-specific chunks of register-accesses
- depending on length of a register and the number of values that can be
- multi-written and multi-read.
-
-The source code of the particular DVB USB devices does just the communication
-with the device via the bus. The connection between the DVB-API-functionality
-is done via callbacks, assigned in a static device-description (struct
-dvb_usb_device) each device-driver has to have.
-
-For an example have a look in drivers/media/usb/dvb-usb/vp7045*.
-
-Objective is to migrate all the usb-devices (dibusb, cinergyT2, maybe the
-ttusb; flexcop-usb already benefits from the generic flexcop-device) to use
-the dvb-usb-lib.
-
-TODO: dynamic enabling and disabling of the pid-filter in regard to number of
-feeds requested.
-
-Supported devices
------------------
-
-See the LinuxTV DVB Wiki at https://linuxtv.org for a complete list of
-cards/drivers/firmwares:
-https://linuxtv.org/wiki/index.php/DVB_USB
-
-0. History & News:
-
- 2005-06-30
-
- - added support for WideView WT-220U (Thanks to Steve Chang)
-
- 2005-05-30
-
- - added basic isochronous support to the dvb-usb-framework
- - added support for Conexant Hybrid reference design and Nebula
- DigiTV USB
-
- 2005-04-17
-
- - all dibusb devices ported to make use of the dvb-usb-framework
-
- 2005-04-02
-
- - re-enabled and improved remote control code.
-
- 2005-03-31
-
- - ported the Yakumo/Hama/Typhoon DVB-T USB2.0 device to dvb-usb.
-
- 2005-03-30
-
- - first commit of the dvb-usb-module based on the dibusb-source.
- First device is a new driver for the
- TwinhanDTV Alpha / MagicBox II USB2.0-only DVB-T device.
- - (change from dvb-dibusb to dvb-usb)
-
- 2005-03-28
-
- - added support for the AVerMedia AverTV DVB-T USB2.0 device
- (Thanks to Glen Harris and Jiun-Kuei Jung, AVerMedia)
-
- 2005-03-14
-
- - added support for the Typhoon/Yakumo/HAMA DVB-T mobile USB2.0
-
- 2005-02-11
-
- - added support for the KWorld/ADSTech Instant DVB-T USB2.0.
- Thanks a lot to Joachim von Caron
-
- 2005-02-02
- - added support for the Hauppauge Win-TV Nova-T USB2
-
- 2005-01-31
- - distorted streaming is gone for USB1.1 devices
-
- 2005-01-13
-
- - moved the mirrored pid_filter_table back to dvb-dibusb
- first almost working version for HanfTek UMT-010
- found out, that Yakumo/HAMA/Typhoon are predecessors of the HanfTek UMT-010
-
- 2005-01-10
-
- - refactoring completed, now everything is very delightful
-
- - tuner quirks for some weird devices (Artec T1 AN2235 device has sometimes a
- Panasonic Tuner assembled). Tunerprobing implemented.
- Thanks a lot to Gunnar Wittich.
-
- 2004-12-29
-
- - after several days of struggling around bug of no returning URBs fixed.
-
- 2004-12-26
-
- - refactored the dibusb-driver, split into separate files
- - i2c-probing enabled
-
- 2004-12-06
-
- - possibility for demod i2c-address probing
- - new usb IDs (Compro, Artec)
-
- 2004-11-23
-
- - merged changes from DiB3000MC_ver2.1
- - revised the debugging
- - possibility to deliver the complete TS for USB2.0
-
- 2004-11-21
-
- - first working version of the dib3000mc/p frontend driver.
-
- 2004-11-12
-
- - added additional remote control keys. Thanks to Uwe Hanke.
-
- 2004-11-07
-
- - added remote control support. Thanks to David Matthews.
-
- 2004-11-05
-
- - added support for a new devices (Grandtec/Avermedia/Artec)
- - merged my changes (for dib3000mb/dibusb) to the FE_REFACTORING, because it became HEAD
- - moved transfer control (pid filter, fifo control) from usb driver to frontend, it seems
- better settled there (added xfer_ops-struct)
- - created a common files for frontends (mc/p/mb)
-
- 2004-09-28
-
- - added support for a new device (Unknown, vendor ID is Hyper-Paltek)
-
- 2004-09-20
-
- - added support for a new device (Compro DVB-U2000), thanks
- to Amaury Demol for reporting
- - changed usb TS transfer method (several urbs, stopping transfer
- before setting a new pid)
-
- 2004-09-13
-
- - added support for a new device (Artec T1 USB TVBOX), thanks
- to Christian Motschke for reporting
-
- 2004-09-05
-
- - released the dibusb device and dib3000mb-frontend driver
- (old news for vp7041.c)
-
- 2004-07-15
-
- - found out, by accident, that the device has a TUA6010XS for PLL
-
- 2004-07-12
-
- - figured out, that the driver should also work with the
- CTS Portable (Chinese Television System)
-
- 2004-07-08
-
- - firmware-extraction-2.422-problem solved, driver is now working
- properly with firmware extracted from 2.422
- - #if for 2.6.4 (dvb), compile issue
- - changed firmware handling, see vp7041.txt sec 1.1
-
- 2004-07-02
-
- - some tuner modifications, v0.1, cleanups, first public
-
- 2004-06-28
-
- - now using the dvb_dmx_swfilter_packets, everything runs fine now
-
- 2004-06-27
-
- - able to watch and switching channels (pre-alpha)
- - no section filtering yet
-
- 2004-06-06
-
- - first TS received, but kernel oops :/
-
- 2004-05-14
-
- - firmware loader is working
-
- 2004-05-11
-
- - start writing the driver
-
-How to use?
------------
-
-Firmware
-~~~~~~~~
-
-Most of the USB drivers need to download a firmware to the device before start
-working.
-
-Have a look at the Wikipage for the DVB-USB-drivers to find out, which firmware
-you need for your device:
-
-https://linuxtv.org/wiki/index.php/DVB_USB
-
-Compiling
-~~~~~~~~~
-
-Since the driver is in the linux kernel, activating the driver in
-your favorite config-environment should sufficient. I recommend
-to compile the driver as module. Hotplug does the rest.
-
-If you use dvb-kernel enter the build-2.6 directory run 'make' and 'insmod.sh
-load' afterwards.
-
-Loading the drivers
-~~~~~~~~~~~~~~~~~~~
-
-Hotplug is able to load the driver, when it is needed (because you plugged
-in the device).
-
-If you want to enable debug output, you have to load the driver manually and
-from within the dvb-kernel cvs repository.
-
-first have a look, which debug level are available:
-
-.. code-block:: none
-
- # modinfo dvb-usb
- # modinfo dvb-usb-vp7045
-
- etc.
-
-.. code-block:: none
-
- modprobe dvb-usb debug=<level>
- modprobe dvb-usb-vp7045 debug=<level>
- etc.
-
-should do the trick.
-
-When the driver is loaded successfully, the firmware file was in
-the right place and the device is connected, the "Power"-LED should be
-turned on.
-
-At this point you should be able to start a dvb-capable application. I'm use
-(t|s)zap, mplayer and dvbscan to test the basics. VDR-xine provides the
-long-term test scenario.
-
-Known problems and bugs
------------------------
-
-- Don't remove the USB device while running an DVB application, your system
- will go crazy or die most likely.
-
-Adding support for devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-TODO
-
-USB1.1 Bandwidth limitation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-A lot of the currently supported devices are USB1.1 and thus they have a
-maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub.
-This is not enough for receiving the complete transport stream of a
-DVB-T channel (which is about 16 MBit/s). Normally this is not a
-problem, if you only want to watch TV (this does not apply for HDTV),
-but watching a channel while recording another channel on the same
-frequency simply does not work very well. This applies to all USB1.1
-DVB-T devices, not just the dvb-usb-devices)
-
-The bug, where the TS is distorted by a heavy usage of the device is gone
-definitely. All dvb-usb-devices I was using (Twinhan, Kworld, DiBcom) are
-working like charm now with VDR. Sometimes I even was able to record a channel
-and watch another one.
-
-Comments
-~~~~~~~~
-
-Patches, comments and suggestions are very very welcome.
-
-3. Acknowledgements
--------------------
-
- Amaury Demol (Amaury.Demol@parrot.com) and Francois Kanounnikoff from DiBcom for
- providing specs, code and help, on which the dvb-dibusb, dib3000mb and
- dib3000mc are based.
-
- David Matthews for identifying a new device type (Artec T1 with AN2235)
- and for extending dibusb with remote control event handling. Thank you.
-
- Alex Woods for frequently answering question about usb and dvb
- stuff, a big thank you.
-
- Bernd Wagner for helping with huge bug reports and discussions.
-
- Gunnar Wittich and Joachim von Caron for their trust for providing
- root-shells on their machines to implement support for new devices.
-
- Allan Third and Michael Hutchinson for their help to write the Nebula
- digitv-driver.
-
- Glen Harris for bringing up, that there is a new dibusb-device and Jiun-Kuei
- Jung from AVerMedia who kindly provided a special firmware to get the device
- up and running in Linux.
-
- Jennifer Chen, Jeff and Jack from Twinhan for kindly supporting by
- writing the vp7045-driver.
-
- Steve Chang from WideView for providing information for new devices and
- firmware files.
-
- Michael Paxton for submitting remote control keymaps.
-
- Some guys on the linux-dvb mailing list for encouraging me.
-
- Peter Schildmann >peter.schildmann-nospam-at-web.de< for his
- user-level firmware loader, which saves a lot of time
- (when writing the vp7041 driver)
-
- Ulf Hermenau for helping me out with traditional chinese.
-
- André Smoktun and Christian Frömmel for supporting me with
- hardware and listening to my problems very patiently.
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-****************
-Frontend drivers
-****************
-
-Frontend attach headers
-***********************
-
-.. Keep it on alphabetic order
-
-.. kernel-doc:: drivers/media/dvb-frontends/a8293.h
-.. kernel-doc:: drivers/media/dvb-frontends/af9013.h
-.. kernel-doc:: drivers/media/dvb-frontends/ascot2e.h
-.. kernel-doc:: drivers/media/dvb-frontends/cxd2820r.h
-.. kernel-doc:: drivers/media/dvb-frontends/drxk.h
-.. kernel-doc:: drivers/media/dvb-frontends/dvb-pll.h
-.. kernel-doc:: drivers/media/dvb-frontends/helene.h
-.. kernel-doc:: drivers/media/dvb-frontends/horus3a.h
-.. kernel-doc:: drivers/media/dvb-frontends/ix2505v.h
-.. kernel-doc:: drivers/media/dvb-frontends/m88ds3103.h
-.. kernel-doc:: drivers/media/dvb-frontends/mb86a20s.h
-.. kernel-doc:: drivers/media/dvb-frontends/mn88472.h
-.. kernel-doc:: drivers/media/dvb-frontends/rtl2830.h
-.. kernel-doc:: drivers/media/dvb-frontends/rtl2832.h
-.. kernel-doc:: drivers/media/dvb-frontends/rtl2832_sdr.h
-.. kernel-doc:: drivers/media/dvb-frontends/stb6000.h
-.. kernel-doc:: drivers/media/dvb-frontends/tda10071.h
-.. kernel-doc:: drivers/media/dvb-frontends/tda826x.h
-.. kernel-doc:: drivers/media/dvb-frontends/zd1301_demod.h
-.. kernel-doc:: drivers/media/dvb-frontends/zl10036.h
-
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: <isonum.txt>
-
-##############################################
-Linux Digital TV driver-specific documentation
-##############################################
-
-**Copyright** |copy| 2001-2016 : LinuxTV Developers
-
-This documentation is free software; you can redistribute it and/or modify it
-under the terms of the GNU General Public License as published by the Free
-Software Foundation version 2 of the License.
-
-This program is distributed in the hope that it will be useful, but WITHOUT
-ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
-FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
-more details.
-
-For more details see the file COPYING in the source distribution of Linux.
-
-.. only:: html
-
- .. class:: toc-title
-
- Table of Contents
-
-.. toctree::
- :maxdepth: 5
- :numbered:
-
- dvb-usb
- frontends
- contributors
../driver-api/media/index
v4l-drivers/index
- dvb-drivers/index
.. only:: html and subproject
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-The bttv driver
-===============
-
-bttv and sound mini howto
--------------------------
-
-There are a lot of different bt848/849/878/879 based boards available.
-Making video work often is not a big deal, because this is handled
-completely by the bt8xx chip, which is common on all boards. But
-sound is handled in slightly different ways on each board.
-
-To handle the grabber boards correctly, there is a array tvcards[] in
-bttv-cards.c, which holds the information required for each board.
-Sound will work only, if the correct entry is used (for video it often
-makes no difference). The bttv driver prints a line to the kernel
-log, telling which card type is used. Like this one:
-
-.. code-block:: none
-
- bttv0: model: BT848(Hauppauge old) [autodetected]
-
-You should verify this is correct. If it isn't, you have to pass the
-correct board type as insmod argument, "insmod bttv card=2" for
-example. The file CARDLIST has a list of valid arguments for card.
-If your card isn't listed there, you might check the source code for
-new entries which are not listed yet. If there isn't one for your
-card, you can check if one of the existing entries does work for you
-(just trial and error...).
-
-Some boards have an extra processor for sound to do stereo decoding
-and other nice features. The msp34xx chips are used by Hauppauge for
-example. If your board has one, you might have to load a helper
-module like msp3400.o to make sound work. If there isn't one for the
-chip used on your board: Bad luck. Start writing a new one. Well,
-you might want to check the video4linux mailing list archive first...
-
-Of course you need a correctly installed soundcard unless you have the
-speakers connected directly to the grabber board. Hint: check the
-mixer settings too. ALSA for example has everything muted by default.
-
-
-How sound works in detail
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Still doesn't work? Looks like some driver hacking is required.
-Below is a do-it-yourself description for you.
-
-The bt8xx chips have 32 general purpose pins, and registers to control
-these pins. One register is the output enable register
-(BT848_GPIO_OUT_EN), it says which pins are actively driven by the
-bt848 chip. Another one is the data register (BT848_GPIO_DATA), where
-you can get/set the status if these pins. They can be used for input
-and output.
-
-Most grabber board vendors use these pins to control an external chip
-which does the sound routing. But every board is a little different.
-These pins are also used by some companies to drive remote control
-receiver chips. Some boards use the i2c bus instead of the gpio pins
-to connect the mux chip.
-
-As mentioned above, there is a array which holds the required
-information for each known board. You basically have to create a new
-line for your board. The important fields are these two:
-
-.. code-block:: c
-
- struct tvcard
- {
- [ ... ]
- u32 gpiomask;
- u32 audiomux[6]; /* Tuner, Radio, external, internal, mute, stereo */
- };
-
-gpiomask specifies which pins are used to control the audio mux chip.
-The corresponding bits in the output enable register
-(BT848_GPIO_OUT_EN) will be set as these pins must be driven by the
-bt848 chip.
-
-The audiomux\[\] array holds the data values for the different inputs
-(i.e. which pins must be high/low for tuner/mute/...). This will be
-written to the data register (BT848_GPIO_DATA) to switch the audio
-mux.
-
-
-What you have to do is figure out the correct values for gpiomask and
-the audiomux array. If you have Windows and the drivers four your
-card installed, you might to check out if you can read these registers
-values used by the windows driver. A tool to do this is available
-from ftp://telepresence.dmem.strath.ac.uk/pub/bt848/winutil, but it
-doesn't work with bt878 boards according to some reports I received.
-Another one with bt878 support is available from
-http://btwincap.sourceforge.net/Files/btspy2.00.zip
-
-You might also dig around in the \*.ini files of the Windows applications.
-You can have a look at the board to see which of the gpio pins are
-connected at all and then start trial-and-error ...
-
-
-Starting with release 0.7.41 bttv has a number of insmod options to
-make the gpio debugging easier:
-
-.. code-block:: none
-
- bttv_gpio=0/1 enable/disable gpio debug messages
- gpiomask=n set the gpiomask value
- audiomux=i,j,... set the values of the audiomux array
- audioall=a set the values of the audiomux array (one
- value for all array elements, useful to check
- out which effect the particular value has).
-
-The messages printed with bttv_gpio=1 look like this:
-
-.. code-block:: none
-
- bttv0: gpio: en=00000027, out=00000024 in=00ffffd8 [audio: off]
-
- en = output _en_able register (BT848_GPIO_OUT_EN)
- out = _out_put bits of the data register (BT848_GPIO_DATA),
- i.e. BT848_GPIO_DATA & BT848_GPIO_OUT_EN
- in = _in_put bits of the data register,
- i.e. BT848_GPIO_DATA & ~BT848_GPIO_OUT_EN
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-The cpia2 driver
-================
-
-Authors: Peter Pregler <Peter_Pregler@email.com>,
-Scott J. Bertin <scottbertin@yahoo.com>, and
-Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which
-this one was modelled from.
-
-
-Notes to developers
-~~~~~~~~~~~~~~~~~~~
-
- - This is a driver version stripped of the 2.4 back compatibility
- and old MJPEG ioctl API. See cpia2.sf.net for 2.4 support.
-
-Programmer's overview of cpia2 driver
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Cpia2 is the second generation video coprocessor from VLSI Vision Ltd (now a
-division of ST Microelectronics). There are two versions. The first is the
-STV0672, which is capable of up to 30 frames per second (fps) in frame sizes
-up to CIF, and 15 fps for VGA frames. The STV0676 is an improved version,
-which can handle up to 30 fps VGA. Both coprocessors can be attached to two
-CMOS sensors - the vvl6410 CIF sensor and the vvl6500 VGA sensor. These will
-be referred to as the 410 and the 500 sensors, or the CIF and VGA sensors.
-
-The two chipsets operate almost identically. The core is an 8051 processor,
-running two different versions of firmware. The 672 runs the VP4 video
-processor code, the 676 runs VP5. There are a few differences in register
-mappings for the two chips. In these cases, the symbols defined in the
-header files are marked with VP4 or VP5 as part of the symbol name.
-
-The cameras appear externally as three sets of registers. Setting register
-values is the only way to control the camera. Some settings are
-interdependant, such as the sequence required to power up the camera. I will
-try to make note of all of these cases.
-
-The register sets are called blocks. Block 0 is the system block. This
-section is always powered on when the camera is plugged in. It contains
-registers that control housekeeping functions such as powering up the video
-processor. The video processor is the VP block. These registers control
-how the video from the sensor is processed. Examples are timing registers,
-user mode (vga, qvga), scaling, cropping, framerates, and so on. The last
-block is the video compressor (VC). The video stream sent from the camera is
-compressed as Motion JPEG (JPEGA). The VC controls all of the compression
-parameters. Looking at the file cpia2_registers.h, you can get a full view
-of these registers and the possible values for most of them.
-
-One or more registers can be set or read by sending a usb control message to
-the camera. There are three modes for this. Block mode requests a number
-of contiguous registers. Random mode reads or writes random registers with
-a tuple structure containing address/value pairs. The repeat mode is only
-used by VP4 to load a firmware patch. It contains a starting address and
-a sequence of bytes to be written into a gpio port.
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-The cx2341x driver
-==================
-
-Memory at cx2341x chips
------------------------
-
-This section describes the cx2341x memory map and documents some of the
-register space.
-
-.. note:: the memory long words are little-endian ('intel format').
-
-.. warning::
-
- This information was figured out from searching through the memory
- and registers, this information may not be correct and is certainly
- not complete, and was not derived from anything more than searching
- through the memory space with commands like:
-
- .. code-block:: none
-
- ivtvctl -O min=0x02000000,max=0x020000ff
-
- So take this as is, I'm always searching for more stuff, it's a large
- register space :-).
-
-Memory Map
-~~~~~~~~~~
-
-The cx2341x exposes its entire 64M memory space to the PCI host via the PCI BAR0
-(Base Address Register 0). The addresses here are offsets relative to the
-address held in BAR0.
-
-.. code-block:: none
-
- 0x00000000-0x00ffffff Encoder memory space
- 0x00000000-0x0003ffff Encode.rom
- ???-??? MPEG buffer(s)
- ???-??? Raw video capture buffer(s)
- ???-??? Raw audio capture buffer(s)
- ???-??? Display buffers (6 or 9)
-
- 0x01000000-0x01ffffff Decoder memory space
- 0x01000000-0x0103ffff Decode.rom
- ???-??? MPEG buffers(s)
- 0x0114b000-0x0115afff Audio.rom (deprecated?)
-
- 0x02000000-0x0200ffff Register Space
-
-Registers
-~~~~~~~~~
-
-The registers occupy the 64k space starting at the 0x02000000 offset from BAR0.
-All of these registers are 32 bits wide.
-
-.. code-block:: none
-
- DMA Registers 0x000-0xff:
-
- 0x00 - Control:
- 0=reset/cancel, 1=read, 2=write, 4=stop
- 0x04 - DMA status:
- 1=read busy, 2=write busy, 4=read error, 8=write error, 16=link list error
- 0x08 - pci DMA pointer for read link list
- 0x0c - pci DMA pointer for write link list
- 0x10 - read/write DMA enable:
- 1=read enable, 2=write enable
- 0x14 - always 0xffffffff, if set any lower instability occurs, 0x00 crashes
- 0x18 - ??
- 0x1c - always 0x20 or 32, smaller values slow down DMA transactions
- 0x20 - always value of 0x780a010a
- 0x24-0x3c - usually just random values???
- 0x40 - Interrupt status
- 0x44 - Write a bit here and shows up in Interrupt status 0x40
- 0x48 - Interrupt Mask
- 0x4C - always value of 0xfffdffff,
- if changed to 0xffffffff DMA write interrupts break.
- 0x50 - always 0xffffffff
- 0x54 - always 0xffffffff (0x4c, 0x50, 0x54 seem like interrupt masks, are
- 3 processors on chip, Java ones, VPU, SPU, APU, maybe these are the
- interrupt masks???).
- 0x60-0x7C - random values
- 0x80 - first write linked list reg, for Encoder Memory addr
- 0x84 - first write linked list reg, for pci memory addr
- 0x88 - first write linked list reg, for length of buffer in memory addr
- (|0x80000000 or this for last link)
- 0x8c-0xdc - rest of write linked list reg, 8 sets of 3 total, DMA goes here
- from linked list addr in reg 0x0c, firmware must push through or
- something.
- 0xe0 - first (and only) read linked list reg, for pci memory addr
- 0xe4 - first (and only) read linked list reg, for Decoder memory addr
- 0xe8 - first (and only) read linked list reg, for length of buffer
- 0xec-0xff - Nothing seems to be in these registers, 0xec-f4 are 0x00000000.
-
-Memory locations for Encoder Buffers 0x700-0x7ff:
-
-These registers show offsets of memory locations pertaining to each
-buffer area used for encoding, have to shift them by <<1 first.
-
-- 0x07F8: Encoder SDRAM refresh
-- 0x07FC: Encoder SDRAM pre-charge
-
-Memory locations for Decoder Buffers 0x800-0x8ff:
-
-These registers show offsets of memory locations pertaining to each
-buffer area used for decoding, have to shift them by <<1 first.
-
-- 0x08F8: Decoder SDRAM refresh
-- 0x08FC: Decoder SDRAM pre-charge
-
-Other memory locations:
-
-- 0x2800: Video Display Module control
-- 0x2D00: AO (audio output?) control
-- 0x2D24: Bytes Flushed
-- 0x7000: LSB I2C write clock bit (inverted)
-- 0x7004: LSB I2C write data bit (inverted)
-- 0x7008: LSB I2C read clock bit
-- 0x700c: LSB I2C read data bit
-- 0x9008: GPIO get input state
-- 0x900c: GPIO set output state
-- 0x9020: GPIO direction (Bit7 (GPIO 0..7) - 0:input, 1:output)
-- 0x9050: SPU control
-- 0x9054: Reset HW blocks
-- 0x9058: VPU control
-- 0xA018: Bit6: interrupt pending?
-- 0xA064: APU command
-
-
-Interrupt Status Register
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The definition of the bits in the interrupt status register 0x0040, and the
-interrupt mask 0x0048. If a bit is cleared in the mask, then we want our ISR to
-execute.
-
-- bit 31 Encoder Start Capture
-- bit 30 Encoder EOS
-- bit 29 Encoder VBI capture
-- bit 28 Encoder Video Input Module reset event
-- bit 27 Encoder DMA complete
-- bit 24 Decoder audio mode change detection event (through event notification)
-- bit 22 Decoder data request
-- bit 20 Decoder DMA complete
-- bit 19 Decoder VBI re-insertion
-- bit 18 Decoder DMA err (linked-list bad)
-
-Missing documentation
----------------------
-
-- Encoder API post(?)
-- Decoder API post(?)
-- Decoder VTRACE event
-
-
-The cx2341x firmware upload
----------------------------
-
-This document describes how to upload the cx2341x firmware to the card.
-
-How to find
-~~~~~~~~~~~
-
-See the web pages of the various projects that uses this chip for information
-on how to obtain the firmware.
-
-The firmware stored in a Windows driver can be detected as follows:
-
-- Each firmware image is 256k bytes.
-- The 1st 32-bit word of the Encoder image is 0x0000da7
-- The 1st 32-bit word of the Decoder image is 0x00003a7
-- The 2nd 32-bit word of both images is 0xaa55bb66
-
-How to load
-~~~~~~~~~~~
-
-- Issue the FWapi command to stop the encoder if it is running. Wait for the
- command to complete.
-- Issue the FWapi command to stop the decoder if it is running. Wait for the
- command to complete.
-- Issue the I2C command to the digitizer to stop emitting VSYNC events.
-- Issue the FWapi command to halt the encoder's firmware.
-- Sleep for 10ms.
-- Issue the FWapi command to halt the decoder's firmware.
-- Sleep for 10ms.
-- Write 0x00000000 to register 0x2800 to stop the Video Display Module.
-- Write 0x00000005 to register 0x2D00 to stop the AO (audio output?).
-- Write 0x00000000 to register 0xA064 to ping? the APU.
-- Write 0xFFFFFFFE to register 0x9058 to stop the VPU.
-- Write 0xFFFFFFFF to register 0x9054 to reset the HW blocks.
-- Write 0x00000001 to register 0x9050 to stop the SPU.
-- Sleep for 10ms.
-- Write 0x0000001A to register 0x07FC to init the Encoder SDRAM's pre-charge.
-- Write 0x80000640 to register 0x07F8 to init the Encoder SDRAM's refresh to 1us.
-- Write 0x0000001A to register 0x08FC to init the Decoder SDRAM's pre-charge.
-- Write 0x80000640 to register 0x08F8 to init the Decoder SDRAM's refresh to 1us.
-- Sleep for 512ms. (600ms is recommended)
-- Transfer the encoder's firmware image to offset 0 in Encoder memory space.
-- Transfer the decoder's firmware image to offset 0 in Decoder memory space.
-- Use a read-modify-write operation to Clear bit 0 of register 0x9050 to
- re-enable the SPU.
-- Sleep for 1 second.
-- Use a read-modify-write operation to Clear bits 3 and 0 of register 0x9058
- to re-enable the VPU.
-- Sleep for 1 second.
-- Issue status API commands to both firmware images to verify.
-
-
-How to call the firmware API
-----------------------------
-
-The preferred calling convention is known as the firmware mailbox. The
-mailboxes are basically a fixed length array that serves as the call-stack.
-
-Firmware mailboxes can be located by searching the encoder and decoder memory
-for a 16 byte signature. That signature will be located on a 256-byte boundary.
-
-Signature:
-
-.. code-block:: none
-
- 0x78, 0x56, 0x34, 0x12, 0x12, 0x78, 0x56, 0x34,
- 0x34, 0x12, 0x78, 0x56, 0x56, 0x34, 0x12, 0x78
-
-The firmware implements 20 mailboxes of 20 32-bit words. The first 10 are
-reserved for API calls. The second 10 are used by the firmware for event
-notification.
-
- ====== =================
- Index Name
- ====== =================
- 0 Flags
- 1 Command
- 2 Return value
- 3 Timeout
- 4-19 Parameter/Result
- ====== =================
-
-
-The flags are defined in the following table. The direction is from the
-perspective of the firmware.
-
- ==== ========== ============================================
- Bit Direction Purpose
- ==== ========== ============================================
- 2 O Firmware has processed the command.
- 1 I Driver has finished setting the parameters.
- 0 I Driver is using this mailbox.
- ==== ========== ============================================
-
-The command is a 32-bit enumerator. The API specifics may be found in this
-chapter.
-
-The return value is a 32-bit enumerator. Only two values are currently defined:
-
-- 0=success
-- -1=command undefined.
-
-There are 16 parameters/results 32-bit fields. The driver populates these fields
-with values for all the parameters required by the call. The driver overwrites
-these fields with result values returned by the call.
-
-The timeout value protects the card from a hung driver thread. If the driver
-doesn't handle the completed call within the timeout specified, the firmware
-will reset that mailbox.
-
-To make an API call, the driver iterates over each mailbox looking for the
-first one available (bit 0 has been cleared). The driver sets that bit, fills
-in the command enumerator, the timeout value and any required parameters. The
-driver then sets the parameter ready bit (bit 1). The firmware scans the
-mailboxes for pending commands, processes them, sets the result code, populates
-the result value array with that call's return values and sets the call
-complete bit (bit 2). Once bit 2 is set, the driver should retrieve the results
-and clear all the flags. If the driver does not perform this task within the
-time set in the timeout register, the firmware will reset that mailbox.
-
-Event notifications are sent from the firmware to the host. The host tells the
-firmware which events it is interested in via an API call. That call tells the
-firmware which notification mailbox to use. The firmware signals the host via
-an interrupt. Only the 16 Results fields are used, the Flags, Command, Return
-value and Timeout words are not used.
-
-
-OSD firmware API description
-----------------------------
-
-.. note:: this API is part of the decoder firmware, so it's cx23415 only.
-
-
-
-CX2341X_OSD_GET_FRAMEBUFFER
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 65/0x41
-
-Description
-^^^^^^^^^^^
-
-Return base and length of contiguous OSD memory.
-
-Result[0]
-^^^^^^^^^
-
-OSD base address
-
-Result[1]
-^^^^^^^^^
-
-OSD length
-
-
-
-CX2341X_OSD_GET_PIXEL_FORMAT
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 66/0x42
-
-Description
-^^^^^^^^^^^
-
-Query OSD format
-
-Result[0]
-^^^^^^^^^
-
-0=8bit index
-1=16bit RGB 5:6:5
-2=16bit ARGB 1:5:5:5
-3=16bit ARGB 1:4:4:4
-4=32bit ARGB 8:8:8:8
-
-
-
-CX2341X_OSD_SET_PIXEL_FORMAT
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 67/0x43
-
-Description
-^^^^^^^^^^^
-
-Assign pixel format
-
-Param[0]
-^^^^^^^^
-
-- 0=8bit index
-- 1=16bit RGB 5:6:5
-- 2=16bit ARGB 1:5:5:5
-- 3=16bit ARGB 1:4:4:4
-- 4=32bit ARGB 8:8:8:8
-
-
-
-CX2341X_OSD_GET_STATE
-~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 68/0x44
-
-Description
-^^^^^^^^^^^
-
-Query OSD state
-
-Result[0]
-^^^^^^^^^
-
-- Bit 0 0=off, 1=on
-- Bits 1:2 alpha control
-- Bits 3:5 pixel format
-
-
-
-CX2341X_OSD_SET_STATE
-~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 69/0x45
-
-Description
-^^^^^^^^^^^
-
-OSD switch
-
-Param[0]
-^^^^^^^^
-
-0=off, 1=on
-
-
-
-CX2341X_OSD_GET_OSD_COORDS
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 70/0x46
-
-Description
-^^^^^^^^^^^
-
-Retrieve coordinates of OSD area blended with video
-
-Result[0]
-^^^^^^^^^
-
-OSD buffer address
-
-Result[1]
-^^^^^^^^^
-
-Stride in pixels
-
-Result[2]
-^^^^^^^^^
-
-Lines in OSD buffer
-
-Result[3]
-^^^^^^^^^
-
-Horizontal offset in buffer
-
-Result[4]
-^^^^^^^^^
-
-Vertical offset in buffer
-
-
-
-CX2341X_OSD_SET_OSD_COORDS
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 71/0x47
-
-Description
-^^^^^^^^^^^
-
-Assign the coordinates of the OSD area to blend with video
-
-Param[0]
-^^^^^^^^
-
-buffer address
-
-Param[1]
-^^^^^^^^
-
-buffer stride in pixels
-
-Param[2]
-^^^^^^^^
-
-lines in buffer
-
-Param[3]
-^^^^^^^^
-
-horizontal offset
-
-Param[4]
-^^^^^^^^
-
-vertical offset
-
-
-
-CX2341X_OSD_GET_SCREEN_COORDS
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 72/0x48
-
-Description
-^^^^^^^^^^^
-
-Retrieve OSD screen area coordinates
-
-Result[0]
-^^^^^^^^^
-
-top left horizontal offset
-
-Result[1]
-^^^^^^^^^
-
-top left vertical offset
-
-Result[2]
-^^^^^^^^^
-
-bottom right horizontal offset
-
-Result[3]
-^^^^^^^^^
-
-bottom right vertical offset
-
-
-
-CX2341X_OSD_SET_SCREEN_COORDS
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 73/0x49
-
-Description
-^^^^^^^^^^^
-
-Assign the coordinates of the screen area to blend with video
-
-Param[0]
-^^^^^^^^
-
-top left horizontal offset
-
-Param[1]
-^^^^^^^^
-
-top left vertical offset
-
-Param[2]
-^^^^^^^^
-
-bottom left horizontal offset
-
-Param[3]
-^^^^^^^^
-
-bottom left vertical offset
-
-
-
-CX2341X_OSD_GET_GLOBAL_ALPHA
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 74/0x4A
-
-Description
-^^^^^^^^^^^
-
-Retrieve OSD global alpha
-
-Result[0]
-^^^^^^^^^
-
-global alpha: 0=off, 1=on
-
-Result[1]
-^^^^^^^^^
-
-bits 0:7 global alpha
-
-
-
-CX2341X_OSD_SET_GLOBAL_ALPHA
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 75/0x4B
-
-Description
-^^^^^^^^^^^
-
-Update global alpha
-
-Param[0]
-^^^^^^^^
-
-global alpha: 0=off, 1=on
-
-Param[1]
-^^^^^^^^
-
-global alpha (8 bits)
-
-Param[2]
-^^^^^^^^
-
-local alpha: 0=on, 1=off
-
-
-
-CX2341X_OSD_SET_BLEND_COORDS
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 78/0x4C
-
-Description
-^^^^^^^^^^^
-
-Move start of blending area within display buffer
-
-Param[0]
-^^^^^^^^
-
-horizontal offset in buffer
-
-Param[1]
-^^^^^^^^
-
-vertical offset in buffer
-
-
-
-CX2341X_OSD_GET_FLICKER_STATE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 79/0x4F
-
-Description
-^^^^^^^^^^^
-
-Retrieve flicker reduction module state
-
-Result[0]
-^^^^^^^^^
-
-flicker state: 0=off, 1=on
-
-
-
-CX2341X_OSD_SET_FLICKER_STATE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 80/0x50
-
-Description
-^^^^^^^^^^^
-
-Set flicker reduction module state
-
-Param[0]
-^^^^^^^^
-
-State: 0=off, 1=on
-
-
-
-CX2341X_OSD_BLT_COPY
-~~~~~~~~~~~~~~~~~~~~
-
-Enum: 82/0x52
-
-Description
-^^^^^^^^^^^
-
-BLT copy
-
-Param[0]
-^^^^^^^^
-
-.. code-block:: none
-
- '0000' zero
- '0001' ~destination AND ~source
- '0010' ~destination AND source
- '0011' ~destination
- '0100' destination AND ~source
- '0101' ~source
- '0110' destination XOR source
- '0111' ~destination OR ~source
- '1000' ~destination AND ~source
- '1001' destination XNOR source
- '1010' source
- '1011' ~destination OR source
- '1100' destination
- '1101' destination OR ~source
- '1110' destination OR source
- '1111' one
-
-
-Param[1]
-^^^^^^^^
-
-Resulting alpha blending
-
-- '01' source_alpha
-- '10' destination_alpha
-- '11' source_alpha*destination_alpha+1
- (zero if both source and destination alpha are zero)
-
-Param[2]
-^^^^^^^^
-
-.. code-block:: none
-
- '00' output_pixel = source_pixel
-
- '01' if source_alpha=0:
- output_pixel = destination_pixel
- if 256 > source_alpha > 1:
- output_pixel = ((source_alpha + 1)*source_pixel +
- (255 - source_alpha)*destination_pixel)/256
-
- '10' if destination_alpha=0:
- output_pixel = source_pixel
- if 255 > destination_alpha > 0:
- output_pixel = ((255 - destination_alpha)*source_pixel +
- (destination_alpha + 1)*destination_pixel)/256
-
- '11' if source_alpha=0:
- source_temp = 0
- if source_alpha=255:
- source_temp = source_pixel*256
- if 255 > source_alpha > 0:
- source_temp = source_pixel*(source_alpha + 1)
- if destination_alpha=0:
- destination_temp = 0
- if destination_alpha=255:
- destination_temp = destination_pixel*256
- if 255 > destination_alpha > 0:
- destination_temp = destination_pixel*(destination_alpha + 1)
- output_pixel = (source_temp + destination_temp)/256
-
-Param[3]
-^^^^^^^^
-
-width
-
-Param[4]
-^^^^^^^^
-
-height
-
-Param[5]
-^^^^^^^^
-
-destination pixel mask
-
-Param[6]
-^^^^^^^^
-
-destination rectangle start address
-
-Param[7]
-^^^^^^^^
-
-destination stride in dwords
-
-Param[8]
-^^^^^^^^
-
-source stride in dwords
-
-Param[9]
-^^^^^^^^
-
-source rectangle start address
-
-
-
-CX2341X_OSD_BLT_FILL
-~~~~~~~~~~~~~~~~~~~~
-
-Enum: 83/0x53
-
-Description
-^^^^^^^^^^^
-
-BLT fill color
-
-Param[0]
-^^^^^^^^
-
-Same as Param[0] on API 0x52
-
-Param[1]
-^^^^^^^^
-
-Same as Param[1] on API 0x52
-
-Param[2]
-^^^^^^^^
-
-Same as Param[2] on API 0x52
-
-Param[3]
-^^^^^^^^
-
-width
-
-Param[4]
-^^^^^^^^
-
-height
-
-Param[5]
-^^^^^^^^
-
-destination pixel mask
-
-Param[6]
-^^^^^^^^
-
-destination rectangle start address
-
-Param[7]
-^^^^^^^^
-
-destination stride in dwords
-
-Param[8]
-^^^^^^^^
-
-color fill value
-
-
-
-CX2341X_OSD_BLT_TEXT
-~~~~~~~~~~~~~~~~~~~~
-
-Enum: 84/0x54
-
-Description
-^^^^^^^^^^^
-
-BLT for 8 bit alpha text source
-
-Param[0]
-^^^^^^^^
-
-Same as Param[0] on API 0x52
-
-Param[1]
-^^^^^^^^
-
-Same as Param[1] on API 0x52
-
-Param[2]
-^^^^^^^^
-
-Same as Param[2] on API 0x52
-
-Param[3]
-^^^^^^^^
-
-width
-
-Param[4]
-^^^^^^^^
-
-height
-
-Param[5]
-^^^^^^^^
-
-destination pixel mask
-
-Param[6]
-^^^^^^^^
-
-destination rectangle start address
-
-Param[7]
-^^^^^^^^
-
-destination stride in dwords
-
-Param[8]
-^^^^^^^^
-
-source stride in dwords
-
-Param[9]
-^^^^^^^^
-
-source rectangle start address
-
-Param[10]
-^^^^^^^^^
-
-color fill value
-
-
-
-CX2341X_OSD_SET_FRAMEBUFFER_WINDOW
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 86/0x56
-
-Description
-^^^^^^^^^^^
-
-Positions the main output window on the screen. The coordinates must be
-such that the entire window fits on the screen.
-
-Param[0]
-^^^^^^^^
-
-window width
-
-Param[1]
-^^^^^^^^
-
-window height
-
-Param[2]
-^^^^^^^^
-
-top left window corner horizontal offset
-
-Param[3]
-^^^^^^^^
-
-top left window corner vertical offset
-
-
-
-CX2341X_OSD_SET_CHROMA_KEY
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 96/0x60
-
-Description
-^^^^^^^^^^^
-
-Chroma key switch and color
-
-Param[0]
-^^^^^^^^
-
-state: 0=off, 1=on
-
-Param[1]
-^^^^^^^^
-
-color
-
-
-
-CX2341X_OSD_GET_ALPHA_CONTENT_INDEX
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 97/0x61
-
-Description
-^^^^^^^^^^^
-
-Retrieve alpha content index
-
-Result[0]
-^^^^^^^^^
-
-alpha content index, Range 0:15
-
-
-
-CX2341X_OSD_SET_ALPHA_CONTENT_INDEX
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 98/0x62
-
-Description
-^^^^^^^^^^^
-
-Assign alpha content index
-
-Param[0]
-^^^^^^^^
-
-alpha content index, range 0:15
-
-
-Encoder firmware API description
---------------------------------
-
-CX2341X_ENC_PING_FW
-~~~~~~~~~~~~~~~~~~~
-
-Enum: 128/0x80
-
-Description
-^^^^^^^^^^^
-
-Does nothing. Can be used to check if the firmware is responding.
-
-
-
-CX2341X_ENC_START_CAPTURE
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 129/0x81
-
-Description
-^^^^^^^^^^^
-
-Commences the capture of video, audio and/or VBI data. All encoding
-parameters must be initialized prior to this API call. Captures frames
-continuously or until a predefined number of frames have been captured.
-
-Param[0]
-^^^^^^^^
-
-Capture stream type:
-
- - 0=MPEG
- - 1=Raw
- - 2=Raw passthrough
- - 3=VBI
-
-
-Param[1]
-^^^^^^^^
-
-Bitmask:
-
- - Bit 0 when set, captures YUV
- - Bit 1 when set, captures PCM audio
- - Bit 2 when set, captures VBI (same as param[0]=3)
- - Bit 3 when set, the capture destination is the decoder
- (same as param[0]=2)
- - Bit 4 when set, the capture destination is the host
-
-.. note:: this parameter is only meaningful for RAW capture type.
-
-
-
-CX2341X_ENC_STOP_CAPTURE
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 130/0x82
-
-Description
-^^^^^^^^^^^
-
-Ends a capture in progress
-
-Param[0]
-^^^^^^^^
-
-- 0=stop at end of GOP (generates IRQ)
-- 1=stop immediate (no IRQ)
-
-Param[1]
-^^^^^^^^
-
-Stream type to stop, see param[0] of API 0x81
-
-Param[2]
-^^^^^^^^
-
-Subtype, see param[1] of API 0x81
-
-
-
-CX2341X_ENC_SET_AUDIO_ID
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 137/0x89
-
-Description
-^^^^^^^^^^^
-
-Assigns the transport stream ID of the encoded audio stream
-
-Param[0]
-^^^^^^^^
-
-Audio Stream ID
-
-
-
-CX2341X_ENC_SET_VIDEO_ID
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 139/0x8B
-
-Description
-^^^^^^^^^^^
-
-Set video transport stream ID
-
-Param[0]
-^^^^^^^^
-
-Video stream ID
-
-
-
-CX2341X_ENC_SET_PCR_ID
-~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 141/0x8D
-
-Description
-^^^^^^^^^^^
-
-Assigns the transport stream ID for PCR packets
-
-Param[0]
-^^^^^^^^
-
-PCR Stream ID
-
-
-
-CX2341X_ENC_SET_FRAME_RATE
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 143/0x8F
-
-Description
-^^^^^^^^^^^
-
-Set video frames per second. Change occurs at start of new GOP.
-
-Param[0]
-^^^^^^^^
-
-- 0=30fps
-- 1=25fps
-
-
-
-CX2341X_ENC_SET_FRAME_SIZE
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 145/0x91
-
-Description
-^^^^^^^^^^^
-
-Select video stream encoding resolution.
-
-Param[0]
-^^^^^^^^
-
-Height in lines. Default 480
-
-Param[1]
-^^^^^^^^
-
-Width in pixels. Default 720
-
-
-
-CX2341X_ENC_SET_BIT_RATE
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 149/0x95
-
-Description
-^^^^^^^^^^^
-
-Assign average video stream bitrate.
-
-Param[0]
-^^^^^^^^
-
-0=variable bitrate, 1=constant bitrate
-
-Param[1]
-^^^^^^^^
-
-bitrate in bits per second
-
-Param[2]
-^^^^^^^^
-
-peak bitrate in bits per second, divided by 400
-
-Param[3]
-^^^^^^^^
-
-Mux bitrate in bits per second, divided by 400. May be 0 (default).
-
-Param[4]
-^^^^^^^^
-
-Rate Control VBR Padding
-
-Param[5]
-^^^^^^^^
-
-VBV Buffer used by encoder
-
-.. note::
-
- #) Param\[3\] and Param\[4\] seem to be always 0
- #) Param\[5\] doesn't seem to be used.
-
-
-
-CX2341X_ENC_SET_GOP_PROPERTIES
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 151/0x97
-
-Description
-^^^^^^^^^^^
-
-Setup the GOP structure
-
-Param[0]
-^^^^^^^^
-
-GOP size (maximum is 34)
-
-Param[1]
-^^^^^^^^
-
-Number of B frames between the I and P frame, plus 1.
-For example: IBBPBBPBBPBB --> GOP size: 12, number of B frames: 2+1 = 3
-
-.. note::
-
- GOP size must be a multiple of (B-frames + 1).
-
-
-
-CX2341X_ENC_SET_ASPECT_RATIO
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 153/0x99
-
-Description
-^^^^^^^^^^^
-
-Sets the encoding aspect ratio. Changes in the aspect ratio take effect
-at the start of the next GOP.
-
-Param[0]
-^^^^^^^^
-
-- '0000' forbidden
-- '0001' 1:1 square
-- '0010' 4:3
-- '0011' 16:9
-- '0100' 2.21:1
-- '0101' to '1111' reserved
-
-
-
-CX2341X_ENC_SET_DNR_FILTER_MODE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 155/0x9B
-
-Description
-^^^^^^^^^^^
-
-Assign Dynamic Noise Reduction operating mode
-
-Param[0]
-^^^^^^^^
-
-Bit0: Spatial filter, set=auto, clear=manual
-Bit1: Temporal filter, set=auto, clear=manual
-
-Param[1]
-^^^^^^^^
-
-Median filter:
-
-- 0=Disabled
-- 1=Horizontal
-- 2=Vertical
-- 3=Horiz/Vert
-- 4=Diagonal
-
-
-
-CX2341X_ENC_SET_DNR_FILTER_PROPS
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 157/0x9D
-
-Description
-^^^^^^^^^^^
-
-These Dynamic Noise Reduction filter values are only meaningful when
-the respective filter is set to "manual" (See API 0x9B)
-
-Param[0]
-^^^^^^^^
-
-Spatial filter: default 0, range 0:15
-
-Param[1]
-^^^^^^^^
-
-Temporal filter: default 0, range 0:31
-
-
-
-CX2341X_ENC_SET_CORING_LEVELS
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 159/0x9F
-
-Description
-^^^^^^^^^^^
-
-Assign Dynamic Noise Reduction median filter properties.
-
-Param[0]
-^^^^^^^^
-
-Threshold above which the luminance median filter is enabled.
-Default: 0, range 0:255
-
-Param[1]
-^^^^^^^^
-
-Threshold below which the luminance median filter is enabled.
-Default: 255, range 0:255
-
-Param[2]
-^^^^^^^^
-
-Threshold above which the chrominance median filter is enabled.
-Default: 0, range 0:255
-
-Param[3]
-^^^^^^^^
-
-Threshold below which the chrominance median filter is enabled.
-Default: 255, range 0:255
-
-
-
-CX2341X_ENC_SET_SPATIAL_FILTER_TYPE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 161/0xA1
-
-Description
-^^^^^^^^^^^
-
-Assign spatial prefilter parameters
-
-Param[0]
-^^^^^^^^
-
-Luminance filter
-
-- 0=Off
-- 1=1D Horizontal
-- 2=1D Vertical
-- 3=2D H/V Separable (default)
-- 4=2D Symmetric non-separable
-
-Param[1]
-^^^^^^^^
-
-Chrominance filter
-
-- 0=Off
-- 1=1D Horizontal (default)
-
-
-
-CX2341X_ENC_SET_VBI_LINE
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 183/0xB7
-
-Description
-^^^^^^^^^^^
-
-Selects VBI line number.
-
-Param[0]
-^^^^^^^^
-
-- Bits 0:4 line number
-- Bit 31 0=top_field, 1=bottom_field
-- Bits 0:31 all set specifies "all lines"
-
-Param[1]
-^^^^^^^^
-
-VBI line information features: 0=disabled, 1=enabled
-
-Param[2]
-^^^^^^^^
-
-Slicing: 0=None, 1=Closed Caption
-Almost certainly not implemented. Set to 0.
-
-Param[3]
-^^^^^^^^
-
-Luminance samples in this line.
-Almost certainly not implemented. Set to 0.
-
-Param[4]
-^^^^^^^^
-
-Chrominance samples in this line
-Almost certainly not implemented. Set to 0.
-
-
-
-CX2341X_ENC_SET_STREAM_TYPE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 185/0xB9
-
-Description
-^^^^^^^^^^^
-
-Assign stream type
-
-.. note::
-
- Transport stream is not working in recent firmwares.
- And in older firmwares the timestamps in the TS seem to be
- unreliable.
-
-Param[0]
-^^^^^^^^
-
-- 0=Program stream
-- 1=Transport stream
-- 2=MPEG1 stream
-- 3=PES A/V stream
-- 5=PES Video stream
-- 7=PES Audio stream
-- 10=DVD stream
-- 11=VCD stream
-- 12=SVCD stream
-- 13=DVD_S1 stream
-- 14=DVD_S2 stream
-
-
-
-CX2341X_ENC_SET_OUTPUT_PORT
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 187/0xBB
-
-Description
-^^^^^^^^^^^
-
-Assign stream output port. Normally 0 when the data is copied through
-the PCI bus (DMA), and 1 when the data is streamed to another chip
-(pvrusb and cx88-blackbird).
-
-Param[0]
-^^^^^^^^
-
-- 0=Memory (default)
-- 1=Streaming
-- 2=Serial
-
-Param[1]
-^^^^^^^^
-
-Unknown, but leaving this to 0 seems to work best. Indications are that
-this might have to do with USB support, although passing anything but 0
-only breaks things.
-
-
-
-CX2341X_ENC_SET_AUDIO_PROPERTIES
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 189/0xBD
-
-Description
-^^^^^^^^^^^
-
-Set audio stream properties, may be called while encoding is in progress.
-
-.. note::
-
- All bitfields are consistent with ISO11172 documentation except
- bits 2:3 which ISO docs define as:
-
- - '11' Layer I
- - '10' Layer II
- - '01' Layer III
- - '00' Undefined
-
- This discrepancy may indicate a possible error in the documentation.
- Testing indicated that only Layer II is actually working, and that
- the minimum bitrate should be 192 kbps.
-
-Param[0]
-^^^^^^^^
-
-Bitmask:
-
-.. code-block:: none
-
- 0:1 '00' 44.1Khz
- '01' 48Khz
- '10' 32Khz
- '11' reserved
-
- 2:3 '01'=Layer I
- '10'=Layer II
-
- 4:7 Bitrate:
- Index | Layer I | Layer II
- ------+-------------+------------
- '0000' | free format | free format
- '0001' | 32 kbit/s | 32 kbit/s
- '0010' | 64 kbit/s | 48 kbit/s
- '0011' | 96 kbit/s | 56 kbit/s
- '0100' | 128 kbit/s | 64 kbit/s
- '0101' | 160 kbit/s | 80 kbit/s
- '0110' | 192 kbit/s | 96 kbit/s
- '0111' | 224 kbit/s | 112 kbit/s
- '1000' | 256 kbit/s | 128 kbit/s
- '1001' | 288 kbit/s | 160 kbit/s
- '1010' | 320 kbit/s | 192 kbit/s
- '1011' | 352 kbit/s | 224 kbit/s
- '1100' | 384 kbit/s | 256 kbit/s
- '1101' | 416 kbit/s | 320 kbit/s
- '1110' | 448 kbit/s | 384 kbit/s
-
- .. note::
-
- For Layer II, not all combinations of total bitrate
- and mode are allowed. See ISO11172-3 3-Annex B,
- Table 3-B.2
-
- 8:9 '00'=Stereo
- '01'=JointStereo
- '10'=Dual
- '11'=Mono
-
- .. note::
-
- The cx23415 cannot decode Joint Stereo properly.
-
- 10:11 Mode Extension used in joint_stereo mode.
- In Layer I and II they indicate which subbands are in
- intensity_stereo. All other subbands are coded in stereo.
- '00' subbands 4-31 in intensity_stereo, bound==4
- '01' subbands 8-31 in intensity_stereo, bound==8
- '10' subbands 12-31 in intensity_stereo, bound==12
- '11' subbands 16-31 in intensity_stereo, bound==16
-
- 12:13 Emphasis:
- '00' None
- '01' 50/15uS
- '10' reserved
- '11' CCITT J.17
-
- 14 CRC:
- '0' off
- '1' on
-
- 15 Copyright:
- '0' off
- '1' on
-
- 16 Generation:
- '0' copy
- '1' original
-
-
-
-CX2341X_ENC_HALT_FW
-~~~~~~~~~~~~~~~~~~~
-
-Enum: 195/0xC3
-
-Description
-^^^^^^^^^^^
-
-The firmware is halted and no further API calls are serviced until the
-firmware is uploaded again.
-
-
-
-CX2341X_ENC_GET_VERSION
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 196/0xC4
-
-Description
-^^^^^^^^^^^
-
-Returns the version of the encoder firmware.
-
-Result[0]
-^^^^^^^^^
-
-Version bitmask:
-- Bits 0:15 build
-- Bits 16:23 minor
-- Bits 24:31 major
-
-
-
-CX2341X_ENC_SET_GOP_CLOSURE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 197/0xC5
-
-Description
-^^^^^^^^^^^
-
-Assigns the GOP open/close property.
-
-Param[0]
-^^^^^^^^
-
-- 0=Open
-- 1=Closed
-
-
-
-CX2341X_ENC_GET_SEQ_END
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 198/0xC6
-
-Description
-^^^^^^^^^^^
-
-Obtains the sequence end code of the encoder's buffer. When a capture
-is started a number of interrupts are still generated, the last of
-which will have Result[0] set to 1 and Result[1] will contain the size
-of the buffer.
-
-Result[0]
-^^^^^^^^^
-
-State of the transfer (1 if last buffer)
-
-Result[1]
-^^^^^^^^^
-
-If Result[0] is 1, this contains the size of the last buffer, undefined
-otherwise.
-
-
-
-CX2341X_ENC_SET_PGM_INDEX_INFO
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 199/0xC7
-
-Description
-^^^^^^^^^^^
-
-Sets the Program Index Information.
-The information is stored as follows:
-
-.. code-block:: c
-
- struct info {
- u32 length; // Length of this frame
- u32 offset_low; // Offset in the file of the
- u32 offset_high; // start of this frame
- u32 mask1; // Bits 0-2 are the type mask:
- // 1=I, 2=P, 4=B
- // 0=End of Program Index, other fields
- // are invalid.
- u32 pts; // The PTS of the frame
- u32 mask2; // Bit 0 is bit 32 of the pts.
- };
- u32 table_ptr;
- struct info index[400];
-
-The table_ptr is the encoder memory address in the table were
-*new* entries will be written.
-
-.. note:: This is a ringbuffer, so the table_ptr will wraparound.
-
-Param[0]
-^^^^^^^^
-
-Picture Mask:
-- 0=No index capture
-- 1=I frames
-- 3=I,P frames
-- 7=I,P,B frames
-
-(Seems to be ignored, it always indexes I, P and B frames)
-
-Param[1]
-^^^^^^^^
-
-Elements requested (up to 400)
-
-Result[0]
-^^^^^^^^^
-
-Offset in the encoder memory of the start of the table.
-
-Result[1]
-^^^^^^^^^
-
-Number of allocated elements up to a maximum of Param[1]
-
-
-
-CX2341X_ENC_SET_VBI_CONFIG
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 200/0xC8
-
-Description
-^^^^^^^^^^^
-
-Configure VBI settings
-
-Param[0]
-^^^^^^^^
-
-Bitmap:
-
-.. code-block:: none
-
- 0 Mode '0' Sliced, '1' Raw
- 1:3 Insertion:
- '000' insert in extension & user data
- '001' insert in private packets
- '010' separate stream and user data
- '111' separate stream and private data
- 8:15 Stream ID (normally 0xBD)
-
-Param[1]
-^^^^^^^^
-
-Frames per interrupt (max 8). Only valid in raw mode.
-
-Param[2]
-^^^^^^^^
-
-Total raw VBI frames. Only valid in raw mode.
-
-Param[3]
-^^^^^^^^
-
-Start codes
-
-Param[4]
-^^^^^^^^
-
-Stop codes
-
-Param[5]
-^^^^^^^^
-
-Lines per frame
-
-Param[6]
-^^^^^^^^
-
-Byte per line
-
-Result[0]
-^^^^^^^^^
-
-Observed frames per interrupt in raw mode only. Rage 1 to Param[1]
-
-Result[1]
-^^^^^^^^^
-
-Observed number of frames in raw mode. Range 1 to Param[2]
-
-Result[2]
-^^^^^^^^^
-
-Memory offset to start or raw VBI data
-
-
-
-CX2341X_ENC_SET_DMA_BLOCK_SIZE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 201/0xC9
-
-Description
-^^^^^^^^^^^
-
-Set DMA transfer block size
-
-Param[0]
-^^^^^^^^
-
-DMA transfer block size in bytes or frames. When unit is bytes,
-supported block sizes are 2^7, 2^8 and 2^9 bytes.
-
-Param[1]
-^^^^^^^^
-
-Unit: 0=bytes, 1=frames
-
-
-
-CX2341X_ENC_GET_PREV_DMA_INFO_MB_10
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 202/0xCA
-
-Description
-^^^^^^^^^^^
-
-Returns information on the previous DMA transfer in conjunction with
-bit 27 of the interrupt mask. Uses mailbox 10.
-
-Result[0]
-^^^^^^^^^
-
-Type of stream
-
-Result[1]
-^^^^^^^^^
-
-Address Offset
-
-Result[2]
-^^^^^^^^^
-
-Maximum size of transfer
-
-
-
-CX2341X_ENC_GET_PREV_DMA_INFO_MB_9
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 203/0xCB
-
-Description
-^^^^^^^^^^^
-
-Returns information on the previous DMA transfer in conjunction with
-bit 27 or 18 of the interrupt mask. Uses mailbox 9.
-
-Result[0]
-^^^^^^^^^
-
-Status bits:
-- 0 read completed
-- 1 write completed
-- 2 DMA read error
-- 3 DMA write error
-- 4 Scatter-Gather array error
-
-Result[1]
-^^^^^^^^^
-
-DMA type
-
-Result[2]
-^^^^^^^^^
-
-Presentation Time Stamp bits 0..31
-
-Result[3]
-^^^^^^^^^
-
-Presentation Time Stamp bit 32
-
-
-
-CX2341X_ENC_SCHED_DMA_TO_HOST
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 204/0xCC
-
-Description
-^^^^^^^^^^^
-
-Setup DMA to host operation
-
-Param[0]
-^^^^^^^^
-
-Memory address of link list
-
-Param[1]
-^^^^^^^^
-
-Length of link list (wtf: what units ???)
-
-Param[2]
-^^^^^^^^
-
-DMA type (0=MPEG)
-
-
-
-CX2341X_ENC_INITIALIZE_INPUT
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 205/0xCD
-
-Description
-^^^^^^^^^^^
-
-Initializes the video input
-
-
-
-CX2341X_ENC_SET_FRAME_DROP_RATE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 208/0xD0
-
-Description
-^^^^^^^^^^^
-
-For each frame captured, skip specified number of frames.
-
-Param[0]
-^^^^^^^^
-
-Number of frames to skip
-
-
-
-CX2341X_ENC_PAUSE_ENCODER
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 210/0xD2
-
-Description
-^^^^^^^^^^^
-
-During a pause condition, all frames are dropped instead of being encoded.
-
-Param[0]
-^^^^^^^^
-
-- 0=Pause encoding
-- 1=Continue encoding
-
-
-
-CX2341X_ENC_REFRESH_INPUT
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 211/0xD3
-
-Description
-^^^^^^^^^^^
-
-Refreshes the video input
-
-
-
-CX2341X_ENC_SET_COPYRIGHT
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 212/0xD4
-
-Description
-^^^^^^^^^^^
-
-Sets stream copyright property
-
-Param[0]
-^^^^^^^^
-
-
-- 0=Stream is not copyrighted
-- 1=Stream is copyrighted
-
-
-
-CX2341X_ENC_SET_EVENT_NOTIFICATION
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 213/0xD5
-
-Description
-^^^^^^^^^^^
-
-Setup firmware to notify the host about a particular event. Host must
-unmask the interrupt bit.
-
-Param[0]
-^^^^^^^^
-
-Event (0=refresh encoder input)
-
-Param[1]
-^^^^^^^^
-
-Notification 0=disabled 1=enabled
-
-Param[2]
-^^^^^^^^
-
-Interrupt bit
-
-Param[3]
-^^^^^^^^
-
-Mailbox slot, -1 if no mailbox required.
-
-
-
-CX2341X_ENC_SET_NUM_VSYNC_LINES
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 214/0xD6
-
-Description
-^^^^^^^^^^^
-
-Depending on the analog video decoder used, this assigns the number
-of lines for field 1 and 2.
-
-Param[0]
-^^^^^^^^
-
-Field 1 number of lines:
-- 0x00EF for SAA7114
-- 0x00F0 for SAA7115
-- 0x0105 for Micronas
-
-Param[1]
-^^^^^^^^
-
-Field 2 number of lines:
-- 0x00EF for SAA7114
-- 0x00F0 for SAA7115
-- 0x0106 for Micronas
-
-
-
-CX2341X_ENC_SET_PLACEHOLDER
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 215/0xD7
-
-Description
-^^^^^^^^^^^
-
-Provides a mechanism of inserting custom user data in the MPEG stream.
-
-Param[0]
-^^^^^^^^
-
-- 0=extension & user data
-- 1=private packet with stream ID 0xBD
-
-Param[1]
-^^^^^^^^
-
-Rate at which to insert data, in units of frames (for private packet)
-or GOPs (for ext. & user data)
-
-Param[2]
-^^^^^^^^
-
-Number of data DWORDs (below) to insert
-
-Param[3]
-^^^^^^^^
-
-Custom data 0
-
-Param[4]
-^^^^^^^^
-
-Custom data 1
-
-Param[5]
-^^^^^^^^
-
-Custom data 2
-
-Param[6]
-^^^^^^^^
-
-Custom data 3
-
-Param[7]
-^^^^^^^^
-
-Custom data 4
-
-Param[8]
-^^^^^^^^
-
-Custom data 5
-
-Param[9]
-^^^^^^^^
-
-Custom data 6
-
-Param[10]
-^^^^^^^^^
-
-Custom data 7
-
-Param[11]
-^^^^^^^^^
-
-Custom data 8
-
-
-
-CX2341X_ENC_MUTE_VIDEO
-~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 217/0xD9
-
-Description
-^^^^^^^^^^^
-
-Video muting
-
-Param[0]
-^^^^^^^^
-
-Bit usage:
-
-.. code-block:: none
-
- 0 '0'=video not muted
- '1'=video muted, creates frames with the YUV color defined below
- 1:7 Unused
- 8:15 V chrominance information
- 16:23 U chrominance information
- 24:31 Y luminance information
-
-
-
-CX2341X_ENC_MUTE_AUDIO
-~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 218/0xDA
-
-Description
-^^^^^^^^^^^
-
-Audio muting
-
-Param[0]
-^^^^^^^^
-
-- 0=audio not muted
-- 1=audio muted (produces silent mpeg audio stream)
-
-
-
-CX2341X_ENC_SET_VERT_CROP_LINE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 219/0xDB
-
-Description
-^^^^^^^^^^^
-
-Something to do with 'Vertical Crop Line'
-
-Param[0]
-^^^^^^^^
-
-If saa7114 and raw VBI capture and 60 Hz, then set to 10001.
-Else 0.
-
-
-
-CX2341X_ENC_MISC
-~~~~~~~~~~~~~~~~
-
-Enum: 220/0xDC
-
-Description
-^^^^^^^^^^^
-
-Miscellaneous actions. Not known for 100% what it does. It's really a
-sort of ioctl call. The first parameter is a command number, the second
-the value.
-
-Param[0]
-^^^^^^^^
-
-Command number:
-
-.. code-block:: none
-
- 1=set initial SCR value when starting encoding (works).
- 2=set quality mode (apparently some test setting).
- 3=setup advanced VIM protection handling.
- Always 1 for the cx23416 and 0 for cx23415.
- 4=generate DVD compatible PTS timestamps
- 5=USB flush mode
- 6=something to do with the quantization matrix
- 7=set navigation pack insertion for DVD: adds 0xbf (private stream 2)
- packets to the MPEG. The size of these packets is 2048 bytes (including
- the header of 6 bytes: 0x000001bf + length). The payload is zeroed and
- it is up to the application to fill them in. These packets are apparently
- inserted every four frames.
- 8=enable scene change detection (seems to be a failure)
- 9=set history parameters of the video input module
- 10=set input field order of VIM
- 11=set quantization matrix
- 12=reset audio interface after channel change or input switch (has no argument).
- Needed for the cx2584x, not needed for the mspx4xx, but it doesn't seem to
- do any harm calling it regardless.
- 13=set audio volume delay
- 14=set audio delay
-
-
-Param[1]
-^^^^^^^^
-
-Command value.
-
-Decoder firmware API description
---------------------------------
-
-.. note:: this API is part of the decoder firmware, so it's cx23415 only.
-
-
-
-CX2341X_DEC_PING_FW
-~~~~~~~~~~~~~~~~~~~
-
-Enum: 0/0x00
-
-Description
-^^^^^^^^^^^
-
-This API call does nothing. It may be used to check if the firmware
-is responding.
-
-
-
-CX2341X_DEC_START_PLAYBACK
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 1/0x01
-
-Description
-^^^^^^^^^^^
-
-Begin or resume playback.
-
-Param[0]
-^^^^^^^^
-
-0 based frame number in GOP to begin playback from.
-
-Param[1]
-^^^^^^^^
-
-Specifies the number of muted audio frames to play before normal
-audio resumes. (This is not implemented in the firmware, leave at 0)
-
-
-
-CX2341X_DEC_STOP_PLAYBACK
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 2/0x02
-
-Description
-^^^^^^^^^^^
-
-Ends playback and clears all decoder buffers. If PTS is not zero,
-playback stops at specified PTS.
-
-Param[0]
-^^^^^^^^
-
-Display 0=last frame, 1=black
-
-.. note::
-
- this takes effect immediately, so if you want to wait for a PTS,
- then use '0', otherwise the screen goes to black at once.
- You can call this later (even if there is no playback) with a 1 value
- to set the screen to black.
-
-Param[1]
-^^^^^^^^
-
-PTS low
-
-Param[2]
-^^^^^^^^
-
-PTS high
-
-
-
-CX2341X_DEC_SET_PLAYBACK_SPEED
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 3/0x03
-
-Description
-^^^^^^^^^^^
-
-Playback stream at speed other than normal. There are two modes of
-operation:
-
- - Smooth: host transfers entire stream and firmware drops unused
- frames.
- - Coarse: host drops frames based on indexing as required to achieve
- desired speed.
-
-Param[0]
-^^^^^^^^
-
-.. code-block:: none
-
- Bitmap:
- 0:7 0 normal
- 1 fast only "1.5 times"
- n nX fast, 1/nX slow
- 30 Framedrop:
- '0' during 1.5 times play, every other B frame is dropped
- '1' during 1.5 times play, stream is unchanged (bitrate
- must not exceed 8mbps)
- 31 Speed:
- '0' slow
- '1' fast
-
-.. note::
-
- n is limited to 2. Anything higher does not result in
- faster playback. Instead the host should start dropping frames.
-
-Param[1]
-^^^^^^^^
-
-Direction: 0=forward, 1=reverse
-
-.. note::
-
- to make reverse playback work you have to write full GOPs in
- reverse order.
-
-Param[2]
-^^^^^^^^
-
-.. code-block:: none
-
- Picture mask:
- 1=I frames
- 3=I, P frames
- 7=I, P, B frames
-
-Param[3]
-^^^^^^^^
-
-B frames per GOP (for reverse play only)
-
-.. note::
-
- for reverse playback the Picture Mask should be set to I or I, P.
- Adding B frames to the mask will result in corrupt video. This field
- has to be set to the correct value in order to keep the timing correct.
-
-Param[4]
-^^^^^^^^
-
-Mute audio: 0=disable, 1=enable
-
-Param[5]
-^^^^^^^^
-
-Display 0=frame, 1=field
-
-Param[6]
-^^^^^^^^
-
-Specifies the number of muted audio frames to play before normal audio
-resumes. (Not implemented in the firmware, leave at 0)
-
-
-
-CX2341X_DEC_STEP_VIDEO
-~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 5/0x05
-
-Description
-^^^^^^^^^^^
-
-Each call to this API steps the playback to the next unit defined below
-in the current playback direction.
-
-Param[0]
-^^^^^^^^
-
-0=frame, 1=top field, 2=bottom field
-
-
-
-CX2341X_DEC_SET_DMA_BLOCK_SIZE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 8/0x08
-
-Description
-^^^^^^^^^^^
-
-Set DMA transfer block size. Counterpart to API 0xC9
-
-Param[0]
-^^^^^^^^
-
-DMA transfer block size in bytes. A different size may be specified
-when issuing the DMA transfer command.
-
-
-
-CX2341X_DEC_GET_XFER_INFO
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 9/0x09
-
-Description
-^^^^^^^^^^^
-
-This API call may be used to detect an end of stream condition.
-
-Result[0]
-^^^^^^^^^
-
-Stream type
-
-Result[1]
-^^^^^^^^^
-
-Address offset
-
-Result[2]
-^^^^^^^^^
-
-Maximum bytes to transfer
-
-Result[3]
-^^^^^^^^^
-
-Buffer fullness
-
-
-
-CX2341X_DEC_GET_DMA_STATUS
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 10/0x0A
-
-Description
-^^^^^^^^^^^
-
-Status of the last DMA transfer
-
-Result[0]
-^^^^^^^^^
-
-Bit 1 set means transfer complete
-Bit 2 set means DMA error
-Bit 3 set means linked list error
-
-Result[1]
-^^^^^^^^^
-
-DMA type: 0=MPEG, 1=OSD, 2=YUV
-
-
-
-CX2341X_DEC_SCHED_DMA_FROM_HOST
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 11/0x0B
-
-Description
-^^^^^^^^^^^
-
-Setup DMA from host operation. Counterpart to API 0xCC
-
-Param[0]
-^^^^^^^^
-
-Memory address of link list
-
-Param[1]
-^^^^^^^^
-
-Total # of bytes to transfer
-
-Param[2]
-^^^^^^^^
-
-DMA type (0=MPEG, 1=OSD, 2=YUV)
-
-
-
-CX2341X_DEC_PAUSE_PLAYBACK
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 13/0x0D
-
-Description
-^^^^^^^^^^^
-
-Freeze playback immediately. In this mode, when internal buffers are
-full, no more data will be accepted and data request IRQs will be
-masked.
-
-Param[0]
-^^^^^^^^
-
-Display: 0=last frame, 1=black
-
-
-
-CX2341X_DEC_HALT_FW
-~~~~~~~~~~~~~~~~~~~
-
-Enum: 14/0x0E
-
-Description
-^^^^^^^^^^^
-
-The firmware is halted and no further API calls are serviced until
-the firmware is uploaded again.
-
-
-
-CX2341X_DEC_SET_STANDARD
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 16/0x10
-
-Description
-^^^^^^^^^^^
-
-Selects display standard
-
-Param[0]
-^^^^^^^^
-
-0=NTSC, 1=PAL
-
-
-
-CX2341X_DEC_GET_VERSION
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 17/0x11
-
-Description
-^^^^^^^^^^^
-
-Returns decoder firmware version information
-
-Result[0]
-^^^^^^^^^
-
-Version bitmask:
- - Bits 0:15 build
- - Bits 16:23 minor
- - Bits 24:31 major
-
-
-
-CX2341X_DEC_SET_STREAM_INPUT
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 20/0x14
-
-Description
-^^^^^^^^^^^
-
-Select decoder stream input port
-
-Param[0]
-^^^^^^^^
-
-0=memory (default), 1=streaming
-
-
-
-CX2341X_DEC_GET_TIMING_INFO
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 21/0x15
-
-Description
-^^^^^^^^^^^
-
-Returns timing information from start of playback
-
-Result[0]
-^^^^^^^^^
-
-Frame count by decode order
-
-Result[1]
-^^^^^^^^^
-
-Video PTS bits 0:31 by display order
-
-Result[2]
-^^^^^^^^^
-
-Video PTS bit 32 by display order
-
-Result[3]
-^^^^^^^^^
-
-SCR bits 0:31 by display order
-
-Result[4]
-^^^^^^^^^
-
-SCR bit 32 by display order
-
-
-
-CX2341X_DEC_SET_AUDIO_MODE
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 22/0x16
-
-Description
-^^^^^^^^^^^
-
-Select audio mode
-
-Param[0]
-^^^^^^^^
-
-Dual mono mode action
- 0=Stereo, 1=Left, 2=Right, 3=Mono, 4=Swap, -1=Unchanged
-
-Param[1]
-^^^^^^^^
-
-Stereo mode action:
- 0=Stereo, 1=Left, 2=Right, 3=Mono, 4=Swap, -1=Unchanged
-
-
-
-CX2341X_DEC_SET_EVENT_NOTIFICATION
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 23/0x17
-
-Description
-^^^^^^^^^^^
-
-Setup firmware to notify the host about a particular event.
-Counterpart to API 0xD5
-
-Param[0]
-^^^^^^^^
-
-Event:
- - 0=Audio mode change between mono, (joint) stereo and dual channel.
- - 3=Decoder started
- - 4=Unknown: goes off 10-15 times per second while decoding.
- - 5=Some sync event: goes off once per frame.
-
-Param[1]
-^^^^^^^^
-
-Notification 0=disabled, 1=enabled
-
-Param[2]
-^^^^^^^^
-
-Interrupt bit
-
-Param[3]
-^^^^^^^^
-
-Mailbox slot, -1 if no mailbox required.
-
-
-
-CX2341X_DEC_SET_DISPLAY_BUFFERS
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 24/0x18
-
-Description
-^^^^^^^^^^^
-
-Number of display buffers. To decode all frames in reverse playback you
-must use nine buffers.
-
-Param[0]
-^^^^^^^^
-
-0=six buffers, 1=nine buffers
-
-
-
-CX2341X_DEC_EXTRACT_VBI
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 25/0x19
-
-Description
-^^^^^^^^^^^
-
-Extracts VBI data
-
-Param[0]
-^^^^^^^^
-
-0=extract from extension & user data, 1=extract from private packets
-
-Result[0]
-^^^^^^^^^
-
-VBI table location
-
-Result[1]
-^^^^^^^^^
-
-VBI table size
-
-
-
-CX2341X_DEC_SET_DECODER_SOURCE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 26/0x1A
-
-Description
-^^^^^^^^^^^
-
-Selects decoder source. Ensure that the parameters passed to this
-API match the encoder settings.
-
-Param[0]
-^^^^^^^^
-
-Mode: 0=MPEG from host, 1=YUV from encoder, 2=YUV from host
-
-Param[1]
-^^^^^^^^
-
-YUV picture width
-
-Param[2]
-^^^^^^^^
-
-YUV picture height
-
-Param[3]
-^^^^^^^^
-
-Bitmap: see Param[0] of API 0xBD
-
-
-
-CX2341X_DEC_SET_PREBUFFERING
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Enum: 30/0x1E
-
-Description
-^^^^^^^^^^^
-
-Decoder prebuffering, when enabled up to 128KB are buffered for
-streams <8mpbs or 640KB for streams >8mbps
-
-Param[0]
-^^^^^^^^
-
-0=off, 1=on
-
-PVR350 Video decoder registers 0x02002800 -> 0x02002B00
--------------------------------------------------------
-
-Author: Ian Armstrong <ian@iarmst.demon.co.uk>
-
-Version: v0.4
-
-Date: 12 March 2007
-
-
-This list has been worked out through trial and error. There will be mistakes
-and omissions. Some registers have no obvious effect so it's hard to say what
-they do, while others interact with each other, or require a certain load
-sequence. Horizontal filter setup is one example, with six registers working
-in unison and requiring a certain load sequence to correctly configure. The
-indexed colour palette is much easier to set at just two registers, but again
-it requires a certain load sequence.
-
-Some registers are fussy about what they are set to. Load in a bad value & the
-decoder will fail. A firmware reload will often recover, but sometimes a reset
-is required. For registers containing size information, setting them to 0 is
-generally a bad idea. For other control registers i.e. 2878, you'll only find
-out what values are bad when it hangs.
-
-.. code-block:: none
-
- --------------------------------------------------------------------------------
- 2800
- bit 0
- Decoder enable
- 0 = disable
- 1 = enable
- --------------------------------------------------------------------------------
- 2804
- bits 0:31
- Decoder horizontal Y alias register 1
- ---------------
- 2808
- bits 0:31
- Decoder horizontal Y alias register 2
- ---------------
- 280C
- bits 0:31
- Decoder horizontal Y alias register 3
- ---------------
- 2810
- bits 0:31
- Decoder horizontal Y alias register 4
- ---------------
- 2814
- bits 0:31
- Decoder horizontal Y alias register 5
- ---------------
- 2818
- bits 0:31
- Decoder horizontal Y alias trigger
-
- These six registers control the horizontal aliasing filter for the Y plane.
- The first five registers must all be loaded before accessing the trigger
- (2818), as this register actually clocks the data through for the first
- five.
-
- To correctly program set the filter, this whole procedure must be done 16
- times. The actual register contents are copied from a lookup-table in the
- firmware which contains 4 different filter settings.
-
- --------------------------------------------------------------------------------
- 281C
- bits 0:31
- Decoder horizontal UV alias register 1
- ---------------
- 2820
- bits 0:31
- Decoder horizontal UV alias register 2
- ---------------
- 2824
- bits 0:31
- Decoder horizontal UV alias register 3
- ---------------
- 2828
- bits 0:31
- Decoder horizontal UV alias register 4
- ---------------
- 282C
- bits 0:31
- Decoder horizontal UV alias register 5
- ---------------
- 2830
- bits 0:31
- Decoder horizontal UV alias trigger
-
- These six registers control the horizontal aliasing for the UV plane.
- Operation is the same as the Y filter, with 2830 being the trigger
- register.
-
- --------------------------------------------------------------------------------
- 2834
- bits 0:15
- Decoder Y source width in pixels
-
- bits 16:31
- Decoder Y destination width in pixels
- ---------------
- 2838
- bits 0:15
- Decoder UV source width in pixels
-
- bits 16:31
- Decoder UV destination width in pixels
-
- NOTE: For both registers, the resulting image must be fully visible on
- screen. If the image exceeds the right edge both the source and destination
- size must be adjusted to reflect the visible portion. For the source width,
- you must take into account the scaling when calculating the new value.
- --------------------------------------------------------------------------------
-
- 283C
- bits 0:31
- Decoder Y horizontal scaling
- Normally = Reg 2854 >> 2
- ---------------
- 2840
- bits 0:31
- Decoder ?? unknown - horizontal scaling
- Usually 0x00080514
- ---------------
- 2844
- bits 0:31
- Decoder UV horizontal scaling
- Normally = Reg 2854 >> 2
- ---------------
- 2848
- bits 0:31
- Decoder ?? unknown - horizontal scaling
- Usually 0x00100514
- ---------------
- 284C
- bits 0:31
- Decoder ?? unknown - Y plane
- Usually 0x00200020
- ---------------
- 2850
- bits 0:31
- Decoder ?? unknown - UV plane
- Usually 0x00200020
- ---------------
- 2854
- bits 0:31
- Decoder 'master' value for horizontal scaling
- ---------------
- 2858
- bits 0:31
- Decoder ?? unknown
- Usually 0
- ---------------
- 285C
- bits 0:31
- Decoder ?? unknown
- Normally = Reg 2854 >> 1
- ---------------
- 2860
- bits 0:31
- Decoder ?? unknown
- Usually 0
- ---------------
- 2864
- bits 0:31
- Decoder ?? unknown
- Normally = Reg 2854 >> 1
- ---------------
- 2868
- bits 0:31
- Decoder ?? unknown
- Usually 0
-
- Most of these registers either control horizontal scaling, or appear linked
- to it in some way. Register 2854 contains the 'master' value & the other
- registers can be calculated from that one. You must also remember to
- correctly set the divider in Reg 2874.
-
- To enlarge:
- Reg 2854 = (source_width * 0x00200000) / destination_width
- Reg 2874 = No divide
-
- To reduce from full size down to half size:
- Reg 2854 = (source_width/2 * 0x00200000) / destination width
- Reg 2874 = Divide by 2
-
- To reduce from half size down to quarter size:
- Reg 2854 = (source_width/4 * 0x00200000) / destination width
- Reg 2874 = Divide by 4
-
- The result is always rounded up.
-
- --------------------------------------------------------------------------------
- 286C
- bits 0:15
- Decoder horizontal Y buffer offset
-
- bits 15:31
- Decoder horizontal UV buffer offset
-
- Offset into the video image buffer. If the offset is gradually incremented,
- the on screen image will move left & wrap around higher up on the right.
-
- --------------------------------------------------------------------------------
- 2870
- bits 0:15
- Decoder horizontal Y output offset
-
- bits 16:31
- Decoder horizontal UV output offset
-
- Offsets the actual video output. Controls output alignment of the Y & UV
- planes. The higher the value, the greater the shift to the left. Use
- reg 2890 to move the image right.
-
- --------------------------------------------------------------------------------
- 2874
- bits 0:1
- Decoder horizontal Y output size divider
- 00 = No divide
- 01 = Divide by 2
- 10 = Divide by 3
-
- bits 4:5
- Decoder horizontal UV output size divider
- 00 = No divide
- 01 = Divide by 2
- 10 = Divide by 3
-
- bit 8
- Decoder ?? unknown
- 0 = Normal
- 1 = Affects video output levels
-
- bit 16
- Decoder ?? unknown
- 0 = Normal
- 1 = Disable horizontal filter
-
- --------------------------------------------------------------------------------
- 2878
- bit 0
- ?? unknown
-
- bit 1
- osd on/off
- 0 = osd off
- 1 = osd on
-
- bit 2
- Decoder + osd video timing
- 0 = NTSC
- 1 = PAL
-
- bits 3:4
- ?? unknown
-
- bit 5
- Decoder + osd
- Swaps upper & lower fields
-
- --------------------------------------------------------------------------------
- 287C
- bits 0:10
- Decoder & osd ?? unknown
- Moves entire screen horizontally. Starts at 0x005 with the screen
- shifted heavily to the right. Incrementing in steps of 0x004 will
- gradually shift the screen to the left.
-
- bits 11:31
- ?? unknown
-
- Normally contents are 0x00101111 (NTSC) or 0x1010111d (PAL)
-
- --------------------------------------------------------------------------------
- 2880 -------- ?? unknown
- 2884 -------- ?? unknown
- --------------------------------------------------------------------------------
- 2888
- bit 0
- Decoder + osd ?? unknown
- 0 = Normal
- 1 = Misaligned fields (Correctable through 289C & 28A4)
-
- bit 4
- ?? unknown
-
- bit 8
- ?? unknown
-
- Warning: Bad values will require a firmware reload to recover.
- Known to be bad are 0x000,0x011,0x100,0x111
- --------------------------------------------------------------------------------
- 288C
- bits 0:15
- osd ?? unknown
- Appears to affect the osd position stability. The higher the value the
- more unstable it becomes. Decoder output remains stable.
-
- bits 16:31
- osd ?? unknown
- Same as bits 0:15
-
- --------------------------------------------------------------------------------
- 2890
- bits 0:11
- Decoder output horizontal offset.
-
- Horizontal offset moves the video image right. A small left shift is
- possible, but it's better to use reg 2870 for that due to its greater
- range.
-
- NOTE: Video corruption will occur if video window is shifted off the right
- edge. To avoid this read the notes for 2834 & 2838.
- --------------------------------------------------------------------------------
- 2894
- bits 0:23
- Decoder output video surround colour.
-
- Contains the colour (in yuv) used to fill the screen when the video is
- running in a window.
- --------------------------------------------------------------------------------
- 2898
- bits 0:23
- Decoder video window colour
- Contains the colour (in yuv) used to fill the video window when the
- video is turned off.
-
- bit 24
- Decoder video output
- 0 = Video on
- 1 = Video off
-
- bit 28
- Decoder plane order
- 0 = Y,UV
- 1 = UV,Y
-
- bit 29
- Decoder second plane byte order
- 0 = Normal (UV)
- 1 = Swapped (VU)
-
- In normal usage, the first plane is Y & the second plane is UV. Though the
- order of the planes can be swapped, only the byte order of the second plane
- can be swapped. This isn't much use for the Y plane, but can be useful for
- the UV plane.
-
- --------------------------------------------------------------------------------
- 289C
- bits 0:15
- Decoder vertical field offset 1
-
- bits 16:31
- Decoder vertical field offset 2
-
- Controls field output vertical alignment. The higher the number, the lower
- the image on screen. Known starting values are 0x011E0017 (NTSC) &
- 0x01500017 (PAL)
- --------------------------------------------------------------------------------
- 28A0
- bits 0:15
- Decoder & osd width in pixels
-
- bits 16:31
- Decoder & osd height in pixels
-
- All output from the decoder & osd are disabled beyond this area. Decoder
- output will simply go black outside of this region. If the osd tries to
- exceed this area it will become corrupt.
- --------------------------------------------------------------------------------
- 28A4
- bits 0:11
- osd left shift.
-
- Has a range of 0x770->0x7FF. With the exception of 0, any value outside of
- this range corrupts the osd.
- --------------------------------------------------------------------------------
- 28A8
- bits 0:15
- osd vertical field offset 1
-
- bits 16:31
- osd vertical field offset 2
-
- Controls field output vertical alignment. The higher the number, the lower
- the image on screen. Known starting values are 0x011E0017 (NTSC) &
- 0x01500017 (PAL)
- --------------------------------------------------------------------------------
- 28AC -------- ?? unknown
- |
- V
- 28BC -------- ?? unknown
- --------------------------------------------------------------------------------
- 28C0
- bit 0
- Current output field
- 0 = first field
- 1 = second field
-
- bits 16:31
- Current scanline
- The scanline counts from the top line of the first field
- through to the last line of the second field.
- --------------------------------------------------------------------------------
- 28C4 -------- ?? unknown
- |
- V
- 28F8 -------- ?? unknown
- --------------------------------------------------------------------------------
- 28FC
- bit 0
- ?? unknown
- 0 = Normal
- 1 = Breaks decoder & osd output
- --------------------------------------------------------------------------------
- 2900
- bits 0:31
- Decoder vertical Y alias register 1
- ---------------
- 2904
- bits 0:31
- Decoder vertical Y alias register 2
- ---------------
- 2908
- bits 0:31
- Decoder vertical Y alias trigger
-
- These three registers control the vertical aliasing filter for the Y plane.
- Operation is similar to the horizontal Y filter (2804). The only real
- difference is that there are only two registers to set before accessing
- the trigger register (2908). As for the horizontal filter, the values are
- taken from a lookup table in the firmware, and the procedure must be
- repeated 16 times to fully program the filter.
- --------------------------------------------------------------------------------
- 290C
- bits 0:31
- Decoder vertical UV alias register 1
- ---------------
- 2910
- bits 0:31
- Decoder vertical UV alias register 2
- ---------------
- 2914
- bits 0:31
- Decoder vertical UV alias trigger
-
- These three registers control the vertical aliasing filter for the UV
- plane. Operation is the same as the Y filter, with 2914 being the trigger.
- --------------------------------------------------------------------------------
- 2918
- bits 0:15
- Decoder Y source height in pixels
-
- bits 16:31
- Decoder Y destination height in pixels
- ---------------
- 291C
- bits 0:15
- Decoder UV source height in pixels divided by 2
-
- bits 16:31
- Decoder UV destination height in pixels
-
- NOTE: For both registers, the resulting image must be fully visible on
- screen. If the image exceeds the bottom edge both the source and
- destination size must be adjusted to reflect the visible portion. For the
- source height, you must take into account the scaling when calculating the
- new value.
- --------------------------------------------------------------------------------
- 2920
- bits 0:31
- Decoder Y vertical scaling
- Normally = Reg 2930 >> 2
- ---------------
- 2924
- bits 0:31
- Decoder Y vertical scaling
- Normally = Reg 2920 + 0x514
- ---------------
- 2928
- bits 0:31
- Decoder UV vertical scaling
- When enlarging = Reg 2930 >> 2
- When reducing = Reg 2930 >> 3
- ---------------
- 292C
- bits 0:31
- Decoder UV vertical scaling
- Normally = Reg 2928 + 0x514
- ---------------
- 2930
- bits 0:31
- Decoder 'master' value for vertical scaling
- ---------------
- 2934
- bits 0:31
- Decoder ?? unknown - Y vertical scaling
- ---------------
- 2938
- bits 0:31
- Decoder Y vertical scaling
- Normally = Reg 2930
- ---------------
- 293C
- bits 0:31
- Decoder ?? unknown - Y vertical scaling
- ---------------
- 2940
- bits 0:31
- Decoder UV vertical scaling
- When enlarging = Reg 2930 >> 1
- When reducing = Reg 2930
- ---------------
- 2944
- bits 0:31
- Decoder ?? unknown - UV vertical scaling
- ---------------
- 2948
- bits 0:31
- Decoder UV vertical scaling
- Normally = Reg 2940
- ---------------
- 294C
- bits 0:31
- Decoder ?? unknown - UV vertical scaling
-
- Most of these registers either control vertical scaling, or appear linked
- to it in some way. Register 2930 contains the 'master' value & all other
- registers can be calculated from that one. You must also remember to
- correctly set the divider in Reg 296C
-
- To enlarge:
- Reg 2930 = (source_height * 0x00200000) / destination_height
- Reg 296C = No divide
-
- To reduce from full size down to half size:
- Reg 2930 = (source_height/2 * 0x00200000) / destination height
- Reg 296C = Divide by 2
-
- To reduce from half down to quarter.
- Reg 2930 = (source_height/4 * 0x00200000) / destination height
- Reg 296C = Divide by 4
-
- --------------------------------------------------------------------------------
- 2950
- bits 0:15
- Decoder Y line index into display buffer, first field
-
- bits 16:31
- Decoder Y vertical line skip, first field
- --------------------------------------------------------------------------------
- 2954
- bits 0:15
- Decoder Y line index into display buffer, second field
-
- bits 16:31
- Decoder Y vertical line skip, second field
- --------------------------------------------------------------------------------
- 2958
- bits 0:15
- Decoder UV line index into display buffer, first field
-
- bits 16:31
- Decoder UV vertical line skip, first field
- --------------------------------------------------------------------------------
- 295C
- bits 0:15
- Decoder UV line index into display buffer, second field
-
- bits 16:31
- Decoder UV vertical line skip, second field
- --------------------------------------------------------------------------------
- 2960
- bits 0:15
- Decoder destination height minus 1
-
- bits 16:31
- Decoder destination height divided by 2
- --------------------------------------------------------------------------------
- 2964
- bits 0:15
- Decoder Y vertical offset, second field
-
- bits 16:31
- Decoder Y vertical offset, first field
-
- These two registers shift the Y plane up. The higher the number, the
- greater the shift.
- --------------------------------------------------------------------------------
- 2968
- bits 0:15
- Decoder UV vertical offset, second field
-
- bits 16:31
- Decoder UV vertical offset, first field
-
- These two registers shift the UV plane up. The higher the number, the
- greater the shift.
- --------------------------------------------------------------------------------
- 296C
- bits 0:1
- Decoder vertical Y output size divider
- 00 = No divide
- 01 = Divide by 2
- 10 = Divide by 4
-
- bits 8:9
- Decoder vertical UV output size divider
- 00 = No divide
- 01 = Divide by 2
- 10 = Divide by 4
- --------------------------------------------------------------------------------
- 2970
- bit 0
- Decoder ?? unknown
- 0 = Normal
- 1 = Affect video output levels
-
- bit 16
- Decoder ?? unknown
- 0 = Normal
- 1 = Disable vertical filter
-
- --------------------------------------------------------------------------------
- 2974 -------- ?? unknown
- |
- V
- 29EF -------- ?? unknown
- --------------------------------------------------------------------------------
- 2A00
- bits 0:2
- osd colour mode
- 000 = 8 bit indexed
- 001 = 16 bit (565)
- 010 = 15 bit (555)
- 011 = 12 bit (444)
- 100 = 32 bit (8888)
-
- bits 4:5
- osd display bpp
- 01 = 8 bit
- 10 = 16 bit
- 11 = 32 bit
-
- bit 8
- osd global alpha
- 0 = Off
- 1 = On
-
- bit 9
- osd local alpha
- 0 = Off
- 1 = On
-
- bit 10
- osd colour key
- 0 = Off
- 1 = On
-
- bit 11
- osd ?? unknown
- Must be 1
-
- bit 13
- osd colour space
- 0 = ARGB
- 1 = AYVU
-
- bits 16:31
- osd ?? unknown
- Must be 0x001B (some kind of buffer pointer ?)
-
- When the bits-per-pixel is set to 8, the colour mode is ignored and
- assumed to be 8 bit indexed. For 16 & 32 bits-per-pixel the colour depth
- is honoured, and when using a colour depth that requires fewer bytes than
- allocated the extra bytes are used as padding. So for a 32 bpp with 8 bit
- index colour, there are 3 padding bytes per pixel. It's also possible to
- select 16bpp with a 32 bit colour mode. This results in the pixel width
- being doubled, but the color key will not work as expected in this mode.
-
- Colour key is as it suggests. You designate a colour which will become
- completely transparent. When using 565, 555 or 444 colour modes, the
- colour key is always 16 bits wide. The colour to key on is set in Reg 2A18.
-
- Local alpha works differently depending on the colour mode. For 32bpp & 8
- bit indexed, local alpha is a per-pixel 256 step transparency, with 0 being
- transparent and 255 being solid. For the 16bpp modes 555 & 444, the unused
- bit(s) act as a simple transparency switch, with 0 being solid & 1 being
- fully transparent. There is no local alpha support for 16bit 565.
-
- Global alpha is a 256 step transparency that applies to the entire osd,
- with 0 being transparent & 255 being solid.
-
- It's possible to combine colour key, local alpha & global alpha.
- --------------------------------------------------------------------------------
- 2A04
- bits 0:15
- osd x coord for left edge
-
- bits 16:31
- osd y coord for top edge
- ---------------
- 2A08
- bits 0:15
- osd x coord for right edge
-
- bits 16:31
- osd y coord for bottom edge
-
- For both registers, (0,0) = top left corner of the display area. These
- registers do not control the osd size, only where it's positioned & how
- much is visible. The visible osd area cannot exceed the right edge of the
- display, otherwise the osd will become corrupt. See reg 2A10 for
- setting osd width.
- --------------------------------------------------------------------------------
- 2A0C
- bits 0:31
- osd buffer index
-
- An index into the osd buffer. Slowly incrementing this moves the osd left,
- wrapping around onto the right edge
- --------------------------------------------------------------------------------
- 2A10
- bits 0:11
- osd buffer 32 bit word width
-
- Contains the width of the osd measured in 32 bit words. This means that all
- colour modes are restricted to a byte width which is divisible by 4.
- --------------------------------------------------------------------------------
- 2A14
- bits 0:15
- osd height in pixels
-
- bits 16:32
- osd line index into buffer
- osd will start displaying from this line.
- --------------------------------------------------------------------------------
- 2A18
- bits 0:31
- osd colour key
-
- Contains the colour value which will be transparent.
- --------------------------------------------------------------------------------
- 2A1C
- bits 0:7
- osd global alpha
-
- Contains the global alpha value (equiv ivtvfbctl --alpha XX)
- --------------------------------------------------------------------------------
- 2A20 -------- ?? unknown
- |
- V
- 2A2C -------- ?? unknown
- --------------------------------------------------------------------------------
- 2A30
- bits 0:7
- osd colour to change in indexed palette
- ---------------
- 2A34
- bits 0:31
- osd colour for indexed palette
-
- To set the new palette, first load the index of the colour to change into
- 2A30, then load the new colour into 2A34. The full palette is 256 colours,
- so the index range is 0x00-0xFF
- --------------------------------------------------------------------------------
- 2A38 -------- ?? unknown
- 2A3C -------- ?? unknown
- --------------------------------------------------------------------------------
- 2A40
- bits 0:31
- osd ?? unknown
-
- Affects overall brightness, wrapping around to black
- --------------------------------------------------------------------------------
- 2A44
- bits 0:31
- osd ?? unknown
-
- Green tint
- --------------------------------------------------------------------------------
- 2A48
- bits 0:31
- osd ?? unknown
-
- Red tint
- --------------------------------------------------------------------------------
- 2A4C
- bits 0:31
- osd ?? unknown
-
- Affects overall brightness, wrapping around to black
- --------------------------------------------------------------------------------
- 2A50
- bits 0:31
- osd ?? unknown
-
- Colour shift
- --------------------------------------------------------------------------------
- 2A54
- bits 0:31
- osd ?? unknown
-
- Colour shift
- --------------------------------------------------------------------------------
- 2A58 -------- ?? unknown
- |
- V
- 2AFC -------- ?? unknown
- --------------------------------------------------------------------------------
- 2B00
- bit 0
- osd filter control
- 0 = filter off
- 1 = filter on
-
- bits 1:4
- osd ?? unknown
-
- --------------------------------------------------------------------------------
-
-The cx231xx DMA engine
-----------------------
-
-
-This page describes the structures and procedures used by the cx2341x DMA
-engine.
-
-Introduction
-~~~~~~~~~~~~
-
-The cx2341x PCI interface is busmaster capable. This means it has a DMA
-engine to efficiently transfer large volumes of data between the card and main
-memory without requiring help from a CPU. Like most hardware, it must operate
-on contiguous physical memory. This is difficult to come by in large quantities
-on virtual memory machines.
-
-Therefore, it also supports a technique called "scatter-gather". The card can
-transfer multiple buffers in one operation. Instead of allocating one large
-contiguous buffer, the driver can allocate several smaller buffers.
-
-In practice, I've seen the average transfer to be roughly 80K, but transfers
-above 128K were not uncommon, particularly at startup. The 128K figure is
-important, because that is the largest block that the kernel can normally
-allocate. Even still, 128K blocks are hard to come by, so the driver writer is
-urged to choose a smaller block size and learn the scatter-gather technique.
-
-Mailbox #10 is reserved for DMA transfer information.
-
-Note: the hardware expects little-endian data ('intel format').
-
-Flow
-~~~~
-
-This section describes, in general, the order of events when handling DMA
-transfers. Detailed information follows this section.
-
-- The card raises the Encoder interrupt.
-- The driver reads the transfer type, offset and size from Mailbox #10.
-- The driver constructs the scatter-gather array from enough free dma buffers
- to cover the size.
-- The driver schedules the DMA transfer via the ScheduleDMAtoHost API call.
-- The card raises the DMA Complete interrupt.
-- The driver checks the DMA status register for any errors.
-- The driver post-processes the newly transferred buffers.
-
-NOTE! It is possible that the Encoder and DMA Complete interrupts get raised
-simultaneously. (End of the last, start of the next, etc.)
-
-Mailbox #10
-~~~~~~~~~~~
-
-The Flags, Command, Return Value and Timeout fields are ignored.
-
-- Name: Mailbox #10
-- Results[0]: Type: 0: MPEG.
-- Results[1]: Offset: The position relative to the card's memory space.
-- Results[2]: Size: The exact number of bytes to transfer.
-
-My speculation is that since the StartCapture API has a capture type of "RAW"
-available, that the type field will have other values that correspond to YUV
-and PCM data.
-
-Scatter-Gather Array
-~~~~~~~~~~~~~~~~~~~~
-
-The scatter-gather array is a contiguously allocated block of memory that
-tells the card the source and destination of each data-block to transfer.
-Card "addresses" are derived from the offset supplied by Mailbox #10. Host
-addresses are the physical memory location of the target DMA buffer.
-
-Each S-G array element is a struct of three 32-bit words. The first word is
-the source address, the second is the destination address. Both take up the
-entire 32 bits. The lowest 18 bits of the third word is the transfer byte
-count. The high-bit of the third word is the "last" flag. The last-flag tells
-the card to raise the DMA_DONE interrupt. From hard personal experience, if
-you forget to set this bit, the card will still "work" but the stream will
-most likely get corrupted.
-
-The transfer count must be a multiple of 256. Therefore, the driver will need
-to track how much data in the target buffer is valid and deal with it
-accordingly.
-
-Array Element:
-
-- 32-bit Source Address
-- 32-bit Destination Address
-- 14-bit reserved (high bit is the last flag)
-- 18-bit byte count
-
-DMA Transfer Status
-~~~~~~~~~~~~~~~~~~~
-
-Register 0x0004 holds the DMA Transfer Status:
-
-- bit 0: read completed
-- bit 1: write completed
-- bit 2: DMA read error
-- bit 3: DMA write error
-- bit 4: Scatter-Gather array error
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-The cx88 driver
-===============
-
-Author: Gerd Hoffmann
-
-Documentation missing at the cx88 datasheet
--------------------------------------------
-
-MO_OUTPUT_FORMAT (0x310164)
-
-.. code-block:: none
-
- Previous default from DScaler: 0x1c1f0008
- Digit 8: 31-28
- 28: PREVREMOD = 1
-
- Digit 7: 27-24 (0xc = 12 = b1100 )
- 27: COMBALT = 1
- 26: PAL_INV_PHASE
- (DScaler apparently set this to 1, resulted in sucky picture)
-
- Digits 6,5: 23-16
- 25-16: COMB_RANGE = 0x1f [default] (9 bits -> max 512)
-
- Digit 4: 15-12
- 15: DISIFX = 0
- 14: INVCBF = 0
- 13: DISADAPT = 0
- 12: NARROWADAPT = 0
-
- Digit 3: 11-8
- 11: FORCE2H
- 10: FORCEREMD
- 9: NCHROMAEN
- 8: NREMODEN
-
- Digit 2: 7-4
- 7-6: YCORE
- 5-4: CCORE
-
- Digit 1: 3-0
- 3: RANGE = 1
- 2: HACTEXT
- 1: HSFMT
-
-0x47 is the sync byte for MPEG-2 transport stream packets.
-Datasheet incorrectly states to use 47 decimal. 188 is the length.
-All DVB compliant frontends output packets with this start code.
-
-Hauppauge WinTV cx88 IR information
------------------------------------
-
-The controls for the mux are GPIO [0,1] for source, and GPIO 2 for muting.
-
-====== ======== =================================================
-GPIO0 GPIO1
-====== ======== =================================================
- 0 0 TV Audio
- 1 0 FM radio
- 0 1 Line-In
- 1 1 Mono tuner bypass or CD passthru (tuner specific)
-====== ======== =================================================
-
-GPIO 16(I believe) is tied to the IR port (if present).
-
-
-From the data sheet:
-
-- Register 24'h20004 PCI Interrupt Status
-
- - bit [18] IR_SMP_INT Set when 32 input samples have been collected over
- - gpio[16] pin into GP_SAMPLE register.
-
-What's missing from the data sheet:
-
-- Setup 4KHz sampling rate (roughly 2x oversampled; good enough for our RC5
- compat remote)
-- set register 0x35C050 to 0xa80a80
-- enable sampling
-- set register 0x35C054 to 0x5
-- enable the IRQ bit 18 in the interrupt mask register (and
- provide for a handler)
-
-GP_SAMPLE register is at 0x35C058
-
-Bits are then right shifted into the GP_SAMPLE register at the specified
-rate; you get an interrupt when a full DWORD is received.
-You need to recover the actual RC5 bits out of the (oversampled) IR sensor
-bits. (Hint: look for the 0/1and 1/0 crossings of the RC5 bi-phase data) An
-actual raw RC5 code will span 2-3 DWORDS, depending on the actual alignment.
-
-I'm pretty sure when no IR signal is present the receiver is always in a
-marking state(1); but stray light, etc can cause intermittent noise values
-as well. Remember, this is a free running sample of the IR receiver state
-over time, so don't assume any sample starts at any particular place.
-
-Additional info
-~~~~~~~~~~~~~~~
-
-This data sheet (google search) seems to have a lovely description of the
-RC5 basics:
-http://www.atmel.com/dyn/resources/prod_documents/doc2817.pdf
-
-This document has more data:
-http://www.nenya.be/beor/electronics/rc5.htm
-
-This document has a how to decode a bi-phase data stream:
-http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt
-
-This document has still more info:
-http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-The VPBE V4L2 driver design
-===========================
-
-File partitioning
------------------
-
- V4L2 display device driver
- drivers/media/platform/davinci/vpbe_display.c
- drivers/media/platform/davinci/vpbe_display.h
-
- VPBE display controller
- drivers/media/platform/davinci/vpbe.c
- drivers/media/platform/davinci/vpbe.h
-
- VPBE venc sub device driver
- drivers/media/platform/davinci/vpbe_venc.c
- drivers/media/platform/davinci/vpbe_venc.h
- drivers/media/platform/davinci/vpbe_venc_regs.h
-
- VPBE osd driver
- drivers/media/platform/davinci/vpbe_osd.c
- drivers/media/platform/davinci/vpbe_osd.h
- drivers/media/platform/davinci/vpbe_osd_regs.h
-
-To be done
-----------
-
-vpbe display controller
- - Add support for external encoders.
- - add support for selecting external encoder as default at probe time.
-
-vpbe venc sub device
- - add timings for supporting ths8200
- - add support for LogicPD LCD.
-
-FB drivers
- - Add support for fbdev drivers.- Ready and part of subsequent patches.
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: <isonum.txt>
-
-The Samsung S5P/EXYNOS4 FIMC driver
-===================================
-
-Copyright |copy| 2012 - 2013 Samsung Electronics Co., Ltd.
-
-Files partitioning
-------------------
-
-- media device driver
-
- drivers/media/platform/exynos4-is/media-dev.[ch]
-
-- camera capture video device driver
-
- drivers/media/platform/exynos4-is/fimc-capture.c
-
-- MIPI-CSI2 receiver subdev
-
- drivers/media/platform/exynos4-is/mipi-csis.[ch]
-
-- video post-processor (mem-to-mem)
-
- drivers/media/platform/exynos4-is/fimc-core.c
-
-- common files
-
- drivers/media/platform/exynos4-is/fimc-core.h
- drivers/media/platform/exynos4-is/fimc-reg.h
- drivers/media/platform/exynos4-is/regs-fimc.h
:maxdepth: 5
:numbered:
- tuners
max2175
- pvrusb2
- pxa_camera
- radiotrack
- sh_mobile_ceu_camera
uvcvideo
- bttv-devel
- cpia2_devel
- cx2341x-devel
- cx88-devel
- davinci-vpbe-devel
- fimc-devel
- saa7134-devel
- vimc-devel
-
cx2341x-uapi
imx-uapi
meye-uapi
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-The pvrusb2 driver
-==================
-
-Author: Mike Isely <isely@pobox.com>
-
-Background
-----------
-
-This driver is intended for the "Hauppauge WinTV PVR USB 2.0", which
-is a USB 2.0 hosted TV Tuner. This driver is a work in progress.
-Its history started with the reverse-engineering effort by Björn
-Danielsson <pvrusb2@dax.nu> whose web page can be found here:
-http://pvrusb2.dax.nu/
-
-From there Aurelien Alleaume <slts@free.fr> began an effort to
-create a video4linux compatible driver. I began with Aurelien's
-last known snapshot and evolved the driver to the state it is in
-here.
-
-More information on this driver can be found at:
-http://www.isely.net/pvrusb2.html
-
-
-This driver has a strong separation of layers. They are very
-roughly:
-
-1. Low level wire-protocol implementation with the device.
-
-2. I2C adaptor implementation and corresponding I2C client drivers
- implemented elsewhere in V4L.
-
-3. High level hardware driver implementation which coordinates all
- activities that ensure correct operation of the device.
-
-4. A "context" layer which manages instancing of driver, setup,
- tear-down, arbitration, and interaction with high level
- interfaces appropriately as devices are hotplugged in the
- system.
-
-5. High level interfaces which glue the driver to various published
- Linux APIs (V4L, sysfs, maybe DVB in the future).
-
-The most important shearing layer is between the top 2 layers. A
-lot of work went into the driver to ensure that any kind of
-conceivable API can be laid on top of the core driver. (Yes, the
-driver internally leverages V4L to do its work but that really has
-nothing to do with the API published by the driver to the outside
-world.) The architecture allows for different APIs to
-simultaneously access the driver. I have a strong sense of fairness
-about APIs and also feel that it is a good design principle to keep
-implementation and interface isolated from each other. Thus while
-right now the V4L high level interface is the most complete, the
-sysfs high level interface will work equally well for similar
-functions, and there's no reason I see right now why it shouldn't be
-possible to produce a DVB high level interface that can sit right
-alongside V4L.
-
-Building
---------
-
-To build these modules essentially amounts to just running "Make",
-but you need the kernel source tree nearby and you will likely also
-want to set a few controlling environment variables first in order
-to link things up with that source tree. Please see the Makefile
-here for comments that explain how to do that.
-
-Source file list / functional overview
---------------------------------------
-
-(Note: The term "module" used below generally refers to loosely
-defined functional units within the pvrusb2 driver and bears no
-relation to the Linux kernel's concept of a loadable module.)
-
-pvrusb2-audio.[ch] - This is glue logic that resides between this
- driver and the msp3400.ko I2C client driver (which is found
- elsewhere in V4L).
-
-pvrusb2-context.[ch] - This module implements the context for an
- instance of the driver. Everything else eventually ties back to
- or is otherwise instanced within the data structures implemented
- here. Hotplugging is ultimately coordinated here. All high level
- interfaces tie into the driver through this module. This module
- helps arbitrate each interface's access to the actual driver core,
- and is designed to allow concurrent access through multiple
- instances of multiple interfaces (thus you can for example change
- the tuner's frequency through sysfs while simultaneously streaming
- video through V4L out to an instance of mplayer).
-
-pvrusb2-debug.h - This header defines a printk() wrapper and a mask
- of debugging bit definitions for the various kinds of debug
- messages that can be enabled within the driver.
-
-pvrusb2-debugifc.[ch] - This module implements a crude command line
- oriented debug interface into the driver. Aside from being part
- of the process for implementing manual firmware extraction (see
- the pvrusb2 web site mentioned earlier), probably I'm the only one
- who has ever used this. It is mainly a debugging aid.
-
-pvrusb2-eeprom.[ch] - This is glue logic that resides between this
- driver the tveeprom.ko module, which is itself implemented
- elsewhere in V4L.
-
-pvrusb2-encoder.[ch] - This module implements all protocol needed to
- interact with the Conexant mpeg2 encoder chip within the pvrusb2
- device. It is a crude echo of corresponding logic in ivtv,
- however the design goals (strict isolation) and physical layer
- (proxy through USB instead of PCI) are enough different that this
- implementation had to be completely different.
-
-pvrusb2-hdw-internal.h - This header defines the core data structure
- in the driver used to track ALL internal state related to control
- of the hardware. Nobody outside of the core hardware-handling
- modules should have any business using this header. All external
- access to the driver should be through one of the high level
- interfaces (e.g. V4L, sysfs, etc), and in fact even those high
- level interfaces are restricted to the API defined in
- pvrusb2-hdw.h and NOT this header.
-
-pvrusb2-hdw.h - This header defines the full internal API for
- controlling the hardware. High level interfaces (e.g. V4L, sysfs)
- will work through here.
-
-pvrusb2-hdw.c - This module implements all the various bits of logic
- that handle overall control of a specific pvrusb2 device.
- (Policy, instantiation, and arbitration of pvrusb2 devices fall
- within the jurisdiction of pvrusb-context not here).
-
-pvrusb2-i2c-chips-\*.c - These modules implement the glue logic to
- tie together and configure various I2C modules as they attach to
- the I2C bus. There are two versions of this file. The "v4l2"
- version is intended to be used in-tree alongside V4L, where we
- implement just the logic that makes sense for a pure V4L
- environment. The "all" version is intended for use outside of
- V4L, where we might encounter other possibly "challenging" modules
- from ivtv or older kernel snapshots (or even the support modules
- in the standalone snapshot).
-
-pvrusb2-i2c-cmd-v4l1.[ch] - This module implements generic V4L1
- compatible commands to the I2C modules. It is here where state
- changes inside the pvrusb2 driver are translated into V4L1
- commands that are in turn send to the various I2C modules.
-
-pvrusb2-i2c-cmd-v4l2.[ch] - This module implements generic V4L2
- compatible commands to the I2C modules. It is here where state
- changes inside the pvrusb2 driver are translated into V4L2
- commands that are in turn send to the various I2C modules.
-
-pvrusb2-i2c-core.[ch] - This module provides an implementation of a
- kernel-friendly I2C adaptor driver, through which other external
- I2C client drivers (e.g. msp3400, tuner, lirc) may connect and
- operate corresponding chips within the pvrusb2 device. It is
- through here that other V4L modules can reach into this driver to
- operate specific pieces (and those modules are in turn driven by
- glue logic which is coordinated by pvrusb2-hdw, doled out by
- pvrusb2-context, and then ultimately made available to users
- through one of the high level interfaces).
-
-pvrusb2-io.[ch] - This module implements a very low level ring of
- transfer buffers, required in order to stream data from the
- device. This module is *very* low level. It only operates the
- buffers and makes no attempt to define any policy or mechanism for
- how such buffers might be used.
-
-pvrusb2-ioread.[ch] - This module layers on top of pvrusb2-io.[ch]
- to provide a streaming API usable by a read() system call style of
- I/O. Right now this is the only layer on top of pvrusb2-io.[ch],
- however the underlying architecture here was intended to allow for
- other styles of I/O to be implemented with additional modules, like
- mmap()'ed buffers or something even more exotic.
-
-pvrusb2-main.c - This is the top level of the driver. Module level
- and USB core entry points are here. This is our "main".
-
-pvrusb2-sysfs.[ch] - This is the high level interface which ties the
- pvrusb2 driver into sysfs. Through this interface you can do
- everything with the driver except actually stream data.
-
-pvrusb2-tuner.[ch] - This is glue logic that resides between this
- driver and the tuner.ko I2C client driver (which is found
- elsewhere in V4L).
-
-pvrusb2-util.h - This header defines some common macros used
- throughout the driver. These macros are not really specific to
- the driver, but they had to go somewhere.
-
-pvrusb2-v4l2.[ch] - This is the high level interface which ties the
- pvrusb2 driver into video4linux. It is through here that V4L
- applications can open and operate the driver in the usual V4L
- ways. Note that **ALL** V4L functionality is published only
- through here and nowhere else.
-
-pvrusb2-video-\*.[ch] - This is glue logic that resides between this
- driver and the saa711x.ko I2C client driver (which is found
- elsewhere in V4L). Note that saa711x.ko used to be known as
- saa7115.ko in ivtv. There are two versions of this; one is
- selected depending on the particular saa711[5x].ko that is found.
-
-pvrusb2.h - This header contains compile time tunable parameters
- (and at the moment the driver has very little that needs to be
- tuned).
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-PXA-Camera Host Driver
-======================
-
-Author: Robert Jarzmik <robert.jarzmik@free.fr>
-
-Constraints
------------
-
-a) Image size for YUV422P format
- All YUV422P images are enforced to have width x height % 16 = 0.
- This is due to DMA constraints, which transfers only planes of 8 byte
- multiples.
-
-
-Global video workflow
----------------------
-
-a) QCI stopped
- Initially, the QCI interface is stopped.
- When a buffer is queued (pxa_videobuf_ops->buf_queue), the QCI starts.
-
-b) QCI started
- More buffers can be queued while the QCI is started without halting the
- capture. The new buffers are "appended" at the tail of the DMA chain, and
- smoothly captured one frame after the other.
-
- Once a buffer is filled in the QCI interface, it is marked as "DONE" and
- removed from the active buffers list. It can be then requeud or dequeued by
- userland application.
-
- Once the last buffer is filled in, the QCI interface stops.
-
-c) Capture global finite state machine schema
-
-.. code-block:: none
-
- +----+ +---+ +----+
- | DQ | | Q | | DQ |
- | v | v | v
- +-----------+ +------------------------+
- | STOP | | Wait for capture start |
- +-----------+ Q +------------------------+
- +-> | QCI: stop | ------------------> | QCI: run | <------------+
- | | DMA: stop | | DMA: stop | |
- | +-----------+ +-----> +------------------------+ |
- | / | |
- | / +---+ +----+ | |
- |capture list empty / | Q | | DQ | | QCI Irq EOF |
- | / | v | v v |
- | +--------------------+ +----------------------+ |
- | | DMA hotlink missed | | Capture running | |
- | +--------------------+ +----------------------+ |
- | | QCI: run | +-----> | QCI: run | <-+ |
- | | DMA: stop | / | DMA: run | | |
- | +--------------------+ / +----------------------+ | Other |
- | ^ /DMA still | | channels |
- | | capture list / running | DMA Irq End | not |
- | | not empty / | | finished |
- | | / v | yet |
- | +----------------------+ +----------------------+ | |
- | | Videobuf released | | Channel completed | | |
- | +----------------------+ +----------------------+ | |
- +-- | QCI: run | | QCI: run | --+ |
- | DMA: run | | DMA: run | |
- +----------------------+ +----------------------+ |
- ^ / | |
- | no overrun / | overrun |
- | / v |
- +--------------------+ / +----------------------+ |
- | Frame completed | / | Frame overran | |
- +--------------------+ <-----+ +----------------------+ restart frame |
- | QCI: run | | QCI: stop | --------------+
- | DMA: run | | DMA: stop |
- +--------------------+ +----------------------+
-
- Legend: - each box is a FSM state
- - each arrow is the condition to transition to another state
- - an arrow with a comment is a mandatory transition (no condition)
- - arrow "Q" means : a buffer was enqueued
- - arrow "DQ" means : a buffer was dequeued
- - "QCI: stop" means the QCI interface is not enabled
- - "DMA: stop" means all 3 DMA channels are stopped
- - "DMA: run" means at least 1 DMA channel is still running
-
-DMA usage
----------
-
-a) DMA flow
- - first buffer queued for capture
- Once a first buffer is queued for capture, the QCI is started, but data
- transfer is not started. On "End Of Frame" interrupt, the irq handler
- starts the DMA chain.
- - capture of one videobuffer
- The DMA chain starts transferring data into videobuffer RAM pages.
- When all pages are transferred, the DMA irq is raised on "ENDINTR" status
- - finishing one videobuffer
- The DMA irq handler marks the videobuffer as "done", and removes it from
- the active running queue
- Meanwhile, the next videobuffer (if there is one), is transferred by DMA
- - finishing the last videobuffer
- On the DMA irq of the last videobuffer, the QCI is stopped.
-
-b) DMA prepared buffer will have this structure
-
-.. code-block:: none
-
- +------------+-----+---------------+-----------------+
- | desc-sg[0] | ... | desc-sg[last] | finisher/linker |
- +------------+-----+---------------+-----------------+
-
-This structure is pointed by dma->sg_cpu.
-The descriptors are used as follows:
-
-- desc-sg[i]: i-th descriptor, transferring the i-th sg
- element to the video buffer scatter gather
-- finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
-- linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0
-
-For the next schema, let's assume d0=desc-sg[0] .. dN=desc-sg[N],
-"f" stands for finisher and "l" for linker.
-A typical running chain is :
-
-.. code-block:: none
-
- Videobuffer 1 Videobuffer 2
- +---------+----+---+ +----+----+----+---+
- | d0 | .. | dN | l | | d0 | .. | dN | f |
- +---------+----+-|-+ ^----+----+----+---+
- | |
- +----+
-
-After the chaining is finished, the chain looks like :
-
-.. code-block:: none
-
- Videobuffer 1 Videobuffer 2 Videobuffer 3
- +---------+----+---+ +----+----+----+---+ +----+----+----+---+
- | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
- +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
- | | | |
- +----+ +----+
- new_link
-
-c) DMA hot chaining timeslice issue
-
-As DMA chaining is done while DMA _is_ running, the linking may be done
-while the DMA jumps from one Videobuffer to another. On the schema, that
-would be a problem if the following sequence is encountered :
-
-- DMA chain is Videobuffer1 + Videobuffer2
-- pxa_videobuf_queue() is called to queue Videobuffer3
-- DMA controller finishes Videobuffer2, and DMA stops
-
-.. code-block:: none
-
- =>
- Videobuffer 1 Videobuffer 2
- +---------+----+---+ +----+----+----+---+
- | d0 | .. | dN | l | | d0 | .. | dN | f |
- +---------+----+-|-+ ^----+----+----+-^-+
- | | |
- +----+ +-- DMA DDADR loads DDADR_STOP
-
-- pxa_dma_add_tail_buf() is called, the Videobuffer2 "finisher" is
- replaced by a "linker" to Videobuffer3 (creation of new_link)
-- pxa_videobuf_queue() finishes
-- the DMA irq handler is called, which terminates Videobuffer2
-- Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!)
-
-.. code-block:: none
-
- Videobuffer 1 Videobuffer 2 Videobuffer 3
- +---------+----+---+ +----+----+----+---+ +----+----+----+---+
- | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
- +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
- | | | |
- +----+ +----+
- new_link
- DMA DDADR still is DDADR_STOP
-
-- pxa_camera_check_link_miss() is called
- This checks if the DMA is finished and a buffer is still on the
- pcdev->capture list. If that's the case, the capture will be restarted,
- and Videobuffer3 is scheduled on DMA chain.
-- the DMA irq handler finishes
-
-.. note::
-
- If DMA stops just after pxa_camera_check_link_miss() reads DDADR()
- value, we have the guarantee that the DMA irq handler will be called back
- when the DMA will finish the buffer, and pxa_camera_check_link_miss() will
- be called again, to reschedule Videobuffer3.
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-The Radiotrack radio driver
-===========================
-
-Author: Stephen M. Benoit <benoits@servicepro.com>
-
-Date: Dec 14, 1996
-
-ACKNOWLEDGMENTS
-----------------
-
-This document was made based on 'C' code for Linux from Gideon le Grange
-(legrang@active.co.za or legrang@cs.sun.ac.za) in 1994, and elaborations from
-Frans Brinkman (brinkman@esd.nl) in 1996. The results reported here are from
-experiments that the author performed on his own setup, so your mileage may
-vary... I make no guarantees, claims or warranties to the suitability or
-validity of this information. No other documentation on the AIMS
-Lab (http://www.aimslab.com/) RadioTrack card was made available to the
-author. This document is offered in the hopes that it might help users who
-want to use the RadioTrack card in an environment other than MS Windows.
-
-WHY THIS DOCUMENT?
-------------------
-
-I have a RadioTrack card from back when I ran an MS-Windows platform. After
-converting to Linux, I found Gideon le Grange's command-line software for
-running the card, and found that it was good! Frans Brinkman made a
-comfortable X-windows interface, and added a scanning feature. For hack
-value, I wanted to see if the tuner could be tuned beyond the usual FM radio
-broadcast band, so I could pick up the audio carriers from North American
-broadcast TV channels, situated just below and above the 87.0-109.0 MHz range.
-I did not get much success, but I learned about programming ioports under
-Linux and gained some insights about the hardware design used for the card.
-
-So, without further delay, here are the details.
-
-
-PHYSICAL DESCRIPTION
---------------------
-
-The RadioTrack card is an ISA 8-bit FM radio card. The radio frequency (RF)
-input is simply an antenna lead, and the output is a power audio signal
-available through a miniature phone plug. Its RF frequencies of operation are
-more or less limited from 87.0 to 109.0 MHz (the commercial FM broadcast
-band). Although the registers can be programmed to request frequencies beyond
-these limits, experiments did not give promising results. The variable
-frequency oscillator (VFO) that demodulates the intermediate frequency (IF)
-signal probably has a small range of useful frequencies, and wraps around or
-gets clipped beyond the limits mentioned above.
-
-
-CONTROLLING THE CARD WITH IOPORT
---------------------------------
-
-The RadioTrack (base) ioport is configurable for 0x30c or 0x20c. Only one
-ioport seems to be involved. The ioport decoding circuitry must be pretty
-simple, as individual ioport bits are directly matched to specific functions
-(or blocks) of the radio card. This way, many functions can be changed in
-parallel with one write to the ioport. The only feedback available through
-the ioports appears to be the "Stereo Detect" bit.
-
-The bits of the ioport are arranged as follows:
-
-.. code-block:: none
-
- MSb LSb
- +------+------+------+--------+--------+-------+---------+--------+
- | VolA | VolB | ???? | Stereo | Radio | TuneA | TuneB | Tune |
- | (+) | (-) | | Detect | Audio | (bit) | (latch) | Update |
- | | | | Enable | Enable | | | Enable |
- +------+------+------+--------+--------+-------+---------+--------+
-
-
-==== ==== =================================
-VolA VolB Description
-==== ==== =================================
-0 0 audio mute
-0 1 volume + (some delay required)
-1 0 volume - (some delay required)
-1 1 stay at present volume
-==== ==== =================================
-
-==================== ===========
-Stereo Detect Enable Description
-==================== ===========
-0 No Detect
-1 Detect
-==================== ===========
-
-Results available by reading ioport >60 msec after last port write.
-
- 0xff ==> no stereo detected, 0xfd ==> stereo detected.
-
-============================= =============================
-Radio to Audio (path) Enable Description
-============================= =============================
-0 Disable path (silence)
-1 Enable path (audio produced)
-============================= =============================
-
-===== ===== ==================
-TuneA TuneB Description
-===== ===== ==================
-0 0 "zero" bit phase 1
-0 1 "zero" bit phase 2
-1 0 "one" bit phase 1
-1 1 "one" bit phase 2
-===== ===== ==================
-
-
-24-bit code, where bits = (freq*40) + 10486188.
-The Most Significant 11 bits must be 1010 xxxx 0x0 to be valid.
-The bits are shifted in LSb first.
-
-================== ===========================
-Tune Update Enable Description
-================== ===========================
-0 Tuner held constant
-1 Tuner updating in progress
-================== ===========================
-
-
-PROGRAMMING EXAMPLES
---------------------
-
-.. code-block:: none
-
- Default: BASE <-- 0xc8 (current volume, no stereo detect,
- radio enable, tuner adjust disable)
-
- Card Off: BASE <-- 0x00 (audio mute, no stereo detect,
- radio disable, tuner adjust disable)
-
- Card On: BASE <-- 0x00 (see "Card Off", clears any unfinished business)
- BASE <-- 0xc8 (see "Default")
-
- Volume Down: BASE <-- 0x48 (volume down, no stereo detect,
- radio enable, tuner adjust disable)
- wait 10 msec
- BASE <-- 0xc8 (see "Default")
-
- Volume Up: BASE <-- 0x88 (volume up, no stereo detect,
- radio enable, tuner adjust disable)
- wait 10 msec
- BASE <-- 0xc8 (see "Default")
-
- Check Stereo: BASE <-- 0xd8 (current volume, stereo detect,
- radio enable, tuner adjust disable)
- wait 100 msec
- x <-- BASE (read ioport)
- BASE <-- 0xc8 (see "Default")
-
- x=0xff ==> "not stereo", x=0xfd ==> "stereo detected"
-
- Set Frequency: code = (freq*40) + 10486188
- foreach of the 24 bits in code,
- (from Least to Most Significant):
- to write a "zero" bit,
- BASE <-- 0x01 (audio mute, no stereo detect, radio
- disable, "zero" bit phase 1, tuner adjust)
- BASE <-- 0x03 (audio mute, no stereo detect, radio
- disable, "zero" bit phase 2, tuner adjust)
- to write a "one" bit,
- BASE <-- 0x05 (audio mute, no stereo detect, radio
- disable, "one" bit phase 1, tuner adjust)
- BASE <-- 0x07 (audio mute, no stereo detect, radio
- disable, "one" bit phase 2, tuner adjust)
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-The saa7134 driver
-==================
-
-Author Gerd Hoffmann
-
-
-Card Variations:
-----------------
-
-Cards can use either of these two crystals (xtal):
-
-- 32.11 MHz -> .audio_clock=0x187de7
-- 24.576MHz -> .audio_clock=0x200000 (xtal * .audio_clock = 51539600)
-
-Some details about 30/34/35:
-
-- saa7130 - low-price chip, doesn't have mute, that is why all those
- cards should have .mute field defined in their tuner structure.
-
-- saa7134 - usual chip
-
-- saa7133/35 - saa7135 is probably a marketing decision, since all those
- chips identifies itself as 33 on pci.
-
-LifeView GPIOs
---------------
-
-This section was authored by: Peter Missel <peter.missel@onlinehome.de>
-
-- LifeView FlyTV Platinum FM (LR214WF)
-
- - GP27 MDT2005 PB4 pin 10
- - GP26 MDT2005 PB3 pin 9
- - GP25 MDT2005 PB2 pin 8
- - GP23 MDT2005 PB1 pin 7
- - GP22 MDT2005 PB0 pin 6
- - GP21 MDT2005 PB5 pin 11
- - GP20 MDT2005 PB6 pin 12
- - GP19 MDT2005 PB7 pin 13
- - nc MDT2005 PA3 pin 2
- - Remote MDT2005 PA2 pin 1
- - GP18 MDT2005 PA1 pin 18
- - nc MDT2005 PA0 pin 17 strap low
- - GP17 Strap "GP7"=High
- - GP16 Strap "GP6"=High
-
- - 0=Radio 1=TV
- - Drives SA630D ENCH1 and HEF4052 A1 pinsto do FM radio through
- SIF input
-
- - GP15 nc
- - GP14 nc
- - GP13 nc
- - GP12 Strap "GP5" = High
- - GP11 Strap "GP4" = High
- - GP10 Strap "GP3" = High
- - GP09 Strap "GP2" = Low
- - GP08 Strap "GP1" = Low
- - GP07.00 nc
-
-Credits
--------
-
-andrew.stevens@philips.com + werner.leeb@philips.com for providing
-saa7134 hardware specs and sample board.
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-Cropping and Scaling algorithm, used in the sh_mobile_ceu_camera driver
-=======================================================================
-
-Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
-
-Terminology
------------
-
-sensor scales: horizontal and vertical scales, configured by the sensor driver
-host scales: -"- host driver
-combined scales: sensor_scale * host_scale
-
-
-Generic scaling / cropping scheme
----------------------------------
-
-.. code-block:: none
-
- -1--
- |
- -2-- -\
- | --\
- | --\
- +-5-- . -- -3-- -\
- | `... -\
- | `... -4-- . - -7..
- | `.
- | `. .6--
- |
- | . .6'-
- | .´
- | ... -4'- .´
- | ...´ - -7'.
- +-5'- .´ -/
- | -- -3'- -/
- | --/
- | --/
- -2'- -/
- |
- |
- -1'-
-
-In the above chart minuses and slashes represent "real" data amounts, points and
-accents represent "useful" data, basically, CEU scaled and cropped output,
-mapped back onto the client's source plane.
-
-Such a configuration can be produced by user requests:
-
-S_CROP(left / top = (5) - (1), width / height = (5') - (5))
-S_FMT(width / height = (6') - (6))
-
-Here:
-
-(1) to (1') - whole max width or height
-(1) to (2) - sensor cropped left or top
-(2) to (2') - sensor cropped width or height
-(3) to (3') - sensor scale
-(3) to (4) - CEU cropped left or top
-(4) to (4') - CEU cropped width or height
-(5) to (5') - reverse sensor scale applied to CEU cropped width or height
-(2) to (5) - reverse sensor scale applied to CEU cropped left or top
-(6) to (6') - CEU scale - user window
-
-
-S_FMT
------
-
-Do not touch input rectangle - it is already optimal.
-
-1. Calculate current sensor scales:
-
- scale_s = ((2') - (2)) / ((3') - (3))
-
-2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
-current sensor scales onto input window - this is user S_CROP:
-
- width_u = (5') - (5) = ((4') - (4)) * scale_s
-
-3. Calculate new combined scales from "effective" input window to requested user
-window:
-
- scale_comb = width_u / ((6') - (6))
-
-4. Calculate sensor output window by applying combined scales to real input
-window:
-
- width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb
-
-5. Apply iterative sensor S_FMT for sensor output window.
-
- subdev->video_ops->s_fmt(.width = width_s_out)
-
-6. Retrieve sensor output window (g_fmt)
-
-7. Calculate new sensor scales:
-
- scale_s_new = ((3')_new - (3)_new) / ((2') - (2))
-
-8. Calculate new CEU crop - apply sensor scales to previously calculated
-"effective" crop:
-
- width_ceu = (4')_new - (4)_new = width_u / scale_s_new
- left_ceu = (4)_new - (3)_new = ((5) - (2)) / scale_s_new
-
-9. Use CEU cropping to crop to the new window:
-
- ceu_crop(.width = width_ceu, .left = left_ceu)
-
-10. Use CEU scaling to scale to the requested user window:
-
- scale_ceu = width_ceu / width
-
-
-S_CROP
-------
-
-The :ref:`V4L2 crop API <crop-scale>` says:
-
-"...specification does not define an origin or units. However by convention
-drivers should horizontally count unscaled samples relative to 0H."
-
-We choose to follow the advise and interpret cropping units as client input
-pixels.
-
-Cropping is performed in the following 6 steps:
-
-1. Request exactly user rectangle from the sensor.
-
-2. If smaller - iterate until a larger one is obtained. Result: sensor cropped
- to 2 : 2', target crop 5 : 5', current output format 6' - 6.
-
-3. In the previous step the sensor has tried to preserve its output frame as
- good as possible, but it could have changed. Retrieve it again.
-
-4. Sensor scaled to 3 : 3'. Sensor's scale is (2' - 2) / (3' - 3). Calculate
- intermediate window: 4' - 4 = (5' - 5) * (3' - 3) / (2' - 2)
-
-5. Calculate and apply host scale = (6' - 6) / (4' - 4)
-
-6. Calculate and apply host crop: 6 - 7 = (5 - 2) * (6' - 6) / (5' - 5)
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-Tuner drivers
-=============
-
-Simple tuner Programming
-------------------------
-
-There are some flavors of Tuner programming APIs.
-These differ mainly by the bandswitch byte.
-
-- L= LG_API (VHF_LO=0x01, VHF_HI=0x02, UHF=0x08, radio=0x04)
-- P= PHILIPS_API (VHF_LO=0xA0, VHF_HI=0x90, UHF=0x30, radio=0x04)
-- T= TEMIC_API (VHF_LO=0x02, VHF_HI=0x04, UHF=0x01)
-- A= ALPS_API (VHF_LO=0x14, VHF_HI=0x12, UHF=0x11)
-- M= PHILIPS_MK3 (VHF_LO=0x01, VHF_HI=0x02, UHF=0x04, radio=0x19)
-
-Tuner Manufacturers
--------------------
-
-- SAMSUNG Tuner identification: (e.g. TCPM9091PD27)
-
-.. code-block:: none
-
- TCP [ABCJLMNQ] 90[89][125] [DP] [ACD] 27 [ABCD]
- [ABCJLMNQ]:
- A= BG+DK
- B= BG
- C= I+DK
- J= NTSC-Japan
- L= Secam LL
- M= BG+I+DK
- N= NTSC
- Q= BG+I+DK+LL
- [89]: ?
- [125]:
- 2: No FM
- 5: With FM
- [DP]:
- D= NTSC
- P= PAL
- [ACD]:
- A= F-connector
- C= Phono connector
- D= Din Jack
- [ABCD]:
- 3-wire/I2C tuning, 2-band/3-band
-
-These Tuners are PHILIPS_API compatible.
-
-Philips Tuner identification: (e.g. FM1216MF)
-
-.. code-block:: none
-
- F[IRMQ]12[1345]6{MF|ME|MP}
- F[IRMQ]:
- FI12x6: Tuner Series
- FR12x6: Tuner + Radio IF
- FM12x6: Tuner + FM
- FQ12x6: special
- FMR12x6: special
- TD15xx: Digital Tuner ATSC
- 12[1345]6:
- 1216: PAL BG
- 1236: NTSC
- 1246: PAL I
- 1256: Pal DK
- {MF|ME|MP}
- MF: BG LL w/ Secam (Multi France)
- ME: BG DK I LL (Multi Europe)
- MP: BG DK I (Multi PAL)
- MR: BG DK M (?)
- MG: BG DKI M (?)
- MK2 series PHILIPS_API, most tuners are compatible to this one !
- MK3 series introduced in 2002 w/ PHILIPS_MK3_API
-
-Temic Tuner identification: (.e.g 4006FH5)
-
-.. code-block:: none
-
- 4[01][0136][269]F[HYNR]5
- 40x2: Tuner (5V/33V), TEMIC_API.
- 40x6: Tuner 5V
- 41xx: Tuner compact
- 40x9: Tuner+FM compact
- [0136]
- xx0x: PAL BG
- xx1x: Pal DK, Secam LL
- xx3x: NTSC
- xx6x: PAL I
- F[HYNR]5
- FH5: Pal BG
- FY5: others
- FN5: multistandard
- FR5: w/ FM radio
- 3X xxxx: order number with specific connector
- Note: Only 40x2 series has TEMIC_API, all newer tuners have PHILIPS_API.
-
-LG Innotek Tuner:
-
-- TPI8NSR11 : NTSC J/M (TPI8NSR01 w/FM) (P,210/497)
-- TPI8PSB11 : PAL B/G (TPI8PSB01 w/FM) (P,170/450)
-- TAPC-I701 : PAL I (TAPC-I001 w/FM) (P,170/450)
-- TPI8PSB12 : PAL D/K+B/G (TPI8PSB02 w/FM) (P,170/450)
-- TAPC-H701P: NTSC_JP (TAPC-H001P w/FM) (L,170/450)
-- TAPC-G701P: PAL B/G (TAPC-G001P w/FM) (L,170/450)
-- TAPC-W701P: PAL I (TAPC-W001P w/FM) (L,170/450)
-- TAPC-Q703P: PAL D/K (TAPC-Q001P w/FM) (L,170/450)
-- TAPC-Q704P: PAL D/K+I (L,170/450)
-- TAPC-G702P: PAL D/K+B/G (L,170/450)
-
-- TADC-H002F: NTSC (L,175/410?; 2-B, C-W+11, W+12-69)
-- TADC-M201D: PAL D/K+B/G+I (L,143/425) (sound control at I2C address 0xc8)
-- TADC-T003F: NTSC Taiwan (L,175/410?; 2-B, C-W+11, W+12-69)
-
-Suffix:
- - P= Standard phono female socket
- - D= IEC female socket
- - F= F-connector
-
-Other Tuners:
-
-- TCL2002MB-1 : PAL BG + DK =TUNER_LG_PAL_NEW_TAPC
-- TCL2002MB-1F: PAL BG + DK w/FM =PHILIPS_PAL
-- TCL2002MI-2 : PAL I = ??
-
-ALPS Tuners:
-
-- Most are LG_API compatible
-- TSCH6 has ALPS_API (TSCH5 ?)
-- TSBE1 has extra API 05,02,08 Control_byte=0xCB Source:[#f1]_
-
-.. [#f1] conexant100029b-PCI-Decoder-ApplicationNote.pdf
+++ /dev/null
-.. SPDX-License-Identifier: GPL-2.0
-
-The Virtual Media Controller Driver (vimc)
-==========================================
-
-Source code documentation
--------------------------
-
-vimc-streamer
-~~~~~~~~~~~~~
-
-.. kernel-doc:: drivers/media/platform/vimc/vimc-streamer.h
- :internal:
-
-.. kernel-doc:: drivers/media/platform/vimc/vimc-streamer.c
S: Odd fixes
W: https://linuxtv.org
T: git git://linuxtv.org/media_tree.git
-F: Documentation/media/v4l-drivers/bttv*
+F: Documentation/driver-api/media/drivers/bttv*
F: drivers/media/pci/bt8xx/bttv*
BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS
S: Odd fixes
W: https://linuxtv.org
T: git git://linuxtv.org/media_tree.git
-F: Documentation/media/v4l-drivers/cx88*
+F: Documentation/driver-api/media/drivers/cx88*
F: drivers/media/pci/cx88/
CXD2820R MEDIA DRIVER
S: Maintained
W: http://www.isely.net/pvrusb2/
T: git git://linuxtv.org/media_tree.git
-F: Documentation/media/v4l-drivers/pvrusb2*
+F: Documentation/driver-api/media/drivers/pvrusb2*
F: drivers/media/usb/pvrusb2/
PWC WEBCAM DRIVER
S: Odd fixes
W: https://linuxtv.org
T: git git://linuxtv.org/media_tree.git
-F: Documentation/media/v4l-drivers/saa7134*
+F: Documentation/driver-api/media/drivers/saa7134*
F: drivers/media/pci/saa7134/
SAA7146 VIDEO4LINUX-2 DRIVER
* Amaury Demol from DiBcom for providing specs and driver
* sources, on which this driver (and the dvb-dibusb) are based.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#ifndef DIB3000_H
* Amaury Demol from DiBcom for providing specs and driver
* sources, on which this driver (and the dvb-dibusb) are based.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
*
* Copyright (C) 2008 Igor M. Liplianin (liplianin@me.by)
*
-* see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+* see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#ifndef EDS1547
*
* Copyright (C) 2008 Igor M. Liplianin (liplianin@me.by)
*
-* see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+* see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#ifndef Z0194A
/*
* Audio related reset according to
- * Documentation/media/v4l-drivers/cx2341x-devel.rst
+ * Documentation/driver-api/media/drivers/cx2341x-devel.rst
*/
if (atomic_read(&cx->ana_capturing) == 0)
cx18_vapi(cx, CX18_CPU_SET_MISC_PARAMETERS, 2,
/*
* Number of lines for Field 1 & Field 2 according to
- * Documentation/media/v4l-drivers/cx2341x-devel.rst
+ * Documentation/driver-api/media/drivers/cx2341x-devel.rst
* Field 1 is 312 for 625 line systems in BT.656
* Field 2 is 313 for 625 line systems in BT.656
*/
* - a videobuffer is queued on the pcdev->capture list
*
* Please check the "DMA hot chaining timeslice issue" in
- * Documentation/media/v4l-drivers/pxa_camera.rst
+ * Documentation/driver-api/media/drivers/pxa_camera.rst
*
* Context: should only be called within the dma irq handler
*/
/*
* Please check the DMA prepared buffer structure in :
- * Documentation/media/v4l-drivers/pxa_camera.rst
+ * Documentation/driver-api/media/drivers/pxa_camera.rst
* Please check also in pxa_camera_check_link_miss() to understand why DMA chain
* modification while DMA chain is running will work anyway.
*/
been reported to be used by these cards.
More information is contained in the file
- <file:Documentation/media/v4l-drivers/radiotrack.rst>.
+ <file:Documentation/driver-api/media/drivers/radiotrack.rst>.
To compile this driver as a module, choose M here: the
module will be called radio-aimslab.
USB1.1 and USB2.0 DVB devices.
Almost every USB device needs a firmware, please look into
- <file:Documentation/media/dvb-drivers/dvb-usb.rst>.
+ <file:Documentation/driver-api/media/drivers/dvb-usb.rst>.
For a complete list of supported USB devices see the LinuxTV DVB Wiki:
<https://linuxtv.org/wiki/index.php/DVB_USB>
// SPDX-License-Identifier: GPL-2.0-only
/* DVB USB compliant linux driver for GL861 USB2.0 devices.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include <linux/string.h>
* Copyright (C) 2010 Malcolm Priestley (tvboxspy@gmail.com)
* LME2510(C)(C) Leaguerme (Shenzhen) MicroElectronics Co., Ltd.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*
* Known Issues :
* LME2510: Non Intel USB chipsets fail to maintain High Speed on
* MVB0001F (LME2510C+LGTDQT-P001F)
*
* *
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#ifndef _DVB_USB_LME2510_H_
#define _DVB_USB_LME2510_H_
/*
* Copyright (C) 2010-2014 Michael Krufky (mkrufky@linuxtv.org)
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include <linux/vmalloc.h>
/*
* Copyright (C) 2010-2014 Michael Krufky (mkrufky@linuxtv.org)
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#ifndef _DVB_USB_MXL111SF_H_
USB1.1 and USB2.0 DVB devices.
Almost every USB device needs a firmware, please look into
- <file:Documentation/media/dvb-drivers/dvb-usb.rst>.
+ <file:Documentation/driver-api/media/drivers/dvb-usb.rst>.
For a complete list of supported USB devices see the LinuxTV DVB Wiki:
<https://linuxtv.org/wiki/index.php/DVB_USB>
* - AVerMedia who kindly provided information and
* - Glen Harris who suffered from my mistakes during development.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "dibusb.h"
*
* Thanks to Afatech who kindly provided information.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "af9005.h"
#include "af9005-script.h"
*
* Thanks to Afatech who kindly provided information.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "af9005.h"
/* debug */
*
* Thanks to Afatech who kindly provided information.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "af9005.h"
*
* Thanks to Afatech who kindly provided information.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#ifndef _DVB_USB_AF9005_H_
#define _DVB_USB_AF9005_H_
*
* Copyright (C) 2009 Adams.Xu <adams.xu@azwave.com.cn>
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "az6027.h"
* Copyright (C) 2006, 2007 Chris Pascoe (c.pascoe@itee.uq.edu.au)
* Copyright (C) 2011, 2017 Maciej S. Szmigiero (mail@maciej.szmigiero.name)
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include <media/tuner.h>
#include <linux/delay.h>
*
* Copyright (C) 2004-5 Patrick Boettcher (patrick.boettcher@posteo.de)
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "dibusb.h"
* based on GPL code from DiBcom, which has
* Copyright (C) 2004 Amaury Demol for DiBcom
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "dibusb.h"
*
* Copyright (C) 2004-5 Patrick Boettcher (patrick.boettcher@desy.de)
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "dibusb.h"
* based on GPL code from DiBcom, which has
* Copyright (C) 2004 Amaury Demol for DiBcom
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "dibusb.h"
*
* Copyright (C) 2004-5 Patrick Boettcher (patrick.boettcher@posteo.de)
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#ifndef _DVB_USB_DIBUSB_H_
#define _DVB_USB_DIBUSB_H_
*
* partly based on the SDK published by Nebula Electronics
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "digitv.h"
*
* Copyright (C) 2005 Patrick Boettcher <patrick.boettcher@posteo.de>
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "dtt200u.h"
*
* Thanks to Steve Chang from WideView for providing support for the WT-220U.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "dtt200u.h"
*
* Copyright (C) 2004-5 Patrick Boettcher (patrick.boettcher@posteo.de)
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#ifndef _DVB_USB_DTT200U_H_
#define _DVB_USB_DTT200U_H_
*
* Copyright (C) 2004-6 Patrick Boettcher (patrick.boettcher@posteo.de)
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "dvb-usb-common.h"
* Terratec Cinergy S2 cards
* Copyright (C) 2008-2012 Igor M. Liplianin (liplianin@me.by)
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include <media/dvb-usb-ids.h>
#include "dw2102.h"
*
* This module is based off the vp7045 and vp702x modules
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "gp8psk.h"
#include "gp8psk-fe.h"
*
* This module is based off the vp7045 and vp702x modules
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#ifndef _DVB_USB_GP8PSK_H_
#define _DVB_USB_GP8PSK_H_
*
* Copyright (C) 2006 Aapo Tahkola (aet@rasterburn.org)
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "m920x.h"
*
* Copyright (C) 2004-5 Patrick Boettcher (patrick.boettcher@posteo.de)
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "dibusb.h"
* Copyright (C) 2006 Mario Hlawitschka (dh1pa@amsat.org)
* Copyright (C) 2006 Marco Gittler (g.marco@freenet.de)
*
-* see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+* see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#define DVB_USB_LOG_PREFIX "opera"
* Copyright (c) 2003 Felix Domke <tmbinc@elitedvb.net>
* Copyright (C) 2005-6 Patrick Boettcher <pb@linuxtv.org>
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#define DVB_USB_LOG_PREFIX "ttusb2"
#include "dvb-usb.h"
* Copyright (c) 2003 Felix Domke <tmbinc@elitedvb.net>
* Copyright (C) 2005-6 Patrick Boettcher <pb@linuxtv.de>
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#ifndef _DVB_USB_TTUSB2_H_
#define _DVB_USB_TTUSB2_H_
*
* Copyright (C) 2004-5 Patrick Boettcher (patrick.boettcher@posteo.de)
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "dibusb.h"
* This file can be removed soon, after the DST-driver is rewritten to provice
* the frontend-controlling separately.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "vp702x.h"
*
* Thanks to Twinhan who kindly provided hardware and information.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "vp702x.h"
#include <linux/mutex.h>
*
* Thanks to Twinhan who kindly provided hardware and information.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "vp7045.h"
*
* Thanks to Twinhan who kindly provided hardware and information.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#include "vp7045.h"
*
* Thanks to Twinhan who kindly provided hardware and information.
*
- * see Documentation/media/dvb-drivers/dvb-usb.rst for more information
+ * see Documentation/driver-api/media/drivers/dvb-usb.rst for more information
*/
#ifndef _DVB_USB_VP7045_H_
#define _DVB_USB_VP7045_H_
projects / linux.git / commitdiff