From 577a7ad33aeff86f6c97277b12b122a0a2ad97d7 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 4 Mar 2020 15:54:10 +0100 Subject: media: docs: move driver-specific info to driver-api 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 --- .../driver-api/media/drivers/bttv-devel.rst | 123 + .../driver-api/media/drivers/contributors.rst | 131 + .../driver-api/media/drivers/cpia2_devel.rst | 56 + .../driver-api/media/drivers/cx2341x-devel.rst | 3685 ++++++++++++++++++++ .../driver-api/media/drivers/cx88-devel.rst | 113 + .../media/drivers/davinci-vpbe-devel.rst | 39 + Documentation/driver-api/media/drivers/dvb-usb.rst | 357 ++ .../driver-api/media/drivers/fimc-devel.rst | 33 + .../driver-api/media/drivers/frontends.rst | 32 + Documentation/driver-api/media/drivers/index.rst | 61 + Documentation/driver-api/media/drivers/pvrusb2.rst | 202 ++ .../driver-api/media/drivers/pxa_camera.rst | 194 ++ .../driver-api/media/drivers/radiotrack.rst | 168 + .../driver-api/media/drivers/saa7134-devel.rst | 67 + .../media/drivers/sh_mobile_ceu_camera.rst | 142 + Documentation/driver-api/media/drivers/tuners.rst | 133 + .../driver-api/media/drivers/vimc-devel.rst | 15 + Documentation/driver-api/media/index.rst | 2 + Documentation/media/dvb-drivers/contributors.rst | 131 - Documentation/media/dvb-drivers/dvb-usb.rst | 357 -- Documentation/media/dvb-drivers/frontends.rst | 32 - Documentation/media/dvb-drivers/index.rst | 34 - Documentation/media/index.rst | 1 - Documentation/media/v4l-drivers/bttv-devel.rst | 123 - Documentation/media/v4l-drivers/cpia2_devel.rst | 56 - Documentation/media/v4l-drivers/cx2341x-devel.rst | 3685 -------------------- Documentation/media/v4l-drivers/cx88-devel.rst | 113 - .../media/v4l-drivers/davinci-vpbe-devel.rst | 39 - Documentation/media/v4l-drivers/fimc-devel.rst | 33 - Documentation/media/v4l-drivers/index.rst | 14 - Documentation/media/v4l-drivers/pvrusb2.rst | 202 -- Documentation/media/v4l-drivers/pxa_camera.rst | 194 -- Documentation/media/v4l-drivers/radiotrack.rst | 168 - Documentation/media/v4l-drivers/saa7134-devel.rst | 67 - .../media/v4l-drivers/sh_mobile_ceu_camera.rst | 142 - Documentation/media/v4l-drivers/tuners.rst | 133 - Documentation/media/v4l-drivers/vimc-devel.rst | 15 - MAINTAINERS | 8 +- drivers/media/dvb-frontends/dib3000.h | 2 +- drivers/media/dvb-frontends/dib3000mb.c | 2 +- drivers/media/dvb-frontends/eds1547.h | 2 +- drivers/media/dvb-frontends/z0194a.h | 2 +- drivers/media/pci/cx18/cx18-streams.c | 4 +- drivers/media/platform/pxa_camera.c | 4 +- drivers/media/radio/Kconfig | 2 +- drivers/media/usb/dvb-usb-v2/Kconfig | 2 +- drivers/media/usb/dvb-usb-v2/gl861.c | 2 +- drivers/media/usb/dvb-usb-v2/lmedm04.c | 2 +- drivers/media/usb/dvb-usb-v2/lmedm04.h | 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf.c | 2 +- drivers/media/usb/dvb-usb-v2/mxl111sf.h | 2 +- drivers/media/usb/dvb-usb/Kconfig | 2 +- drivers/media/usb/dvb-usb/a800.c | 2 +- drivers/media/usb/dvb-usb/af9005-fe.c | 2 +- drivers/media/usb/dvb-usb/af9005-remote.c | 2 +- drivers/media/usb/dvb-usb/af9005.c | 2 +- drivers/media/usb/dvb-usb/af9005.h | 2 +- drivers/media/usb/dvb-usb/az6027.c | 2 +- drivers/media/usb/dvb-usb/cxusb.c | 2 +- drivers/media/usb/dvb-usb/dibusb-common.c | 2 +- drivers/media/usb/dvb-usb/dibusb-mb.c | 2 +- drivers/media/usb/dvb-usb/dibusb-mc-common.c | 2 +- drivers/media/usb/dvb-usb/dibusb-mc.c | 2 +- drivers/media/usb/dvb-usb/dibusb.h | 2 +- drivers/media/usb/dvb-usb/digitv.c | 2 +- drivers/media/usb/dvb-usb/dtt200u-fe.c | 2 +- drivers/media/usb/dvb-usb/dtt200u.c | 2 +- drivers/media/usb/dvb-usb/dtt200u.h | 2 +- drivers/media/usb/dvb-usb/dvb-usb-init.c | 2 +- drivers/media/usb/dvb-usb/dw2102.c | 2 +- drivers/media/usb/dvb-usb/gp8psk.c | 2 +- drivers/media/usb/dvb-usb/gp8psk.h | 2 +- drivers/media/usb/dvb-usb/m920x.c | 2 +- drivers/media/usb/dvb-usb/nova-t-usb2.c | 2 +- drivers/media/usb/dvb-usb/opera1.c | 2 +- drivers/media/usb/dvb-usb/ttusb2.c | 2 +- drivers/media/usb/dvb-usb/ttusb2.h | 2 +- drivers/media/usb/dvb-usb/umt-010.c | 2 +- drivers/media/usb/dvb-usb/vp702x-fe.c | 2 +- drivers/media/usb/dvb-usb/vp702x.c | 2 +- drivers/media/usb/dvb-usb/vp7045-fe.c | 2 +- drivers/media/usb/dvb-usb/vp7045.c | 2 +- drivers/media/usb/dvb-usb/vp7045.h | 2 +- 83 files changed, 5604 insertions(+), 5590 deletions(-) create mode 100644 Documentation/driver-api/media/drivers/bttv-devel.rst create mode 100644 Documentation/driver-api/media/drivers/contributors.rst create mode 100644 Documentation/driver-api/media/drivers/cpia2_devel.rst create mode 100644 Documentation/driver-api/media/drivers/cx2341x-devel.rst create mode 100644 Documentation/driver-api/media/drivers/cx88-devel.rst create mode 100644 Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst create mode 100644 Documentation/driver-api/media/drivers/dvb-usb.rst create mode 100644 Documentation/driver-api/media/drivers/fimc-devel.rst create mode 100644 Documentation/driver-api/media/drivers/frontends.rst create mode 100644 Documentation/driver-api/media/drivers/index.rst create mode 100644 Documentation/driver-api/media/drivers/pvrusb2.rst create mode 100644 Documentation/driver-api/media/drivers/pxa_camera.rst create mode 100644 Documentation/driver-api/media/drivers/radiotrack.rst create mode 100644 Documentation/driver-api/media/drivers/saa7134-devel.rst create mode 100644 Documentation/driver-api/media/drivers/sh_mobile_ceu_camera.rst create mode 100644 Documentation/driver-api/media/drivers/tuners.rst create mode 100644 Documentation/driver-api/media/drivers/vimc-devel.rst delete mode 100644 Documentation/media/dvb-drivers/contributors.rst delete mode 100644 Documentation/media/dvb-drivers/dvb-usb.rst delete mode 100644 Documentation/media/dvb-drivers/frontends.rst delete mode 100644 Documentation/media/dvb-drivers/index.rst delete mode 100644 Documentation/media/v4l-drivers/bttv-devel.rst delete mode 100644 Documentation/media/v4l-drivers/cpia2_devel.rst delete mode 100644 Documentation/media/v4l-drivers/cx2341x-devel.rst delete mode 100644 Documentation/media/v4l-drivers/cx88-devel.rst delete mode 100644 Documentation/media/v4l-drivers/davinci-vpbe-devel.rst delete mode 100644 Documentation/media/v4l-drivers/fimc-devel.rst delete mode 100644 Documentation/media/v4l-drivers/pvrusb2.rst delete mode 100644 Documentation/media/v4l-drivers/pxa_camera.rst delete mode 100644 Documentation/media/v4l-drivers/radiotrack.rst delete mode 100644 Documentation/media/v4l-drivers/saa7134-devel.rst delete mode 100644 Documentation/media/v4l-drivers/sh_mobile_ceu_camera.rst delete mode 100644 Documentation/media/v4l-drivers/tuners.rst delete mode 100644 Documentation/media/v4l-drivers/vimc-devel.rst diff --git a/Documentation/driver-api/media/drivers/bttv-devel.rst b/Documentation/driver-api/media/drivers/bttv-devel.rst new file mode 100644 index 000000000000..396fad572c93 --- /dev/null +++ b/Documentation/driver-api/media/drivers/bttv-devel.rst @@ -0,0 +1,123 @@ +.. 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 diff --git a/Documentation/driver-api/media/drivers/contributors.rst b/Documentation/driver-api/media/drivers/contributors.rst new file mode 100644 index 000000000000..f23b6e6faf46 --- /dev/null +++ b/Documentation/driver-api/media/drivers/contributors.rst @@ -0,0 +1,131 @@ +.. 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 + + - for the initial saa7146 driver and its recent overhaul + +- Christian Theiss + + - for his work on the initial Linux DVB driver + +- Marcus Metzler and + Ralph Metzler + + - for their continuing work on the DVB driver + +- Michael Holzt + + - for his contributions to the dvb-net driver + +- Diego Picciani + + - 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 + + - for patching the cable card decoder driver + +- Klaus Schmidinger + + - for various fixes regarding tuning, OSD and CI stuff and his work on VDR + +- Steve Brown + + - for his AFC kernel thread + +- Christoph Martin + + - for his LIRC infrared handler + +- Andreas Oberritter , + Dennis Noermann , + Felix Domke , + Florian Schirmer , + Ronny Strutz <3des@elitedvb.de>, + Wolfram Joost + 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 + + - for many bugfixes + +- Andrew de Quincey + + - for the tda1004x frontend driver, and various bugfixes + +- Peter Schildmann + + - for the driver for the Technisat SkyStar2 PCI DVB card + +- Vadim Catana , + Roberto Ragusa and + Augusto Cardoso + + - for all the work for the FlexCopII chipset by B2C2,Inc. + +- Davor Emard + + - for his work on the budget drivers, the demux code, + the module unloading problems, ... + +- Hans-Frieder Vogt + + - for his work on calculating and checking the crc's for the + TechnoTrend/Hauppauge DEC driver firmware + +- Michael Dreher and + Andreas 'randy' Weinberger + + - for the support of the Fujitsu-Siemens Activy budget DVB-S + +- Kenneth Aafløy + + - for adding support for Typhoon DVB-S budget card + +- Ernst Peinlich + + - for tuning/DiSEqC support for the DEC 3000-s + +- Peter Beutner + + - for the IR code for the ttusb-dec driver + +- Wilson Michaels + + - for the lgdt330x frontend driver, and various bugfixes + +- Michael Krufky + + - for maintaining v4l/dvb inter-tree dependencies + +- Taylor Jacob + + - for the nxt2002 frontend driver + +- Jean-Francois Thibert + + - for the nxt2004 frontend driver + +- Kirk Lapray + + - 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) diff --git a/Documentation/driver-api/media/drivers/cpia2_devel.rst b/Documentation/driver-api/media/drivers/cpia2_devel.rst new file mode 100644 index 000000000000..decaa4768c78 --- /dev/null +++ b/Documentation/driver-api/media/drivers/cpia2_devel.rst @@ -0,0 +1,56 @@ +.. SPDX-License-Identifier: GPL-2.0 + +The cpia2 driver +================ + +Authors: Peter Pregler , +Scott J. Bertin , and +Jarl Totland 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. diff --git a/Documentation/driver-api/media/drivers/cx2341x-devel.rst b/Documentation/driver-api/media/drivers/cx2341x-devel.rst new file mode 100644 index 000000000000..97699df6ea2e --- /dev/null +++ b/Documentation/driver-api/media/drivers/cx2341x-devel.rst @@ -0,0 +1,3685 @@ +.. 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 + +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 diff --git a/Documentation/driver-api/media/drivers/cx88-devel.rst b/Documentation/driver-api/media/drivers/cx88-devel.rst new file mode 100644 index 000000000000..cfe7c03f4930 --- /dev/null +++ b/Documentation/driver-api/media/drivers/cx88-devel.rst @@ -0,0 +1,113 @@ +.. 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 diff --git a/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst b/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst new file mode 100644 index 000000000000..f0961672e6a3 --- /dev/null +++ b/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst @@ -0,0 +1,39 @@ +.. 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. diff --git a/Documentation/driver-api/media/drivers/dvb-usb.rst b/Documentation/driver-api/media/drivers/dvb-usb.rst new file mode 100644 index 000000000000..b2d5d9e62b30 --- /dev/null +++ b/Documentation/driver-api/media/drivers/dvb-usb.rst @@ -0,0 +1,357 @@ +.. 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= + modprobe dvb-usb-vp7045 debug= + 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. diff --git a/Documentation/driver-api/media/drivers/fimc-devel.rst b/Documentation/driver-api/media/drivers/fimc-devel.rst new file mode 100644 index 000000000000..956e3a9901f8 --- /dev/null +++ b/Documentation/driver-api/media/drivers/fimc-devel.rst @@ -0,0 +1,33 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: + +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 diff --git a/Documentation/driver-api/media/drivers/frontends.rst b/Documentation/driver-api/media/drivers/frontends.rst new file mode 100644 index 000000000000..7b8336ece681 --- /dev/null +++ b/Documentation/driver-api/media/drivers/frontends.rst @@ -0,0 +1,32 @@ +.. 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 + diff --git a/Documentation/driver-api/media/drivers/index.rst b/Documentation/driver-api/media/drivers/index.rst new file mode 100644 index 000000000000..aafff51f7e0e --- /dev/null +++ b/Documentation/driver-api/media/drivers/index.rst @@ -0,0 +1,61 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: + +################################################ +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 diff --git a/Documentation/driver-api/media/drivers/pvrusb2.rst b/Documentation/driver-api/media/drivers/pvrusb2.rst new file mode 100644 index 000000000000..83bfaa531ea8 --- /dev/null +++ b/Documentation/driver-api/media/drivers/pvrusb2.rst @@ -0,0 +1,202 @@ +.. SPDX-License-Identifier: GPL-2.0 + +The pvrusb2 driver +================== + +Author: Mike Isely + +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 whose web page can be found here: +http://pvrusb2.dax.nu/ + +From there Aurelien Alleaume 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). diff --git a/Documentation/driver-api/media/drivers/pxa_camera.rst b/Documentation/driver-api/media/drivers/pxa_camera.rst new file mode 100644 index 000000000000..ee1bd96b66dd --- /dev/null +++ b/Documentation/driver-api/media/drivers/pxa_camera.rst @@ -0,0 +1,194 @@ +.. SPDX-License-Identifier: GPL-2.0 + +PXA-Camera Host Driver +====================== + +Author: Robert Jarzmik + +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. diff --git a/Documentation/driver-api/media/drivers/radiotrack.rst b/Documentation/driver-api/media/drivers/radiotrack.rst new file mode 100644 index 000000000000..a85cb6205db8 --- /dev/null +++ b/Documentation/driver-api/media/drivers/radiotrack.rst @@ -0,0 +1,168 @@ +.. SPDX-License-Identifier: GPL-2.0 + +The Radiotrack radio driver +=========================== + +Author: Stephen M. Benoit + +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) diff --git a/Documentation/driver-api/media/drivers/saa7134-devel.rst b/Documentation/driver-api/media/drivers/saa7134-devel.rst new file mode 100644 index 000000000000..167fd729bc8c --- /dev/null +++ b/Documentation/driver-api/media/drivers/saa7134-devel.rst @@ -0,0 +1,67 @@ +.. 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 + +- 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. diff --git a/Documentation/driver-api/media/drivers/sh_mobile_ceu_camera.rst b/Documentation/driver-api/media/drivers/sh_mobile_ceu_camera.rst new file mode 100644 index 000000000000..822fcb8368ae --- /dev/null +++ b/Documentation/driver-api/media/drivers/sh_mobile_ceu_camera.rst @@ -0,0 +1,142 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Cropping and Scaling algorithm, used in the sh_mobile_ceu_camera driver +======================================================================= + +Author: Guennadi Liakhovetski + +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 ` 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) diff --git a/Documentation/driver-api/media/drivers/tuners.rst b/Documentation/driver-api/media/drivers/tuners.rst new file mode 100644 index 000000000000..7509be888909 --- /dev/null +++ b/Documentation/driver-api/media/drivers/tuners.rst @@ -0,0 +1,133 @@ +.. 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 diff --git a/Documentation/driver-api/media/drivers/vimc-devel.rst b/Documentation/driver-api/media/drivers/vimc-devel.rst new file mode 100644 index 000000000000..b2aa2ee79205 --- /dev/null +++ b/Documentation/driver-api/media/drivers/vimc-devel.rst @@ -0,0 +1,15 @@ +.. 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 diff --git a/Documentation/driver-api/media/index.rst b/Documentation/driver-api/media/index.rst index d2842f300bbd..57383df79bd3 100644 --- a/Documentation/driver-api/media/index.rst +++ b/Documentation/driver-api/media/index.rst @@ -36,3 +36,5 @@ For more details see the file COPYING in the source distribution of Linux. mc-core cec-core csi2 + + drivers/index diff --git a/Documentation/media/dvb-drivers/contributors.rst b/Documentation/media/dvb-drivers/contributors.rst deleted file mode 100644 index f23b6e6faf46..000000000000 --- a/Documentation/media/dvb-drivers/contributors.rst +++ /dev/null @@ -1,131 +0,0 @@ -.. 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 - - - for the initial saa7146 driver and its recent overhaul - -- Christian Theiss - - - for his work on the initial Linux DVB driver - -- Marcus Metzler and - Ralph Metzler - - - for their continuing work on the DVB driver - -- Michael Holzt - - - for his contributions to the dvb-net driver - -- Diego Picciani - - - 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 - - - for patching the cable card decoder driver - -- Klaus Schmidinger - - - for various fixes regarding tuning, OSD and CI stuff and his work on VDR - -- Steve Brown - - - for his AFC kernel thread - -- Christoph Martin - - - for his LIRC infrared handler - -- Andreas Oberritter , - Dennis Noermann , - Felix Domke , - Florian Schirmer , - Ronny Strutz <3des@elitedvb.de>, - Wolfram Joost - 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 - - - for many bugfixes - -- Andrew de Quincey - - - for the tda1004x frontend driver, and various bugfixes - -- Peter Schildmann - - - for the driver for the Technisat SkyStar2 PCI DVB card - -- Vadim Catana , - Roberto Ragusa and - Augusto Cardoso - - - for all the work for the FlexCopII chipset by B2C2,Inc. - -- Davor Emard - - - for his work on the budget drivers, the demux code, - the module unloading problems, ... - -- Hans-Frieder Vogt - - - for his work on calculating and checking the crc's for the - TechnoTrend/Hauppauge DEC driver firmware - -- Michael Dreher and - Andreas 'randy' Weinberger - - - for the support of the Fujitsu-Siemens Activy budget DVB-S - -- Kenneth Aafløy - - - for adding support for Typhoon DVB-S budget card - -- Ernst Peinlich - - - for tuning/DiSEqC support for the DEC 3000-s - -- Peter Beutner - - - for the IR code for the ttusb-dec driver - -- Wilson Michaels - - - for the lgdt330x frontend driver, and various bugfixes - -- Michael Krufky - - - for maintaining v4l/dvb inter-tree dependencies - -- Taylor Jacob - - - for the nxt2002 frontend driver - -- Jean-Francois Thibert - - - for the nxt2004 frontend driver - -- Kirk Lapray - - - 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) diff --git a/Documentation/media/dvb-drivers/dvb-usb.rst b/Documentation/media/dvb-drivers/dvb-usb.rst deleted file mode 100644 index b2d5d9e62b30..000000000000 --- a/Documentation/media/dvb-drivers/dvb-usb.rst +++ /dev/null @@ -1,357 +0,0 @@ -.. 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= - modprobe dvb-usb-vp7045 debug= - 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. diff --git a/Documentation/media/dvb-drivers/frontends.rst b/Documentation/media/dvb-drivers/frontends.rst deleted file mode 100644 index 7b8336ece681..000000000000 --- a/Documentation/media/dvb-drivers/frontends.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. 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 - diff --git a/Documentation/media/dvb-drivers/index.rst b/Documentation/media/dvb-drivers/index.rst deleted file mode 100644 index 7a870ee7ac7d..000000000000 --- a/Documentation/media/dvb-drivers/index.rst +++ /dev/null @@ -1,34 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -.. include:: - -############################################## -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 diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst index 0f75280b8c43..a5cd600e0b04 100644 --- a/Documentation/media/index.rst +++ b/Documentation/media/index.rst @@ -16,7 +16,6 @@ Linux Media Subsystem Documentation ../driver-api/media/index v4l-drivers/index - dvb-drivers/index .. only:: html and subproject diff --git a/Documentation/media/v4l-drivers/bttv-devel.rst b/Documentation/media/v4l-drivers/bttv-devel.rst deleted file mode 100644 index 396fad572c93..000000000000 --- a/Documentation/media/v4l-drivers/bttv-devel.rst +++ /dev/null @@ -1,123 +0,0 @@ -.. 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 diff --git a/Documentation/media/v4l-drivers/cpia2_devel.rst b/Documentation/media/v4l-drivers/cpia2_devel.rst deleted file mode 100644 index decaa4768c78..000000000000 --- a/Documentation/media/v4l-drivers/cpia2_devel.rst +++ /dev/null @@ -1,56 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -The cpia2 driver -================ - -Authors: Peter Pregler , -Scott J. Bertin , and -Jarl Totland 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. diff --git a/Documentation/media/v4l-drivers/cx2341x-devel.rst b/Documentation/media/v4l-drivers/cx2341x-devel.rst deleted file mode 100644 index 97699df6ea2e..000000000000 --- a/Documentation/media/v4l-drivers/cx2341x-devel.rst +++ /dev/null @@ -1,3685 +0,0 @@ -.. 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 - -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 diff --git a/Documentation/media/v4l-drivers/cx88-devel.rst b/Documentation/media/v4l-drivers/cx88-devel.rst deleted file mode 100644 index cfe7c03f4930..000000000000 --- a/Documentation/media/v4l-drivers/cx88-devel.rst +++ /dev/null @@ -1,113 +0,0 @@ -.. 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 diff --git a/Documentation/media/v4l-drivers/davinci-vpbe-devel.rst b/Documentation/media/v4l-drivers/davinci-vpbe-devel.rst deleted file mode 100644 index f0961672e6a3..000000000000 --- a/Documentation/media/v4l-drivers/davinci-vpbe-devel.rst +++ /dev/null @@ -1,39 +0,0 @@ -.. 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. diff --git a/Documentation/media/v4l-drivers/fimc-devel.rst b/Documentation/media/v4l-drivers/fimc-devel.rst deleted file mode 100644 index 956e3a9901f8..000000000000 --- a/Documentation/media/v4l-drivers/fimc-devel.rst +++ /dev/null @@ -1,33 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -.. include:: - -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 diff --git a/Documentation/media/v4l-drivers/index.rst b/Documentation/media/v4l-drivers/index.rst index aef375cfb05a..ee7faff88a33 100644 --- a/Documentation/media/v4l-drivers/index.rst +++ b/Documentation/media/v4l-drivers/index.rst @@ -31,23 +31,9 @@ For more details see the file COPYING in the source distribution of Linux. :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 diff --git a/Documentation/media/v4l-drivers/pvrusb2.rst b/Documentation/media/v4l-drivers/pvrusb2.rst deleted file mode 100644 index 83bfaa531ea8..000000000000 --- a/Documentation/media/v4l-drivers/pvrusb2.rst +++ /dev/null @@ -1,202 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -The pvrusb2 driver -================== - -Author: Mike Isely - -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 whose web page can be found here: -http://pvrusb2.dax.nu/ - -From there Aurelien Alleaume 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). diff --git a/Documentation/media/v4l-drivers/pxa_camera.rst b/Documentation/media/v4l-drivers/pxa_camera.rst deleted file mode 100644 index ee1bd96b66dd..000000000000 --- a/Documentation/media/v4l-drivers/pxa_camera.rst +++ /dev/null @@ -1,194 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -PXA-Camera Host Driver -====================== - -Author: Robert Jarzmik - -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. diff --git a/Documentation/media/v4l-drivers/radiotrack.rst b/Documentation/media/v4l-drivers/radiotrack.rst deleted file mode 100644 index a85cb6205db8..000000000000 --- a/Documentation/media/v4l-drivers/radiotrack.rst +++ /dev/null @@ -1,168 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -The Radiotrack radio driver -=========================== - -Author: Stephen M. Benoit - -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) diff --git a/Documentation/media/v4l-drivers/saa7134-devel.rst b/Documentation/media/v4l-drivers/saa7134-devel.rst deleted file mode 100644 index 167fd729bc8c..000000000000 --- a/Documentation/media/v4l-drivers/saa7134-devel.rst +++ /dev/null @@ -1,67 +0,0 @@ -.. 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 - -- 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. diff --git a/Documentation/media/v4l-drivers/sh_mobile_ceu_camera.rst b/Documentation/media/v4l-drivers/sh_mobile_ceu_camera.rst deleted file mode 100644 index 822fcb8368ae..000000000000 --- a/Documentation/media/v4l-drivers/sh_mobile_ceu_camera.rst +++ /dev/null @@ -1,142 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -Cropping and Scaling algorithm, used in the sh_mobile_ceu_camera driver -======================================================================= - -Author: Guennadi Liakhovetski - -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 ` 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) diff --git a/Documentation/media/v4l-drivers/tuners.rst b/Documentation/media/v4l-drivers/tuners.rst deleted file mode 100644 index 7509be888909..000000000000 --- a/Documentation/media/v4l-drivers/tuners.rst +++ /dev/null @@ -1,133 +0,0 @@ -.. 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 diff --git a/Documentation/media/v4l-drivers/vimc-devel.rst b/Documentation/media/v4l-drivers/vimc-devel.rst deleted file mode 100644 index b2aa2ee79205..000000000000 --- a/Documentation/media/v4l-drivers/vimc-devel.rst +++ /dev/null @@ -1,15 +0,0 @@ -.. 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 diff --git a/MAINTAINERS b/MAINTAINERS index abe6a64183fa..e0a0a3fbfe21 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3667,7 +3667,7 @@ L: linux-media@vger.kernel.org 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 @@ -4539,7 +4539,7 @@ L: linux-media@vger.kernel.org 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 @@ -13711,7 +13711,7 @@ L: linux-media@vger.kernel.org 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 @@ -14720,7 +14720,7 @@ L: linux-media@vger.kernel.org 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 diff --git a/drivers/media/dvb-frontends/dib3000.h b/drivers/media/dvb-frontends/dib3000.h index 9118a7a48ef2..3f129efa21de 100644 --- a/drivers/media/dvb-frontends/dib3000.h +++ b/drivers/media/dvb-frontends/dib3000.h @@ -14,7 +14,7 @@ * 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 diff --git a/drivers/media/dvb-frontends/dib3000mb.c b/drivers/media/dvb-frontends/dib3000mb.c index 46ed0e20c8fa..0f0480d8576d 100644 --- a/drivers/media/dvb-frontends/dib3000mb.c +++ b/drivers/media/dvb-frontends/dib3000mb.c @@ -14,7 +14,7 @@ * 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 diff --git a/drivers/media/dvb-frontends/eds1547.h b/drivers/media/dvb-frontends/eds1547.h index 907254b85708..bb85a6e27076 100644 --- a/drivers/media/dvb-frontends/eds1547.h +++ b/drivers/media/dvb-frontends/eds1547.h @@ -3,7 +3,7 @@ * * 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 diff --git a/drivers/media/dvb-frontends/z0194a.h b/drivers/media/dvb-frontends/z0194a.h index 21442905d116..3446ccbf3c1c 100644 --- a/drivers/media/dvb-frontends/z0194a.h +++ b/drivers/media/dvb-frontends/z0194a.h @@ -3,7 +3,7 @@ * * 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 diff --git a/drivers/media/pci/cx18/cx18-streams.c b/drivers/media/pci/cx18/cx18-streams.c index 0e2365c9f4ad..c41bae118415 100644 --- a/drivers/media/pci/cx18/cx18-streams.c +++ b/drivers/media/pci/cx18/cx18-streams.c @@ -845,7 +845,7 @@ int cx18_start_v4l2_encode_stream(struct cx18_stream *s) /* * 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, @@ -853,7 +853,7 @@ int cx18_start_v4l2_encode_stream(struct cx18_stream *s) /* * 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 */ diff --git a/drivers/media/platform/pxa_camera.c b/drivers/media/platform/pxa_camera.c index 70c85a2a10f5..3c5fe737d36f 100644 --- a/drivers/media/platform/pxa_camera.c +++ b/drivers/media/platform/pxa_camera.c @@ -1016,7 +1016,7 @@ static void pxa_camera_wakeup(struct pxa_camera_dev *pcdev, * - 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 */ @@ -1438,7 +1438,7 @@ static void pxac_vb2_queue(struct vb2_buffer *vb) /* * 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. */ diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index f4df16df19d9..d29e29645e04 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -272,7 +272,7 @@ config RADIO_RTRACK been reported to be used by these cards. More information is contained in the file - . + . To compile this driver as a module, choose M here: the module will be called radio-aimslab. diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig b/drivers/media/usb/dvb-usb-v2/Kconfig index b21a4d413872..ff0ae64424c4 100644 --- a/drivers/media/usb/dvb-usb-v2/Kconfig +++ b/drivers/media/usb/dvb-usb-v2/Kconfig @@ -7,7 +7,7 @@ config DVB_USB_V2 USB1.1 and USB2.0 DVB devices. Almost every USB device needs a firmware, please look into - . + . For a complete list of supported USB devices see the LinuxTV DVB Wiki: diff --git a/drivers/media/usb/dvb-usb-v2/gl861.c b/drivers/media/usb/dvb-usb-v2/gl861.c index 19217dcf20f1..42c3b8af0774 100644 --- a/drivers/media/usb/dvb-usb-v2/gl861.c +++ b/drivers/media/usb/dvb-usb-v2/gl861.c @@ -1,7 +1,7 @@ // 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 diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c b/drivers/media/usb/dvb-usb-v2/lmedm04.c index fb8280620c58..8a3c0eeed959 100644 --- a/drivers/media/usb/dvb-usb-v2/lmedm04.c +++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c @@ -39,7 +39,7 @@ * 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 diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.h b/drivers/media/usb/dvb-usb-v2/lmedm04.h index 766a8348624d..4335b6ebcc1c 100644 --- a/drivers/media/usb/dvb-usb-v2/lmedm04.h +++ b/drivers/media/usb/dvb-usb-v2/lmedm04.h @@ -14,7 +14,7 @@ * 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_ diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c b/drivers/media/usb/dvb-usb-v2/mxl111sf.c index 55b4ae7037a4..7865fa0a8295 100644 --- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c @@ -2,7 +2,7 @@ /* * 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 diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.h b/drivers/media/usb/dvb-usb-v2/mxl111sf.h index 70bd2a2a8ec1..e57e5d2353b4 100644 --- a/drivers/media/usb/dvb-usb-v2/mxl111sf.h +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.h @@ -2,7 +2,7 @@ /* * 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_ diff --git a/drivers/media/usb/dvb-usb/Kconfig b/drivers/media/usb/dvb-usb/Kconfig index 42334a02cdce..15d29c91662f 100644 --- a/drivers/media/usb/dvb-usb/Kconfig +++ b/drivers/media/usb/dvb-usb/Kconfig @@ -8,7 +8,7 @@ config DVB_USB USB1.1 and USB2.0 DVB devices. Almost every USB device needs a firmware, please look into - . + . For a complete list of supported USB devices see the LinuxTV DVB Wiki: diff --git a/drivers/media/usb/dvb-usb/a800.c b/drivers/media/usb/dvb-usb/a800.c index 666213f5d5d8..15bbefe3bc00 100644 --- a/drivers/media/usb/dvb-usb/a800.c +++ b/drivers/media/usb/dvb-usb/a800.c @@ -8,7 +8,7 @@ * - 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" diff --git a/drivers/media/usb/dvb-usb/af9005-fe.c b/drivers/media/usb/dvb-usb/af9005-fe.c index 6c960f723457..9d6fa0556d7b 100644 --- a/drivers/media/usb/dvb-usb/af9005-fe.c +++ b/drivers/media/usb/dvb-usb/af9005-fe.c @@ -6,7 +6,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/af9005-remote.c b/drivers/media/usb/dvb-usb/af9005-remote.c index c664353f3911..41d48b3c8d05 100644 --- a/drivers/media/usb/dvb-usb/af9005-remote.c +++ b/drivers/media/usb/dvb-usb/af9005-remote.c @@ -8,7 +8,7 @@ * * 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 */ diff --git a/drivers/media/usb/dvb-usb/af9005.c b/drivers/media/usb/dvb-usb/af9005.c index 89b4b5d84cdf..3446bcac8ed1 100644 --- a/drivers/media/usb/dvb-usb/af9005.c +++ b/drivers/media/usb/dvb-usb/af9005.c @@ -6,7 +6,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/af9005.h b/drivers/media/usb/dvb-usb/af9005.h index 3179a7c71e8f..11d74dc26d83 100644 --- a/drivers/media/usb/dvb-usb/af9005.h +++ b/drivers/media/usb/dvb-usb/af9005.h @@ -6,7 +6,7 @@ * * 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_ diff --git a/drivers/media/usb/dvb-usb/az6027.c b/drivers/media/usb/dvb-usb/az6027.c index 8de18da0c4bd..d5be540e31a7 100644 --- a/drivers/media/usb/dvb-usb/az6027.c +++ b/drivers/media/usb/dvb-usb/az6027.c @@ -4,7 +4,7 @@ * * Copyright (C) 2009 Adams.Xu * - * 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" diff --git a/drivers/media/usb/dvb-usb/cxusb.c b/drivers/media/usb/dvb-usb/cxusb.c index c421b603be44..fd058f71ce49 100644 --- a/drivers/media/usb/dvb-usb/cxusb.c +++ b/drivers/media/usb/dvb-usb/cxusb.c @@ -18,7 +18,7 @@ * 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 #include diff --git a/drivers/media/usb/dvb-usb/dibusb-common.c b/drivers/media/usb/dvb-usb/dibusb-common.c index 59ce2dec11e9..02b51d1a1b67 100644 --- a/drivers/media/usb/dvb-usb/dibusb-common.c +++ b/drivers/media/usb/dvb-usb/dibusb-common.c @@ -3,7 +3,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/dibusb-mb.c b/drivers/media/usb/dvb-usb/dibusb-mb.c index d4ea72bf09c5..f462c918d5a4 100644 --- a/drivers/media/usb/dvb-usb/dibusb-mb.c +++ b/drivers/media/usb/dvb-usb/dibusb-mb.c @@ -7,7 +7,7 @@ * 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" diff --git a/drivers/media/usb/dvb-usb/dibusb-mc-common.c b/drivers/media/usb/dvb-usb/dibusb-mc-common.c index 967027e29c17..b8cde4cded33 100644 --- a/drivers/media/usb/dvb-usb/dibusb-mc-common.c +++ b/drivers/media/usb/dvb-usb/dibusb-mc-common.c @@ -3,7 +3,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/dibusb-mc.c b/drivers/media/usb/dvb-usb/dibusb-mc.c index ada3bee296c2..e2689977c8c8 100644 --- a/drivers/media/usb/dvb-usb/dibusb-mc.c +++ b/drivers/media/usb/dvb-usb/dibusb-mc.c @@ -7,7 +7,7 @@ * 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" diff --git a/drivers/media/usb/dvb-usb/dibusb.h b/drivers/media/usb/dvb-usb/dibusb.h index a83326c36ca7..f61de0744821 100644 --- a/drivers/media/usb/dvb-usb/dibusb.h +++ b/drivers/media/usb/dvb-usb/dibusb.h @@ -3,7 +3,7 @@ * * 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_ diff --git a/drivers/media/usb/dvb-usb/digitv.c b/drivers/media/usb/dvb-usb/digitv.c index 99a39339d45d..906438c5a40f 100644 --- a/drivers/media/usb/dvb-usb/digitv.c +++ b/drivers/media/usb/dvb-usb/digitv.c @@ -6,7 +6,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/dtt200u-fe.c b/drivers/media/usb/dvb-usb/dtt200u-fe.c index 00ce723c7bf0..9f83560ba63d 100644 --- a/drivers/media/usb/dvb-usb/dtt200u-fe.c +++ b/drivers/media/usb/dvb-usb/dtt200u-fe.c @@ -4,7 +4,7 @@ * * Copyright (C) 2005 Patrick Boettcher * - * 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" diff --git a/drivers/media/usb/dvb-usb/dtt200u.c b/drivers/media/usb/dvb-usb/dtt200u.c index 1e7296b2e5b2..24efa023d827 100644 --- a/drivers/media/usb/dvb-usb/dtt200u.c +++ b/drivers/media/usb/dvb-usb/dtt200u.c @@ -6,7 +6,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/dtt200u.h b/drivers/media/usb/dvb-usb/dtt200u.h index 832f355114e4..696c2c1f3af3 100644 --- a/drivers/media/usb/dvb-usb/dtt200u.h +++ b/drivers/media/usb/dvb-usb/dtt200u.h @@ -4,7 +4,7 @@ * * 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_ diff --git a/drivers/media/usb/dvb-usb/dvb-usb-init.c b/drivers/media/usb/dvb-usb/dvb-usb-init.c index 16a0b4a359ea..46ada09ce38a 100644 --- a/drivers/media/usb/dvb-usb/dvb-usb-init.c +++ b/drivers/media/usb/dvb-usb/dvb-usb-init.c @@ -6,7 +6,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/dw2102.c b/drivers/media/usb/dvb-usb/dw2102.c index 1007366a295b..594a763b46cf 100644 --- a/drivers/media/usb/dvb-usb/dw2102.c +++ b/drivers/media/usb/dvb-usb/dw2102.c @@ -8,7 +8,7 @@ * 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 #include "dw2102.h" diff --git a/drivers/media/usb/dvb-usb/gp8psk.c b/drivers/media/usb/dvb-usb/gp8psk.c index 1282f701f185..c07f46f5176e 100644 --- a/drivers/media/usb/dvb-usb/gp8psk.c +++ b/drivers/media/usb/dvb-usb/gp8psk.c @@ -9,7 +9,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/gp8psk.h b/drivers/media/usb/dvb-usb/gp8psk.h index 2f4c1368eabe..5293dfdd2609 100644 --- a/drivers/media/usb/dvb-usb/gp8psk.h +++ b/drivers/media/usb/dvb-usb/gp8psk.h @@ -9,7 +9,7 @@ * * 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_ diff --git a/drivers/media/usb/dvb-usb/m920x.c b/drivers/media/usb/dvb-usb/m920x.c index d866a1990a7d..b8b99be5564b 100644 --- a/drivers/media/usb/dvb-usb/m920x.c +++ b/drivers/media/usb/dvb-usb/m920x.c @@ -3,7 +3,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/nova-t-usb2.c b/drivers/media/usb/dvb-usb/nova-t-usb2.c index e368935a5089..e7b290552b66 100644 --- a/drivers/media/usb/dvb-usb/nova-t-usb2.c +++ b/drivers/media/usb/dvb-usb/nova-t-usb2.c @@ -4,7 +4,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/opera1.c b/drivers/media/usb/dvb-usb/opera1.c index 823b33ae828d..e8d784b9d119 100644 --- a/drivers/media/usb/dvb-usb/opera1.c +++ b/drivers/media/usb/dvb-usb/opera1.c @@ -4,7 +4,7 @@ * 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" diff --git a/drivers/media/usb/dvb-usb/ttusb2.c b/drivers/media/usb/dvb-usb/ttusb2.c index e12a5466b677..fd3e7312daef 100644 --- a/drivers/media/usb/dvb-usb/ttusb2.c +++ b/drivers/media/usb/dvb-usb/ttusb2.c @@ -17,7 +17,7 @@ * Copyright (c) 2003 Felix Domke * Copyright (C) 2005-6 Patrick Boettcher * - * 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" diff --git a/drivers/media/usb/dvb-usb/ttusb2.h b/drivers/media/usb/dvb-usb/ttusb2.h index 8a3853cd6a26..b34c469d83f9 100644 --- a/drivers/media/usb/dvb-usb/ttusb2.h +++ b/drivers/media/usb/dvb-usb/ttusb2.h @@ -6,7 +6,7 @@ * Copyright (c) 2003 Felix Domke * Copyright (C) 2005-6 Patrick Boettcher * - * 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_ diff --git a/drivers/media/usb/dvb-usb/umt-010.c b/drivers/media/usb/dvb-usb/umt-010.c index a2101bd43349..2181993771ae 100644 --- a/drivers/media/usb/dvb-usb/umt-010.c +++ b/drivers/media/usb/dvb-usb/umt-010.c @@ -4,7 +4,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/vp702x-fe.c b/drivers/media/usb/dvb-usb/vp702x-fe.c index 1c75a9c9dfca..c1e7931900ee 100644 --- a/drivers/media/usb/dvb-usb/vp702x-fe.c +++ b/drivers/media/usb/dvb-usb/vp702x-fe.c @@ -12,7 +12,7 @@ * 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" diff --git a/drivers/media/usb/dvb-usb/vp702x.c b/drivers/media/usb/dvb-usb/vp702x.c index 381b5c898a07..bf54747e2e01 100644 --- a/drivers/media/usb/dvb-usb/vp702x.c +++ b/drivers/media/usb/dvb-usb/vp702x.c @@ -9,7 +9,7 @@ * * 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 diff --git a/drivers/media/usb/dvb-usb/vp7045-fe.c b/drivers/media/usb/dvb-usb/vp7045-fe.c index d253307a35f8..e99740ec2650 100644 --- a/drivers/media/usb/dvb-usb/vp7045-fe.c +++ b/drivers/media/usb/dvb-usb/vp7045-fe.c @@ -6,7 +6,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/vp7045.c b/drivers/media/usb/dvb-usb/vp7045.c index 2baf57216d19..23e3a90af1f4 100644 --- a/drivers/media/usb/dvb-usb/vp7045.c +++ b/drivers/media/usb/dvb-usb/vp7045.c @@ -7,7 +7,7 @@ * * 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" diff --git a/drivers/media/usb/dvb-usb/vp7045.h b/drivers/media/usb/dvb-usb/vp7045.h index 818366746c41..1c8438f22b97 100644 --- a/drivers/media/usb/dvb-usb/vp7045.h +++ b/drivers/media/usb/dvb-usb/vp7045.h @@ -6,7 +6,7 @@ * * 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_ -- cgit v1.2.3