diff options
| author | Mauro Carvalho Chehab <mchehab+huawei@kernel.org> | 2020-03-04 17:54:10 +0300 |
|---|---|---|
| committer | Mauro Carvalho Chehab <mchehab+huawei@kernel.org> | 2020-04-14 11:36:18 +0300 |
| commit | 577a7ad33aeff86f6c97277b12b122a0a2ad97d7 (patch) | |
| tree | 1c29f9e40be3b350ed2a30e5fa199e7c6092d5a2 /Documentation/media | |
| parent | 32e2eae23f8fd1b90d86f4d04ca9790952d9d928 (diff) | |
| download | linux-577a7ad33aeff86f6c97277b12b122a0a2ad97d7.tar.xz | |
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 <mchehab+huawei@kernel.org>
Diffstat (limited to 'Documentation/media')
19 files changed, 0 insertions, 5539 deletions
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 <m.hunold@gmx.de> - - - for the initial saa7146 driver and its recent overhaul - -- Christian Theiss - - - for his work on the initial Linux DVB driver - -- Marcus Metzler <mocm@metzlerbros.de> and - Ralph Metzler <rjkm@metzlerbros.de> - - - for their continuing work on the DVB driver - -- Michael Holzt <kju@debian.org> - - - for his contributions to the dvb-net driver - -- Diego Picciani <d.picciani@novacomp.it> - - - for CyberLogin for Linux which allows logging onto EON - (in case you are wondering where CyberLogin is, EON changed its login - procedure and CyberLogin is no longer used.) - -- Martin Schaller <martin@smurf.franken.de> - - - for patching the cable card decoder driver - -- Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> - - - for various fixes regarding tuning, OSD and CI stuff and his work on VDR - -- Steve Brown <sbrown@cortland.com> - - - for his AFC kernel thread - -- Christoph Martin <martin@uni-mainz.de> - - - for his LIRC infrared handler - -- Andreas Oberritter <obi@linuxtv.org>, - Dennis Noermann <dennis.noermann@noernet.de>, - Felix Domke <tmbinc@elitedvb.net>, - Florian Schirmer <jolt@tuxbox.org>, - Ronny Strutz <3des@elitedvb.de>, - Wolfram Joost <dbox2@frokaschwei.de> - and all the other dbox2 people - - - for many bugfixes in the generic DVB Core, frontend drivers and - their work on the dbox2 port of the DVB driver - -- Oliver Endriss <o.endriss@gmx.de> - - - for many bugfixes - -- Andrew de Quincey <adq_dvb@lidskialf.net> - - - for the tda1004x frontend driver, and various bugfixes - -- Peter Schildmann <peter.schildmann@web.de> - - - for the driver for the Technisat SkyStar2 PCI DVB card - -- Vadim Catana <skystar@moldova.cc>, - Roberto Ragusa <r.ragusa@libero.it> and - Augusto Cardoso <augusto@carhil.net> - - - for all the work for the FlexCopII chipset by B2C2,Inc. - -- Davor Emard <emard@softhome.net> - - - for his work on the budget drivers, the demux code, - the module unloading problems, ... - -- Hans-Frieder Vogt <hfvogt@arcor.de> - - - for his work on calculating and checking the crc's for the - TechnoTrend/Hauppauge DEC driver firmware - -- Michael Dreher <michael@5dot1.de> and - Andreas 'randy' Weinberger - - - for the support of the Fujitsu-Siemens Activy budget DVB-S - -- Kenneth Aafløy <ke-aa@frisurf.no> - - - for adding support for Typhoon DVB-S budget card - -- Ernst Peinlich <e.peinlich@inode.at> - - - for tuning/DiSEqC support for the DEC 3000-s - -- Peter Beutner <p.beutner@gmx.net> - - - for the IR code for the ttusb-dec driver - -- Wilson Michaels <wilsonmichaels@earthlink.net> - - - for the lgdt330x frontend driver, and various bugfixes - -- Michael Krufky <mkrufky@linuxtv.org> - - - for maintaining v4l/dvb inter-tree dependencies - -- Taylor Jacob <rtjacob@earthlink.net> - - - for the nxt2002 frontend driver - -- Jean-Francois Thibert <jeanfrancois@sagetv.com> - - - for the nxt2004 frontend driver - -- Kirk Lapray <kirk.lapray@gmail.com> - - - for the or51211 and or51132 frontend drivers, and - for merging the nxt2002 and nxt2004 modules into a - single nxt200x frontend driver. - -(If you think you should be in this list, but you are not, drop a -line to the DVB mailing list) 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=<level> - modprobe dvb-usb-vp7045 debug=<level> - etc. - -should do the trick. - -When the driver is loaded successfully, the firmware file was in -the right place and the device is connected, the "Power"-LED should be -turned on. - -At this point you should be able to start a dvb-capable application. I'm use -(t|s)zap, mplayer and dvbscan to test the basics. VDR-xine provides the -long-term test scenario. - -Known problems and bugs ------------------------ - -- Don't remove the USB device while running an DVB application, your system - will go crazy or die most likely. - -Adding support for devices -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -TODO - -USB1.1 Bandwidth limitation -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -A lot of the currently supported devices are USB1.1 and thus they have a -maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub. -This is not enough for receiving the complete transport stream of a -DVB-T channel (which is about 16 MBit/s). Normally this is not a -problem, if you only want to watch TV (this does not apply for HDTV), -but watching a channel while recording another channel on the same -frequency simply does not work very well. This applies to all USB1.1 -DVB-T devices, not just the dvb-usb-devices) - -The bug, where the TS is distorted by a heavy usage of the device is gone -definitely. All dvb-usb-devices I was using (Twinhan, Kworld, DiBcom) are -working like charm now with VDR. Sometimes I even was able to record a channel -and watch another one. - -Comments -~~~~~~~~ - -Patches, comments and suggestions are very very welcome. - -3. Acknowledgements -------------------- - - Amaury Demol (Amaury.Demol@parrot.com) and Francois Kanounnikoff from DiBcom for - providing specs, code and help, on which the dvb-dibusb, dib3000mb and - dib3000mc are based. - - David Matthews for identifying a new device type (Artec T1 with AN2235) - and for extending dibusb with remote control event handling. Thank you. - - Alex Woods for frequently answering question about usb and dvb - stuff, a big thank you. - - Bernd Wagner for helping with huge bug reports and discussions. - - Gunnar Wittich and Joachim von Caron for their trust for providing - root-shells on their machines to implement support for new devices. - - Allan Third and Michael Hutchinson for their help to write the Nebula - digitv-driver. - - Glen Harris for bringing up, that there is a new dibusb-device and Jiun-Kuei - Jung from AVerMedia who kindly provided a special firmware to get the device - up and running in Linux. - - Jennifer Chen, Jeff and Jack from Twinhan for kindly supporting by - writing the vp7045-driver. - - Steve Chang from WideView for providing information for new devices and - firmware files. - - Michael Paxton for submitting remote control keymaps. - - Some guys on the linux-dvb mailing list for encouraging me. - - Peter Schildmann >peter.schildmann-nospam-at-web.de< for his - user-level firmware loader, which saves a lot of time - (when writing the vp7041 driver) - - Ulf Hermenau for helping me out with traditional chinese. - - André Smoktun and Christian Frömmel for supporting me with - hardware and listening to my problems very patiently. 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:: <isonum.txt> - -############################################## -Linux Digital TV driver-specific documentation -############################################## - -**Copyright** |copy| 2001-2016 : LinuxTV Developers - -This documentation is free software; you can redistribute it and/or modify it -under the terms of the GNU General Public License as published by the Free -Software Foundation version 2 of the License. - -This program is distributed in the hope that it will be useful, but WITHOUT -ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or -FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for -more details. - -For more details see the file COPYING in the source distribution of Linux. - -.. only:: html - - .. class:: toc-title - - Table of Contents - -.. toctree:: - :maxdepth: 5 - :numbered: - - dvb-usb - frontends - contributors 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 <Peter_Pregler@email.com>, -Scott J. Bertin <scottbertin@yahoo.com>, and -Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which -this one was modelled from. - - -Notes to developers -~~~~~~~~~~~~~~~~~~~ - - - This is a driver version stripped of the 2.4 back compatibility - and old MJPEG ioctl API. See cpia2.sf.net for 2.4 support. - -Programmer's overview of cpia2 driver -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Cpia2 is the second generation video coprocessor from VLSI Vision Ltd (now a -division of ST Microelectronics). There are two versions. The first is the -STV0672, which is capable of up to 30 frames per second (fps) in frame sizes -up to CIF, and 15 fps for VGA frames. The STV0676 is an improved version, -which can handle up to 30 fps VGA. Both coprocessors can be attached to two -CMOS sensors - the vvl6410 CIF sensor and the vvl6500 VGA sensor. These will -be referred to as the 410 and the 500 sensors, or the CIF and VGA sensors. - -The two chipsets operate almost identically. The core is an 8051 processor, -running two different versions of firmware. The 672 runs the VP4 video -processor code, the 676 runs VP5. There are a few differences in register -mappings for the two chips. In these cases, the symbols defined in the -header files are marked with VP4 or VP5 as part of the symbol name. - -The cameras appear externally as three sets of registers. Setting register -values is the only way to control the camera. Some settings are -interdependant, such as the sequence required to power up the camera. I will -try to make note of all of these cases. - -The register sets are called blocks. Block 0 is the system block. This -section is always powered on when the camera is plugged in. It contains -registers that control housekeeping functions such as powering up the video -processor. The video processor is the VP block. These registers control -how the video from the sensor is processed. Examples are timing registers, -user mode (vga, qvga), scaling, cropping, framerates, and so on. The last -block is the video compressor (VC). The video stream sent from the camera is -compressed as Motion JPEG (JPEGA). The VC controls all of the compression -parameters. Looking at the file cpia2_registers.h, you can get a full view -of these registers and the possible values for most of them. - -One or more registers can be set or read by sending a usb control message to -the camera. There are three modes for this. Block mode requests a number -of contiguous registers. Random mode reads or writes random registers with -a tuple structure containing address/value pairs. The repeat mode is only -used by VP4 to load a firmware patch. It contains a starting address and -a sequence of bytes to be written into a gpio port. 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 <ian@iarmst.demon.co.uk> - -Version: v0.4 - -Date: 12 March 2007 - - -This list has been worked out through trial and error. There will be mistakes -and omissions. Some registers have no obvious effect so it's hard to say what -they do, while others interact with each other, or require a certain load -sequence. Horizontal filter setup is one example, with six registers working -in unison and requiring a certain load sequence to correctly configure. The -indexed colour palette is much easier to set at just two registers, but again -it requires a certain load sequence. - -Some registers are fussy about what they are set to. Load in a bad value & the -decoder will fail. A firmware reload will often recover, but sometimes a reset -is required. For registers containing size information, setting them to 0 is -generally a bad idea. For other control registers i.e. 2878, you'll only find -out what values are bad when it hangs. - -.. code-block:: none - - -------------------------------------------------------------------------------- - 2800 - bit 0 - Decoder enable - 0 = disable - 1 = enable - -------------------------------------------------------------------------------- - 2804 - bits 0:31 - Decoder horizontal Y alias register 1 - --------------- - 2808 - bits 0:31 - Decoder horizontal Y alias register 2 - --------------- - 280C - bits 0:31 - Decoder horizontal Y alias register 3 - --------------- - 2810 - bits 0:31 - Decoder horizontal Y alias register 4 - --------------- - 2814 - bits 0:31 - Decoder horizontal Y alias register 5 - --------------- - 2818 - bits 0:31 - Decoder horizontal Y alias trigger - - These six registers control the horizontal aliasing filter for the Y plane. - The first five registers must all be loaded before accessing the trigger - (2818), as this register actually clocks the data through for the first - five. - - To correctly program set the filter, this whole procedure must be done 16 - times. The actual register contents are copied from a lookup-table in the - firmware which contains 4 different filter settings. - - -------------------------------------------------------------------------------- - 281C - bits 0:31 - Decoder horizontal UV alias register 1 - --------------- - 2820 - bits 0:31 - Decoder horizontal UV alias register 2 - --------------- - 2824 - bits 0:31 - Decoder horizontal UV alias register 3 - --------------- - 2828 - bits 0:31 - Decoder horizontal UV alias register 4 - --------------- - 282C - bits 0:31 - Decoder horizontal UV alias register 5 - --------------- - 2830 - bits 0:31 - Decoder horizontal UV alias trigger - - These six registers control the horizontal aliasing for the UV plane. - Operation is the same as the Y filter, with 2830 being the trigger - register. - - -------------------------------------------------------------------------------- - 2834 - bits 0:15 - Decoder Y source width in pixels - - bits 16:31 - Decoder Y destination width in pixels - --------------- - 2838 - bits 0:15 - Decoder UV source width in pixels - - bits 16:31 - Decoder UV destination width in pixels - - NOTE: For both registers, the resulting image must be fully visible on - screen. If the image exceeds the right edge both the source and destination - size must be adjusted to reflect the visible portion. For the source width, - you must take into account the scaling when calculating the new value. - -------------------------------------------------------------------------------- - - 283C - bits 0:31 - Decoder Y horizontal scaling - Normally = Reg 2854 >> 2 - --------------- - 2840 - bits 0:31 - Decoder ?? unknown - horizontal scaling - Usually 0x00080514 - --------------- - 2844 - bits 0:31 - Decoder UV horizontal scaling - Normally = Reg 2854 >> 2 - --------------- - 2848 - bits 0:31 - Decoder ?? unknown - horizontal scaling - Usually 0x00100514 - --------------- - 284C - bits 0:31 - Decoder ?? unknown - Y plane - Usually 0x00200020 - --------------- - 2850 - bits 0:31 - Decoder ?? unknown - UV plane - Usually 0x00200020 - --------------- - 2854 - bits 0:31 - Decoder 'master' value for horizontal scaling - --------------- - 2858 - bits 0:31 - Decoder ?? unknown - Usually 0 - --------------- - 285C - bits 0:31 - Decoder ?? unknown - Normally = Reg 2854 >> 1 - --------------- - 2860 - bits 0:31 - Decoder ?? unknown - Usually 0 - --------------- - 2864 - bits 0:31 - Decoder ?? unknown - Normally = Reg 2854 >> 1 - --------------- - 2868 - bits 0:31 - Decoder ?? unknown - Usually 0 - - Most of these registers either control horizontal scaling, or appear linked - to it in some way. Register 2854 contains the 'master' value & the other - registers can be calculated from that one. You must also remember to - correctly set the divider in Reg 2874. - - To enlarge: - Reg 2854 = (source_width * 0x00200000) / destination_width - Reg 2874 = No divide - - To reduce from full size down to half size: - Reg 2854 = (source_width/2 * 0x00200000) / destination width - Reg 2874 = Divide by 2 - - To reduce from half size down to quarter size: - Reg 2854 = (source_width/4 * 0x00200000) / destination width - Reg 2874 = Divide by 4 - - The result is always rounded up. - - -------------------------------------------------------------------------------- - 286C - bits 0:15 - Decoder horizontal Y buffer offset - - bits 15:31 - Decoder horizontal UV buffer offset - - Offset into the video image buffer. If the offset is gradually incremented, - the on screen image will move left & wrap around higher up on the right. - - -------------------------------------------------------------------------------- - 2870 - bits 0:15 - Decoder horizontal Y output offset - - bits 16:31 - Decoder horizontal UV output offset - - Offsets the actual video output. Controls output alignment of the Y & UV - planes. The higher the value, the greater the shift to the left. Use - reg 2890 to move the image right. - - -------------------------------------------------------------------------------- - 2874 - bits 0:1 - Decoder horizontal Y output size divider - 00 = No divide - 01 = Divide by 2 - 10 = Divide by 3 - - bits 4:5 - Decoder horizontal UV output size divider - 00 = No divide - 01 = Divide by 2 - 10 = Divide by 3 - - bit 8 - Decoder ?? unknown - 0 = Normal - 1 = Affects video output levels - - bit 16 - Decoder ?? unknown - 0 = Normal - 1 = Disable horizontal filter - - -------------------------------------------------------------------------------- - 2878 - bit 0 - ?? unknown - - bit 1 - osd on/off - 0 = osd off - 1 = osd on - - bit 2 - Decoder + osd video timing - 0 = NTSC - 1 = PAL - - bits 3:4 - ?? unknown - - bit 5 - Decoder + osd - Swaps upper & lower fields - - -------------------------------------------------------------------------------- - 287C - bits 0:10 - Decoder & osd ?? unknown - Moves entire screen horizontally. Starts at 0x005 with the screen - shifted heavily to the right. Incrementing in steps of 0x004 will - gradually shift the screen to the left. - - bits 11:31 - ?? unknown - - Normally contents are 0x00101111 (NTSC) or 0x1010111d (PAL) - - -------------------------------------------------------------------------------- - 2880 -------- ?? unknown - 2884 -------- ?? unknown - -------------------------------------------------------------------------------- - 2888 - bit 0 - Decoder + osd ?? unknown - 0 = Normal - 1 = Misaligned fields (Correctable through 289C & 28A4) - - bit 4 - ?? unknown - - bit 8 - ?? unknown - - Warning: Bad values will require a firmware reload to recover. - Known to be bad are 0x000,0x011,0x100,0x111 - -------------------------------------------------------------------------------- - 288C - bits 0:15 - osd ?? unknown - Appears to affect the osd position stability. The higher the value the - more unstable it becomes. Decoder output remains stable. - - bits 16:31 - osd ?? unknown - Same as bits 0:15 - - -------------------------------------------------------------------------------- - 2890 - bits 0:11 - Decoder output horizontal offset. - - Horizontal offset moves the video image right. A small left shift is - possible, but it's better to use reg 2870 for that due to its greater - range. - - NOTE: Video corruption will occur if video window is shifted off the right - edge. To avoid this read the notes for 2834 & 2838. - -------------------------------------------------------------------------------- - 2894 - bits 0:23 - Decoder output video surround colour. - - Contains the colour (in yuv) used to fill the screen when the video is - running in a window. - -------------------------------------------------------------------------------- - 2898 - bits 0:23 - Decoder video window colour - Contains the colour (in yuv) used to fill the video window when the - video is turned off. - - bit 24 - Decoder video output - 0 = Video on - 1 = Video off - - bit 28 - Decoder plane order - 0 = Y,UV - 1 = UV,Y - - bit 29 - Decoder second plane byte order - 0 = Normal (UV) - 1 = Swapped (VU) - - In normal usage, the first plane is Y & the second plane is UV. Though the - order of the planes can be swapped, only the byte order of the second plane - can be swapped. This isn't much use for the Y plane, but can be useful for - the UV plane. - - -------------------------------------------------------------------------------- - 289C - bits 0:15 - Decoder vertical field offset 1 - - bits 16:31 - Decoder vertical field offset 2 - - Controls field output vertical alignment. The higher the number, the lower - the image on screen. Known starting values are 0x011E0017 (NTSC) & - 0x01500017 (PAL) - -------------------------------------------------------------------------------- - 28A0 - bits 0:15 - Decoder & osd width in pixels - - bits 16:31 - Decoder & osd height in pixels - - All output from the decoder & osd are disabled beyond this area. Decoder - output will simply go black outside of this region. If the osd tries to - exceed this area it will become corrupt. - -------------------------------------------------------------------------------- - 28A4 - bits 0:11 - osd left shift. - - Has a range of 0x770->0x7FF. With the exception of 0, any value outside of - this range corrupts the osd. - -------------------------------------------------------------------------------- - 28A8 - bits 0:15 - osd vertical field offset 1 - - bits 16:31 - osd vertical field offset 2 - - Controls field output vertical alignment. The higher the number, the lower - the image on screen. Known starting values are 0x011E0017 (NTSC) & - 0x01500017 (PAL) - -------------------------------------------------------------------------------- - 28AC -------- ?? unknown - | - V - 28BC -------- ?? unknown - -------------------------------------------------------------------------------- - 28C0 - bit 0 - Current output field - 0 = first field - 1 = second field - - bits 16:31 - Current scanline - The scanline counts from the top line of the first field - through to the last line of the second field. - -------------------------------------------------------------------------------- - 28C4 -------- ?? unknown - | - V - 28F8 -------- ?? unknown - -------------------------------------------------------------------------------- - 28FC - bit 0 - ?? unknown - 0 = Normal - 1 = Breaks decoder & osd output - -------------------------------------------------------------------------------- - 2900 - bits 0:31 - Decoder vertical Y alias register 1 - --------------- - 2904 - bits 0:31 - Decoder vertical Y alias register 2 - --------------- - 2908 - bits 0:31 - Decoder vertical Y alias trigger - - These three registers control the vertical aliasing filter for the Y plane. - Operation is similar to the horizontal Y filter (2804). The only real - difference is that there are only two registers to set before accessing - the trigger register (2908). As for the horizontal filter, the values are - taken from a lookup table in the firmware, and the procedure must be - repeated 16 times to fully program the filter. - -------------------------------------------------------------------------------- - 290C - bits 0:31 - Decoder vertical UV alias register 1 - --------------- - 2910 - bits 0:31 - Decoder vertical UV alias register 2 - --------------- - 2914 - bits 0:31 - Decoder vertical UV alias trigger - - These three registers control the vertical aliasing filter for the UV - plane. Operation is the same as the Y filter, with 2914 being the trigger. - -------------------------------------------------------------------------------- - 2918 - bits 0:15 - Decoder Y source height in pixels - - bits 16:31 - Decoder Y destination height in pixels - --------------- - 291C - bits 0:15 - Decoder UV source height in pixels divided by 2 - - bits 16:31 - Decoder UV destination height in pixels - - NOTE: For both registers, the resulting image must be fully visible on - screen. If the image exceeds the bottom edge both the source and - destination size must be adjusted to reflect the visible portion. For the - source height, you must take into account the scaling when calculating the - new value. - -------------------------------------------------------------------------------- - 2920 - bits 0:31 - Decoder Y vertical scaling - Normally = Reg 2930 >> 2 - --------------- - 2924 - bits 0:31 - Decoder Y vertical scaling - Normally = Reg 2920 + 0x514 - --------------- - 2928 - bits 0:31 - Decoder UV vertical scaling - When enlarging = Reg 2930 >> 2 - When reducing = Reg 2930 >> 3 - --------------- - 292C - bits 0:31 - Decoder UV vertical scaling - Normally = Reg 2928 + 0x514 - --------------- - 2930 - bits 0:31 - Decoder 'master' value for vertical scaling - --------------- - 2934 - bits 0:31 - Decoder ?? unknown - Y vertical scaling - --------------- - 2938 - bits 0:31 - Decoder Y vertical scaling - Normally = Reg 2930 - --------------- - 293C - bits 0:31 - Decoder ?? unknown - Y vertical scaling - --------------- - 2940 - bits 0:31 - Decoder UV vertical scaling - When enlarging = Reg 2930 >> 1 - When reducing = Reg 2930 - --------------- - 2944 - bits 0:31 - Decoder ?? unknown - UV vertical scaling - --------------- - 2948 - bits 0:31 - Decoder UV vertical scaling - Normally = Reg 2940 - --------------- - 294C - bits 0:31 - Decoder ?? unknown - UV vertical scaling - - Most of these registers either control vertical scaling, or appear linked - to it in some way. Register 2930 contains the 'master' value & all other - registers can be calculated from that one. You must also remember to - correctly set the divider in Reg 296C - - To enlarge: - Reg 2930 = (source_height * 0x00200000) / destination_height - Reg 296C = No divide - - To reduce from full size down to half size: - Reg 2930 = (source_height/2 * 0x00200000) / destination height - Reg 296C = Divide by 2 - - To reduce from half down to quarter. - Reg 2930 = (source_height/4 * 0x00200000) / destination height - Reg 296C = Divide by 4 - - -------------------------------------------------------------------------------- - 2950 - bits 0:15 - Decoder Y line index into display buffer, first field - - bits 16:31 - Decoder Y vertical line skip, first field - -------------------------------------------------------------------------------- - 2954 - bits 0:15 - Decoder Y line index into display buffer, second field - - bits 16:31 - Decoder Y vertical line skip, second field - -------------------------------------------------------------------------------- - 2958 - bits 0:15 - Decoder UV line index into display buffer, first field - - bits 16:31 - Decoder UV vertical line skip, first field - -------------------------------------------------------------------------------- - 295C - bits 0:15 - Decoder UV line index into display buffer, second field - - bits 16:31 - Decoder UV vertical line skip, second field - -------------------------------------------------------------------------------- - 2960 - bits 0:15 - Decoder destination height minus 1 - - bits 16:31 - Decoder destination height divided by 2 - -------------------------------------------------------------------------------- - 2964 - bits 0:15 - Decoder Y vertical offset, second field - - bits 16:31 - Decoder Y vertical offset, first field - - These two registers shift the Y plane up. The higher the number, the - greater the shift. - -------------------------------------------------------------------------------- - 2968 - bits 0:15 - Decoder UV vertical offset, second field - - bits 16:31 - Decoder UV vertical offset, first field - - These two registers shift the UV plane up. The higher the number, the - greater the shift. - -------------------------------------------------------------------------------- - 296C - bits 0:1 - Decoder vertical Y output size divider - 00 = No divide - 01 = Divide by 2 - 10 = Divide by 4 - - bits 8:9 - Decoder vertical UV output size divider - 00 = No divide - 01 = Divide by 2 - 10 = Divide by 4 - -------------------------------------------------------------------------------- - 2970 - bit 0 - Decoder ?? unknown - 0 = Normal - 1 = Affect video output levels - - bit 16 - Decoder ?? unknown - 0 = Normal - 1 = Disable vertical filter - - -------------------------------------------------------------------------------- - 2974 -------- ?? unknown - | - V - 29EF -------- ?? unknown - -------------------------------------------------------------------------------- - 2A00 - bits 0:2 - osd colour mode - 000 = 8 bit indexed - 001 = 16 bit (565) - 010 = 15 bit (555) - 011 = 12 bit (444) - 100 = 32 bit (8888) - - bits 4:5 - osd display bpp - 01 = 8 bit - 10 = 16 bit - 11 = 32 bit - - bit 8 - osd global alpha - 0 = Off - 1 = On - - bit 9 - osd local alpha - 0 = Off - 1 = On - - bit 10 - osd colour key - 0 = Off - 1 = On - - bit 11 - osd ?? unknown - Must be 1 - - bit 13 - osd colour space - 0 = ARGB - 1 = AYVU - - bits 16:31 - osd ?? unknown - Must be 0x001B (some kind of buffer pointer ?) - - When the bits-per-pixel is set to 8, the colour mode is ignored and - assumed to be 8 bit indexed. For 16 & 32 bits-per-pixel the colour depth - is honoured, and when using a colour depth that requires fewer bytes than - allocated the extra bytes are used as padding. So for a 32 bpp with 8 bit - index colour, there are 3 padding bytes per pixel. It's also possible to - select 16bpp with a 32 bit colour mode. This results in the pixel width - being doubled, but the color key will not work as expected in this mode. - - Colour key is as it suggests. You designate a colour which will become - completely transparent. When using 565, 555 or 444 colour modes, the - colour key is always 16 bits wide. The colour to key on is set in Reg 2A18. - - Local alpha works differently depending on the colour mode. For 32bpp & 8 - bit indexed, local alpha is a per-pixel 256 step transparency, with 0 being - transparent and 255 being solid. For the 16bpp modes 555 & 444, the unused - bit(s) act as a simple transparency switch, with 0 being solid & 1 being - fully transparent. There is no local alpha support for 16bit 565. - - Global alpha is a 256 step transparency that applies to the entire osd, - with 0 being transparent & 255 being solid. - - It's possible to combine colour key, local alpha & global alpha. - -------------------------------------------------------------------------------- - 2A04 - bits 0:15 - osd x coord for left edge - - bits 16:31 - osd y coord for top edge - --------------- - 2A08 - bits 0:15 - osd x coord for right edge - - bits 16:31 - osd y coord for bottom edge - - For both registers, (0,0) = top left corner of the display area. These - registers do not control the osd size, only where it's positioned & how - much is visible. The visible osd area cannot exceed the right edge of the - display, otherwise the osd will become corrupt. See reg 2A10 for - setting osd width. - -------------------------------------------------------------------------------- - 2A0C - bits 0:31 - osd buffer index - - An index into the osd buffer. Slowly incrementing this moves the osd left, - wrapping around onto the right edge - -------------------------------------------------------------------------------- - 2A10 - bits 0:11 - osd buffer 32 bit word width - - Contains the width of the osd measured in 32 bit words. This means that all - colour modes are restricted to a byte width which is divisible by 4. - -------------------------------------------------------------------------------- - 2A14 - bits 0:15 - osd height in pixels - - bits 16:32 - osd line index into buffer - osd will start displaying from this line. - -------------------------------------------------------------------------------- - 2A18 - bits 0:31 - osd colour key - - Contains the colour value which will be transparent. - -------------------------------------------------------------------------------- - 2A1C - bits 0:7 - osd global alpha - - Contains the global alpha value (equiv ivtvfbctl --alpha XX) - -------------------------------------------------------------------------------- - 2A20 -------- ?? unknown - | - V - 2A2C -------- ?? unknown - -------------------------------------------------------------------------------- - 2A30 - bits 0:7 - osd colour to change in indexed palette - --------------- - 2A34 - bits 0:31 - osd colour for indexed palette - - To set the new palette, first load the index of the colour to change into - 2A30, then load the new colour into 2A34. The full palette is 256 colours, - so the index range is 0x00-0xFF - -------------------------------------------------------------------------------- - 2A38 -------- ?? unknown - 2A3C -------- ?? unknown - -------------------------------------------------------------------------------- - 2A40 - bits 0:31 - osd ?? unknown - - Affects overall brightness, wrapping around to black - -------------------------------------------------------------------------------- - 2A44 - bits 0:31 - osd ?? unknown - - Green tint - -------------------------------------------------------------------------------- - 2A48 - bits 0:31 - osd ?? unknown - - Red tint - -------------------------------------------------------------------------------- - 2A4C - bits 0:31 - osd ?? unknown - - Affects overall brightness, wrapping around to black - -------------------------------------------------------------------------------- - 2A50 - bits 0:31 - osd ?? unknown - - Colour shift - -------------------------------------------------------------------------------- - 2A54 - bits 0:31 - osd ?? unknown - - Colour shift - -------------------------------------------------------------------------------- - 2A58 -------- ?? unknown - | - V - 2AFC -------- ?? unknown - -------------------------------------------------------------------------------- - 2B00 - bit 0 - osd filter control - 0 = filter off - 1 = filter on - - bits 1:4 - osd ?? unknown - - -------------------------------------------------------------------------------- - -The cx231xx DMA engine ----------------------- - - -This page describes the structures and procedures used by the cx2341x DMA -engine. - -Introduction -~~~~~~~~~~~~ - -The cx2341x PCI interface is busmaster capable. This means it has a DMA -engine to efficiently transfer large volumes of data between the card and main -memory without requiring help from a CPU. Like most hardware, it must operate -on contiguous physical memory. This is difficult to come by in large quantities -on virtual memory machines. - -Therefore, it also supports a technique called "scatter-gather". The card can -transfer multiple buffers in one operation. Instead of allocating one large -contiguous buffer, the driver can allocate several smaller buffers. - -In practice, I've seen the average transfer to be roughly 80K, but transfers -above 128K were not uncommon, particularly at startup. The 128K figure is -important, because that is the largest block that the kernel can normally -allocate. Even still, 128K blocks are hard to come by, so the driver writer is -urged to choose a smaller block size and learn the scatter-gather technique. - -Mailbox #10 is reserved for DMA transfer information. - -Note: the hardware expects little-endian data ('intel format'). - -Flow -~~~~ - -This section describes, in general, the order of events when handling DMA -transfers. Detailed information follows this section. - -- The card raises the Encoder interrupt. -- The driver reads the transfer type, offset and size from Mailbox #10. -- The driver constructs the scatter-gather array from enough free dma buffers - to cover the size. -- The driver schedules the DMA transfer via the ScheduleDMAtoHost API call. -- The card raises the DMA Complete interrupt. -- The driver checks the DMA status register for any errors. -- The driver post-processes the newly transferred buffers. - -NOTE! It is possible that the Encoder and DMA Complete interrupts get raised -simultaneously. (End of the last, start of the next, etc.) - -Mailbox #10 -~~~~~~~~~~~ - -The Flags, Command, Return Value and Timeout fields are ignored. - -- Name: Mailbox #10 -- Results[0]: Type: 0: MPEG. -- Results[1]: Offset: The position relative to the card's memory space. -- Results[2]: Size: The exact number of bytes to transfer. - -My speculation is that since the StartCapture API has a capture type of "RAW" -available, that the type field will have other values that correspond to YUV -and PCM data. - -Scatter-Gather Array -~~~~~~~~~~~~~~~~~~~~ - -The scatter-gather array is a contiguously allocated block of memory that -tells the card the source and destination of each data-block to transfer. -Card "addresses" are derived from the offset supplied by Mailbox #10. Host -addresses are the physical memory location of the target DMA buffer. - -Each S-G array element is a struct of three 32-bit words. The first word is -the source address, the second is the destination address. Both take up the -entire 32 bits. The lowest 18 bits of the third word is the transfer byte -count. The high-bit of the third word is the "last" flag. The last-flag tells -the card to raise the DMA_DONE interrupt. From hard personal experience, if -you forget to set this bit, the card will still "work" but the stream will -most likely get corrupted. - -The transfer count must be a multiple of 256. Therefore, the driver will need -to track how much data in the target buffer is valid and deal with it -accordingly. - -Array Element: - -- 32-bit Source Address -- 32-bit Destination Address -- 14-bit reserved (high bit is the last flag) -- 18-bit byte count - -DMA Transfer Status -~~~~~~~~~~~~~~~~~~~ - -Register 0x0004 holds the DMA Transfer Status: - -- bit 0: read completed -- bit 1: write completed -- bit 2: DMA read error -- bit 3: DMA write error -- bit 4: Scatter-Gather array error 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:: <isonum.txt> - -The Samsung S5P/EXYNOS4 FIMC driver -=================================== - -Copyright |copy| 2012 - 2013 Samsung Electronics Co., Ltd. - -Files partitioning ------------------- - -- media device driver - - drivers/media/platform/exynos4-is/media-dev.[ch] - -- camera capture video device driver - - drivers/media/platform/exynos4-is/fimc-capture.c - -- MIPI-CSI2 receiver subdev - - drivers/media/platform/exynos4-is/mipi-csis.[ch] - -- video post-processor (mem-to-mem) - - drivers/media/platform/exynos4-is/fimc-core.c - -- common files - - drivers/media/platform/exynos4-is/fimc-core.h - drivers/media/platform/exynos4-is/fimc-reg.h - drivers/media/platform/exynos4-is/regs-fimc.h 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 <isely@pobox.com> - -Background ----------- - -This driver is intended for the "Hauppauge WinTV PVR USB 2.0", which -is a USB 2.0 hosted TV Tuner. This driver is a work in progress. -Its history started with the reverse-engineering effort by Björn -Danielsson <pvrusb2@dax.nu> whose web page can be found here: -http://pvrusb2.dax.nu/ - -From there Aurelien Alleaume <slts@free.fr> began an effort to -create a video4linux compatible driver. I began with Aurelien's -last known snapshot and evolved the driver to the state it is in -here. - -More information on this driver can be found at: -http://www.isely.net/pvrusb2.html - - -This driver has a strong separation of layers. They are very -roughly: - -1. Low level wire-protocol implementation with the device. - -2. I2C adaptor implementation and corresponding I2C client drivers - implemented elsewhere in V4L. - -3. High level hardware driver implementation which coordinates all - activities that ensure correct operation of the device. - -4. A "context" layer which manages instancing of driver, setup, - tear-down, arbitration, and interaction with high level - interfaces appropriately as devices are hotplugged in the - system. - -5. High level interfaces which glue the driver to various published - Linux APIs (V4L, sysfs, maybe DVB in the future). - -The most important shearing layer is between the top 2 layers. A -lot of work went into the driver to ensure that any kind of -conceivable API can be laid on top of the core driver. (Yes, the -driver internally leverages V4L to do its work but that really has -nothing to do with the API published by the driver to the outside -world.) The architecture allows for different APIs to -simultaneously access the driver. I have a strong sense of fairness -about APIs and also feel that it is a good design principle to keep -implementation and interface isolated from each other. Thus while -right now the V4L high level interface is the most complete, the -sysfs high level interface will work equally well for similar -functions, and there's no reason I see right now why it shouldn't be -possible to produce a DVB high level interface that can sit right -alongside V4L. - -Building --------- - -To build these modules essentially amounts to just running "Make", -but you need the kernel source tree nearby and you will likely also -want to set a few controlling environment variables first in order -to link things up with that source tree. Please see the Makefile -here for comments that explain how to do that. - -Source file list / functional overview --------------------------------------- - -(Note: The term "module" used below generally refers to loosely -defined functional units within the pvrusb2 driver and bears no -relation to the Linux kernel's concept of a loadable module.) - -pvrusb2-audio.[ch] - This is glue logic that resides between this - driver and the msp3400.ko I2C client driver (which is found - elsewhere in V4L). - -pvrusb2-context.[ch] - This module implements the context for an - instance of the driver. Everything else eventually ties back to - or is otherwise instanced within the data structures implemented - here. Hotplugging is ultimately coordinated here. All high level - interfaces tie into the driver through this module. This module - helps arbitrate each interface's access to the actual driver core, - and is designed to allow concurrent access through multiple - instances of multiple interfaces (thus you can for example change - the tuner's frequency through sysfs while simultaneously streaming - video through V4L out to an instance of mplayer). - -pvrusb2-debug.h - This header defines a printk() wrapper and a mask - of debugging bit definitions for the various kinds of debug - messages that can be enabled within the driver. - -pvrusb2-debugifc.[ch] - This module implements a crude command line - oriented debug interface into the driver. Aside from being part - of the process for implementing manual firmware extraction (see - the pvrusb2 web site mentioned earlier), probably I'm the only one - who has ever used this. It is mainly a debugging aid. - -pvrusb2-eeprom.[ch] - This is glue logic that resides between this - driver the tveeprom.ko module, which is itself implemented - elsewhere in V4L. - -pvrusb2-encoder.[ch] - This module implements all protocol needed to - interact with the Conexant mpeg2 encoder chip within the pvrusb2 - device. It is a crude echo of corresponding logic in ivtv, - however the design goals (strict isolation) and physical layer - (proxy through USB instead of PCI) are enough different that this - implementation had to be completely different. - -pvrusb2-hdw-internal.h - This header defines the core data structure - in the driver used to track ALL internal state related to control - of the hardware. Nobody outside of the core hardware-handling - modules should have any business using this header. All external - access to the driver should be through one of the high level - interfaces (e.g. V4L, sysfs, etc), and in fact even those high - level interfaces are restricted to the API defined in - pvrusb2-hdw.h and NOT this header. - -pvrusb2-hdw.h - This header defines the full internal API for - controlling the hardware. High level interfaces (e.g. V4L, sysfs) - will work through here. - -pvrusb2-hdw.c - This module implements all the various bits of logic - that handle overall control of a specific pvrusb2 device. - (Policy, instantiation, and arbitration of pvrusb2 devices fall - within the jurisdiction of pvrusb-context not here). - -pvrusb2-i2c-chips-\*.c - These modules implement the glue logic to - tie together and configure various I2C modules as they attach to - the I2C bus. There are two versions of this file. The "v4l2" - version is intended to be used in-tree alongside V4L, where we - implement just the logic that makes sense for a pure V4L - environment. The "all" version is intended for use outside of - V4L, where we might encounter other possibly "challenging" modules - from ivtv or older kernel snapshots (or even the support modules - in the standalone snapshot). - -pvrusb2-i2c-cmd-v4l1.[ch] - This module implements generic V4L1 - compatible commands to the I2C modules. It is here where state - changes inside the pvrusb2 driver are translated into V4L1 - commands that are in turn send to the various I2C modules. - -pvrusb2-i2c-cmd-v4l2.[ch] - This module implements generic V4L2 - compatible commands to the I2C modules. It is here where state - changes inside the pvrusb2 driver are translated into V4L2 - commands that are in turn send to the various I2C modules. - -pvrusb2-i2c-core.[ch] - This module provides an implementation of a - kernel-friendly I2C adaptor driver, through which other external - I2C client drivers (e.g. msp3400, tuner, lirc) may connect and - operate corresponding chips within the pvrusb2 device. It is - through here that other V4L modules can reach into this driver to - operate specific pieces (and those modules are in turn driven by - glue logic which is coordinated by pvrusb2-hdw, doled out by - pvrusb2-context, and then ultimately made available to users - through one of the high level interfaces). - -pvrusb2-io.[ch] - This module implements a very low level ring of - transfer buffers, required in order to stream data from the - device. This module is *very* low level. It only operates the - buffers and makes no attempt to define any policy or mechanism for - how such buffers might be used. - -pvrusb2-ioread.[ch] - This module layers on top of pvrusb2-io.[ch] - to provide a streaming API usable by a read() system call style of - I/O. Right now this is the only layer on top of pvrusb2-io.[ch], - however the underlying architecture here was intended to allow for - other styles of I/O to be implemented with additional modules, like - mmap()'ed buffers or something even more exotic. - -pvrusb2-main.c - This is the top level of the driver. Module level - and USB core entry points are here. This is our "main". - -pvrusb2-sysfs.[ch] - This is the high level interface which ties the - pvrusb2 driver into sysfs. Through this interface you can do - everything with the driver except actually stream data. - -pvrusb2-tuner.[ch] - This is glue logic that resides between this - driver and the tuner.ko I2C client driver (which is found - elsewhere in V4L). - -pvrusb2-util.h - This header defines some common macros used - throughout the driver. These macros are not really specific to - the driver, but they had to go somewhere. - -pvrusb2-v4l2.[ch] - This is the high level interface which ties the - pvrusb2 driver into video4linux. It is through here that V4L - applications can open and operate the driver in the usual V4L - ways. Note that **ALL** V4L functionality is published only - through here and nowhere else. - -pvrusb2-video-\*.[ch] - This is glue logic that resides between this - driver and the saa711x.ko I2C client driver (which is found - elsewhere in V4L). Note that saa711x.ko used to be known as - saa7115.ko in ivtv. There are two versions of this; one is - selected depending on the particular saa711[5x].ko that is found. - -pvrusb2.h - This header contains compile time tunable parameters - (and at the moment the driver has very little that needs to be - tuned). 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 <robert.jarzmik@free.fr> - -Constraints ------------ - -a) Image size for YUV422P format - All YUV422P images are enforced to have width x height % 16 = 0. - This is due to DMA constraints, which transfers only planes of 8 byte - multiples. - - -Global video workflow ---------------------- - -a) QCI stopped - Initially, the QCI interface is stopped. - When a buffer is queued (pxa_videobuf_ops->buf_queue), the QCI starts. - -b) QCI started - More buffers can be queued while the QCI is started without halting the - capture. The new buffers are "appended" at the tail of the DMA chain, and - smoothly captured one frame after the other. - - Once a buffer is filled in the QCI interface, it is marked as "DONE" and - removed from the active buffers list. It can be then requeud or dequeued by - userland application. - - Once the last buffer is filled in, the QCI interface stops. - -c) Capture global finite state machine schema - -.. code-block:: none - - +----+ +---+ +----+ - | DQ | | Q | | DQ | - | v | v | v - +-----------+ +------------------------+ - | STOP | | Wait for capture start | - +-----------+ Q +------------------------+ - +-> | QCI: stop | ------------------> | QCI: run | <------------+ - | | DMA: stop | | DMA: stop | | - | +-----------+ +-----> +------------------------+ | - | / | | - | / +---+ +----+ | | - |capture list empty / | Q | | DQ | | QCI Irq EOF | - | / | v | v v | - | +--------------------+ +----------------------+ | - | | DMA hotlink missed | | Capture running | | - | +--------------------+ +----------------------+ | - | | QCI: run | +-----> | QCI: run | <-+ | - | | DMA: stop | / | DMA: run | | | - | +--------------------+ / +----------------------+ | Other | - | ^ /DMA still | | channels | - | | capture list / running | DMA Irq End | not | - | | not empty / | | finished | - | | / v | yet | - | +----------------------+ +----------------------+ | | - | | Videobuf released | | Channel completed | | | - | +----------------------+ +----------------------+ | | - +-- | QCI: run | | QCI: run | --+ | - | DMA: run | | DMA: run | | - +----------------------+ +----------------------+ | - ^ / | | - | no overrun / | overrun | - | / v | - +--------------------+ / +----------------------+ | - | Frame completed | / | Frame overran | | - +--------------------+ <-----+ +----------------------+ restart frame | - | QCI: run | | QCI: stop | --------------+ - | DMA: run | | DMA: stop | - +--------------------+ +----------------------+ - - Legend: - each box is a FSM state - - each arrow is the condition to transition to another state - - an arrow with a comment is a mandatory transition (no condition) - - arrow "Q" means : a buffer was enqueued - - arrow "DQ" means : a buffer was dequeued - - "QCI: stop" means the QCI interface is not enabled - - "DMA: stop" means all 3 DMA channels are stopped - - "DMA: run" means at least 1 DMA channel is still running - -DMA usage ---------- - -a) DMA flow - - first buffer queued for capture - Once a first buffer is queued for capture, the QCI is started, but data - transfer is not started. On "End Of Frame" interrupt, the irq handler - starts the DMA chain. - - capture of one videobuffer - The DMA chain starts transferring data into videobuffer RAM pages. - When all pages are transferred, the DMA irq is raised on "ENDINTR" status - - finishing one videobuffer - The DMA irq handler marks the videobuffer as "done", and removes it from - the active running queue - Meanwhile, the next videobuffer (if there is one), is transferred by DMA - - finishing the last videobuffer - On the DMA irq of the last videobuffer, the QCI is stopped. - -b) DMA prepared buffer will have this structure - -.. code-block:: none - - +------------+-----+---------------+-----------------+ - | desc-sg[0] | ... | desc-sg[last] | finisher/linker | - +------------+-----+---------------+-----------------+ - -This structure is pointed by dma->sg_cpu. -The descriptors are used as follows: - -- desc-sg[i]: i-th descriptor, transferring the i-th sg - element to the video buffer scatter gather -- finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN -- linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0 - -For the next schema, let's assume d0=desc-sg[0] .. dN=desc-sg[N], -"f" stands for finisher and "l" for linker. -A typical running chain is : - -.. code-block:: none - - Videobuffer 1 Videobuffer 2 - +---------+----+---+ +----+----+----+---+ - | d0 | .. | dN | l | | d0 | .. | dN | f | - +---------+----+-|-+ ^----+----+----+---+ - | | - +----+ - -After the chaining is finished, the chain looks like : - -.. code-block:: none - - Videobuffer 1 Videobuffer 2 Videobuffer 3 - +---------+----+---+ +----+----+----+---+ +----+----+----+---+ - | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f | - +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+ - | | | | - +----+ +----+ - new_link - -c) DMA hot chaining timeslice issue - -As DMA chaining is done while DMA _is_ running, the linking may be done -while the DMA jumps from one Videobuffer to another. On the schema, that -would be a problem if the following sequence is encountered : - -- DMA chain is Videobuffer1 + Videobuffer2 -- pxa_videobuf_queue() is called to queue Videobuffer3 -- DMA controller finishes Videobuffer2, and DMA stops - -.. code-block:: none - - => - Videobuffer 1 Videobuffer 2 - +---------+----+---+ +----+----+----+---+ - | d0 | .. | dN | l | | d0 | .. | dN | f | - +---------+----+-|-+ ^----+----+----+-^-+ - | | | - +----+ +-- DMA DDADR loads DDADR_STOP - -- pxa_dma_add_tail_buf() is called, the Videobuffer2 "finisher" is - replaced by a "linker" to Videobuffer3 (creation of new_link) -- pxa_videobuf_queue() finishes -- the DMA irq handler is called, which terminates Videobuffer2 -- Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!) - -.. code-block:: none - - Videobuffer 1 Videobuffer 2 Videobuffer 3 - +---------+----+---+ +----+----+----+---+ +----+----+----+---+ - | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f | - +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+ - | | | | - +----+ +----+ - new_link - DMA DDADR still is DDADR_STOP - -- pxa_camera_check_link_miss() is called - This checks if the DMA is finished and a buffer is still on the - pcdev->capture list. If that's the case, the capture will be restarted, - and Videobuffer3 is scheduled on DMA chain. -- the DMA irq handler finishes - -.. note:: - - If DMA stops just after pxa_camera_check_link_miss() reads DDADR() - value, we have the guarantee that the DMA irq handler will be called back - when the DMA will finish the buffer, and pxa_camera_check_link_miss() will - be called again, to reschedule Videobuffer3. 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 <benoits@servicepro.com> - -Date: Dec 14, 1996 - -ACKNOWLEDGMENTS ----------------- - -This document was made based on 'C' code for Linux from Gideon le Grange -(legrang@active.co.za or legrang@cs.sun.ac.za) in 1994, and elaborations from -Frans Brinkman (brinkman@esd.nl) in 1996. The results reported here are from -experiments that the author performed on his own setup, so your mileage may -vary... I make no guarantees, claims or warranties to the suitability or -validity of this information. No other documentation on the AIMS -Lab (http://www.aimslab.com/) RadioTrack card was made available to the -author. This document is offered in the hopes that it might help users who -want to use the RadioTrack card in an environment other than MS Windows. - -WHY THIS DOCUMENT? ------------------- - -I have a RadioTrack card from back when I ran an MS-Windows platform. After -converting to Linux, I found Gideon le Grange's command-line software for -running the card, and found that it was good! Frans Brinkman made a -comfortable X-windows interface, and added a scanning feature. For hack -value, I wanted to see if the tuner could be tuned beyond the usual FM radio -broadcast band, so I could pick up the audio carriers from North American -broadcast TV channels, situated just below and above the 87.0-109.0 MHz range. -I did not get much success, but I learned about programming ioports under -Linux and gained some insights about the hardware design used for the card. - -So, without further delay, here are the details. - - -PHYSICAL DESCRIPTION --------------------- - -The RadioTrack card is an ISA 8-bit FM radio card. The radio frequency (RF) -input is simply an antenna lead, and the output is a power audio signal -available through a miniature phone plug. Its RF frequencies of operation are -more or less limited from 87.0 to 109.0 MHz (the commercial FM broadcast -band). Although the registers can be programmed to request frequencies beyond -these limits, experiments did not give promising results. The variable -frequency oscillator (VFO) that demodulates the intermediate frequency (IF) -signal probably has a small range of useful frequencies, and wraps around or -gets clipped beyond the limits mentioned above. - - -CONTROLLING THE CARD WITH IOPORT --------------------------------- - -The RadioTrack (base) ioport is configurable for 0x30c or 0x20c. Only one -ioport seems to be involved. The ioport decoding circuitry must be pretty -simple, as individual ioport bits are directly matched to specific functions -(or blocks) of the radio card. This way, many functions can be changed in -parallel with one write to the ioport. The only feedback available through -the ioports appears to be the "Stereo Detect" bit. - -The bits of the ioport are arranged as follows: - -.. code-block:: none - - MSb LSb - +------+------+------+--------+--------+-------+---------+--------+ - | VolA | VolB | ???? | Stereo | Radio | TuneA | TuneB | Tune | - | (+) | (-) | | Detect | Audio | (bit) | (latch) | Update | - | | | | Enable | Enable | | | Enable | - +------+------+------+--------+--------+-------+---------+--------+ - - -==== ==== ================================= -VolA VolB Description -==== ==== ================================= -0 0 audio mute -0 1 volume + (some delay required) -1 0 volume - (some delay required) -1 1 stay at present volume -==== ==== ================================= - -==================== =========== -Stereo Detect Enable Description -==================== =========== -0 No Detect -1 Detect -==================== =========== - -Results available by reading ioport >60 msec after last port write. - - 0xff ==> no stereo detected, 0xfd ==> stereo detected. - -============================= ============================= -Radio to Audio (path) Enable Description -============================= ============================= -0 Disable path (silence) -1 Enable path (audio produced) -============================= ============================= - -===== ===== ================== -TuneA TuneB Description -===== ===== ================== -0 0 "zero" bit phase 1 -0 1 "zero" bit phase 2 -1 0 "one" bit phase 1 -1 1 "one" bit phase 2 -===== ===== ================== - - -24-bit code, where bits = (freq*40) + 10486188. -The Most Significant 11 bits must be 1010 xxxx 0x0 to be valid. -The bits are shifted in LSb first. - -================== =========================== -Tune Update Enable Description -================== =========================== -0 Tuner held constant -1 Tuner updating in progress -================== =========================== - - -PROGRAMMING EXAMPLES --------------------- - -.. code-block:: none - - Default: BASE <-- 0xc8 (current volume, no stereo detect, - radio enable, tuner adjust disable) - - Card Off: BASE <-- 0x00 (audio mute, no stereo detect, - radio disable, tuner adjust disable) - - Card On: BASE <-- 0x00 (see "Card Off", clears any unfinished business) - BASE <-- 0xc8 (see "Default") - - Volume Down: BASE <-- 0x48 (volume down, no stereo detect, - radio enable, tuner adjust disable) - wait 10 msec - BASE <-- 0xc8 (see "Default") - - Volume Up: BASE <-- 0x88 (volume up, no stereo detect, - radio enable, tuner adjust disable) - wait 10 msec - BASE <-- 0xc8 (see "Default") - - Check Stereo: BASE <-- 0xd8 (current volume, stereo detect, - radio enable, tuner adjust disable) - wait 100 msec - x <-- BASE (read ioport) - BASE <-- 0xc8 (see "Default") - - x=0xff ==> "not stereo", x=0xfd ==> "stereo detected" - - Set Frequency: code = (freq*40) + 10486188 - foreach of the 24 bits in code, - (from Least to Most Significant): - to write a "zero" bit, - BASE <-- 0x01 (audio mute, no stereo detect, radio - disable, "zero" bit phase 1, tuner adjust) - BASE <-- 0x03 (audio mute, no stereo detect, radio - disable, "zero" bit phase 2, tuner adjust) - to write a "one" bit, - BASE <-- 0x05 (audio mute, no stereo detect, radio - disable, "one" bit phase 1, tuner adjust) - BASE <-- 0x07 (audio mute, no stereo detect, radio - disable, "one" bit phase 2, tuner adjust) 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 <peter.missel@onlinehome.de> - -- LifeView FlyTV Platinum FM (LR214WF) - - - GP27 MDT2005 PB4 pin 10 - - GP26 MDT2005 PB3 pin 9 - - GP25 MDT2005 PB2 pin 8 - - GP23 MDT2005 PB1 pin 7 - - GP22 MDT2005 PB0 pin 6 - - GP21 MDT2005 PB5 pin 11 - - GP20 MDT2005 PB6 pin 12 - - GP19 MDT2005 PB7 pin 13 - - nc MDT2005 PA3 pin 2 - - Remote MDT2005 PA2 pin 1 - - GP18 MDT2005 PA1 pin 18 - - nc MDT2005 PA0 pin 17 strap low - - GP17 Strap "GP7"=High - - GP16 Strap "GP6"=High - - - 0=Radio 1=TV - - Drives SA630D ENCH1 and HEF4052 A1 pinsto do FM radio through - SIF input - - - GP15 nc - - GP14 nc - - GP13 nc - - GP12 Strap "GP5" = High - - GP11 Strap "GP4" = High - - GP10 Strap "GP3" = High - - GP09 Strap "GP2" = Low - - GP08 Strap "GP1" = Low - - GP07.00 nc - -Credits -------- - -andrew.stevens@philips.com + werner.leeb@philips.com for providing -saa7134 hardware specs and sample board. 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 <g.liakhovetski@gmx.de> - -Terminology ------------ - -sensor scales: horizontal and vertical scales, configured by the sensor driver -host scales: -"- host driver -combined scales: sensor_scale * host_scale - - -Generic scaling / cropping scheme ---------------------------------- - -.. code-block:: none - - -1-- - | - -2-- -\ - | --\ - | --\ - +-5-- . -- -3-- -\ - | `... -\ - | `... -4-- . - -7.. - | `. - | `. .6-- - | - | . .6'- - | .´ - | ... -4'- .´ - | ...´ - -7'. - +-5'- .´ -/ - | -- -3'- -/ - | --/ - | --/ - -2'- -/ - | - | - -1'- - -In the above chart minuses and slashes represent "real" data amounts, points and -accents represent "useful" data, basically, CEU scaled and cropped output, -mapped back onto the client's source plane. - -Such a configuration can be produced by user requests: - -S_CROP(left / top = (5) - (1), width / height = (5') - (5)) -S_FMT(width / height = (6') - (6)) - -Here: - -(1) to (1') - whole max width or height -(1) to (2) - sensor cropped left or top -(2) to (2') - sensor cropped width or height -(3) to (3') - sensor scale -(3) to (4) - CEU cropped left or top -(4) to (4') - CEU cropped width or height -(5) to (5') - reverse sensor scale applied to CEU cropped width or height -(2) to (5) - reverse sensor scale applied to CEU cropped left or top -(6) to (6') - CEU scale - user window - - -S_FMT ------ - -Do not touch input rectangle - it is already optimal. - -1. Calculate current sensor scales: - - scale_s = ((2') - (2)) / ((3') - (3)) - -2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at -current sensor scales onto input window - this is user S_CROP: - - width_u = (5') - (5) = ((4') - (4)) * scale_s - -3. Calculate new combined scales from "effective" input window to requested user -window: - - scale_comb = width_u / ((6') - (6)) - -4. Calculate sensor output window by applying combined scales to real input -window: - - width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb - -5. Apply iterative sensor S_FMT for sensor output window. - - subdev->video_ops->s_fmt(.width = width_s_out) - -6. Retrieve sensor output window (g_fmt) - -7. Calculate new sensor scales: - - scale_s_new = ((3')_new - (3)_new) / ((2') - (2)) - -8. Calculate new CEU crop - apply sensor scales to previously calculated -"effective" crop: - - width_ceu = (4')_new - (4)_new = width_u / scale_s_new - left_ceu = (4)_new - (3)_new = ((5) - (2)) / scale_s_new - -9. Use CEU cropping to crop to the new window: - - ceu_crop(.width = width_ceu, .left = left_ceu) - -10. Use CEU scaling to scale to the requested user window: - - scale_ceu = width_ceu / width - - -S_CROP ------- - -The :ref:`V4L2 crop API <crop-scale>` says: - -"...specification does not define an origin or units. However by convention -drivers should horizontally count unscaled samples relative to 0H." - -We choose to follow the advise and interpret cropping units as client input -pixels. - -Cropping is performed in the following 6 steps: - -1. Request exactly user rectangle from the sensor. - -2. If smaller - iterate until a larger one is obtained. Result: sensor cropped - to 2 : 2', target crop 5 : 5', current output format 6' - 6. - -3. In the previous step the sensor has tried to preserve its output frame as - good as possible, but it could have changed. Retrieve it again. - -4. Sensor scaled to 3 : 3'. Sensor's scale is (2' - 2) / (3' - 3). Calculate - intermediate window: 4' - 4 = (5' - 5) * (3' - 3) / (2' - 2) - -5. Calculate and apply host scale = (6' - 6) / (4' - 4) - -6. Calculate and apply host crop: 6 - 7 = (5 - 2) * (6' - 6) / (5' - 5) 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 |