* [PATCH 01/18] [media] doc-rst: move bttv documentation to bttv.rst file
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 02/18] [media] doc-rst: add documentation for bttv driver Mauro Carvalho Chehab
` (17 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet,
Randy Dunlap, Paul E. McKenney, Kees Cook, linux-doc
There were several files under Documentation/video4linux/bttv.
Instead of simply copying them to the rst folder, I opted to
merge into a single document and adjust the headers to
adjust the section levels and fix the cards tables.
There are two exceptions on the merge:
- The Tuners were renamed as a separate document, as they
describe a separate driver;
- I removed the PROBLEMS section. It describes problems with
the very first generation of 3D boards (Mistique/S3).
It sounds very unlikely that someone would still need to
install a bttv board on such hardware. Also, it is not
very well written, IMHO.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/bttv.rst | 1881 ++++++++++++++++++++
.../bttv/Tuners => media/v4l-drivers/tuners.rst} | 0
Documentation/video4linux/bttv/CONTRIBUTORS | 25 -
Documentation/video4linux/bttv/Cards | 960 ----------
Documentation/video4linux/bttv/ICs | 37 -
Documentation/video4linux/bttv/Insmod-options | 172 --
Documentation/video4linux/bttv/MAKEDEV | 27 -
Documentation/video4linux/bttv/Modprobe.conf | 11 -
Documentation/video4linux/bttv/Modules.conf | 14 -
Documentation/video4linux/bttv/PROBLEMS | 62 -
Documentation/video4linux/bttv/README | 90 -
Documentation/video4linux/bttv/README.WINVIEW | 33 -
Documentation/video4linux/bttv/README.freeze | 74 -
Documentation/video4linux/bttv/README.quirks | 83 -
Documentation/video4linux/bttv/Sound-FAQ | 148 --
Documentation/video4linux/bttv/Specs | 3 -
Documentation/video4linux/bttv/THANKS | 24 -
17 files changed, 1881 insertions(+), 1763 deletions(-)
create mode 100644 Documentation/media/v4l-drivers/bttv.rst
rename Documentation/{video4linux/bttv/Tuners => media/v4l-drivers/tuners.rst} (100%)
delete mode 100644 Documentation/video4linux/bttv/CONTRIBUTORS
delete mode 100644 Documentation/video4linux/bttv/Cards
delete mode 100644 Documentation/video4linux/bttv/ICs
delete mode 100644 Documentation/video4linux/bttv/Insmod-options
delete mode 100644 Documentation/video4linux/bttv/MAKEDEV
delete mode 100644 Documentation/video4linux/bttv/Modprobe.conf
delete mode 100644 Documentation/video4linux/bttv/Modules.conf
delete mode 100644 Documentation/video4linux/bttv/PROBLEMS
delete mode 100644 Documentation/video4linux/bttv/README
delete mode 100644 Documentation/video4linux/bttv/README.WINVIEW
delete mode 100644 Documentation/video4linux/bttv/README.freeze
delete mode 100644 Documentation/video4linux/bttv/README.quirks
delete mode 100644 Documentation/video4linux/bttv/Sound-FAQ
delete mode 100644 Documentation/video4linux/bttv/Specs
delete mode 100644 Documentation/video4linux/bttv/THANKS
diff --git a/Documentation/media/v4l-drivers/bttv.rst b/Documentation/media/v4l-drivers/bttv.rst
new file mode 100644
index 000000000000..d7d956835e38
--- /dev/null
+++ b/Documentation/media/v4l-drivers/bttv.rst
@@ -0,0 +1,1881 @@
+The bttv driver
+===============
+
+
+Release notes for bttv
+----------------------
+
+You'll need at least these config options for bttv:
+ CONFIG_I2C=m
+ CONFIG_I2C_ALGOBIT=m
+ CONFIG_VIDEO_DEV=m
+
+The latest bttv version is available from http://bytesex.org/bttv/
+
+
+Make bttv work with your card
+-----------------------------
+
+Just try "modprobe bttv" and see if that works.
+
+If it doesn't bttv likely could not autodetect your card and needs some
+insmod options. The most important insmod option for bttv is "card=n"
+to select the correct card type. If you get video but no sound you've
+very likely specified the wrong (or no) card type. A list of supported
+cards is in CARDLIST.bttv
+
+If bttv takes very long to load (happens sometimes with the cheap
+cards which have no tuner), try adding this to your modules.conf:
+ options i2c-algo-bit bit_test=1
+
+For the WinTV/PVR you need one firmware file from the driver CD:
+hcwamc.rbf. The file is in the pvr45xxx.exe archive (self-extracting
+zip file, unzip can unpack it). Put it into the /etc/pvr directory or
+use the firm_altera=<path> insmod option to point the driver to the
+location of the file.
+
+If your card isn't listed in CARDLIST.bttv or if you have trouble making
+audio work, you should read the Sound-FAQ.
+
+
+Autodetecting cards
+-------------------
+
+bttv uses the PCI Subsystem ID to autodetect the card type. lspci lists
+the Subsystem ID in the second line, looks like this:
+
+00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
+ Subsystem: Hauppauge computer works Inc. WinTV/GO
+ Flags: bus master, medium devsel, latency 32, IRQ 5
+ Memory at e2000000 (32-bit, prefetchable) [size=4K]
+
+only bt878-based cards can have a subsystem ID (which does not mean
+that every card really has one). bt848 cards can't have a Subsystem
+ID and therefore can't be autodetected. There is a list with the ID's
+in bttv-cards.c (in case you are intrested or want to mail patches
+with updates).
+
+
+Still doesn't work?
+-------------------
+
+I do NOT have a lab with 30+ different grabber boards and a
+PAL/NTSC/SECAM test signal generator at home, so I often can't
+reproduce your problems. This makes debugging very difficult for me.
+If you have some knowledge and spare time, please try to fix this
+yourself (patches very welcome of course...) You know: The linux
+slogan is "Do it yourself".
+
+There is a mailing list: linux-media@vger.kernel.org
+http://vger.kernel.org/vger-lists.html#linux-media
+
+If you have trouble with some specific TV card, try to ask there
+instead of mailing me directly. The chance that someone with the
+same card listens there is much higher...
+
+For problems with sound: There are a lot of different systems used
+for TV sound all over the world. And there are also different chips
+which decode the audio signal. Reports about sound problems ("stereo
+does'nt work") are pretty useless unless you include some details
+about your hardware and the TV sound scheme used in your country (or
+at least the country you are living in).
+
+Modprobe options
+----------------
+
+Note: "modinfo <module>" prints various information about a kernel
+module, among them a complete and up-to-date list of insmod options.
+This list tends to be outdated because it is updated manually ...
+
+==========================================================================
+
+bttv.o
+
+::
+
+ the bt848/878 (grabber chip) driver
+
+ insmod args:
+ card=n card type, see CARDLIST for a list.
+ tuner=n tuner type, see CARDLIST for a list.
+ radio=0/1 card supports radio
+ pll=0/1/2 pll settings
+ 0: don't use PLL
+ 1: 28 MHz crystal installed
+ 2: 35 MHz crystal installed
+
+ triton1=0/1 for Triton1 (+others) compatibility
+ vsfx=0/1 yet another chipset bug compatibility bit
+ see README.quirks for details on these two.
+
+ bigendian=n Set the endianness of the gfx framebuffer.
+ Default is native endian.
+ fieldnr=0/1 Count fields. Some TV descrambling software
+ needs this, for others it only generates
+ 50 useless IRQs/sec. default is 0 (off).
+ autoload=0/1 autoload helper modules (tuner, audio).
+ default is 1 (on).
+ bttv_verbose=0/1/2 verbose level (at insmod time, while
+ looking at the hardware). default is 1.
+ bttv_debug=0/1 debug messages (for capture).
+ default is 0 (off).
+ irq_debug=0/1 irq handler debug messages.
+ default is 0 (off).
+ gbuffers=2-32 number of capture buffers for mmap'ed capture.
+ default is 4.
+ gbufsize= size of capture buffers. default and
+ maximum value is 0x208000 (~2MB)
+ no_overlay=0 Enable overlay on broken hardware. There
+ are some chipsets (SIS for example) which
+ are known to have problems with the PCI DMA
+ push used by bttv. bttv will disable overlay
+ by default on this hardware to avoid crashes.
+ With this insmod option you can override this.
+ no_overlay=1 Disable overlay. It should be used by broken
+ hardware that doesn't support PCI2PCI direct
+ transfers.
+ automute=0/1 Automatically mutes the sound if there is
+ no TV signal, on by default. You might try
+ to disable this if you have bad input signal
+ quality which leading to unwanted sound
+ dropouts.
+ chroma_agc=0/1 AGC of chroma signal, off by default.
+ adc_crush=0/1 Luminance ADC crush, on by default.
+ i2c_udelay= Allow reduce I2C speed. Default is 5 usecs
+ (meaning 66,67 Kbps). The default is the
+ maximum supported speed by kernel bitbang
+ algorithm. You may use lower numbers, if I2C
+ messages are lost (16 is known to work on
+ all supported cards).
+
+ bttv_gpio=0/1
+ gpiomask=
+ audioall=
+ audiomux=
+ See Sound-FAQ for a detailed description.
+
+ remap, card, radio and pll accept up to four comma-separated arguments
+ (for multiple boards).
+
+tuner.o
+
+::
+
+ The tuner driver. You need this unless you want to use only
+ with a camera or external tuner ...
+
+ insmod args:
+ debug=1 print some debug info to the syslog
+ type=n type of the tuner chip. n as follows:
+ see CARDLIST for a complete list.
+ pal=[bdgil] select PAL variant (used for some tuners
+ only, important for the audio carrier).
+
+tvaudio.o
+
+::
+
+ new, experimental module which is supported to provide a single
+ driver for all simple i2c audio control chips (tda/tea*).
+
+ insmod args:
+ tda8425 = 1 enable/disable the support for the
+ tda9840 = 1 various chips.
+ tda9850 = 1 The tea6300 can't be autodetected and is
+ tda9855 = 1 therefore off by default, if you have
+ tda9873 = 1 this one on your card (STB uses these)
+ tda9874a = 1 you have to enable it explicitly.
+ tea6300 = 0 The two tda985x chips use the same i2c
+ tea6420 = 1 address and can't be disturgished from
+ pic16c54 = 1 each other, you might have to disable
+ the wrong one.
+ debug = 1 print debug messages
+
+ insmod args for tda9874a:
+ tda9874a_SIF=1/2 select sound IF input pin (1 or 2)
+ (default is pin 1)
+ tda9874a_AMSEL=0/1 auto-mute select for NICAM (default=0)
+ Please read note 3 below!
+ tda9874a_STD=n select TV sound standard (0..8):
+ 0 - A2, B/G
+ 1 - A2, M (Korea)
+ 2 - A2, D/K (1)
+ 3 - A2, D/K (2)
+ 4 - A2, D/K (3)
+ 5 - NICAM, I
+ 6 - NICAM, B/G
+ 7 - NICAM, D/K (default)
+ 8 - NICAM, L
+
+ Note 1: tda9874a supports both tda9874h (old) and tda9874a (new) chips.
+ Note 2: tda9874h/a and tda9875 (which is supported separately by
+ tda9875.o) use the same i2c address so both modules should not be
+ used at the same time.
+ Note 3: Using tda9874a_AMSEL option depends on your TV card design!
+ AMSEL=0: auto-mute will switch between NICAM sound
+ and the sound on 1st carrier (i.e. FM mono or AM).
+ AMSEL=1: auto-mute will switch between NICAM sound
+ and the analog mono input (MONOIN pin).
+ If tda9874a decoder on your card has MONOIN pin not connected, then
+ use only tda9874_AMSEL=0 or don't specify this option at all.
+ For example:
+ card=65 (FlyVideo 2000S) - set AMSEL=1 or AMSEL=0
+ card=72 (Prolink PV-BT878P rev.9B) - set AMSEL=0 only
+
+msp3400.o
+
+::
+
+
+ The driver for the msp34xx sound processor chips. If you have a
+ stereo card, you probably want to insmod this one.
+
+ insmod args:
+ debug=1/2 print some debug info to the syslog,
+ 2 is more verbose.
+ simple=1 Use the "short programming" method. Newer
+ msp34xx versions support this. You need this
+ for dbx stereo. Default is on if supported by
+ the chip.
+ once=1 Don't check the TV-stations Audio mode
+ every few seconds, but only once after
+ channel switches.
+ amsound=1 Audio carrier is AM/NICAM at 6.5 Mhz. This
+ should improve things for french people, the
+ carrier autoscan seems to work with FM only...
+
+tea6300.o - OBSOLETE (use tvaudio instead)
+
+::
+
+ The driver for the tea6300 fader chip. If you have a stereo
+ card and the msp3400.o doesn't work, you might want to try this
+ one. This chip is seen on most STB TV/FM cards (usually from
+ Gateway OEM sold surplus on auction sites).
+
+ insmod args:
+ debug=1 print some debug info to the syslog.
+
+tda8425.o - OBSOLETE (use tvaudio instead)
+
+::
+
+ The driver for the tda8425 fader chip. This driver used to be
+ part of bttv.c, so if your sound used to work but does not
+ anymore, try loading this module.
+
+ insmod args:
+ debug=1 print some debug info to the syslog.
+
+tda985x.o - OBSOLETE (use tvaudio instead)
+
+::
+
+ The driver for the tda9850/55 audio chips.
+
+ insmod args:
+ debug=1 print some debug info to the syslog.
+ chip=9850/9855 set the chip type.
+
+
+If the box freezes hard with bttv
+---------------------------------
+
+It might be a bttv driver bug. It also might be bad hardware. It also
+might be something else ...
+
+Just mailing me "bttv freezes" isn't going to help much. This README
+has a few hints how you can help to pin down the problem.
+
+
+bttv bugs
+~~~~~~~~~
+
+If some version works and another doesn't it is likely to be a driver
+bug. It is very helpful if you can tell where exactly it broke
+(i.e. the last working and the first broken version).
+
+With a hard freeze you probably doesn't find anything in the logfiles.
+The only way to capture any kernel messages is to hook up a serial
+console and let some terminal application log the messages. /me uses
+screen. See Documentation/serial-console.txt for details on setting
+up a serial console.
+
+Read Documentation/oops-tracing.txt to learn how to get any useful
+information out of a register+stack dump printed by the kernel on
+protection faults (so-called "kernel oops").
+
+If you run into some kind of deadlock, you can try to dump a call trace
+for each process using sysrq-t (see Documentation/sysrq.txt).
+This way it is possible to figure where *exactly* some process in "D"
+state is stuck.
+
+I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid
+for some people. Thus probably a small buglet left somewhere in bttv
+0.7.x. I have no idea where exactly, it works stable for me and a lot of
+other people. But in case you have problems with the 0.7.x versions you
+can give 0.8.x a try ...
+
+
+hardware bugs
+~~~~~~~~~~~~~
+
+Some hardware can't deal with PCI-PCI transfers (i.e. grabber => vga).
+Sometimes problems show up with bttv just because of the high load on
+the PCI bus. The bt848/878 chips have a few workarounds for known
+incompatibilities, see README.quirks.
+
+Some folks report that increasing the pci latency helps too,
+althrought I'm not sure whenever this really fixes the problems or
+only makes it less likely to happen. Both bttv and btaudio have a
+insmod option to set the PCI latency of the device.
+
+Some mainboard have problems to deal correctly with multiple devices
+doing DMA at the same time. bttv + ide seems to cause this sometimes,
+if this is the case you likely see freezes only with video and hard disk
+access at the same time. Updating the IDE driver to get the latest and
+greatest workarounds for hardware bugs might fix these problems.
+
+
+other
+~~~~~
+
+If you use some binary-only yunk (like nvidia module) try to reproduce
+the problem without.
+
+IRQ sharing is known to cause problems in some cases. It works just
+fine in theory and many configurations. Neverless it might be worth a
+try to shuffle around the PCI cards to give bttv another IRQ or make
+it share the IRQ with some other piece of hardware. IRQ sharing with
+VGA cards seems to cause trouble sometimes. I've also seen funny
+effects with bttv sharing the IRQ with the ACPI bridge (and
+apci-enabled kernel).
+
+Bttv quirks
+-----------
+
+Below is what the bt878 data book says about the PCI bug compatibility
+modes of the bt878 chip.
+
+The triton1 insmod option sets the EN_TBFX bit in the control register.
+The vsfx insmod option does the same for EN_VSFX bit. If you have
+stability problems you can try if one of these options makes your box
+work solid.
+
+drivers/pci/quirks.c knows about these issues, this way these bits are
+enabled automagically for known-buggy chipsets (look at the kernel
+messages, bttv tells you).
+
+Normal PCI Mode
+~~~~~~~~~~~~~~~
+
+The PCI REQ signal is the logical-or of the incoming function requests.
+The inter-nal GNT[0:1] signals are gated asynchronously with GNT and
+demultiplexed by the audio request signal. Thus the arbiter defaults to
+the video function at power-up and parks there during no requests for
+bus access. This is desirable since the video will request the bus more
+often. However, the audio will have highest bus access priority. Thus
+the audio will have first access to the bus even when issuing a request
+after the video request but before the PCI external arbiter has granted
+access to the Bt879. Neither function can preempt the other once on the
+bus. The duration to empty the entire video PCI FIFO onto the PCI bus is
+very short compared to the bus access latency the audio PCI FIFO can
+tolerate.
+
+
+430FX Compatibility Mode
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+When using the 430FX PCI, the following rules will ensure
+compatibility:
+
+ (1) Deassert REQ at the same time as asserting FRAME.
+ (2) Do not reassert REQ to request another bus transaction until after
+ finish-ing the previous transaction.
+
+Since the individual bus masters do not have direct control of REQ, a
+simple logical-or of video and audio requests would violate the rules.
+Thus, both the arbiter and the initiator contain 430FX compatibility
+mode logic. To enable 430FX mode, set the EN_TBFX bit as indicated in
+Device Control Register on page 104.
+
+When EN_TBFX is enabled, the arbiter ensures that the two compatibility
+rules are satisfied. Before GNT is asserted by the PCI arbiter, this
+internal arbiter may still logical-or the two requests. However, once
+the GNT is issued, this arbiter must lock in its decision and now route
+only the granted request to the REQ pin. The arbiter decision lock
+happens regardless of the state of FRAME because it does not know when
+FRAME will be asserted (typically - each initiator will assert FRAME on
+the cycle following GNT). When FRAME is asserted, it is the initiator s
+responsibility to remove its request at the same time. It is the
+arbiters responsibility to allow this request to flow through to REQ and
+not allow the other request to hold REQ asserted. The decision lock may
+be removed at the end of the transaction: for example, when the bus is
+idle (FRAME and IRDY). The arbiter decision may then continue
+asynchronously until GNT is again asserted.
+
+
+Interfacing with Non-PCI 2.1 Compliant Core Logic
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A small percentage of core logic devices may start a bus transaction
+during the same cycle that GNT is de-asserted. This is non PCI 2.1
+compliant. To ensure compatibility when using PCs with these PCI
+controllers, the EN_VSFX bit must be enabled (refer to Device Control
+Register on page 104). When in this mode, the arbiter does not pass GNT
+to the internal functions unless REQ is asserted. This prevents a bus
+transaction from starting the same cycle as GNT is de-asserted. This
+also has the side effect of not being able to take advantage of bus
+parking, thus lowering arbitration performance. The Bt879 drivers must
+query for these non-compliant devices, and set the EN_VSFX bit only if
+required.
+
+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:
+
+ 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:
+
+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
+does'nt 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:
+
+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:
+
+ 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
+
+
+
+Other elements of the tvcards array
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you are trying to make a new card work you might find it useful to
+know what the other elements in the tvcards array are good for:
+
+video_inputs - # of video inputs the card has
+audio_inputs - historical cruft, not used any more.
+tuner - which input is the tuner
+svhs - which input is svhs (all others are labeled composite)
+muxsel - video mux, input->registervalue mapping
+pll - same as pll= insmod option
+tuner_type - same as tuner= insmod option
+*_modulename - hint whenever some card needs this or that audio
+ module loaded to work properly.
+has_radio - whenever this TV card has a radio tuner.
+no_msp34xx - "1" disables loading of msp3400.o module
+no_tda9875 - "1" disables loading of tda9875.o module
+needs_tvaudio - set to "1" to load tvaudio.o module
+
+If some config item is specified both from the tvcards array and as
+insmod option, the insmod option takes precedence.
+
+Cards
+-----
+
+.. note::
+ For a more updated list, please check
+ https://linuxtv.org/wiki/index.php/Hardware_Device_Information
+
+Supported cards: Bt848/Bt848a/Bt849/Bt878/Bt879 cards
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All cards with Bt848/Bt848a/Bt849/Bt878/Bt879 and normal
+Composite/S-VHS inputs are supported. Teletext and Intercast support
+(PAL only) for ALL cards via VBI sample decoding in software.
+
+Some cards with additional multiplexing of inputs or other additional
+fancy chips are only partially supported (unless specifications by the
+card manufacturer are given). When a card is listed here it isn't
+necessarily fully supported.
+
+All other cards only differ by additional components as tuners, sound
+decoders, EEPROMs, teletext decoders ...
+
+
+MATRIX Vision
+~~~~~~~~~~~~~
+
+MV-Delta
+- Bt848A
+- 4 Composite inputs, 1 S-VHS input (shared with 4th composite)
+- EEPROM
+
+http://www.matrix-vision.de/
+
+This card has no tuner but supports all 4 composite (1 shared with an
+S-VHS input) of the Bt848A.
+Very nice card if you only have satellite TV but several tuners connected
+to the card via composite.
+
+Many thanks to Matrix-Vision for giving us 2 cards for free which made
+Bt848a/Bt849 single crystal operation support possible!!!
+
+
+
+Miro/Pinnacle PCTV
+~~~~~~~~~~~~~~~~~~
+
+- Bt848
+ some (all??) come with 2 crystals for PAL/SECAM and NTSC
+- PAL, SECAM or NTSC TV tuner (Philips or TEMIC)
+- MSP34xx sound decoder on add on board
+ decoder is supported but AFAIK does not yet work
+ (other sound MUX setting in GPIO port needed??? somebody who fixed this???)
+- 1 tuner, 1 composite and 1 S-VHS input
+- tuner type is autodetected
+
+http://www.miro.de/
+http://www.miro.com/
+
+
+Many thanks for the free card which made first NTSC support possible back
+in 1997!
+
+
+Hauppauge Win/TV pci
+~~~~~~~~~~~~~~~~~~~~
+
+There are many different versions of the Hauppauge cards with different
+tuners (TV+Radio ...), teletext decoders.
+Note that even cards with same model numbers have (depending on the revision)
+different chips on it.
+
+- Bt848 (and others but always in 2 crystal operation???)
+ newer cards have a Bt878
+
+- PAL, SECAM, NTSC or tuner with or without Radio support
+
+e.g.:
+
+- PAL:
+
+ - TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
+ - TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3
+
+- NTSC:
+
+ - TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
+ - TSA5518: no datasheet available on Philips site
+
+- Philips SAA5246 or SAA5284 ( or no) Teletext decoder chip
+ with buffer RAM (e.g. Winbond W24257AS-35: 32Kx8 CMOS static RAM)
+ SAA5246 (I2C 0x22) is supported
+
+- 256 bytes EEPROM: Microchip 24LC02B or Philips 8582E2Y
+ with configuration information
+ I2C address 0xa0 (24LC02B also responds to 0xa2-0xaf)
+
+- 1 tuner, 1 composite and (depending on model) 1 S-VHS input
+
+- 14052B: mux for selection of sound source
+
+- sound decoder: TDA9800, MSP34xx (stereo cards)
+
+
+Askey CPH-Series
+~~~~~~~~~~~~~~~~
+Developed by TelSignal(?), OEMed by many vendors (Typhoon, Anubis, Dynalink)
+
+- Card series:
+ - CPH01x: BT848 capture only
+ - CPH03x: BT848
+ - CPH05x: BT878 with FM
+ - CPH06x: BT878 (w/o FM)
+ - CPH07x: BT878 capture only
+
+- TV standards:
+ - CPH0x0: NTSC-M/M
+ - CPH0x1: PAL-B/G
+ - CPH0x2: PAL-I/I
+ - CPH0x3: PAL-D/K
+ - CPH0x4: SECAM-L/L
+ - CPH0x5: SECAM-B/G
+ - CPH0x6: SECAM-D/K
+ - CPH0x7: PAL-N/N
+ - CPH0x8: PAL-B/H
+ - CPH0x9: PAL-M/M
+
+- CPH03x was often sold as "TV capturer".
+
+Identifying:
+
+ #) 878 cards can be identified by PCI Subsystem-ID:
+ - 144f:3000 = CPH06x
+ - 144F:3002 = CPH05x w/ FM
+ - 144F:3005 = CPH06x_LC (w/o remote control)
+ #) The cards have a sticker with "CPH"-model on the back.
+ #) These cards have a number printed on the PCB just above the tuner metal box:
+ - "80-CP2000300-x" = CPH03X
+ - "80-CP2000500-x" = CPH05X
+ - "80-CP2000600-x" = CPH06X / CPH06x_LC
+
+ Askey sells these cards as "Magic TView series", Brand "MagicXpress".
+ Other OEM often call these "Tview", "TView99" or else.
+
+Lifeview Flyvideo Series:
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The naming of these series differs in time and space.
+
+Identifying:
+ #) Some models can be identified by PCI subsystem ID:
+
+ - 1852:1852 = Flyvideo 98 FM
+ - 1851:1850 = Flyvideo 98
+ - 1851:1851 = Flyvideo 98 EZ (capture only)
+
+ #) There is a print on the PCB:
+
+ - LR25 = Flyvideo (Zoran ZR36120, SAA7110A)
+ - LR26 Rev.N = Flyvideo II (Bt848)
+ - LR26 Rev.O = Flyvideo II (Bt878)
+ - LR37 Rev.C = Flyvideo EZ (Capture only, ZR36120 + SAA7110)
+ - LR38 Rev.A1= Flyvideo II EZ (Bt848 capture only)
+ - LR50 Rev.Q = Flyvideo 98 (w/eeprom and PCI subsystem ID)
+ - LR50 Rev.W = Flyvideo 98 (no eeprom)
+ - LR51 Rev.E = Flyvideo 98 EZ (capture only)
+ - LR90 = Flyvideo 2000 (Bt878)
+ - LR90 Flyvideo 2000S (Bt878) w/Stereo TV (Package incl. LR91 daughterboard)
+ - LR91 = Stereo daughter card for LR90
+ - LR97 = Flyvideo DVBS
+ - LR99 Rev.E = Low profile card for OEM integration (only internal audio!) bt878
+ - LR136 = Flyvideo 2100/3100 (Low profile, SAA7130/SAA7134)
+ - LR137 = Flyvideo DV2000/DV3000 (SAA7130/SAA7134 + IEEE1394)
+ - LR138 Rev.C= Flyvideo 2000 (SAA7130)
+ - LR138 Flyvideo 3000 (SAA7134) w/Stereo TV
+ - These exist in variations w/FM and w/Remote sometimes denoted
+ by suffixes "FM" and "R".
+
+ #) You have a laptop (miniPCI card):
+ - Product = FlyTV Platinum Mini
+ - Model/Chip = LR212/saa7135
+
+ - Lifeview.com.tw states (Feb. 2002):
+ "The FlyVideo2000 and FlyVideo2000s product name have renamed to FlyVideo98."
+ Their Bt8x8 cards are listed as discontinued.
+ - Flyvideo 2000S was probably sold as Flyvideo 3000 in some contries(Europe?).
+ The new Flyvideo 2000/3000 are SAA7130/SAA7134 based.
+
+"Flyvideo II" had been the name for the 848 cards, nowadays (in Germany)
+this name is re-used for LR50 Rev.W.
+
+The Lifeview website mentioned Flyvideo III at some time, but such a card
+has not yet been seen (perhaps it was the german name for LR90 [stereo]).
+These cards are sold by many OEMs too.
+
+FlyVideo A2 (Elta 8680)= LR90 Rev.F (w/Remote, w/o FM, stereo TV by tda9821) {Germany}
+
+Lifeview 3000 (Elta 8681) as sold by Plus(April 2002), Germany = LR138 w/ saa7134
+
+
+Typhoon TV card series:
+~~~~~~~~~~~~~~~~~~~~~~~
+
+These can be CPH, Flyvideo, Pixelview or KNC1 series.
+Typhoon is the brand of Anubis.
+Model 50680 got re-used, some model no. had different contents over time.
+
+Models:
+
+ - 50680 "TV Tuner PCI Pal BG"(old,red package)=can be CPH03x(bt848) or CPH06x(bt878)
+ - 50680 "TV Tuner Pal BG" (blue package)= Pixelview PV-BT878P+ (Rev 9B)
+ - 50681 "TV Tuner PCI Pal I" (variant of 50680)
+ - 50682 "TView TV/FM Tuner Pal BG" = Flyvideo 98FM (LR50 Rev.Q)
+
+ .. note::
+
+ The package has a picture of CPH05x (which would be a real TView)
+
+ - 50683 "TV Tuner PCI SECAM" (variant of 50680)
+ - 50684 "TV Tuner Pal BG" = Pixelview 878TV(Rev.3D)
+ - 50686 "TV Tuner" = KNC1 TV Station
+ - 50687 "TV Tuner stereo" = KNC1 TV Station pro
+ - 50688 "TV Tuner RDS" (black package) = KNC1 TV Station RDS
+ - 50689 TV SAT DVB-S CARD CI PCI (SAA7146AH, SU1278?) = "KNC1 TV Station DVB-S"
+ - 50692 "TV/FM Tuner" (small PCB)
+ - 50694 TV TUNER CARD RDS (PHILIPS CHIPSET SAA7134HL)
+ - 50696 TV TUNER STEREO (PHILIPS CHIPSET SAA7134HL, MK3ME Tuner)
+ - 50804 PC-SAT TV/Audio Karte = Techni-PC-Sat (ZORAN 36120PQC, Tuner:Alps)
+ - 50866 TVIEW SAT RECEIVER+ADR
+ - 50868 "TV/FM Tuner Pal I" (variant of 50682)
+ - 50999 "TV/FM Tuner Secam" (variant of 50682)
+
+Guillemot
+~~~~~~~~~
+
+Models:
+
+- Maxi-TV PCI (ZR36120)
+- Maxi TV Video 2 = LR50 Rev.Q (FI1216MF, PAL BG+SECAM)
+- Maxi TV Video 3 = CPH064 (PAL BG + SECAM)
+
+Mentor
+~~~~~~
+
+Mentor TV card ("55-878TV-U1") = Pixelview 878TV(Rev.3F) (w/FM w/Remote)
+
+Prolink
+~~~~~~~
+
+- TV cards:
+
+ - PixelView Play TV pro - (Model: PV-BT878P+ REV 8E)
+ - PixelView Play TV pro - (Model: PV-BT878P+ REV 9D)
+ - PixelView Play TV pro - (Model: PV-BT878P+ REV 4C / 8D / 10A )
+ - PixelView Play TV - (Model: PV-BT848P+)
+ - 878TV - (Model: PV-BT878TV)
+
+- Multimedia TV packages (card + software pack):
+
+ - PixelView Play TV Theater - (Model: PV-M4200) = PixelView Play TV pro + Software
+ - PixelView Play TV PAK - (Model: PV-BT878P+ REV 4E)
+ - PixelView Play TV/VCR - (Model: PV-M3200 REV 4C / 8D / 10A )
+ - PixelView Studio PAK - (Model: M2200 REV 4C / 8D / 10A )
+ - PixelView PowerStudio PAK - (Model: PV-M3600 REV 4E)
+ - PixelView DigitalVCR PAK - (Model: PV-M2400 REV 4C / 8D / 10A )
+ - PixelView PlayTV PAK II (TV/FM card + usb camera) PV-M3800
+ - PixelView PlayTV XP PV-M4700,PV-M4700(w/FM)
+ - PixelView PlayTV DVR PV-M4600 package contents:PixelView PlayTV pro, windvr & videoMail s/w
+
+- Further Cards:
+
+ - PV-BT878P+rev.9B (Play TV Pro, opt. w/FM w/NICAM)
+ - PV-BT878P+rev.2F
+ - PV-BT878P Rev.1D (bt878, capture only)
+
+ - XCapture PV-CX881P (cx23881)
+ - PlayTV HD PV-CX881PL+, PV-CX881PL+(w/FM) (cx23881)
+
+ - DTV3000 PV-DTV3000P+ DVB-S CI = Twinhan VP-1030
+ - DTV2000 DVB-S = Twinhan VP-1020
+
+- Video Conferencing:
+
+ - PixelView Meeting PAK - (Model: PV-BT878P)
+ - PixelView Meeting PAK Lite - (Model: PV-BT878P)
+ - PixelView Meeting PAK plus - (Model: PV-BT878P+rev 4C/8D/10A)
+ - PixelView Capture - (Model: PV-BT848P)
+ - PixelView PlayTV USB pro
+ - Model No. PV-NT1004+, PV-NT1004+ (w/FM) = NT1004 USB decoder chip + SAA7113 video decoder chip
+
+Dynalink
+~~~~~~~~
+
+These are CPH series.
+
+Phoebemicro
+~~~~~~~~~~~
+
+- TV Master = CPH030 or CPH060
+- TV Master FM = CPH050
+
+Genius/Kye
+~~~~~~~~~~
+
+- Video Wonder/Genius Internet Video Kit = LR37 Rev.C
+- Video Wonder Pro II (848 or 878) = LR26
+
+Tekram
+~~~~~~
+
+- VideoCap C205 (Bt848)
+- VideoCap C210 (zr36120 +Philips)
+- CaptureTV M200 (ISA)
+- CaptureTV M205 (Bt848)
+
+Lucky Star
+~~~~~~~~~~
+
+- Image World Conference TV = LR50 Rev. Q
+
+Leadtek
+~~~~~~~
+
+- WinView 601 (Bt848)
+- WinView 610 (Zoran)
+- WinFast2000
+- WinFast2000 XP
+
+Support for the Leadtek WinView 601 TV/FM
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Author of this section: Jon Tombs <jon@gte.esi.us.es>
+
+This card is basically the same as all the rest (Bt484A, Philips tuner),
+the main difference is that they have attached a programmable attenuator to 3
+GPIO lines in order to give some volume control. They have also stuck an
+infra-red remote control decoded on the board, I will add support for this
+when I get time (it simple generates an interrupt for each key press, with
+the key code is placed in the GPIO port).
+
+I don't yet have any application to test the radio support. The tuner
+frequency setting should work but it is possible that the audio multiplexer
+is wrong. If it doesn't work, send me email.
+
+
+- No Thanks to Leadtek they refused to answer any questions about their
+hardware. The driver was written by visual inspection of the card. If you
+use this driver, send an email insult to them, and tell them you won't
+continue buying their hardware unless they support Linux.
+
+- Little thanks to Princeton Technology Corp (http://www.princeton.com.tw)
+who make the audio attenuator. Their publicly available data-sheet available
+on their web site doesn't include the chip programming information! Hidden
+on their server are the full data-sheets, but don't ask how I found it.
+
+To use the driver I use the following options, the tuner and pll settings might
+be different in your country
+
+insmod videodev
+insmod i2c scan=1 i2c_debug=0 verbose=0
+insmod tuner type=1 debug=0
+insmod bttv pll=1 radio=1 card=17
+
+
+KNC One
+~~~~~~~
+
+- TV-Station
+- TV-Station SE (+Software Bundle)
+- TV-Station pro (+TV stereo)
+- TV-Station FM (+Radio)
+- TV-Station RDS (+RDS)
+- TV Station SAT (analog satellite)
+- TV-Station DVB-S
+
+.. note:: newer Cards have saa7134, but model name stayed the same?
+
+Provideo
+~~~~~~~~
+
+- PV951 or PV-951 (also are sold as:
+ Boeder TV-FM Video Capture Card,
+ Titanmedia Supervision TV-2400,
+ Provideo PV951 TF,
+ 3DeMon PV951,
+ MediaForte TV-Vision PV951,
+ Yoko PV951,
+ Vivanco Tuner Card PCI Art.-Nr.: 68404,
+ ) now named PV-951T
+
+- Surveillance Series:
+
+ - PV-141
+ - PV-143
+ - PV-147
+ - PV-148 (capture only)
+ - PV-150
+ - PV-151
+
+- TV-FM Tuner Series:
+
+ - PV-951TDV (tv tuner + 1394)
+ - PV-951T/TF
+ - PV-951PT/TF
+ - PV-956T/TF Low Profile
+ - PV-911
+
+Highscreen
+~~~~~~~~~~
+
+Models:
+
+- TV Karte = LR50 Rev.S
+- TV-Boostar = Terratec Terra TV+ Version 1.0 (Bt848, tda9821) "ceb105.pcb"
+
+Zoltrix
+~~~~~~~
+
+Models:
+
+- Face to Face Capture (Bt848 capture only) (PCB "VP-2848")
+- Face To Face TV MAX (Bt848) (PCB "VP-8482 Rev1.3")
+- Genie TV (Bt878) (PCB "VP-8790 Rev 2.1")
+- Genie Wonder Pro
+
+AVerMedia
+~~~~~~~~~
+
+- AVer FunTV Lite (ISA, AV3001 chipset) "M101.C"
+- AVerTV
+- AVerTV Stereo
+- AVerTV Studio (w/FM)
+- AVerMedia TV98 with Remote
+- AVerMedia TV/FM98 Stereo
+- AVerMedia TVCAM98
+- TVCapture (Bt848)
+- TVPhone (Bt848)
+- TVCapture98 (="AVerMedia TV98" in USA) (Bt878)
+- TVPhone98 (Bt878, w/FM)
+
+======== =========== =============== ======= ====== ======== =======================
+PCB PCI-ID Model-Name Eeprom Tuner Sound Country
+======== =========== =============== ======= ====== ======== =======================
+M101.C ISA !
+M108-B Bt848 -- FR1236 US [#f2]_,[#f3]_
+M1A8-A Bt848 AVer TV-Phone FM1216 --
+M168-T 1461:0003 AVerTV Studio 48:17 FM1216 TDA9840T D [#f1]_ w/FM w/Remote
+M168-U 1461:0004 TVCapture98 40:11 FI1216 -- D w/Remote
+M168II-B 1461:0003 Medion MD9592 48:16 FM1216 TDA9873H D w/FM
+======== =========== =============== ======= ====== ======== =======================
+
+.. [#f1] Daughterboard MB68-A with TDA9820T and TDA9840T
+.. [#f2] Sony NE41S soldered (stereo sound?)
+.. [#f3] Daughterboard M118-A w/ pic 16c54 and 4 MHz quartz
+
+- US site has different drivers for (as of 09/2002):
+
+ - EZ Capture/InterCam PCI (BT-848 chip)
+ - EZ Capture/InterCam PCI (BT-878 chip)
+ - TV-Phone (BT-848 chip)
+ - TV98 (BT-848 chip)
+ - TV98 With Remote (BT-848 chip)
+ - TV98 (BT-878 chip)
+ - TV98 With Remote (BT-878)
+ - TV/FM98 (BT-878 chip)
+ - AVerTV
+ - AverTV Stereo
+ - AVerTV Studio
+
+DE hat diverse Treiber fuer diese Modelle (Stand 09/2002):
+
+ - TVPhone (848) mit Philips tuner FR12X6 (w/ FM radio)
+ - TVPhone (848) mit Philips tuner FM12X6 (w/ FM radio)
+ - TVCapture (848) w/Philips tuner FI12X6
+ - TVCapture (848) non-Philips tuner
+ - TVCapture98 (Bt878)
+ - TVPhone98 (Bt878)
+ - AVerTV und TVCapture98 w/VCR (Bt 878)
+ - AVerTVStudio und TVPhone98 w/VCR (Bt878)
+ - AVerTV GO Serie (Kein SVideo Input)
+ - AVerTV98 (BT-878 chip)
+ - AVerTV98 mit Fernbedienung (BT-878 chip)
+ - AVerTV/FM98 (BT-878 chip)
+
+ - VDOmate (www.averm.com.cn) = M168U ?
+
+Aimslab
+~~~~~~~
+
+Models:
+
+- Video Highway or "Video Highway TR200" (ISA)
+- Video Highway Xtreme (aka "VHX") (Bt848, FM w/ TEA5757)
+
+IXMicro (former: IMS=Integrated Micro Solutions)
+~~~~~~~
+
+Models:
+
+- IXTV BT848 (=TurboTV)
+- IXTV BT878
+- IMS TurboTV (Bt848)
+
+Lifetec/Medion/Tevion/Aldi
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- LT9306/MD9306 = CPH061
+- LT9415/MD9415 = LR90 Rev.F or Rev.G
+- MD9592 = Avermedia TVphone98 (PCI_ID=1461:0003), PCB-Rev=M168II-B (w/TDA9873H)
+- MD9717 = KNC One (Rev D4, saa7134, FM1216 MK2 tuner)
+- MD5044 = KNC One (Rev D4, saa7134, FM1216ME MK3 tuner)
+
+Modular Technologies (www.modulartech.com) UK
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- MM100 PCTV (Bt848)
+- MM201 PCTV (Bt878, Bt832) w/ Quartzsight camera
+- MM202 PCTV (Bt878, Bt832, tda9874)
+- MM205 PCTV (Bt878)
+- MM210 PCTV (Bt878) (Galaxy TV, Galaxymedia ?)
+
+Terratec
+~~~~~~~~
+
+Models:
+
+- Terra TV+ Version 1.0 (Bt848), "ceb105.PCB" printed on the PCB, TDA9821
+- Terra TV+ Version 1.1 (Bt878), "LR74 Rev.E" printed on the PCB, TDA9821
+- Terra TValueRadio, "LR102 Rev.C" printed on the PCB
+- Terra TV/Radio+ Version 1.0, "80-CP2830100-0" TTTV3 printed on the PCB,
+ "CPH010-E83" on the back, SAA6588T, TDA9873H
+- Terra TValue Version BT878, "80-CP2830110-0 TTTV4" printed on the PCB,
+ "CPH011-D83" on back
+- Terra TValue Version 1.0 "ceb105.PCB" (really identical to Terra TV+ Version 1.0)
+- Terra TValue New Revision "LR102 Rec.C"
+- Terra Active Radio Upgrade (tea5757h, saa6588t)
+
+- LR74 is a newer PCB revision of ceb105 (both incl. connector for Active Radio Upgrade)
+
+- Cinergy 400 (saa7134), "E877 11(S)", "PM820092D" printed on PCB
+- Cinergy 600 (saa7134)
+
+Technisat
+~~~~~~~~~
+
+Models:
+
+- Discos ADR PC-Karte ISA (no TV!)
+- Discos ADR PC-Karte PCI (probably no TV?)
+- Techni-PC-Sat (Sat. analog)
+ Rev 1.2 (zr36120, vpx3220, stv0030, saa5246, BSJE3-494A)
+- Mediafocus I (zr36120/zr36125, drp3510, Sat. analog + ADR Radio)
+- Mediafocus II (saa7146, Sat. analog)
+- SatADR Rev 2.1 (saa7146a, saa7113h, stv0056a, msp3400c, drp3510a, BSKE3-307A)
+- SkyStar 1 DVB (AV7110) = Technotrend Premium
+- SkyStar 2 DVB (B2C2) (=Sky2PC)
+
+Siemens
+~~~~~~~
+
+Multimedia eXtension Board (MXB) (SAA7146, SAA7111)
+
+Powercolor
+~~~~~~~~~~
+
+Models:
+
+- MTV878
+ Package comes with different contents:
+ a) pcb "MTV878" (CARD=75)
+ b) Pixelview Rev. 4_
+- MTV878R w/Remote Control
+- MTV878F w/Remote Control w/FM radio
+
+Pinnacle
+~~~~~~~~
+
+PCTV models:
+
+- Mirovideo PCTV (Bt848)
+- Mirovideo PCTV SE (Bt848)
+- Mirovideo PCTV Pro (Bt848 + Daughterboard for TV Stereo and FM)
+- Studio PCTV Rave (Bt848 Version = Mirovideo PCTV)
+- Studio PCTV Rave (Bt878 package w/o infrared)
+- Studio PCTV (Bt878)
+- Studio PCTV Pro (Bt878 stereo w/ FM)
+- Pinnacle PCTV (Bt878, MT2032)
+- Pinnacle PCTV Pro (Bt878, MT2032)
+- Pinncale PCTV Sat (bt878a, HM1821/1221) ["Conexant CX24110 with CX24108 tuner, aka HM1221/HM1811"]
+- Pinnacle PCTV Sat XE
+
+M(J)PEG capture and playback models:
+
+- DC1+ (ISA)
+- DC10 (zr36057, zr36060, saa7110, adv7176)
+- DC10+ (zr36067, zr36060, saa7110, adv7176)
+- DC20 (ql16x24b,zr36050, zr36016, saa7110, saa7187 ...)
+- DC30 (zr36057, zr36050, zr36016, vpx3220, adv7176, ad1843, tea6415, miro FST97A1)
+- DC30+ (zr36067, zr36050, zr36016, vpx3220, adv7176)
+- DC50 (zr36067, zr36050, zr36016, saa7112, adv7176 (2 pcs.?), ad1843, miro FST97A1, Lattice ???)
+
+Lenco
+~~~~~
+
+Models:
+
+- MXR-9565 (=Technisat Mediafocus?)
+- MXR-9571 (Bt848) (=CPH031?)
+- MXR-9575
+- MXR-9577 (Bt878) (=Prolink 878TV Rev.3x)
+- MXTV-9578CP (Bt878) (= Prolink PV-BT878P+4E)
+
+Iomega
+~~~~~~
+
+Buz (zr36067, zr36060, saa7111, saa7185)
+
+LML
+~~~
+ LML33 (zr36067, zr36060, bt819, bt856)
+
+Grandtec
+~~~~~~~~
+
+Models:
+
+- Grand Video Capture (Bt848)
+- Multi Capture Card (Bt878)
+
+Koutech
+~~~~~~~
+
+Models:
+
+- KW-606 (Bt848)
+- KW-607 (Bt848 capture only)
+- KW-606RSF
+- KW-607A (capture only)
+- KW-608 (Zoran capture only)
+
+IODATA (jp)
+~~~~~~~~~~~
+
+Models:
+
+- GV-BCTV/PCI
+- GV-BCTV2/PCI
+- GV-BCTV3/PCI
+- GV-BCTV4/PCI
+- GV-VCP/PCI (capture only)
+- GV-VCP2/PCI (capture only)
+
+Canopus (jp)
+~~~~~~~~~~~~
+
+WinDVR = Kworld "KW-TVL878RF"
+
+www.sigmacom.co.kr
+~~~~~~~~~~~~~~~~~~
+
+Sigma Cyber TV II
+
+www.sasem.co.kr
+~~~~~~~~~~~~~~~
+
+Litte OnAir TV
+
+hama
+~~~~
+
+TV/Radio-Tuner Card, PCI (Model 44677) = CPH051
+
+Sigma Designs
+~~~~~~~~~~~~~
+
+Hollywood plus (em8300, em9010, adv7175), (PCB "M340-10") MPEG DVD decoder
+
+Formac
+~~~~~~
+
+Models:
+
+- iProTV (Card for iMac Mezzanine slot, Bt848+SCSI)
+- ProTV (Bt848)
+- ProTV II = ProTV Stereo (Bt878) ["stereo" means FM stereo, tv is still mono]
+
+ATI
+~~~
+
+Models:
+
+- TV-Wonder
+- TV-Wonder VE
+
+Diamond Multimedia
+~~~~~~~~~~~~~~~~~~
+
+DTV2000 (Bt848, tda9875)
+
+Aopen
+~~~~~
+
+- VA1000 Plus (w/ Stereo)
+- VA1000 Lite
+- VA1000 (=LR90)
+
+Intel
+~~~~~
+
+Models:
+
+- Smart Video Recorder (ISA full-length)
+- Smart Video Recorder pro (ISA half-length)
+- Smart Video Recorder III (Bt848)
+
+STB
+~~~
+
+Models:
+
+- STB Gateway 6000704 (bt878)
+- STB Gateway 6000699 (bt848)
+- STB Gateway 6000402 (bt848)
+- STB TV130 PCI
+
+Videologic
+~~~~~~~~~~
+
+Models:
+
+- Captivator Pro/TV (ISA?)
+- Captivator PCI/VC (Bt848 bundled with camera) (capture only)
+
+Technotrend
+~~~~~~~~~~~~
+
+Models:
+
+- TT-SAT PCI (PCB "Sat-PCI Rev.:1.3.1"; zr36125, vpx3225d, stc0056a, Tuner:BSKE6-155A
+- TT-DVB-Sat
+ - revisions 1.1, 1.3, 1.5, 1.6 and 2.1
+ - This card is sold as OEM from:
+ - Siemens DVB-s Card
+ - Hauppauge WinTV DVB-S
+ - Technisat SkyStar 1 DVB
+ - Galaxis DVB Sat
+ - Now this card is called TT-PCline Premium Family
+ - TT-Budget (saa7146, bsru6-701a)
+ This card is sold as OEM from:
+ - Hauppauge WinTV Nova
+ - Satelco Standard PCI (DVB-S)
+ - TT-DVB-C PCI
+
+Teles
+~~~~~
+
+ DVB-s (Rev. 2.2, BSRV2-301A, data only?)
+
+Remote Vision
+~~~~~~~~~~~~~
+
+MX RV605 (Bt848 capture only)
+
+Boeder
+~~~~~~
+
+Models:
+
+- PC ChatCam (Model 68252) (Bt848 capture only)
+- Tv/Fm Capture Card (Model 68404) = PV951
+
+Media-Surfer (esc-kathrein.de)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- Sat-Surfer (ISA)
+- Sat-Surfer PCI = Techni-PC-Sat
+- Cable-Surfer 1
+- Cable-Surfer 2
+- Cable-Surfer PCI (zr36120)
+- Audio-Surfer (ISA Radio card)
+
+Jetway (www.jetway.com.tw)
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- JW-TV 878M
+- JW-TV 878 = KWorld KW-TV878RF
+
+Galaxis
+~~~~~~~
+
+Models:
+
+- Galaxis DVB Card S CI
+- Galaxis DVB Card C CI
+- Galaxis DVB Card S
+- Galaxis DVB Card C
+- Galaxis plug.in S [neuer Name: Galaxis DVB Card S CI
+
+Hauppauge
+~~~~~~~~~
+
+Models:
+
+- many many WinTV models ...
+- WinTV DVBs = Technotrend Premium 1.3
+- WinTV NOVA = Technotrend Budget 1.1 "S-DVB DATA"
+- WinTV NOVA-CI "SDVBACI"
+- WinTV Nova USB (=Technotrend USB 1.0)
+- WinTV-Nexus-s (=Technotrend Premium 2.1 or 2.2)
+- WinTV PVR
+- WinTV PVR 250
+- WinTV PVR 450
+
+US models
+
+-990 WinTV-PVR-350 (249USD) (iTVC15 chipset + radio)
+-980 WinTV-PVR-250 (149USD) (iTVC15 chipset)
+-880 WinTV-PVR-PCI (199USD) (KFIR chipset + bt878)
+-881 WinTV-PVR-USB
+-190 WinTV-GO
+-191 WinTV-GO-FM
+-404 WinTV
+-401 WinTV-radio
+-495 WinTV-Theater
+-602 WinTV-USB
+-621 WinTV-USB-FM
+-600 USB-Live
+-698 WinTV-HD
+-697 WinTV-D
+-564 WinTV-Nexus-S
+
+Deutsche Modelle:
+
+-603 WinTV GO
+-719 WinTV Primio-FM
+-718 WinTV PCI-FM
+-497 WinTV Theater
+-569 WinTV USB
+-568 WinTV USB-FM
+-882 WinTV PVR
+-981 WinTV PVR 250
+-891 WinTV-PVR-USB
+-541 WinTV Nova
+-488 WinTV Nova-Ci
+-564 WinTV-Nexus-s
+-727 WinTV-DVB-c
+-545 Common Interface
+-898 WinTV-Nova-USB
+
+UK models:
+
+-607 WinTV Go
+-693,793 WinTV Primio FM
+-647,747 WinTV PCI FM
+-498 WinTV Theater
+-883 WinTV PVR
+-893 WinTV PVR USB (Duplicate entry)
+-566 WinTV USB (UK)
+-573 WinTV USB FM
+-429 Impact VCB (bt848)
+-600 USB Live (Video-In 1x Comp, 1xSVHS)
+-542 WinTV Nova
+-717 WinTV DVB-S
+-909 Nova-t PCI
+-893 Nova-t USB (Duplicate entry)
+-802 MyTV
+-804 MyView
+-809 MyVideo
+-872 MyTV2Go FM
+-546 WinTV Nova-S CI
+-543 WinTV Nova
+-907 Nova-S USB
+-908 Nova-T USB
+-717 WinTV Nexus-S
+-157 DEC3000-s Standalone + USB
+
+Spain:
+
+-685 WinTV-Go
+-690 WinTV-PrimioFM
+-416 WinTV-PCI Nicam Estereo
+-677 WinTV-PCI-FM
+-699 WinTV-Theater
+-683 WinTV-USB
+-678 WinTV-USB-FM
+-983 WinTV-PVR-250
+-883 WinTV-PVR-PCI
+-993 WinTV-PVR-350
+-893 WinTV-PVR-USB
+-728 WinTV-DVB-C PCI
+-832 MyTV2Go
+-869 MyTV2Go-FM
+-805 MyVideo (USB)
+
+
+Matrix-Vision
+~~~~~~~~~~~~~
+
+Models:
+
+- MATRIX-Vision MV-Delta
+- MATRIX-Vision MV-Delta 2
+- MVsigma-SLC (Bt848)
+
+Conceptronic (.net)
+~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- TVCON FM, TV card w/ FM = CPH05x
+- TVCON = CPH06x
+
+BestData
+~~~~~~~~
+
+Models:
+
+- HCC100 = VCC100rev1 + camera
+- VCC100 rev1 (bt848)
+- VCC100 rev2 (bt878)
+
+Gallant (www.gallantcom.com) www.minton.com.tw
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- Intervision IV-510 (capture only bt8x8)
+- Intervision IV-550 (bt8x8)
+- Intervision IV-100 (zoran)
+- Intervision IV-1000 (bt8x8)
+
+Asonic (www.asonic.com.cn) (website down)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+SkyEye tv 878
+
+Hoontech
+~~~~~~~~
+
+878TV/FM
+
+Teppro (www.itcteppro.com.tw)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- ITC PCITV (Card Ver 1.0) "Teppro TV1/TVFM1 Card"
+- ITC PCITV (Card Ver 2.0)
+- ITC PCITV (Card Ver 3.0) = "PV-BT878P+ (REV.9D)"
+- ITC PCITV (Card Ver 4.0)
+- TEPPRO IV-550 (For BT848 Main Chip)
+- ITC DSTTV (bt878, satellite)
+- ITC VideoMaker (saa7146, StreamMachine sm2110, tvtuner) "PV-SM2210P+ (REV:1C)"
+
+Kworld (www.kworld.com.tw)
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+PC TV Station:
+
+- KWORLD KW-TV878R TV (no radio)
+- KWORLD KW-TV878RF TV (w/ radio)
+- KWORLD KW-TVL878RF (low profile)
+- KWORLD KW-TV713XRF (saa7134)
+
+
+ MPEG TV Station (same cards as above plus WinDVR Software MPEG en/decoder)
+
+- KWORLD KW-TV878R -Pro TV (no Radio)
+- KWORLD KW-TV878RF-Pro TV (w/ Radio)
+- KWORLD KW-TV878R -Ultra TV (no Radio)
+- KWORLD KW-TV878RF-Ultra TV (w/ Radio)
+
+JTT/ Justy Corp.(http://www.jtt.ne.jp/)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+JTT-02 (JTT TV) "TV watchmate pro" (bt848)
+
+ADS www.adstech.com
+~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- Channel Surfer TV ( CHX-950 )
+- Channel Surfer TV+FM ( CHX-960FM )
+
+AVEC www.prochips.com
+~~~~~~~~~~~~~~~~~~~~~
+
+AVEC Intercapture (bt848, tea6320)
+
+NoBrand
+~~~~~~~
+
+TV Excel = Australian Name for "PV-BT878P+ 8E" or "878TV Rev.3_"
+
+Mach www.machspeed.com
+~~~~~~~~~~~~~~~~~~~~~~
+
+Mach TV 878
+
+Eline www.eline-net.com/
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- Eline Vision TVMaster / TVMaster FM (ELV-TVM/ ELV-TVM-FM) = LR26 (bt878)
+- Eline Vision TVMaster-2000 (ELV-TVM-2000, ELV-TVM-2000-FM)= LR138 (saa713x)
+
+Spirit
+~~~~~~
+
+- Spirit TV Tuner/Video Capture Card (bt848)
+
+Boser www.boser.com.tw
+~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- HS-878 Mini PCI Capture Add-on Card
+- HS-879 Mini PCI 3D Audio and Capture Add-on Card (w/ ES1938 Solo-1)
+
+Satelco www.citycom-gmbh.de, www.satelco.de
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- TV-FM =KNC1 saa7134
+- Standard PCI (DVB-S) = Technotrend Budget
+- Standard PCI (DVB-S) w/ CI
+- Satelco Highend PCI (DVB-S) = Technotrend Premium
+
+
+Sensoray www.sensoray.com
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- Sensoray 311 (PC/104 bus)
+- Sensoray 611 (PCI)
+
+CEI (Chartered Electronics Industries Pte Ltd [CEI] [FCC ID HBY])
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- TV Tuner - HBY-33A-RAFFLES Brooktree Bt848KPF + Philips
+- TV Tuner MG9910 - HBY33A-TVO CEI + Philips SAA7110 + OKI M548262 + ST STV8438CV
+- Primetime TV (ISA)
+ - acquired by Singapore Technologies
+ - now operating as Chartered Semiconductor Manufacturing
+ - Manufacturer of video cards is listed as:
+ - Cogent Electronics Industries [CEI]
+
+AITech
+~~~~~~
+
+Models:
+
+- Wavewatcher TV (ISA)
+- AITech WaveWatcher TV-PCI = can be LR26 (Bt848) or LR50 (BT878)
+- WaveWatcher TVR-202 TV/FM Radio Card (ISA)
+
+MAXRON
+~~~~~~
+
+Maxron MaxTV/FM Radio (KW-TV878-FNT) = Kworld or JW-TV878-FBK
+
+www.ids-imaging.de
+~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- Falcon Series (capture only)
+ In USA: http://www.theimagingsource.com/
+- DFG/LC1
+
+www.sknet-web.co.jp
+~~~~~~~~~~~~~~~~~~~
+
+SKnet Monster TV (saa7134)
+
+A-Max www.amaxhk.com (Colormax, Amax, Napa)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+APAC Viewcomp 878
+
+Cybertainment
+~~~~~~~~~~~~~
+
+Models:
+
+- CyberMail AV Video Email Kit w/ PCI Capture Card (capture only)
+- CyberMail Xtreme
+
+These are Flyvideo
+
+VCR (http://www.vcrinc.com/)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Video Catcher 16
+
+Twinhan
+~~~~~~~
+
+Models:
+
+- DST Card/DST-IP (bt878, twinhan asic) VP-1020
+ - Sold as:
+ - KWorld DVBS Satellite TV-Card
+ - Powercolor DSTV Satellite Tuner Card
+ - Prolink Pixelview DTV2000
+ - Provideo PV-911 Digital Satellite TV Tuner Card With Common Interface ?
+- DST-CI Card (DVB Satellite) VP-1030
+- DCT Card (DVB cable)
+
+MSI
+~~~
+
+Models:
+
+- MSI TV@nywhere Tuner Card (MS-8876) (CX23881/883) Not Bt878 compatible.
+- MS-8401 DVB-S
+
+Focus www.focusinfo.com
+~~~~~~~~~~~~~~~~~~~~~~~
+
+InVideo PCI (bt878)
+
+Sdisilk www.sdisilk.com/
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- SDI Silk 100
+- SDI Silk 200 SDI Input Card
+
+www.euresys.com
+~~~~~~~~~~~~~~~
+
+PICOLO series
+
+PMC/Pace
+~~~~~~~~
+
+www.pacecom.co.uk website closed
+
+Mercury www.kobian.com (UK and FR)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- LR50
+- LR138RBG-Rx == LR138
+
+TEC sound
+~~~~~~~~~
+
+TV-Mate = Zoltrix VP-8482
+
+Though educated googling found: www.techmakers.com
+
+(package and manuals don't have any other manufacturer info) TecSound
+
+Lorenzen www.lorenzen.de
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+SL DVB-S PCI = Technotrend Budget PCI (su1278 or bsru version)
+
+Origo (.uk) www.origo2000.com
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+PC TV Card = LR50
+
+I/O Magic www.iomagic.com
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+PC PVR - Desktop TV Personal Video Recorder DR-PCTV100 = Pinnacle ROB2D-51009464 4.0 + Cyberlink PowerVCR II
+
+Arowana
+~~~~~~~
+
+TV-Karte / Poso Power TV (?) = Zoltrix VP-8482 (?)
+
+iTVC15 boards:
+~~~~~~~~~~~~~
+
+kuroutoshikou.com ITVC15
+yuan.com MPG160 PCI TV (Internal PCI MPEG2 encoder card plus TV-tuner)
+
+Asus www.asuscom.com
+~~~~~~~~~~~~~~~~~~~~
+
+Models:
+
+- Asus TV Tuner Card 880 NTSC (low profile, cx23880)
+- Asus TV (saa7134)
+
+Hoontech
+~~~~~~~~
+
+http://www.hoontech.de/
+
+- HART Vision 848 (H-ART Vision 848)
+- HART Vision 878 (H-Art Vision 878)
+
+
+
+Chips used at bttv devices
+--------------------------
+
+- all boards:
+
+ - Brooktree Bt848/848A/849/878/879: video capture chip
+
+- Board specific
+
+ - Miro PCTV:
+
+ - Philips or Temic Tuner
+
+ - Hauppauge Win/TV pci (version 405):
+
+ - Microchip 24LC02B or Philips 8582E2Y:
+ - 256 Byte EEPROM with configuration information
+ - I2C 0xa0-0xa1, (24LC02B also responds to 0xa2-0xaf)
+ - Philips SAA5246AGP/E: Videotext decoder chip, I2C 0x22-0x23
+
+ - TDA9800: sound decoder
+
+ - Winbond W24257AS-35: 32Kx8 CMOS static RAM (Videotext buffer mem)
+
+ - 14052B: analog switch for selection of sound source
+
+- PAL:
+
+ - TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
+ - TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3
+
+- NTSC:
+
+ - TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
+ - TSA5518: no datasheet available on Philips site
+
+- STB TV pci:
+
+ - ???
+ - if you want better support for STB cards send me info!
+ Look at the board! What chips are on it?
+
+
+
+
+Specs
+-----
+Philips http://www.Semiconductors.COM/pip/
+Conexant http://www.conexant.com/
+Micronas http://www.micronas.com/en/home/index.html
+
+Thanks
+------
+
+Many thanks to:
+
+- Markus Schroeder <schroedm@uni-duesseldorf.de> for information on the Bt848
+ and tuner programming and his control program xtvc.
+
+- Martin Buck <martin-2.buck@student.uni-ulm.de> for his great Videotext
+ package.
+
+- Gerd Hoffmann for the MSP3400 support and the modular
+ I2C, tuner, ... support.
+
+
+- MATRIX Vision for giving us 2 cards for free, which made support of
+ single crystal operation possible.
+
+- MIRO for providing a free PCTV card and detailed information about the
+ components on their cards. (E.g. how the tuner type is detected)
+ Without their card I could not have debugged the NTSC mode.
+
+- Hauppauge for telling how the sound input is selected and what components
+ they do and will use on their radio cards.
+ Also many thanks for faxing me the FM1216 data sheet.
+
+Contributors
+------------
+
+Michael Chu <mmchu@pobox.com>
+ AverMedia fix and more flexible card recognition
+
+Alan Cox <alan@lxorguk.ukuu.org.uk>
+ Video4Linux interface and 2.1.x kernel adaptation
+
+Chris Kleitsch
+ Hardware I2C
+
+Gerd Hoffmann
+ Radio card (ITT sound processor)
+
+bigfoot <bigfoot@net-way.net>
+Ragnar Hojland Espinosa <ragnar@macula.net>
+ ConferenceTV card
+
+
++ many more (please mail me if you are missing in this list and would
+ like to be mentioned)
diff --git a/Documentation/video4linux/bttv/Tuners b/Documentation/media/v4l-drivers/tuners.rst
similarity index 100%
rename from Documentation/video4linux/bttv/Tuners
rename to Documentation/media/v4l-drivers/tuners.rst
diff --git a/Documentation/video4linux/bttv/CONTRIBUTORS b/Documentation/video4linux/bttv/CONTRIBUTORS
deleted file mode 100644
index eb41b2650860..000000000000
--- a/Documentation/video4linux/bttv/CONTRIBUTORS
+++ /dev/null
@@ -1,25 +0,0 @@
-Contributors to bttv:
-
-Michael Chu <mmchu@pobox.com>
- AverMedia fix and more flexible card recognition
-
-Alan Cox <alan@lxorguk.ukuu.org.uk>
- Video4Linux interface and 2.1.x kernel adaptation
-
-Chris Kleitsch
- Hardware I2C
-
-Gerd Knorr <kraxel@cs.tu-berlin.de>
- Radio card (ITT sound processor)
-
-bigfoot <bigfoot@net-way.net>
-Ragnar Hojland Espinosa <ragnar@macula.net>
- ConferenceTV card
-
-
-+ many more (please mail me if you are missing in this list and would
- like to be mentioned)
-
-
-
-
diff --git a/Documentation/video4linux/bttv/Cards b/Documentation/video4linux/bttv/Cards
deleted file mode 100644
index a8fb6e2d3c8b..000000000000
--- a/Documentation/video4linux/bttv/Cards
+++ /dev/null
@@ -1,960 +0,0 @@
-
-Gunther Mayer's bttv card gallery (graphical version of this text file :-)
-is available at: http://www.bttv-gallery.de/
-
-
-Supported cards:
-Bt848/Bt848a/Bt849/Bt878/Bt879 cards
-------------------------------------
-
-All cards with Bt848/Bt848a/Bt849/Bt878/Bt879 and normal
-Composite/S-VHS inputs are supported. Teletext and Intercast support
-(PAL only) for ALL cards via VBI sample decoding in software.
-
-Some cards with additional multiplexing of inputs or other additional
-fancy chips are only partially supported (unless specifications by the
-card manufacturer are given). When a card is listed here it isn't
-necessarily fully supported.
-
-All other cards only differ by additional components as tuners, sound
-decoders, EEPROMs, teletext decoders ...
-
-
-Unsupported Cards:
-------------------
-
-Cards with Zoran (ZR) or Philips (SAA) or ISA are not supported by
-this driver.
-
-
-MATRIX Vision
--------------
-
-MV-Delta
-- Bt848A
-- 4 Composite inputs, 1 S-VHS input (shared with 4th composite)
-- EEPROM
-
-http://www.matrix-vision.de/
-
-This card has no tuner but supports all 4 composite (1 shared with an
-S-VHS input) of the Bt848A.
-Very nice card if you only have satellite TV but several tuners connected
-to the card via composite.
-
-Many thanks to Matrix-Vision for giving us 2 cards for free which made
-Bt848a/Bt849 single crystal operation support possible!!!
-
-
-
-Miro/Pinnacle PCTV
-------------------
-
-- Bt848
- some (all??) come with 2 crystals for PAL/SECAM and NTSC
-- PAL, SECAM or NTSC TV tuner (Philips or TEMIC)
-- MSP34xx sound decoder on add on board
- decoder is supported but AFAIK does not yet work
- (other sound MUX setting in GPIO port needed??? somebody who fixed this???)
-- 1 tuner, 1 composite and 1 S-VHS input
-- tuner type is autodetected
-
-http://www.miro.de/
-http://www.miro.com/
-
-
-Many thanks for the free card which made first NTSC support possible back
-in 1997!
-
-
-Hauppauge Win/TV pci
---------------------
-
-There are many different versions of the Hauppauge cards with different
-tuners (TV+Radio ...), teletext decoders.
-Note that even cards with same model numbers have (depending on the revision)
-different chips on it.
-
-- Bt848 (and others but always in 2 crystal operation???)
- newer cards have a Bt878
-- PAL, SECAM, NTSC or tuner with or without Radio support
-
-e.g.:
- PAL:
- TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
- TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3
-
- NTSC:
- TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
- TSA5518: no datasheet available on Philips site
-- Philips SAA5246 or SAA5284 ( or no) Teletext decoder chip
- with buffer RAM (e.g. Winbond W24257AS-35: 32Kx8 CMOS static RAM)
- SAA5246 (I2C 0x22) is supported
-- 256 bytes EEPROM: Microchip 24LC02B or Philips 8582E2Y
- with configuration information
- I2C address 0xa0 (24LC02B also responds to 0xa2-0xaf)
-- 1 tuner, 1 composite and (depending on model) 1 S-VHS input
-- 14052B: mux for selection of sound source
-- sound decoder: TDA9800, MSP34xx (stereo cards)
-
-
-Askey CPH-Series
-----------------
-Developed by TelSignal(?), OEMed by many vendors (Typhoon, Anubis, Dynalink)
-
- Card series:
- CPH01x: BT848 capture only
- CPH03x: BT848
- CPH05x: BT878 with FM
- CPH06x: BT878 (w/o FM)
- CPH07x: BT878 capture only
-
- TV standards:
- CPH0x0: NTSC-M/M
- CPH0x1: PAL-B/G
- CPH0x2: PAL-I/I
- CPH0x3: PAL-D/K
- CPH0x4: SECAM-L/L
- CPH0x5: SECAM-B/G
- CPH0x6: SECAM-D/K
- CPH0x7: PAL-N/N
- CPH0x8: PAL-B/H
- CPH0x9: PAL-M/M
-
- CPH03x was often sold as "TV capturer".
-
- Identifying:
- 1) 878 cards can be identified by PCI Subsystem-ID:
- 144f:3000 = CPH06x
- 144F:3002 = CPH05x w/ FM
- 144F:3005 = CPH06x_LC (w/o remote control)
- 1) The cards have a sticker with "CPH"-model on the back.
- 2) These cards have a number printed on the PCB just above the tuner metal box:
- "80-CP2000300-x" = CPH03X
- "80-CP2000500-x" = CPH05X
- "80-CP2000600-x" = CPH06X / CPH06x_LC
-
- Askey sells these cards as "Magic TView series", Brand "MagicXpress".
- Other OEM often call these "Tview", "TView99" or else.
-
-Lifeview Flyvideo Series:
--------------------------
- The naming of these series differs in time and space.
-
- Identifying:
- 1) Some models can be identified by PCI subsystem ID:
- 1852:1852 = Flyvideo 98 FM
- 1851:1850 = Flyvideo 98
- 1851:1851 = Flyvideo 98 EZ (capture only)
- 2) There is a print on the PCB:
- LR25 = Flyvideo (Zoran ZR36120, SAA7110A)
- LR26 Rev.N = Flyvideo II (Bt848)
- Rev.O = Flyvideo II (Bt878)
- LR37 Rev.C = Flyvideo EZ (Capture only, ZR36120 + SAA7110)
- LR38 Rev.A1= Flyvideo II EZ (Bt848 capture only)
- LR50 Rev.Q = Flyvideo 98 (w/eeprom and PCI subsystem ID)
- Rev.W = Flyvideo 98 (no eeprom)
- LR51 Rev.E = Flyvideo 98 EZ (capture only)
- LR90 = Flyvideo 2000 (Bt878)
- Flyvideo 2000S (Bt878) w/Stereo TV (Package incl. LR91 daughterboard)
- LR91 = Stereo daughter card for LR90
- LR97 = Flyvideo DVBS
- LR99 Rev.E = Low profile card for OEM integration (only internal audio!) bt878
- LR136 = Flyvideo 2100/3100 (Low profile, SAA7130/SAA7134)
- LR137 = Flyvideo DV2000/DV3000 (SAA7130/SAA7134 + IEEE1394)
- LR138 Rev.C= Flyvideo 2000 (SAA7130)
- or Flyvideo 3000 (SAA7134) w/Stereo TV
- These exist in variations w/FM and w/Remote sometimes denoted
- by suffixes "FM" and "R".
- 3) You have a laptop (miniPCI card):
- Product = FlyTV Platinum Mini
- Model/Chip = LR212/saa7135
-
- Lifeview.com.tw states (Feb. 2002):
- "The FlyVideo2000 and FlyVideo2000s product name have renamed to FlyVideo98."
- Their Bt8x8 cards are listed as discontinued.
- Flyvideo 2000S was probably sold as Flyvideo 3000 in some contries(Europe?).
- The new Flyvideo 2000/3000 are SAA7130/SAA7134 based.
-
- "Flyvideo II" had been the name for the 848 cards, nowadays (in Germany)
- this name is re-used for LR50 Rev.W.
- The Lifeview website mentioned Flyvideo III at some time, but such a card
- has not yet been seen (perhaps it was the german name for LR90 [stereo]).
- These cards are sold by many OEMs too.
-
- FlyVideo A2 (Elta 8680)= LR90 Rev.F (w/Remote, w/o FM, stereo TV by tda9821) {Germany}
- Lifeview 3000 (Elta 8681) as sold by Plus(April 2002), Germany = LR138 w/ saa7134
-
-
-Typhoon TV card series:
------------------------
- These can be CPH, Flyvideo, Pixelview or KNC1 series.
- Typhoon is the brand of Anubis.
- Model 50680 got re-used, some model no. had different contents over time.
-
- Models:
- 50680 "TV Tuner PCI Pal BG"(old,red package)=can be CPH03x(bt848) or CPH06x(bt878)
- 50680 "TV Tuner Pal BG" (blue package)= Pixelview PV-BT878P+ (Rev 9B)
- 50681 "TV Tuner PCI Pal I" (variant of 50680)
- 50682 "TView TV/FM Tuner Pal BG" = Flyvideo 98FM (LR50 Rev.Q)
- Note: The package has a picture of CPH05x (which would be a real TView)
- 50683 "TV Tuner PCI SECAM" (variant of 50680)
- 50684 "TV Tuner Pal BG" = Pixelview 878TV(Rev.3D)
- 50686 "TV Tuner" = KNC1 TV Station
- 50687 "TV Tuner stereo" = KNC1 TV Station pro
- 50688 "TV Tuner RDS" (black package) = KNC1 TV Station RDS
- 50689 TV SAT DVB-S CARD CI PCI (SAA7146AH, SU1278?) = "KNC1 TV Station DVB-S"
- 50692 "TV/FM Tuner" (small PCB)
- 50694 TV TUNER CARD RDS (PHILIPS CHIPSET SAA7134HL)
- 50696 TV TUNER STEREO (PHILIPS CHIPSET SAA7134HL, MK3ME Tuner)
- 50804 PC-SAT TV/Audio Karte = Techni-PC-Sat (ZORAN 36120PQC, Tuner:Alps)
- 50866 TVIEW SAT RECEIVER+ADR
- 50868 "TV/FM Tuner Pal I" (variant of 50682)
- 50999 "TV/FM Tuner Secam" (variant of 50682)
-
-
-Guillemot
----------
- Maxi-TV PCI (ZR36120)
- Maxi TV Video 2 = LR50 Rev.Q (FI1216MF, PAL BG+SECAM)
- Maxi TV Video 3 = CPH064 (PAL BG + SECAM)
-
-Mentor
-------
- Mentor TV card ("55-878TV-U1") = Pixelview 878TV(Rev.3F) (w/FM w/Remote)
-
-Prolink
--------
- TV cards:
- PixelView Play TV pro - (Model: PV-BT878P+ REV 8E)
- PixelView Play TV pro - (Model: PV-BT878P+ REV 9D)
- PixelView Play TV pro - (Model: PV-BT878P+ REV 4C / 8D / 10A )
- PixelView Play TV - (Model: PV-BT848P+)
- 878TV - (Model: PV-BT878TV)
-
- Multimedia TV packages (card + software pack):
- PixelView Play TV Theater - (Model: PV-M4200) = PixelView Play TV pro + Software
- PixelView Play TV PAK - (Model: PV-BT878P+ REV 4E)
- PixelView Play TV/VCR - (Model: PV-M3200 REV 4C / 8D / 10A )
- PixelView Studio PAK - (Model: M2200 REV 4C / 8D / 10A )
- PixelView PowerStudio PAK - (Model: PV-M3600 REV 4E)
- PixelView DigitalVCR PAK - (Model: PV-M2400 REV 4C / 8D / 10A )
-
- PixelView PlayTV PAK II (TV/FM card + usb camera) PV-M3800
- PixelView PlayTV XP PV-M4700,PV-M4700(w/FM)
- PixelView PlayTV DVR PV-M4600 package contents:PixelView PlayTV pro, windvr & videoMail s/w
-
- Further Cards:
- PV-BT878P+rev.9B (Play TV Pro, opt. w/FM w/NICAM)
- PV-BT878P+rev.2F
- PV-BT878P Rev.1D (bt878, capture only)
-
- XCapture PV-CX881P (cx23881)
- PlayTV HD PV-CX881PL+, PV-CX881PL+(w/FM) (cx23881)
-
- DTV3000 PV-DTV3000P+ DVB-S CI = Twinhan VP-1030
- DTV2000 DVB-S = Twinhan VP-1020
-
- Video Conferencing:
- PixelView Meeting PAK - (Model: PV-BT878P)
- PixelView Meeting PAK Lite - (Model: PV-BT878P)
- PixelView Meeting PAK plus - (Model: PV-BT878P+rev 4C/8D/10A)
- PixelView Capture - (Model: PV-BT848P)
-
- PixelView PlayTV USB pro
- Model No. PV-NT1004+, PV-NT1004+ (w/FM) = NT1004 USB decoder chip + SAA7113 video decoder chip
-
-Dynalink
---------
- These are CPH series.
-
-Phoebemicro
------------
- TV Master = CPH030 or CPH060
- TV Master FM = CPH050
-
-Genius/Kye
-----------
- Video Wonder/Genius Internet Video Kit = LR37 Rev.C
- Video Wonder Pro II (848 or 878) = LR26
-
-Tekram
-------
- VideoCap C205 (Bt848)
- VideoCap C210 (zr36120 +Philips)
- CaptureTV M200 (ISA)
- CaptureTV M205 (Bt848)
-
-Lucky Star
-----------
- Image World Conference TV = LR50 Rev. Q
-
-Leadtek
--------
- WinView 601 (Bt848)
- WinView 610 (Zoran)
- WinFast2000
- WinFast2000 XP
-
-KNC One
--------
- TV-Station
- TV-Station SE (+Software Bundle)
- TV-Station pro (+TV stereo)
- TV-Station FM (+Radio)
- TV-Station RDS (+RDS)
- TV Station SAT (analog satellite)
- TV-Station DVB-S
-
- newer Cards have saa7134, but model name stayed the same?
-
-Provideo
---------
- PV951 or PV-951 (also are sold as:
- Boeder TV-FM Video Capture Card
- Titanmedia Supervision TV-2400
- Provideo PV951 TF
- 3DeMon PV951
- MediaForte TV-Vision PV951
- Yoko PV951
- Vivanco Tuner Card PCI Art.-Nr.: 68404
- ) now named PV-951T
-
- Surveillance Series
- PV-141
- PV-143
- PV-147
- PV-148 (capture only)
- PV-150
- PV-151
-
- TV-FM Tuner Series
- PV-951TDV (tv tuner + 1394)
- PV-951T/TF
- PV-951PT/TF
- PV-956T/TF Low Profile
- PV-911
-
-Highscreen
-----------
- TV Karte = LR50 Rev.S
- TV-Boostar = Terratec Terra TV+ Version 1.0 (Bt848, tda9821) "ceb105.pcb"
-
-Zoltrix
--------
- Face to Face Capture (Bt848 capture only) (PCB "VP-2848")
- Face To Face TV MAX (Bt848) (PCB "VP-8482 Rev1.3")
- Genie TV (Bt878) (PCB "VP-8790 Rev 2.1")
- Genie Wonder Pro
-
-AVerMedia
----------
- AVer FunTV Lite (ISA, AV3001 chipset) "M101.C"
- AVerTV
- AVerTV Stereo
- AVerTV Studio (w/FM)
- AVerMedia TV98 with Remote
- AVerMedia TV/FM98 Stereo
- AVerMedia TVCAM98
- TVCapture (Bt848)
- TVPhone (Bt848)
- TVCapture98 (="AVerMedia TV98" in USA) (Bt878)
- TVPhone98 (Bt878, w/FM)
-
- PCB PCI-ID Model-Name Eeprom Tuner Sound Country
- --------------------------------------------------------------------
- M101.C ISA !
- M108-B Bt848 -- FR1236 US (2),(3)
- M1A8-A Bt848 AVer TV-Phone FM1216 --
- M168-T 1461:0003 AVerTV Studio 48:17 FM1216 TDA9840T D (1) w/FM w/Remote
- M168-U 1461:0004 TVCapture98 40:11 FI1216 -- D w/Remote
- M168II-B 1461:0003 Medion MD9592 48:16 FM1216 TDA9873H D w/FM
-
- (1) Daughterboard MB68-A with TDA9820T and TDA9840T
- (2) Sony NE41S soldered (stereo sound?)
- (3) Daughterboard M118-A w/ pic 16c54 and 4 MHz quartz
-
- US site has different drivers for (as of 09/2002):
- EZ Capture/InterCam PCI (BT-848 chip)
- EZ Capture/InterCam PCI (BT-878 chip)
- TV-Phone (BT-848 chip)
- TV98 (BT-848 chip)
- TV98 With Remote (BT-848 chip)
- TV98 (BT-878 chip)
- TV98 With Remote (BT-878)
- TV/FM98 (BT-878 chip)
- AVerTV
- AverTV Stereo
- AVerTV Studio
-
- DE hat diverse Treiber fuer diese Modelle (Stand 09/2002):
- TVPhone (848) mit Philips tuner FR12X6 (w/ FM radio)
- TVPhone (848) mit Philips tuner FM12X6 (w/ FM radio)
- TVCapture (848) w/Philips tuner FI12X6
- TVCapture (848) non-Philips tuner
- TVCapture98 (Bt878)
- TVPhone98 (Bt878)
- AVerTV und TVCapture98 w/VCR (Bt 878)
- AVerTVStudio und TVPhone98 w/VCR (Bt878)
- AVerTV GO Serie (Kein SVideo Input)
- AVerTV98 (BT-878 chip)
- AVerTV98 mit Fernbedienung (BT-878 chip)
- AVerTV/FM98 (BT-878 chip)
-
- VDOmate (www.averm.com.cn) = M168U ?
-
-Aimslab
--------
- Video Highway or "Video Highway TR200" (ISA)
- Video Highway Xtreme (aka "VHX") (Bt848, FM w/ TEA5757)
-
-IXMicro (former: IMS=Integrated Micro Solutions)
--------
- IXTV BT848 (=TurboTV)
- IXTV BT878
- IMS TurboTV (Bt848)
-
-Lifetec/Medion/Tevion/Aldi
---------------------------
- LT9306/MD9306 = CPH061
- LT9415/MD9415 = LR90 Rev.F or Rev.G
- MD9592 = Avermedia TVphone98 (PCI_ID=1461:0003), PCB-Rev=M168II-B (w/TDA9873H)
- MD9717 = KNC One (Rev D4, saa7134, FM1216 MK2 tuner)
- MD5044 = KNC One (Rev D4, saa7134, FM1216ME MK3 tuner)
-
-Modular Technologies (www.modulartech.com) UK
----------------------------------------------
- MM100 PCTV (Bt848)
- MM201 PCTV (Bt878, Bt832) w/ Quartzsight camera
- MM202 PCTV (Bt878, Bt832, tda9874)
- MM205 PCTV (Bt878)
- MM210 PCTV (Bt878) (Galaxy TV, Galaxymedia ?)
-
-Terratec
---------
- Terra TV+ Version 1.0 (Bt848), "ceb105.PCB" printed on the PCB, TDA9821
- Terra TV+ Version 1.1 (Bt878), "LR74 Rev.E" printed on the PCB, TDA9821
- Terra TValueRadio, "LR102 Rev.C" printed on the PCB
- Terra TV/Radio+ Version 1.0, "80-CP2830100-0" TTTV3 printed on the PCB,
- "CPH010-E83" on the back, SAA6588T, TDA9873H
- Terra TValue Version BT878, "80-CP2830110-0 TTTV4" printed on the PCB,
- "CPH011-D83" on back
- Terra TValue Version 1.0 "ceb105.PCB" (really identical to Terra TV+ Version 1.0)
- Terra TValue New Revision "LR102 Rec.C"
- Terra Active Radio Upgrade (tea5757h, saa6588t)
-
- LR74 is a newer PCB revision of ceb105 (both incl. connector for Active Radio Upgrade)
-
- Cinergy 400 (saa7134), "E877 11(S)", "PM820092D" printed on PCB
- Cinergy 600 (saa7134)
-
-Technisat
----------
- Discos ADR PC-Karte ISA (no TV!)
- Discos ADR PC-Karte PCI (probably no TV?)
- Techni-PC-Sat (Sat. analog)
- Rev 1.2 (zr36120, vpx3220, stv0030, saa5246, BSJE3-494A)
- Mediafocus I (zr36120/zr36125, drp3510, Sat. analog + ADR Radio)
- Mediafocus II (saa7146, Sat. analog)
- SatADR Rev 2.1 (saa7146a, saa7113h, stv0056a, msp3400c, drp3510a, BSKE3-307A)
- SkyStar 1 DVB (AV7110) = Technotrend Premium
- SkyStar 2 DVB (B2C2) (=Sky2PC)
-
-Siemens
--------
- Multimedia eXtension Board (MXB) (SAA7146, SAA7111)
-
-Powercolor
-----------
- MTV878
- Package comes with different contents:
- a) pcb "MTV878" (CARD=75)
- b) Pixelview Rev. 4_
- MTV878R w/Remote Control
- MTV878F w/Remote Control w/FM radio
-
-Pinnacle
---------
- Mirovideo PCTV (Bt848)
- Mirovideo PCTV SE (Bt848)
- Mirovideo PCTV Pro (Bt848 + Daughterboard for TV Stereo and FM)
- Studio PCTV Rave (Bt848 Version = Mirovideo PCTV)
- Studio PCTV Rave (Bt878 package w/o infrared)
- Studio PCTV (Bt878)
- Studio PCTV Pro (Bt878 stereo w/ FM)
- Pinnacle PCTV (Bt878, MT2032)
- Pinnacle PCTV Pro (Bt878, MT2032)
- Pinncale PCTV Sat (bt878a, HM1821/1221) ["Conexant CX24110 with CX24108 tuner, aka HM1221/HM1811"]
- Pinnacle PCTV Sat XE
-
- M(J)PEG capture and playback:
- DC1+ (ISA)
- DC10 (zr36057, zr36060, saa7110, adv7176)
- DC10+ (zr36067, zr36060, saa7110, adv7176)
- DC20 (ql16x24b,zr36050, zr36016, saa7110, saa7187 ...)
- DC30 (zr36057, zr36050, zr36016, vpx3220, adv7176, ad1843, tea6415, miro FST97A1)
- DC30+ (zr36067, zr36050, zr36016, vpx3220, adv7176)
- DC50 (zr36067, zr36050, zr36016, saa7112, adv7176 (2 pcs.?), ad1843, miro FST97A1, Lattice ???)
-
-Lenco
------
- MXR-9565 (=Technisat Mediafocus?)
- MXR-9571 (Bt848) (=CPH031?)
- MXR-9575
- MXR-9577 (Bt878) (=Prolink 878TV Rev.3x)
- MXTV-9578CP (Bt878) (= Prolink PV-BT878P+4E)
-
-Iomega
-------
- Buz (zr36067, zr36060, saa7111, saa7185)
-
-LML
----
- LML33 (zr36067, zr36060, bt819, bt856)
-
-Grandtec
---------
- Grand Video Capture (Bt848)
- Multi Capture Card (Bt878)
-
-Koutech
--------
- KW-606 (Bt848)
- KW-607 (Bt848 capture only)
- KW-606RSF
- KW-607A (capture only)
- KW-608 (Zoran capture only)
-
-IODATA (jp)
-------
- GV-BCTV/PCI
- GV-BCTV2/PCI
- GV-BCTV3/PCI
- GV-BCTV4/PCI
- GV-VCP/PCI (capture only)
- GV-VCP2/PCI (capture only)
-
-Canopus (jp)
--------
- WinDVR = Kworld "KW-TVL878RF"
-
-www.sigmacom.co.kr
-------------------
- Sigma Cyber TV II
-
-www.sasem.co.kr
----------------
- Litte OnAir TV
-
-hama
-----
- TV/Radio-Tuner Card, PCI (Model 44677) = CPH051
-
-Sigma Designs
--------------
- Hollywood plus (em8300, em9010, adv7175), (PCB "M340-10") MPEG DVD decoder
-
-Formac
-------
- iProTV (Card for iMac Mezzanine slot, Bt848+SCSI)
- ProTV (Bt848)
- ProTV II = ProTV Stereo (Bt878) ["stereo" means FM stereo, tv is still mono]
-
-ATI
----
- TV-Wonder
- TV-Wonder VE
-
-Diamond Multimedia
-------------------
- DTV2000 (Bt848, tda9875)
-
-Aopen
------
- VA1000 Plus (w/ Stereo)
- VA1000 Lite
- VA1000 (=LR90)
-
-Intel
------
- Smart Video Recorder (ISA full-length)
- Smart Video Recorder pro (ISA half-length)
- Smart Video Recorder III (Bt848)
-
-STB
----
- STB Gateway 6000704 (bt878)
- STB Gateway 6000699 (bt848)
- STB Gateway 6000402 (bt848)
- STB TV130 PCI
-
-Videologic
-----------
- Captivator Pro/TV (ISA?)
- Captivator PCI/VC (Bt848 bundled with camera) (capture only)
-
-Technotrend
-------------
- TT-SAT PCI (PCB "Sat-PCI Rev.:1.3.1"; zr36125, vpx3225d, stc0056a, Tuner:BSKE6-155A
- TT-DVB-Sat
- revisions 1.1, 1.3, 1.5, 1.6 and 2.1
- This card is sold as OEM from:
- Siemens DVB-s Card
- Hauppauge WinTV DVB-S
- Technisat SkyStar 1 DVB
- Galaxis DVB Sat
- Now this card is called TT-PCline Premium Family
- TT-Budget (saa7146, bsru6-701a)
- This card is sold as OEM from:
- Hauppauge WinTV Nova
- Satelco Standard PCI (DVB-S)
- TT-DVB-C PCI
-
-Teles
------
- DVB-s (Rev. 2.2, BSRV2-301A, data only?)
-
-Remote Vision
--------------
- MX RV605 (Bt848 capture only)
-
-Boeder
-------
- PC ChatCam (Model 68252) (Bt848 capture only)
- Tv/Fm Capture Card (Model 68404) = PV951
-
-Media-Surfer (esc-kathrein.de)
--------------------------------
- Sat-Surfer (ISA)
- Sat-Surfer PCI = Techni-PC-Sat
- Cable-Surfer 1
- Cable-Surfer 2
- Cable-Surfer PCI (zr36120)
- Audio-Surfer (ISA Radio card)
-
-Jetway (www.jetway.com.tw)
---------------------------
- JW-TV 878M
- JW-TV 878 = KWorld KW-TV878RF
-
-Galaxis
--------
- Galaxis DVB Card S CI
- Galaxis DVB Card C CI
- Galaxis DVB Card S
- Galaxis DVB Card C
- Galaxis plug.in S [neuer Name: Galaxis DVB Card S CI
-
-Hauppauge
----------
- many many WinTV models ...
- WinTV DVBs = Technotrend Premium 1.3
- WinTV NOVA = Technotrend Budget 1.1 "S-DVB DATA"
- WinTV NOVA-CI "SDVBACI"
- WinTV Nova USB (=Technotrend USB 1.0)
- WinTV-Nexus-s (=Technotrend Premium 2.1 or 2.2)
- WinTV PVR
- WinTV PVR 250
- WinTV PVR 450
-
- US models
- 990 WinTV-PVR-350 (249USD) (iTVC15 chipset + radio)
- 980 WinTV-PVR-250 (149USD) (iTVC15 chipset)
- 880 WinTV-PVR-PCI (199USD) (KFIR chipset + bt878)
- 881 WinTV-PVR-USB
- 190 WinTV-GO
- 191 WinTV-GO-FM
- 404 WinTV
- 401 WinTV-radio
- 495 WinTV-Theater
- 602 WinTV-USB
- 621 WinTV-USB-FM
- 600 USB-Live
- 698 WinTV-HD
- 697 WinTV-D
- 564 WinTV-Nexus-S
-
- Deutsche Modelle
- 603 WinTV GO
- 719 WinTV Primio-FM
- 718 WinTV PCI-FM
- 497 WinTV Theater
- 569 WinTV USB
- 568 WinTV USB-FM
- 882 WinTV PVR
- 981 WinTV PVR 250
- 891 WinTV-PVR-USB
- 541 WinTV Nova
- 488 WinTV Nova-Ci
- 564 WinTV-Nexus-s
- 727 WinTV-DVB-c
- 545 Common Interface
- 898 WinTV-Nova-USB
-
- UK models
- 607 WinTV Go
- 693,793 WinTV Primio FM
- 647,747 WinTV PCI FM
- 498 WinTV Theater
- 883 WinTV PVR
- 893 WinTV PVR USB (Duplicate entry)
- 566 WinTV USB (UK)
- 573 WinTV USB FM
- 429 Impact VCB (bt848)
- 600 USB Live (Video-In 1x Comp, 1xSVHS)
- 542 WinTV Nova
- 717 WinTV DVB-S
- 909 Nova-t PCI
- 893 Nova-t USB (Duplicate entry)
- 802 MyTV
- 804 MyView
- 809 MyVideo
- 872 MyTV2Go FM
-
-
- 546 WinTV Nova-S CI
- 543 WinTV Nova
- 907 Nova-S USB
- 908 Nova-T USB
- 717 WinTV Nexus-S
- 157 DEC3000-s Standalone + USB
-
- Spain
- 685 WinTV-Go
- 690 WinTV-PrimioFM
- 416 WinTV-PCI Nicam Estereo
- 677 WinTV-PCI-FM
- 699 WinTV-Theater
- 683 WinTV-USB
- 678 WinTV-USB-FM
- 983 WinTV-PVR-250
- 883 WinTV-PVR-PCI
- 993 WinTV-PVR-350
- 893 WinTV-PVR-USB
- 728 WinTV-DVB-C PCI
- 832 MyTV2Go
- 869 MyTV2Go-FM
- 805 MyVideo (USB)
-
-
-Matrix-Vision
--------------
- MATRIX-Vision MV-Delta
- MATRIX-Vision MV-Delta 2
- MVsigma-SLC (Bt848)
-
-Conceptronic (.net)
-------------
- TVCON FM, TV card w/ FM = CPH05x
- TVCON = CPH06x
-
-BestData
---------
- HCC100 = VCC100rev1 + camera
- VCC100 rev1 (bt848)
- VCC100 rev2 (bt878)
-
-Gallant (www.gallantcom.com) www.minton.com.tw
------------------------------------------------
- Intervision IV-510 (capture only bt8x8)
- Intervision IV-550 (bt8x8)
- Intervision IV-100 (zoran)
- Intervision IV-1000 (bt8x8)
-
-Asonic (www.asonic.com.cn) (website down)
------------------------------------------
- SkyEye tv 878
-
-Hoontech
---------
- 878TV/FM
-
-Teppro (www.itcteppro.com.tw)
------------------------------
- ITC PCITV (Card Ver 1.0) "Teppro TV1/TVFM1 Card"
- ITC PCITV (Card Ver 2.0)
- ITC PCITV (Card Ver 3.0) = "PV-BT878P+ (REV.9D)"
- ITC PCITV (Card Ver 4.0)
- TEPPRO IV-550 (For BT848 Main Chip)
- ITC DSTTV (bt878, satellite)
- ITC VideoMaker (saa7146, StreamMachine sm2110, tvtuner) "PV-SM2210P+ (REV:1C)"
-
-Kworld (www.kworld.com.tw)
---------------------------
- PC TV Station
- KWORLD KW-TV878R TV (no radio)
- KWORLD KW-TV878RF TV (w/ radio)
-
- KWORLD KW-TVL878RF (low profile)
-
- KWORLD KW-TV713XRF (saa7134)
-
-
- MPEG TV Station (same cards as above plus WinDVR Software MPEG en/decoder)
- KWORLD KW-TV878R -Pro TV (no Radio)
- KWORLD KW-TV878RF-Pro TV (w/ Radio)
- KWORLD KW-TV878R -Ultra TV (no Radio)
- KWORLD KW-TV878RF-Ultra TV (w/ Radio)
-
-
-
-JTT/ Justy Corp.(http://www.jtt.ne.jp/)
----------------------------------------------------------------------
- JTT-02 (JTT TV) "TV watchmate pro" (bt848)
-
-ADS www.adstech.com
--------------------
- Channel Surfer TV ( CHX-950 )
- Channel Surfer TV+FM ( CHX-960FM )
-
-AVEC www.prochips.com
----------------------
- AVEC Intercapture (bt848, tea6320)
-
-NoBrand
--------
- TV Excel = Australian Name for "PV-BT878P+ 8E" or "878TV Rev.3_"
-
-Mach www.machspeed.com
-----
- Mach TV 878
-
-Eline www.eline-net.com/
------
- Eline Vision TVMaster / TVMaster FM (ELV-TVM/ ELV-TVM-FM) = LR26 (bt878)
- Eline Vision TVMaster-2000 (ELV-TVM-2000, ELV-TVM-2000-FM)= LR138 (saa713x)
-
-Spirit
-------
- Spirit TV Tuner/Video Capture Card (bt848)
-
-Boser www.boser.com.tw
------
- HS-878 Mini PCI Capture Add-on Card
- HS-879 Mini PCI 3D Audio and Capture Add-on Card (w/ ES1938 Solo-1)
-
-Satelco www.citycom-gmbh.de, www.satelco.de
--------
- TV-FM =KNC1 saa7134
- Standard PCI (DVB-S) = Technotrend Budget
- Standard PCI (DVB-S) w/ CI
- Satelco Highend PCI (DVB-S) = Technotrend Premium
-
-
-Sensoray www.sensoray.com
---------
- Sensoray 311 (PC/104 bus)
- Sensoray 611 (PCI)
-
-CEI (Chartered Electronics Industries Pte Ltd [CEI] [FCC ID HBY])
----
- TV Tuner - HBY-33A-RAFFLES Brooktree Bt848KPF + Philips
- TV Tuner MG9910 - HBY33A-TVO CEI + Philips SAA7110 + OKI M548262 + ST STV8438CV
- Primetime TV (ISA)
- acquired by Singapore Technologies
- now operating as Chartered Semiconductor Manufacturing
- Manufacturer of video cards is listed as:
- Cogent Electronics Industries [CEI]
-
-AITech
-------
- Wavewatcher TV (ISA)
- AITech WaveWatcher TV-PCI = can be LR26 (Bt848) or LR50 (BT878)
- WaveWatcher TVR-202 TV/FM Radio Card (ISA)
-
-MAXRON
-------
- Maxron MaxTV/FM Radio (KW-TV878-FNT) = Kworld or JW-TV878-FBK
-
-www.ids-imaging.de
-------------------
- Falcon Series (capture only)
- In USA: http://www.theimagingsource.com/
- DFG/LC1
-
-www.sknet-web.co.jp
--------------------
- SKnet Monster TV (saa7134)
-
-A-Max www.amaxhk.com (Colormax, Amax, Napa)
--------------------
- APAC Viewcomp 878
-
-Cybertainment
--------------
- CyberMail AV Video Email Kit w/ PCI Capture Card (capture only)
- CyberMail Xtreme
- These are Flyvideo
-
-VCR (http://www.vcrinc.com/)
----
- Video Catcher 16
-
-Twinhan
--------
- DST Card/DST-IP (bt878, twinhan asic) VP-1020
- Sold as:
- KWorld DVBS Satellite TV-Card
- Powercolor DSTV Satellite Tuner Card
- Prolink Pixelview DTV2000
- Provideo PV-911 Digital Satellite TV Tuner Card With Common Interface ?
- DST-CI Card (DVB Satellite) VP-1030
- DCT Card (DVB cable)
-
-MSI
----
- MSI TV@nywhere Tuner Card (MS-8876) (CX23881/883) Not Bt878 compatible.
- MS-8401 DVB-S
-
-Focus www.focusinfo.com
------
- InVideo PCI (bt878)
-
-Sdisilk www.sdisilk.com/
--------
- SDI Silk 100
- SDI Silk 200 SDI Input Card
-
-www.euresys.com
- PICOLO series
-
-PMC/Pace
-www.pacecom.co.uk website closed
-
-Mercury www.kobian.com (UK and FR)
- LR50
- LR138RBG-Rx == LR138
-
-TEC sound (package and manuals don't have any other manufacturer info) TecSound
- Though educated googling found: www.techmakers.com
- TV-Mate = Zoltrix VP-8482
-
-Lorenzen www.lorenzen.de
---------
- SL DVB-S PCI = Technotrend Budget PCI (su1278 or bsru version)
-
-Origo (.uk) www.origo2000.com
- PC TV Card = LR50
-
-I/O Magic www.iomagic.com
----------
- PC PVR - Desktop TV Personal Video Recorder DR-PCTV100 = Pinnacle ROB2D-51009464 4.0 + Cyberlink PowerVCR II
-
-Arowana
--------
- TV-Karte / Poso Power TV (?) = Zoltrix VP-8482 (?)
-
-iTVC15 boards:
--------------
-kuroutoshikou.com ITVC15
-yuan.com MPG160 PCI TV (Internal PCI MPEG2 encoder card plus TV-tuner)
-
-Asus www.asuscom.com
- Asus TV Tuner Card 880 NTSC (low profile, cx23880)
- Asus TV (saa7134)
-
-Hoontech
---------
-http://www.hoontech.de/
- HART Vision 848 (H-ART Vision 848)
- HART Vision 878 (H-Art Vision 878)
diff --git a/Documentation/video4linux/bttv/ICs b/Documentation/video4linux/bttv/ICs
deleted file mode 100644
index 611315f87c3e..000000000000
--- a/Documentation/video4linux/bttv/ICs
+++ /dev/null
@@ -1,37 +0,0 @@
-all boards:
-
-Brooktree Bt848/848A/849/878/879: video capture chip
-
-
-
-Miro PCTV:
-
-Philips or Temic Tuner
-
-
-
-Hauppauge Win/TV pci (version 405):
-
-Microchip 24LC02B or
-Philips 8582E2Y: 256 Byte EEPROM with configuration information
- I2C 0xa0-0xa1, (24LC02B also responds to 0xa2-0xaf)
-Philips SAA5246AGP/E: Videotext decoder chip, I2C 0x22-0x23
-TDA9800: sound decoder
-Winbond W24257AS-35: 32Kx8 CMOS static RAM (Videotext buffer mem)
-14052B: analog switch for selection of sound source
-
-PAL:
-TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
-TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3
-
-NTSC:
-TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
-TSA5518: no datasheet available on Philips site
-
-
-
-STB TV pci:
-
-???
-if you want better support for STB cards send me info!
-Look at the board! What chips are on it?
diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options
deleted file mode 100644
index 14c065fa23ef..000000000000
--- a/Documentation/video4linux/bttv/Insmod-options
+++ /dev/null
@@ -1,172 +0,0 @@
-
-Note: "modinfo <module>" prints various information about a kernel
-module, among them a complete and up-to-date list of insmod options.
-This list tends to be outdated because it is updated manually ...
-
-==========================================================================
-
-bttv.o
- the bt848/878 (grabber chip) driver
-
- insmod args:
- card=n card type, see CARDLIST for a list.
- tuner=n tuner type, see CARDLIST for a list.
- radio=0/1 card supports radio
- pll=0/1/2 pll settings
- 0: don't use PLL
- 1: 28 MHz crystal installed
- 2: 35 MHz crystal installed
-
- triton1=0/1 for Triton1 (+others) compatibility
- vsfx=0/1 yet another chipset bug compatibility bit
- see README.quirks for details on these two.
-
- bigendian=n Set the endianness of the gfx framebuffer.
- Default is native endian.
- fieldnr=0/1 Count fields. Some TV descrambling software
- needs this, for others it only generates
- 50 useless IRQs/sec. default is 0 (off).
- autoload=0/1 autoload helper modules (tuner, audio).
- default is 1 (on).
- bttv_verbose=0/1/2 verbose level (at insmod time, while
- looking at the hardware). default is 1.
- bttv_debug=0/1 debug messages (for capture).
- default is 0 (off).
- irq_debug=0/1 irq handler debug messages.
- default is 0 (off).
- gbuffers=2-32 number of capture buffers for mmap'ed capture.
- default is 4.
- gbufsize= size of capture buffers. default and
- maximum value is 0x208000 (~2MB)
- no_overlay=0 Enable overlay on broken hardware. There
- are some chipsets (SIS for example) which
- are known to have problems with the PCI DMA
- push used by bttv. bttv will disable overlay
- by default on this hardware to avoid crashes.
- With this insmod option you can override this.
- no_overlay=1 Disable overlay. It should be used by broken
- hardware that doesn't support PCI2PCI direct
- transfers.
- automute=0/1 Automatically mutes the sound if there is
- no TV signal, on by default. You might try
- to disable this if you have bad input signal
- quality which leading to unwanted sound
- dropouts.
- chroma_agc=0/1 AGC of chroma signal, off by default.
- adc_crush=0/1 Luminance ADC crush, on by default.
- i2c_udelay= Allow reduce I2C speed. Default is 5 usecs
- (meaning 66,67 Kbps). The default is the
- maximum supported speed by kernel bitbang
- algorithm. You may use lower numbers, if I2C
- messages are lost (16 is known to work on
- all supported cards).
-
- bttv_gpio=0/1
- gpiomask=
- audioall=
- audiomux=
- See Sound-FAQ for a detailed description.
-
- remap, card, radio and pll accept up to four comma-separated arguments
- (for multiple boards).
-
-tuner.o
- The tuner driver. You need this unless you want to use only
- with a camera or external tuner ...
-
- insmod args:
- debug=1 print some debug info to the syslog
- type=n type of the tuner chip. n as follows:
- see CARDLIST for a complete list.
- pal=[bdgil] select PAL variant (used for some tuners
- only, important for the audio carrier).
-
-tvaudio.o
- new, experimental module which is supported to provide a single
- driver for all simple i2c audio control chips (tda/tea*).
-
- insmod args:
- tda8425 = 1 enable/disable the support for the
- tda9840 = 1 various chips.
- tda9850 = 1 The tea6300 can't be autodetected and is
- tda9855 = 1 therefore off by default, if you have
- tda9873 = 1 this one on your card (STB uses these)
- tda9874a = 1 you have to enable it explicitly.
- tea6300 = 0 The two tda985x chips use the same i2c
- tea6420 = 1 address and can't be disturgished from
- pic16c54 = 1 each other, you might have to disable
- the wrong one.
- debug = 1 print debug messages
-
- insmod args for tda9874a:
- tda9874a_SIF=1/2 select sound IF input pin (1 or 2)
- (default is pin 1)
- tda9874a_AMSEL=0/1 auto-mute select for NICAM (default=0)
- Please read note 3 below!
- tda9874a_STD=n select TV sound standard (0..8):
- 0 - A2, B/G
- 1 - A2, M (Korea)
- 2 - A2, D/K (1)
- 3 - A2, D/K (2)
- 4 - A2, D/K (3)
- 5 - NICAM, I
- 6 - NICAM, B/G
- 7 - NICAM, D/K (default)
- 8 - NICAM, L
-
- Note 1: tda9874a supports both tda9874h (old) and tda9874a (new) chips.
- Note 2: tda9874h/a and tda9875 (which is supported separately by
- tda9875.o) use the same i2c address so both modules should not be
- used at the same time.
- Note 3: Using tda9874a_AMSEL option depends on your TV card design!
- AMSEL=0: auto-mute will switch between NICAM sound
- and the sound on 1st carrier (i.e. FM mono or AM).
- AMSEL=1: auto-mute will switch between NICAM sound
- and the analog mono input (MONOIN pin).
- If tda9874a decoder on your card has MONOIN pin not connected, then
- use only tda9874_AMSEL=0 or don't specify this option at all.
- For example:
- card=65 (FlyVideo 2000S) - set AMSEL=1 or AMSEL=0
- card=72 (Prolink PV-BT878P rev.9B) - set AMSEL=0 only
-
-msp3400.o
- The driver for the msp34xx sound processor chips. If you have a
- stereo card, you probably want to insmod this one.
-
- insmod args:
- debug=1/2 print some debug info to the syslog,
- 2 is more verbose.
- simple=1 Use the "short programming" method. Newer
- msp34xx versions support this. You need this
- for dbx stereo. Default is on if supported by
- the chip.
- once=1 Don't check the TV-stations Audio mode
- every few seconds, but only once after
- channel switches.
- amsound=1 Audio carrier is AM/NICAM at 6.5 Mhz. This
- should improve things for french people, the
- carrier autoscan seems to work with FM only...
-
-tea6300.o - OBSOLETE (use tvaudio instead)
- The driver for the tea6300 fader chip. If you have a stereo
- card and the msp3400.o doesn't work, you might want to try this
- one. This chip is seen on most STB TV/FM cards (usually from
- Gateway OEM sold surplus on auction sites).
-
- insmod args:
- debug=1 print some debug info to the syslog.
-
-tda8425.o - OBSOLETE (use tvaudio instead)
- The driver for the tda8425 fader chip. This driver used to be
- part of bttv.c, so if your sound used to work but does not
- anymore, try loading this module.
-
- insmod args:
- debug=1 print some debug info to the syslog.
-
-tda985x.o - OBSOLETE (use tvaudio instead)
- The driver for the tda9850/55 audio chips.
-
- insmod args:
- debug=1 print some debug info to the syslog.
- chip=9850/9855 set the chip type.
diff --git a/Documentation/video4linux/bttv/MAKEDEV b/Documentation/video4linux/bttv/MAKEDEV
deleted file mode 100644
index 093c0cd18042..000000000000
--- a/Documentation/video4linux/bttv/MAKEDEV
+++ /dev/null
@@ -1,27 +0,0 @@
-#!/bin/bash
-
-function makedev () {
-
- for dev in 0 1 2 3; do
- echo "/dev/$1$dev: char 81 $[ $2 + $dev ]"
- rm -f /dev/$1$dev
- mknod /dev/$1$dev c 81 $[ $2 + $dev ]
- chmod 666 /dev/$1$dev
- done
-
- # symlink for default device
- rm -f /dev/$1
- ln -s /dev/${1}0 /dev/$1
-}
-
-# see http://linux.bytesex.org/v4l2/API.html
-
-echo "*** new device names ***"
-makedev video 0
-makedev radio 64
-makedev vbi 224
-
-#echo "*** old device names (for compatibility only) ***"
-#makedev bttv 0
-#makedev bttv-fm 64
-#makedev bttv-vbi 224
diff --git a/Documentation/video4linux/bttv/Modprobe.conf b/Documentation/video4linux/bttv/Modprobe.conf
deleted file mode 100644
index 55f14650d8cd..000000000000
--- a/Documentation/video4linux/bttv/Modprobe.conf
+++ /dev/null
@@ -1,11 +0,0 @@
-# i2c
-alias char-major-89 i2c-dev
-options i2c-core i2c_debug=1
-options i2c-algo-bit bit_test=1
-
-# bttv
-alias char-major-81 videodev
-alias char-major-81-0 bttv
-options bttv card=2 radio=1
-options tuner debug=1
-
diff --git a/Documentation/video4linux/bttv/Modules.conf b/Documentation/video4linux/bttv/Modules.conf
deleted file mode 100644
index 8f258faf18f1..000000000000
--- a/Documentation/video4linux/bttv/Modules.conf
+++ /dev/null
@@ -1,14 +0,0 @@
-# For modern kernels (2.6 or above), this belongs in /etc/modprobe.d/*.conf
-# For for 2.4 kernels or earlier, this belongs in /etc/modules.conf.
-
-# i2c
-alias char-major-89 i2c-dev
-options i2c-core i2c_debug=1
-options i2c-algo-bit bit_test=1
-
-# bttv
-alias char-major-81 videodev
-alias char-major-81-0 bttv
-options bttv card=2 radio=1
-options tuner debug=1
-
diff --git a/Documentation/video4linux/bttv/PROBLEMS b/Documentation/video4linux/bttv/PROBLEMS
deleted file mode 100644
index 2b8b0079f7c7..000000000000
--- a/Documentation/video4linux/bttv/PROBLEMS
+++ /dev/null
@@ -1,62 +0,0 @@
-- Start capturing by pressing "c" or by selecting it via a menu!
-
-- Start capturing by pressing "c" or by selecting it via a menu!!!
-
-- The memory of some S3 cards is not recognized right:
-
- First of all, if you are not using XFree-3.2 or newer, upgrade AT LEAST to
- XFree-3.2A! This solved the problem for most people.
-
- Start up X11 like this: "XF86_S3 -probeonly" and write down where the
- linear frame buffer is.
- If it is different to the address found by bttv install bttv like this:
- "insmod bttv vidmem=0xfb0"
- if the linear frame buffer is at 0xfb000000 (i.e. omit the last 5 zeros!)
-
- Some S3 cards even take up 64MB of memory but only report 32MB to the BIOS.
- If this 64MB area overlaps the IO memory of the Bt848 you also have to
- remap this. E.g.: insmod bttv vidmem=0xfb0 remap=0xfa0
-
- If the video memory is found at the right place and there are no address
- conflicts but still no picture (or the computer even crashes),
- try disabling features of your PCI chipset in the BIOS setup.
-
- Frank Kapahnke <frank@kapahnke.prima.ruhr.de> also reported that problems
- with his S3 868 went away when he upgraded to XFree 3.2.
-
-
-- I still only get a black picture with my S3 card!
-
- Even with XFree-3.2A some people have problems with their S3 cards
- (mostly with Trio 64 but also with some others)
- Get the free demo version of Accelerated X from www.xinside.com and try
- bttv with it. bttv seems to work with most S3 cards with Accelerated X.
-
- Since I do not know much (better make that almost nothing) about VGA card
- programming I do not know the reason for this.
- Looks like XFree does something different when setting up the video memory?
- Maybe somebody can enlighten me?
- Would be nice if somebody could get this to work with XFree since
- Accelerated X costs more than some of the grabber cards ...
-
- Better linear frame buffer support for S3 cards will probably be in
- XFree 4.0.
-
-- Grabbing is not switched off when changing consoles with XFree.
- That's because XFree and some AcceleratedX versions do not send unmap
- events.
-
-- Some popup windows (e.g. of the window manager) are not refreshed.
-
- Disable backing store by starting X with the option "-bs"
-
-- When using 32 bpp in XFree or 24+8bpp mode in AccelX 3.1 the system
- can sometimes lock up if you use more than 1 bt848 card at the same time.
- You will always get pixel errors when e.g. using more than 1 card in full
- screen mode. Maybe we need something faster than the PCI bus ...
-
-
-- Some S3 cards and the Matrox Mystique will produce pixel errors with
- full resolution in 32-bit mode.
-
-- Some video cards have problems with Accelerated X 4.1
diff --git a/Documentation/video4linux/bttv/README b/Documentation/video4linux/bttv/README
deleted file mode 100644
index 7cbf4fb6cf31..000000000000
--- a/Documentation/video4linux/bttv/README
+++ /dev/null
@@ -1,90 +0,0 @@
-
-Release notes for bttv
-======================
-
-You'll need at least these config options for bttv:
- CONFIG_I2C=m
- CONFIG_I2C_ALGOBIT=m
- CONFIG_VIDEO_DEV=m
-
-The latest bttv version is available from http://bytesex.org/bttv/
-
-
-Make bttv work with your card
------------------------------
-
-Just try "modprobe bttv" and see if that works.
-
-If it doesn't bttv likely could not autodetect your card and needs some
-insmod options. The most important insmod option for bttv is "card=n"
-to select the correct card type. If you get video but no sound you've
-very likely specified the wrong (or no) card type. A list of supported
-cards is in CARDLIST.bttv
-
-If bttv takes very long to load (happens sometimes with the cheap
-cards which have no tuner), try adding this to your modules.conf:
- options i2c-algo-bit bit_test=1
-
-For the WinTV/PVR you need one firmware file from the driver CD:
-hcwamc.rbf. The file is in the pvr45xxx.exe archive (self-extracting
-zip file, unzip can unpack it). Put it into the /etc/pvr directory or
-use the firm_altera=<path> insmod option to point the driver to the
-location of the file.
-
-If your card isn't listed in CARDLIST.bttv or if you have trouble making
-audio work, you should read the Sound-FAQ.
-
-
-Autodetecting cards
--------------------
-
-bttv uses the PCI Subsystem ID to autodetect the card type. lspci lists
-the Subsystem ID in the second line, looks like this:
-
-00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
- Subsystem: Hauppauge computer works Inc. WinTV/GO
- Flags: bus master, medium devsel, latency 32, IRQ 5
- Memory at e2000000 (32-bit, prefetchable) [size=4K]
-
-only bt878-based cards can have a subsystem ID (which does not mean
-that every card really has one). bt848 cards can't have a Subsystem
-ID and therefore can't be autodetected. There is a list with the ID's
-in bttv-cards.c (in case you are intrested or want to mail patches
-with updates).
-
-
-Still doesn't work?
--------------------
-
-I do NOT have a lab with 30+ different grabber boards and a
-PAL/NTSC/SECAM test signal generator at home, so I often can't
-reproduce your problems. This makes debugging very difficult for me.
-If you have some knowledge and spare time, please try to fix this
-yourself (patches very welcome of course...) You know: The linux
-slogan is "Do it yourself".
-
-There is a mailing list: linux-media@vger.kernel.org
-http://vger.kernel.org/vger-lists.html#linux-media
-
-If you have trouble with some specific TV card, try to ask there
-instead of mailing me directly. The chance that someone with the
-same card listens there is much higher...
-
-For problems with sound: There are a lot of different systems used
-for TV sound all over the world. And there are also different chips
-which decode the audio signal. Reports about sound problems ("stereo
-does'nt work") are pretty useless unless you include some details
-about your hardware and the TV sound scheme used in your country (or
-at least the country you are living in).
-
-
-Finally: If you mail some patches for bttv around the world (to
-linux-kernel/Alan/Linus/...), please Cc: me.
-
-
-Have fun with bttv,
-
- Gerd
-
---
-Gerd Knorr <kraxel@bytesex.org>
diff --git a/Documentation/video4linux/bttv/README.WINVIEW b/Documentation/video4linux/bttv/README.WINVIEW
deleted file mode 100644
index c61cf2864287..000000000000
--- a/Documentation/video4linux/bttv/README.WINVIEW
+++ /dev/null
@@ -1,33 +0,0 @@
-
-Support for the Leadtek WinView 601 TV/FM by Jon Tombs <jon@gte.esi.us.es>
-
-This card is basically the same as all the rest (Bt484A, Philips tuner),
-the main difference is that they have attached a programmable attenuator to 3
-GPIO lines in order to give some volume control. They have also stuck an
-infra-red remote control decoded on the board, I will add support for this
-when I get time (it simple generates an interrupt for each key press, with
-the key code is placed in the GPIO port).
-
-I don't yet have any application to test the radio support. The tuner
-frequency setting should work but it is possible that the audio multiplexer
-is wrong. If it doesn't work, send me email.
-
-
-- No Thanks to Leadtek they refused to answer any questions about their
-hardware. The driver was written by visual inspection of the card. If you
-use this driver, send an email insult to them, and tell them you won't
-continue buying their hardware unless they support Linux.
-
-- Little thanks to Princeton Technology Corp (http://www.princeton.com.tw)
-who make the audio attenuator. Their publicly available data-sheet available
-on their web site doesn't include the chip programming information! Hidden
-on their server are the full data-sheets, but don't ask how I found it.
-
-To use the driver I use the following options, the tuner and pll settings might
-be different in your country
-
-insmod videodev
-insmod i2c scan=1 i2c_debug=0 verbose=0
-insmod tuner type=1 debug=0
-insmod bttv pll=1 radio=1 card=17
-
diff --git a/Documentation/video4linux/bttv/README.freeze b/Documentation/video4linux/bttv/README.freeze
deleted file mode 100644
index 5eddfa076cfb..000000000000
--- a/Documentation/video4linux/bttv/README.freeze
+++ /dev/null
@@ -1,74 +0,0 @@
-
-If the box freezes hard with bttv ...
-=====================================
-
-It might be a bttv driver bug. It also might be bad hardware. It also
-might be something else ...
-
-Just mailing me "bttv freezes" isn't going to help much. This README
-has a few hints how you can help to pin down the problem.
-
-
-bttv bugs
----------
-
-If some version works and another doesn't it is likely to be a driver
-bug. It is very helpful if you can tell where exactly it broke
-(i.e. the last working and the first broken version).
-
-With a hard freeze you probably doesn't find anything in the logfiles.
-The only way to capture any kernel messages is to hook up a serial
-console and let some terminal application log the messages. /me uses
-screen. See Documentation/serial-console.txt for details on setting
-up a serial console.
-
-Read Documentation/oops-tracing.txt to learn how to get any useful
-information out of a register+stack dump printed by the kernel on
-protection faults (so-called "kernel oops").
-
-If you run into some kind of deadlock, you can try to dump a call trace
-for each process using sysrq-t (see Documentation/sysrq.txt).
-This way it is possible to figure where *exactly* some process in "D"
-state is stuck.
-
-I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid
-for some people. Thus probably a small buglet left somewhere in bttv
-0.7.x. I have no idea where exactly, it works stable for me and a lot of
-other people. But in case you have problems with the 0.7.x versions you
-can give 0.8.x a try ...
-
-
-hardware bugs
--------------
-
-Some hardware can't deal with PCI-PCI transfers (i.e. grabber => vga).
-Sometimes problems show up with bttv just because of the high load on
-the PCI bus. The bt848/878 chips have a few workarounds for known
-incompatibilities, see README.quirks.
-
-Some folks report that increasing the pci latency helps too,
-althrought I'm not sure whenever this really fixes the problems or
-only makes it less likely to happen. Both bttv and btaudio have a
-insmod option to set the PCI latency of the device.
-
-Some mainboard have problems to deal correctly with multiple devices
-doing DMA at the same time. bttv + ide seems to cause this sometimes,
-if this is the case you likely see freezes only with video and hard disk
-access at the same time. Updating the IDE driver to get the latest and
-greatest workarounds for hardware bugs might fix these problems.
-
-
-other
------
-
-If you use some binary-only yunk (like nvidia module) try to reproduce
-the problem without.
-
-IRQ sharing is known to cause problems in some cases. It works just
-fine in theory and many configurations. Neverless it might be worth a
-try to shuffle around the PCI cards to give bttv another IRQ or make
-it share the IRQ with some other piece of hardware. IRQ sharing with
-VGA cards seems to cause trouble sometimes. I've also seen funny
-effects with bttv sharing the IRQ with the ACPI bridge (and
-apci-enabled kernel).
-
diff --git a/Documentation/video4linux/bttv/README.quirks b/Documentation/video4linux/bttv/README.quirks
deleted file mode 100644
index 92e03929a6b2..000000000000
--- a/Documentation/video4linux/bttv/README.quirks
+++ /dev/null
@@ -1,83 +0,0 @@
-
-Below is what the bt878 data book says about the PCI bug compatibility
-modes of the bt878 chip.
-
-The triton1 insmod option sets the EN_TBFX bit in the control register.
-The vsfx insmod option does the same for EN_VSFX bit. If you have
-stability problems you can try if one of these options makes your box
-work solid.
-
-drivers/pci/quirks.c knows about these issues, this way these bits are
-enabled automagically for known-buggy chipsets (look at the kernel
-messages, bttv tells you).
-
-HTH,
-
- Gerd
-
----------------------------- cut here --------------------------
-
-Normal PCI Mode
----------------
-
-The PCI REQ signal is the logical-or of the incoming function requests.
-The inter-nal GNT[0:1] signals are gated asynchronously with GNT and
-demultiplexed by the audio request signal. Thus the arbiter defaults to
-the video function at power-up and parks there during no requests for
-bus access. This is desirable since the video will request the bus more
-often. However, the audio will have highest bus access priority. Thus
-the audio will have first access to the bus even when issuing a request
-after the video request but before the PCI external arbiter has granted
-access to the Bt879. Neither function can preempt the other once on the
-bus. The duration to empty the entire video PCI FIFO onto the PCI bus is
-very short compared to the bus access latency the audio PCI FIFO can
-tolerate.
-
-
-430FX Compatibility Mode
-------------------------
-
-When using the 430FX PCI, the following rules will ensure
-compatibility:
-
- (1) Deassert REQ at the same time as asserting FRAME.
- (2) Do not reassert REQ to request another bus transaction until after
- finish-ing the previous transaction.
-
-Since the individual bus masters do not have direct control of REQ, a
-simple logical-or of video and audio requests would violate the rules.
-Thus, both the arbiter and the initiator contain 430FX compatibility
-mode logic. To enable 430FX mode, set the EN_TBFX bit as indicated in
-Device Control Register on page 104.
-
-When EN_TBFX is enabled, the arbiter ensures that the two compatibility
-rules are satisfied. Before GNT is asserted by the PCI arbiter, this
-internal arbiter may still logical-or the two requests. However, once
-the GNT is issued, this arbiter must lock in its decision and now route
-only the granted request to the REQ pin. The arbiter decision lock
-happens regardless of the state of FRAME because it does not know when
-FRAME will be asserted (typically - each initiator will assert FRAME on
-the cycle following GNT). When FRAME is asserted, it is the initiator s
-responsibility to remove its request at the same time. It is the
-arbiters responsibility to allow this request to flow through to REQ and
-not allow the other request to hold REQ asserted. The decision lock may
-be removed at the end of the transaction: for example, when the bus is
-idle (FRAME and IRDY). The arbiter decision may then continue
-asynchronously until GNT is again asserted.
-
-
-Interfacing with Non-PCI 2.1 Compliant Core Logic
--------------------------------------------------
-
-A small percentage of core logic devices may start a bus transaction
-during the same cycle that GNT is de-asserted. This is non PCI 2.1
-compliant. To ensure compatibility when using PCs with these PCI
-controllers, the EN_VSFX bit must be enabled (refer to Device Control
-Register on page 104). When in this mode, the arbiter does not pass GNT
-to the internal functions unless REQ is asserted. This prevents a bus
-transaction from starting the same cycle as GNT is de-asserted. This
-also has the side effect of not being able to take advantage of bus
-parking, thus lowering arbitration performance. The Bt879 drivers must
-query for these non-compliant devices, and set the EN_VSFX bit only if
-required.
-
diff --git a/Documentation/video4linux/bttv/Sound-FAQ b/Documentation/video4linux/bttv/Sound-FAQ
deleted file mode 100644
index 646a47de0016..000000000000
--- a/Documentation/video4linux/bttv/Sound-FAQ
+++ /dev/null
@@ -1,148 +0,0 @@
-
-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:
-
- 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:
-
-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
-does'nt 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:
-
-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:
-
- 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
-
-
-
-Other elements of the tvcards array
-===================================
-
-If you are trying to make a new card work you might find it useful to
-know what the other elements in the tvcards array are good for:
-
-video_inputs - # of video inputs the card has
-audio_inputs - historical cruft, not used any more.
-tuner - which input is the tuner
-svhs - which input is svhs (all others are labeled composite)
-muxsel - video mux, input->registervalue mapping
-pll - same as pll= insmod option
-tuner_type - same as tuner= insmod option
-*_modulename - hint whenever some card needs this or that audio
- module loaded to work properly.
-has_radio - whenever this TV card has a radio tuner.
-no_msp34xx - "1" disables loading of msp3400.o module
-no_tda9875 - "1" disables loading of tda9875.o module
-needs_tvaudio - set to "1" to load tvaudio.o module
-
-If some config item is specified both from the tvcards array and as
-insmod option, the insmod option takes precedence.
-
-
-
-Good luck,
-
- Gerd
-
-
-PS: If you have a new working entry, mail it to me.
-
---
-Gerd Knorr <kraxel@bytesex.org>
diff --git a/Documentation/video4linux/bttv/Specs b/Documentation/video4linux/bttv/Specs
deleted file mode 100644
index f32466cdae05..000000000000
--- a/Documentation/video4linux/bttv/Specs
+++ /dev/null
@@ -1,3 +0,0 @@
-Philips http://www.Semiconductors.COM/pip/
-Conexant http://www.conexant.com/
-Micronas http://www.micronas.com/en/home/index.html
diff --git a/Documentation/video4linux/bttv/THANKS b/Documentation/video4linux/bttv/THANKS
deleted file mode 100644
index 950aa781c2e9..000000000000
--- a/Documentation/video4linux/bttv/THANKS
+++ /dev/null
@@ -1,24 +0,0 @@
-Many thanks to:
-
-- Markus Schroeder <schroedm@uni-duesseldorf.de> for information on the Bt848
- and tuner programming and his control program xtvc.
-
-- Martin Buck <martin-2.buck@student.uni-ulm.de> for his great Videotext
- package.
-
-- Gerd Knorr <kraxel@cs.tu-berlin.de> for the MSP3400 support and the modular
- I2C, tuner, ... support.
-
-
-- MATRIX Vision for giving us 2 cards for free, which made support of
- single crystal operation possible.
-
-- MIRO for providing a free PCTV card and detailed information about the
- components on their cards. (E.g. how the tuner type is detected)
- Without their card I could not have debugged the NTSC mode.
-
-- Hauppauge for telling how the sound input is selected and what components
- they do and will use on their radio cards.
- Also many thanks for faxing me the FM1216 data sheet.
-
-
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 02/18] [media] doc-rst: add documentation for bttv driver
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 01/18] [media] doc-rst: move bttv documentation to bttv.rst file Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 03/18] [media] doc-rst: add documentation for tuners Mauro Carvalho Chehab
` (16 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
Convert it to ReST and add it to media/v4l-drivers book.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/bttv.rst | 156 ++++++++++++++++++------------
Documentation/media/v4l-drivers/index.rst | 1 +
2 files changed, 96 insertions(+), 61 deletions(-)
diff --git a/Documentation/media/v4l-drivers/bttv.rst b/Documentation/media/v4l-drivers/bttv.rst
index d7d956835e38..611e8d529f16 100644
--- a/Documentation/media/v4l-drivers/bttv.rst
+++ b/Documentation/media/v4l-drivers/bttv.rst
@@ -1,11 +1,13 @@
The bttv driver
===============
-
Release notes for bttv
----------------------
You'll need at least these config options for bttv:
+
+.. code-block:: none
+
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_VIDEO_DEV=m
@@ -26,6 +28,9 @@ cards is in CARDLIST.bttv
If bttv takes very long to load (happens sometimes with the cheap
cards which have no tuner), try adding this to your modules.conf:
+
+.. code-block:: none
+
options i2c-algo-bit bit_test=1
For the WinTV/PVR you need one firmware file from the driver CD:
@@ -44,10 +49,12 @@ Autodetecting cards
bttv uses the PCI Subsystem ID to autodetect the card type. lspci lists
the Subsystem ID in the second line, looks like this:
-00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
- Subsystem: Hauppauge computer works Inc. WinTV/GO
- Flags: bus master, medium devsel, latency 32, IRQ 5
- Memory at e2000000 (32-bit, prefetchable) [size=4K]
+.. code-block:: none
+
+ 00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
+ Subsystem: Hauppauge computer works Inc. WinTV/GO
+ Flags: bus master, medium devsel, latency 32, IRQ 5
+ Memory at e2000000 (32-bit, prefetchable) [size=4K]
only bt878-based cards can have a subsystem ID (which does not mean
that every card really has one). bt848 cards can't have a Subsystem
@@ -66,7 +73,7 @@ If you have some knowledge and spare time, please try to fix this
yourself (patches very welcome of course...) You know: The linux
slogan is "Do it yourself".
-There is a mailing list: linux-media@vger.kernel.org
+There is a mailing list at
http://vger.kernel.org/vger-lists.html#linux-media
If you have trouble with some specific TV card, try to ask there
@@ -91,7 +98,7 @@ This list tends to be outdated because it is updated manually ...
bttv.o
-::
+.. code-block:: none
the bt848/878 (grabber chip) driver
@@ -159,7 +166,7 @@ bttv.o
tuner.o
-::
+.. code-block:: none
The tuner driver. You need this unless you want to use only
with a camera or external tuner ...
@@ -173,7 +180,7 @@ tuner.o
tvaudio.o
-::
+.. code-block:: none
new, experimental module which is supported to provide a single
driver for all simple i2c audio control chips (tda/tea*).
@@ -224,8 +231,7 @@ tvaudio.o
msp3400.o
-::
-
+.. code-block:: none
The driver for the msp34xx sound processor chips. If you have a
stereo card, you probably want to insmod this one.
@@ -246,7 +252,7 @@ msp3400.o
tea6300.o - OBSOLETE (use tvaudio instead)
-::
+.. code-block:: none
The driver for the tea6300 fader chip. If you have a stereo
card and the msp3400.o doesn't work, you might want to try this
@@ -258,7 +264,7 @@ tea6300.o - OBSOLETE (use tvaudio instead)
tda8425.o - OBSOLETE (use tvaudio instead)
-::
+.. code-block:: none
The driver for the tda8425 fader chip. This driver used to be
part of bttv.c, so if your sound used to work but does not
@@ -269,7 +275,7 @@ tda8425.o - OBSOLETE (use tvaudio instead)
tda985x.o - OBSOLETE (use tvaudio instead)
-::
+.. code-block:: none
The driver for the tda9850/55 audio chips.
@@ -444,6 +450,8 @@ 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
@@ -489,19 +497,21 @@ 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:
-struct tvcard
-{
- [ ... ]
- u32 gpiomask;
- u32 audiomux[6]; /* Tuner, Radio, external, internal, mute, stereo */
-};
+.. 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
+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.
@@ -512,11 +522,11 @@ 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
-does'nt work with bt878 boards according to some reports I received.
+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 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 ...
@@ -524,22 +534,26 @@ 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:
-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).
+.. 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
+ 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
@@ -549,19 +563,21 @@ Other elements of the tvcards array
If you are trying to make a new card work you might find it useful to
know what the other elements in the tvcards array are good for:
-video_inputs - # of video inputs the card has
-audio_inputs - historical cruft, not used any more.
-tuner - which input is the tuner
-svhs - which input is svhs (all others are labeled composite)
-muxsel - video mux, input->registervalue mapping
-pll - same as pll= insmod option
-tuner_type - same as tuner= insmod option
-*_modulename - hint whenever some card needs this or that audio
- module loaded to work properly.
-has_radio - whenever this TV card has a radio tuner.
-no_msp34xx - "1" disables loading of msp3400.o module
-no_tda9875 - "1" disables loading of tda9875.o module
-needs_tvaudio - set to "1" to load tvaudio.o module
+.. code-block:: none
+
+ video_inputs - # of video inputs the card has
+ audio_inputs - historical cruft, not used any more.
+ tuner - which input is the tuner
+ svhs - which input is svhs (all others are labeled composite)
+ muxsel - video mux, input->registervalue mapping
+ pll - same as pll= insmod option
+ tuner_type - same as tuner= insmod option
+ *_modulename - hint whenever some card needs this or that audio
+ module loaded to work properly.
+ has_radio - whenever this TV card has a radio tuner.
+ no_msp34xx - "1" disables loading of msp3400.o module
+ no_tda9875 - "1" disables loading of tda9875.o module
+ needs_tvaudio - set to "1" to load tvaudio.o module
If some config item is specified both from the tvcards array and as
insmod option, the insmod option takes precedence.
@@ -740,10 +756,12 @@ Identifying:
- LR137 = Flyvideo DV2000/DV3000 (SAA7130/SAA7134 + IEEE1394)
- LR138 Rev.C= Flyvideo 2000 (SAA7130)
- LR138 Flyvideo 3000 (SAA7134) w/Stereo TV
+
- These exist in variations w/FM and w/Remote sometimes denoted
by suffixes "FM" and "R".
#) You have a laptop (miniPCI card):
+
- Product = FlyTV Platinum Mini
- Model/Chip = LR212/saa7135
@@ -911,14 +929,14 @@ is wrong. If it doesn't work, send me email.
- No Thanks to Leadtek they refused to answer any questions about their
-hardware. The driver was written by visual inspection of the card. If you
-use this driver, send an email insult to them, and tell them you won't
-continue buying their hardware unless they support Linux.
+ hardware. The driver was written by visual inspection of the card. If you
+ use this driver, send an email insult to them, and tell them you won't
+ continue buying their hardware unless they support Linux.
- Little thanks to Princeton Technology Corp (http://www.princeton.com.tw)
-who make the audio attenuator. Their publicly available data-sheet available
-on their web site doesn't include the chip programming information! Hidden
-on their server are the full data-sheets, but don't ask how I found it.
+ who make the audio attenuator. Their publicly available data-sheet available
+ on their web site doesn't include the chip programming information! Hidden
+ on their server are the full data-sheets, but don't ask how I found it.
To use the driver I use the following options, the tuner and pll settings might
be different in your country
@@ -953,7 +971,7 @@ Provideo
MediaForte TV-Vision PV951,
Yoko PV951,
Vivanco Tuner Card PCI Art.-Nr.: 68404,
- ) now named PV-951T
+ ) now named PV-951T
- Surveillance Series:
@@ -1009,7 +1027,7 @@ AVerMedia
PCB PCI-ID Model-Name Eeprom Tuner Sound Country
======== =========== =============== ======= ====== ======== =======================
M101.C ISA !
-M108-B Bt848 -- FR1236 US [#f2]_,[#f3]_
+M108-B Bt848 -- FR1236 US [#f2]_, [#f3]_
M1A8-A Bt848 AVer TV-Phone FM1216 --
M168-T 1461:0003 AVerTV Studio 48:17 FM1216 TDA9840T D [#f1]_ w/FM w/Remote
M168-U 1461:0004 TVCapture98 40:11 FI1216 -- D w/Remote
@@ -1060,7 +1078,7 @@ Models:
- Video Highway Xtreme (aka "VHX") (Bt848, FM w/ TEA5757)
IXMicro (former: IMS=Integrated Micro Solutions)
-~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Models:
@@ -1138,8 +1156,10 @@ Models:
- MTV878
Package comes with different contents:
+
a) pcb "MTV878" (CARD=75)
- b) Pixelview Rev. 4_
+ b) Pixelview Rev. 4\_
+
- MTV878R w/Remote Control
- MTV878F w/Remote Control w/FM radio
@@ -1311,13 +1331,16 @@ Models:
- TT-DVB-Sat
- revisions 1.1, 1.3, 1.5, 1.6 and 2.1
- This card is sold as OEM from:
+
- Siemens DVB-s Card
- Hauppauge WinTV DVB-S
- Technisat SkyStar 1 DVB
- Galaxis DVB Sat
+
- Now this card is called TT-PCline Premium Family
- TT-Budget (saa7146, bsru6-701a)
- This card is sold as OEM from:
+ This card is sold as OEM from:
+
- Hauppauge WinTV Nova
- Satelco Standard PCI (DVB-S)
- TT-DVB-C PCI
@@ -1566,7 +1589,7 @@ AVEC Intercapture (bt848, tea6320)
NoBrand
~~~~~~~
-TV Excel = Australian Name for "PV-BT878P+ 8E" or "878TV Rev.3_"
+TV Excel = Australian Name for "PV-BT878P+ 8E" or "878TV Rev.3\_"
Mach www.machspeed.com
~~~~~~~~~~~~~~~~~~~~~~
@@ -1621,9 +1644,11 @@ Models:
- TV Tuner - HBY-33A-RAFFLES Brooktree Bt848KPF + Philips
- TV Tuner MG9910 - HBY33A-TVO CEI + Philips SAA7110 + OKI M548262 + ST STV8438CV
- Primetime TV (ISA)
+
- acquired by Singapore Technologies
- now operating as Chartered Semiconductor Manufacturing
- Manufacturer of video cards is listed as:
+
- Cogent Electronics Industries [CEI]
AITech
@@ -1646,7 +1671,8 @@ www.ids-imaging.de
Models:
- Falcon Series (capture only)
- In USA: http://www.theimagingsource.com/
+
+In USA: http://www.theimagingsource.com/
- DFG/LC1
www.sknet-web.co.jp
@@ -1681,10 +1707,12 @@ Models:
- DST Card/DST-IP (bt878, twinhan asic) VP-1020
- Sold as:
+
- KWorld DVBS Satellite TV-Card
- Powercolor DSTV Satellite Tuner Card
- Prolink Pixelview DTV2000
- Provideo PV-911 Digital Satellite TV Tuner Card With Common Interface ?
+
- DST-CI Card (DVB Satellite) VP-1030
- DCT Card (DVB cable)
@@ -1756,7 +1784,7 @@ Arowana
TV-Karte / Poso Power TV (?) = Zoltrix VP-8482 (?)
-iTVC15 boards:
+iTVC15 boards
~~~~~~~~~~~~~
kuroutoshikou.com ITVC15
@@ -1796,8 +1824,10 @@ Chips used at bttv devices
- Hauppauge Win/TV pci (version 405):
- Microchip 24LC02B or Philips 8582E2Y:
+
- 256 Byte EEPROM with configuration information
- I2C 0xa0-0xa1, (24LC02B also responds to 0xa2-0xaf)
+
- Philips SAA5246AGP/E: Videotext decoder chip, I2C 0x22-0x23
- TDA9800: sound decoder
@@ -1827,8 +1857,11 @@ Chips used at bttv devices
Specs
-----
+
Philips http://www.Semiconductors.COM/pip/
+
Conexant http://www.conexant.com/
+
Micronas http://www.micronas.com/en/home/index.html
Thanks
@@ -1873,6 +1906,7 @@ Gerd Hoffmann
Radio card (ITT sound processor)
bigfoot <bigfoot@net-way.net>
+
Ragnar Hojland Espinosa <ragnar@macula.net>
ConferenceTV card
diff --git a/Documentation/media/v4l-drivers/index.rst b/Documentation/media/v4l-drivers/index.rst
index 8a026455b09c..6cb19b24271e 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -22,6 +22,7 @@ License".
fourcc
v4l-with-ir
cardlist
+ bttv
cafe_ccic
cpia2
cx18
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 03/18] [media] doc-rst: add documentation for tuners
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 01/18] [media] doc-rst: move bttv documentation to bttv.rst file Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 02/18] [media] doc-rst: add documentation for bttv driver Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 04/18] [media] doc-rst: start adding documentation for cx2341x Mauro Carvalho Chehab
` (15 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
Convert bttv/Tuners to ReST and add it to the media/v4l-drivers book.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/index.rst | 1 +
Documentation/media/v4l-drivers/tuners.rst | 90 ++++++++++++++++++------------
2 files changed, 54 insertions(+), 37 deletions(-)
diff --git a/Documentation/media/v4l-drivers/index.rst b/Documentation/media/v4l-drivers/index.rst
index 6cb19b24271e..53bc53c948ab 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -21,6 +21,7 @@ License".
fourcc
v4l-with-ir
+ tuners
cardlist
bttv
cafe_ccic
diff --git a/Documentation/media/v4l-drivers/tuners.rst b/Documentation/media/v4l-drivers/tuners.rst
index 0a371d349542..c3e8a1cf64a6 100644
--- a/Documentation/media/v4l-drivers/tuners.rst
+++ b/Documentation/media/v4l-drivers/tuners.rst
@@ -1,19 +1,26 @@
-1) Tuner Programming
-====================
+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)
+- 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)
-2) Tuner Manufacturers
-======================
+Tuner Manufacturers
+-------------------
-SAMSUNG Tuner identification: (e.g. TCPM9091PD27)
- TCP [ABCJLMNQ] 90[89][125] [DP] [ACD] 27 [ABCD]
+- SAMSUNG Tuner identification: (e.g. TCPM9091PD27)
+
+.. code-block:: none
+
+ TCP [ABCJLMNQ] 90[89][125] [DP] [ACD] 27 [ABCD]
[ABCJLMNQ]:
A= BG+DK
B= BG
@@ -37,9 +44,12 @@ SAMSUNG Tuner identification: (e.g. TCPM9091PD27)
[ABCD]:
3-wire/I2C tuning, 2-band/3-band
- These Tuners are PHILIPS_API compatible.
+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
@@ -63,6 +73,9 @@ Philips Tuner identification: (e.g. FM1216MF)
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
@@ -82,34 +95,37 @@ Temic Tuner identification: (.e.g 4006FH5)
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
+- 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 = ??
+
+- 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:(1)
-Lit.
-(1) conexant100029b-PCI-Decoder-ApplicationNote.pdf
+- 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
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 04/18] [media] doc-rst: start adding documentation for cx2341x
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (2 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 03/18] [media] doc-rst: add documentation for tuners Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 05/18] [media] cx2341x.rst: add fw-decoder-registers.txt content Mauro Carvalho Chehab
` (14 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
move the contents of fw-decoder-api.txt to cx2341x and
convert it to ReST file, adding it to media/v4l-drivers
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/cx2341x.rst | 564 +++++++++++++++++++++
Documentation/media/v4l-drivers/index.rst | 1 +
.../video4linux/cx2341x/fw-decoder-api.txt | 297 -----------
3 files changed, 565 insertions(+), 297 deletions(-)
create mode 100644 Documentation/media/v4l-drivers/cx2341x.rst
delete mode 100644 Documentation/video4linux/cx2341x/fw-decoder-api.txt
diff --git a/Documentation/media/v4l-drivers/cx2341x.rst b/Documentation/media/v4l-drivers/cx2341x.rst
new file mode 100644
index 000000000000..6f4ac07f52cd
--- /dev/null
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -0,0 +1,564 @@
+The cx2341x driver
+==================
+
+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
diff --git a/Documentation/media/v4l-drivers/index.rst b/Documentation/media/v4l-drivers/index.rst
index 53bc53c948ab..34990b536d39 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -27,6 +27,7 @@ License".
cafe_ccic
cpia2
cx18
+ cx2341x
cx88
davinci-vpbe
fimc
diff --git a/Documentation/video4linux/cx2341x/fw-decoder-api.txt b/Documentation/video4linux/cx2341x/fw-decoder-api.txt
deleted file mode 100644
index 8c317b7a4fc9..000000000000
--- a/Documentation/video4linux/cx2341x/fw-decoder-api.txt
+++ /dev/null
@@ -1,297 +0,0 @@
-Decoder firmware API description
-================================
-
-Note: this API is part of the decoder firmware, so it's cx23415 only.
-
--------------------------------------------------------------------------------
-
-Name CX2341X_DEC_PING_FW
-Enum 0/0x00
-Description
- This API call does nothing. It may be used to check if the firmware
- is responding.
-
--------------------------------------------------------------------------------
-
-Name 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)
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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]
- 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]
- 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)
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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.
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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)
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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.
-
--------------------------------------------------------------------------------
-
-Name CX2341X_DEC_SET_STANDARD
-Enum 16/0x10
-Description
- Selects display standard
-Param[0]
- 0=NTSC, 1=PAL
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name CX2341X_DEC_SET_STREAM_INPUT
-Enum 20/0x14
-Description
- Select decoder stream input port
-Param[0]
- 0=memory (default), 1=streaming
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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.
- Event: 3=Decoder started
- Event: 4=Unknown: goes off 10-15 times per second while decoding.
- Event: 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.
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 05/18] [media] cx2341x.rst: add fw-decoder-registers.txt content
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (3 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 04/18] [media] doc-rst: start adding documentation for cx2341x Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 06/18] [media] cx2341x.rst: Add the contents of fw-encoder-api.txt Mauro Carvalho Chehab
` (13 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
Convert the contents of fw-decoder-registers.txt to ReST and
add it to cx2341x.rst file.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/cx2341x.rst | 1003 ++++++++++++++++++--
.../video4linux/cx2341x/fw-decoder-regs.txt | 817 ----------------
2 files changed, 914 insertions(+), 906 deletions(-)
delete mode 100644 Documentation/video4linux/cx2341x/fw-decoder-regs.txt
diff --git a/Documentation/media/v4l-drivers/cx2341x.rst b/Documentation/media/v4l-drivers/cx2341x.rst
index 6f4ac07f52cd..f1c2d8d5978d 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -9,12 +9,12 @@ Decoder firmware API description
CX2341X_DEC_PING_FW
--------------------
+~~~~~~~~~~~~~~~~~~~
Enum: 0/0x00
Description
-~~~~~~~~~~~
+^^^^^^^^^^^
This API call does nothing. It may be used to check if the firmware
is responding.
@@ -22,22 +22,22 @@ 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)
@@ -45,18 +45,18 @@ 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
@@ -68,24 +68,24 @@ Display 0=last frame, 1=black
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:
@@ -96,7 +96,7 @@ operation:
desired speed.
Param[0]
-~~~~~~~~
+^^^^^^^^
.. code-block:: none
@@ -118,7 +118,7 @@ Param[0]
faster playback. Instead the host should start dropping frames.
Param[1]
-~~~~~~~~
+^^^^^^^^
Direction: 0=forward, 1=reverse
@@ -128,7 +128,7 @@ Direction: 0=forward, 1=reverse
reverse order.
Param[2]
-~~~~~~~~
+^^^^^^^^
.. code-block:: none
@@ -138,7 +138,7 @@ Param[2]
7=I, P, B frames
Param[3]
-~~~~~~~~
+^^^^^^^^
B frames per GOP (for reverse play only)
@@ -149,17 +149,17 @@ B frames per GOP (for reverse play only)
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)
@@ -167,35 +167,35 @@ 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.
@@ -203,114 +203,114 @@ 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.
@@ -318,34 +318,34 @@ 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
@@ -355,77 +355,77 @@ Version bitmask:
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
@@ -433,18 +433,18 @@ Stereo mode action:
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.
@@ -453,112 +453,937 @@ Event:
- 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
+
+ --------------------------------------------------------------------------------
+
diff --git a/Documentation/video4linux/cx2341x/fw-decoder-regs.txt b/Documentation/video4linux/cx2341x/fw-decoder-regs.txt
deleted file mode 100644
index cf52c8f20b9e..000000000000
--- a/Documentation/video4linux/cx2341x/fw-decoder-regs.txt
+++ /dev/null
@@ -1,817 +0,0 @@
-PVR350 Video decoder registers 0x02002800 -> 0x02002B00
-=======================================================
-
-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.
-
---------------------------------------------------------------------------------
-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
-
---------------------------------------------------------------------------------
-
-v0.4 - 12 March 2007 - Ian Armstrong (ian@iarmst.demon.co.uk)
-
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 06/18] [media] cx2341x.rst: Add the contents of fw-encoder-api.txt
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (4 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 05/18] [media] cx2341x.rst: add fw-decoder-registers.txt content Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 07/18] [media] cx2341x.rst: add the contents of fw-calling.txt Mauro Carvalho Chehab
` (12 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
Convert its contents to ReST and add to cx2341x.rst.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/cx2341x.rst | 1241 ++++++++++++++++++++
.../video4linux/cx2341x/fw-encoder-api.txt | 709 -----------
2 files changed, 1241 insertions(+), 709 deletions(-)
delete mode 100644 Documentation/video4linux/cx2341x/fw-encoder-api.txt
diff --git a/Documentation/media/v4l-drivers/cx2341x.rst b/Documentation/media/v4l-drivers/cx2341x.rst
index f1c2d8d5978d..2677ac6fd649 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -1,6 +1,1247 @@
The cx2341x driver
==================
+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
--------------------------------
diff --git a/Documentation/video4linux/cx2341x/fw-encoder-api.txt b/Documentation/video4linux/cx2341x/fw-encoder-api.txt
deleted file mode 100644
index 5a27af2ee1c6..000000000000
--- a/Documentation/video4linux/cx2341x/fw-encoder-api.txt
+++ /dev/null
@@ -1,709 +0,0 @@
-Encoder firmware API description
-================================
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_PING_FW
-Enum 128/0x80
-Description
- Does nothing. Can be used to check if the firmware is responding.
-
--------------------------------------------------------------------------------
-
-Name 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.
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_SET_AUDIO_ID
-Enum 137/0x89
-Description
- Assigns the transport stream ID of the encoded audio stream
-Param[0]
- Audio Stream ID
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_SET_VIDEO_ID
-Enum 139/0x8B
-Description
- Set video transport stream ID
-Param[0]
- Video stream ID
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_SET_PCR_ID
-Enum 141/0x8D
-Description
- Assigns the transport stream ID for PCR packets
-Param[0]
- PCR Stream ID
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_SET_BIT_RATE
-Enum 149/0x95
-Description
- Assign average video stream bitrate. Note on the last three params:
- Param[3] and [4] seem to be always 0, param [5] doesn't seem to be used.
-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
-
--------------------------------------------------------------------------------
-
-Name 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 that GOP size must be a multiple of (B-frames + 1).
-
--------------------------------------------------------------------------------
-
-Name 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' reserved
- ....
- '1111' reserved
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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)
-
--------------------------------------------------------------------------------
-
-Name 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.
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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.
-
--------------------------------------------------------------------------------
-
-Name 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:
- 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
-
--------------------------------------------------------------------------------
-
-Name 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.
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_SET_GOP_CLOSURE
-Enum 197/0xC5
-Description
- Assigns the GOP open/close property.
-Param[0]
- 0=Open
- 1=Closed
-
--------------------------------------------------------------------------------
-
-Name 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.
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_SET_PGM_INDEX_INFO
-Enum 199/0xC7
-Description
- Sets the Program Index Information.
- The information is stored as follows:
-
- 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 that 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]
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_SET_VBI_CONFIG
-Enum 200/0xC8
-Description
- Configure VBI settings
-Param[0]
- Bitmap:
- 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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)
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_INITIALIZE_INPUT
-Enum 205/0xCD
-Description
- Initializes the video input
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_REFRESH_INPUT
-Enum 211/0xD3
-Description
- Refreshes the video input
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_SET_COPYRIGHT
-Enum 212/0xD4
-Description
- Sets stream copyright property
-Param[0]
- 0=Stream is not copyrighted
- 1=Stream is copyrighted
-
--------------------------------------------------------------------------------
-
-Name 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.
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_MUTE_VIDEO
-Enum 217/0xD9
-Description
- Video muting
-Param[0]
- Bit usage:
- 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
-
--------------------------------------------------------------------------------
-
-Name CX2341X_ENC_MUTE_AUDIO
-Enum 218/0xDA
-Description
- Audio muting
-Param[0]
- 0=audio not muted
- 1=audio muted (produces silent mpeg audio stream)
-
--------------------------------------------------------------------------------
-
-Name 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.
-
--------------------------------------------------------------------------------
-
-Name 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:
- 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.
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 07/18] [media] cx2341x.rst: add the contents of fw-calling.txt
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (5 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 06/18] [media] cx2341x.rst: Add the contents of fw-encoder-api.txt Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 08/18] [media] cx2341x.rst: add contents of fw-dma.txt Mauro Carvalho Chehab
` (11 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
Convert it to ReST and add its contents at this file.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/cx2341x.rst | 75 ++++++++++++++++++++++++
Documentation/video4linux/cx2341x/fw-calling.txt | 69 ----------------------
2 files changed, 75 insertions(+), 69 deletions(-)
delete mode 100644 Documentation/video4linux/cx2341x/fw-calling.txt
diff --git a/Documentation/media/v4l-drivers/cx2341x.rst b/Documentation/media/v4l-drivers/cx2341x.rst
index 2677ac6fd649..cbfa14eccd76 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -1,6 +1,81 @@
The cx2341x driver
==================
+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.
+
+
Encoder firmware API description
--------------------------------
diff --git a/Documentation/video4linux/cx2341x/fw-calling.txt b/Documentation/video4linux/cx2341x/fw-calling.txt
deleted file mode 100644
index 8d21181de537..000000000000
--- a/Documentation/video4linux/cx2341x/fw-calling.txt
+++ /dev/null
@@ -1,69 +0,0 @@
-This page describes how to make calls to the firmware api.
-
-How to call
-===========
-
-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:
-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 the
-fw-*-api.txt documents.
-
-The return value is a 32-bit enumerator. Only two values are currently defined:
-0=success and -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 API specifics may be
-found in the fw-*-api.txt documents.
-
-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.
-
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 08/18] [media] cx2341x.rst: add contents of fw-dma.txt
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (6 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 07/18] [media] cx2341x.rst: add the contents of fw-calling.txt Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 09/18] [media] cx2341x.rst: add contents of fw-memory.txt Mauro Carvalho Chehab
` (10 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
Add the contents of fw-dma.txt, converted to ReST, and
drop the old file.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/cx2341x.rst | 99 ++++++++++++++++++++++++++++
Documentation/video4linux/cx2341x/fw-dma.txt | 96 ---------------------------
2 files changed, 99 insertions(+), 96 deletions(-)
delete mode 100644 Documentation/video4linux/cx2341x/fw-dma.txt
diff --git a/Documentation/media/v4l-drivers/cx2341x.rst b/Documentation/media/v4l-drivers/cx2341x.rst
index cbfa14eccd76..ca2f15c5b8f7 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -2703,3 +2703,102 @@ out what values are bad when it hangs.
--------------------------------------------------------------------------------
+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/video4linux/cx2341x/fw-dma.txt b/Documentation/video4linux/cx2341x/fw-dma.txt
deleted file mode 100644
index be52b6fd1e9a..000000000000
--- a/Documentation/video4linux/cx2341x/fw-dma.txt
+++ /dev/null
@@ -1,96 +0,0 @@
-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
-1 write completed
-2 DMA read error
-3 DMA write error
-4 Scatter-Gather array error
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 09/18] [media] cx2341x.rst: add contents of fw-memory.txt
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (7 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 08/18] [media] cx2341x.rst: add contents of fw-dma.txt Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 10/18] [media] cx2341x.rst: add the contents of fw-upload.txt Mauro Carvalho Chehab
` (9 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
Convert the content to ReST and add it at the cx231xx.rst
file.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/cx2341x.rst | 151 ++++++++++++++++++++++++
Documentation/video4linux/cx2341x/fw-memory.txt | 139 ----------------------
2 files changed, 151 insertions(+), 139 deletions(-)
delete mode 100644 Documentation/video4linux/cx2341x/fw-memory.txt
diff --git a/Documentation/media/v4l-drivers/cx2341x.rst b/Documentation/media/v4l-drivers/cx2341x.rst
index ca2f15c5b8f7..ed7e536c9bd0 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -1,6 +1,157 @@
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
+
+
How to call the firmware API
----------------------------
diff --git a/Documentation/video4linux/cx2341x/fw-memory.txt b/Documentation/video4linux/cx2341x/fw-memory.txt
deleted file mode 100644
index 9d736fe8de66..000000000000
--- a/Documentation/video4linux/cx2341x/fw-memory.txt
+++ /dev/null
@@ -1,139 +0,0 @@
-This document 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:
-
- 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.
-
-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.
-
-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
-30 Encoder EOS
-29 Encoder VBI capture
-28 Encoder Video Input Module reset event
-27 Encoder DMA complete
-24 Decoder audio mode change detection event (through event notification)
-22 Decoder data request
-20 Decoder DMA complete
-19 Decoder VBI re-insertion
-18 Decoder DMA err (linked-list bad)
-
-Missing
-Encoder API call completed
-Decoder API call completed
-Encoder API post(?)
-Decoder API post(?)
-Decoder VTRACE event
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 10/18] [media] cx2341x.rst: add the contents of fw-upload.txt
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (8 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 09/18] [media] cx2341x.rst: add contents of fw-memory.txt Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 11/18] [media] cx2341x.rst: add contents of fw-osd-api.txt Mauro Carvalho Chehab
` (8 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
Add the contents of fw-upload.txt, after converting it to
ReST format.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/cx2341x.rst | 53 +++++++++++++++++++++++++++++
1 file changed, 53 insertions(+)
diff --git a/Documentation/media/v4l-drivers/cx2341x.rst b/Documentation/media/v4l-drivers/cx2341x.rst
index ed7e536c9bd0..0d1bd26623b9 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -152,6 +152,59 @@ Missing documentation
- 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
----------------------------
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 11/18] [media] cx2341x.rst: add contents of fw-osd-api.txt
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (9 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 10/18] [media] cx2341x.rst: add the contents of fw-upload.txt Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 12/18] [media] cx2341x: add contents of README.hm12 Mauro Carvalho Chehab
` (7 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
Convert it to ReST format and add to cx2341x.rst file.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/cx2341x.rst | 675 +++++++++++++++++++++++
Documentation/video4linux/cx2341x/fw-osd-api.txt | 350 ------------
Documentation/video4linux/cx2341x/fw-upload.txt | 49 --
3 files changed, 675 insertions(+), 399 deletions(-)
delete mode 100644 Documentation/video4linux/cx2341x/fw-osd-api.txt
delete mode 100644 Documentation/video4linux/cx2341x/fw-upload.txt
diff --git a/Documentation/media/v4l-drivers/cx2341x.rst b/Documentation/media/v4l-drivers/cx2341x.rst
index 0d1bd26623b9..57ae45938919 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -280,6 +280,681 @@ 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
--------------------------------
diff --git a/Documentation/video4linux/cx2341x/fw-osd-api.txt b/Documentation/video4linux/cx2341x/fw-osd-api.txt
deleted file mode 100644
index 89c4601042c1..000000000000
--- a/Documentation/video4linux/cx2341x/fw-osd-api.txt
+++ /dev/null
@@ -1,350 +0,0 @@
-OSD firmware API description
-============================
-
-Note: this API is part of the decoder firmware, so it's cx23415 only.
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name CX2341X_OSD_SET_STATE
-Enum 69/0x45
-Description
- OSD switch
-Param[0]
- 0=off, 1=on
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name CX2341X_OSD_GET_FLICKER_STATE
-Enum 79/0x4F
-Description
- Retrieve flicker reduction module state
-Result[0]
- flicker state: 0=off, 1=on
-
--------------------------------------------------------------------------------
-
-Name CX2341X_OSD_SET_FLICKER_STATE
-Enum 80/0x50
-Description
- Set flicker reduction module state
-Param[0]
- State: 0=off, 1=on
-
--------------------------------------------------------------------------------
-
-Name CX2341X_OSD_BLT_COPY
-Enum 82/0x52
-Description
- BLT copy
-Param[0]
-'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]
- '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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name 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
-
--------------------------------------------------------------------------------
-
-Name CX2341X_OSD_SET_CHROMA_KEY
-Enum 96/0x60
-Description
- Chroma key switch and color
-Param[0]
- state: 0=off, 1=on
-Param[1]
- color
-
--------------------------------------------------------------------------------
-
-Name CX2341X_OSD_GET_ALPHA_CONTENT_INDEX
-Enum 97/0x61
-Description
- Retrieve alpha content index
-Result[0]
- alpha content index, Range 0:15
-
--------------------------------------------------------------------------------
-
-Name CX2341X_OSD_SET_ALPHA_CONTENT_INDEX
-Enum 98/0x62
-Description
- Assign alpha content index
-Param[0]
- alpha content index, range 0:15
diff --git a/Documentation/video4linux/cx2341x/fw-upload.txt b/Documentation/video4linux/cx2341x/fw-upload.txt
deleted file mode 100644
index 60c502ce3215..000000000000
--- a/Documentation/video4linux/cx2341x/fw-upload.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-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.
-
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 12/18] [media] cx2341x: add contents of README.hm12
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (10 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 11/18] [media] cx2341x.rst: add contents of fw-osd-api.txt Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 13/18] [media] cx2341x.rst: add contents of README.vbi Mauro Carvalho Chehab
` (6 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
The README.hm12 file describes the proprietary format used
by this driver for raw format, called HM12. Add its description
at the document, after converted to ReST.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/cx2341x.rst | 125 ++++++++++++++++++++++++++
Documentation/video4linux/cx2341x/README.hm12 | 120 -------------------------
2 files changed, 125 insertions(+), 120 deletions(-)
delete mode 100644 Documentation/video4linux/cx2341x/README.hm12
diff --git a/Documentation/media/v4l-drivers/cx2341x.rst b/Documentation/media/v4l-drivers/cx2341x.rst
index 57ae45938919..15bfd345df48 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -3681,3 +3681,128 @@ Register 0x0004 holds the DMA Transfer Status:
- bit 2: DMA read error
- bit 3: DMA write error
- bit 4: Scatter-Gather array error
+
+Non-compressed file format
+--------------------------
+
+The cx23416 can produce (and the cx23415 can also read) raw YUV output. The
+format of a YUV frame is specific to this chip and is called HM12. 'HM' stands
+for 'Hauppauge Macroblock', which is a misnomer as 'Conexant Macroblock' would
+be more accurate.
+
+The format is YUV 4:2:0 which uses 1 Y byte per pixel and 1 U and V byte per
+four pixels.
+
+The data is encoded as two macroblock planes, the first containing the Y
+values, the second containing UV macroblocks.
+
+The Y plane is divided into blocks of 16x16 pixels from left to right
+and from top to bottom. Each block is transmitted in turn, line-by-line.
+
+So the first 16 bytes are the first line of the top-left block, the
+second 16 bytes are the second line of the top-left block, etc. After
+transmitting this block the first line of the block on the right to the
+first block is transmitted, etc.
+
+The UV plane is divided into blocks of 16x8 UV values going from left
+to right, top to bottom. Each block is transmitted in turn, line-by-line.
+
+So the first 16 bytes are the first line of the top-left block and
+contain 8 UV value pairs (16 bytes in total). The second 16 bytes are the
+second line of 8 UV pairs of the top-left block, etc. After transmitting
+this block the first line of the block on the right to the first block is
+transmitted, etc.
+
+The code below is given as an example on how to convert HM12 to separate
+Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels.
+
+The width of a frame is always 720 pixels, regardless of the actual specified
+width.
+
+If the height is not a multiple of 32 lines, then the captured video is
+missing macroblocks at the end and is unusable. So the height must be a
+multiple of 32.
+
+Raw format c example
+~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <string.h>
+
+ static unsigned char frame[576*720*3/2];
+ static unsigned char framey[576*720];
+ static unsigned char frameu[576*720 / 4];
+ static unsigned char framev[576*720 / 4];
+
+ static void de_macro_y(unsigned char* dst, unsigned char *src, int dstride, int w, int h)
+ {
+ unsigned int y, x, i;
+
+ // descramble Y plane
+ // dstride = 720 = w
+ // The Y plane is divided into blocks of 16x16 pixels
+ // Each block in transmitted in turn, line-by-line.
+ for (y = 0; y < h; y += 16) {
+ for (x = 0; x < w; x += 16) {
+ for (i = 0; i < 16; i++) {
+ memcpy(dst + x + (y + i) * dstride, src, 16);
+ src += 16;
+ }
+ }
+ }
+ }
+
+ static void de_macro_uv(unsigned char *dstu, unsigned char *dstv, unsigned char *src, int dstride, int w, int h)
+ {
+ unsigned int y, x, i;
+
+ // descramble U/V plane
+ // dstride = 720 / 2 = w
+ // The U/V values are interlaced (UVUV...).
+ // Again, the UV plane is divided into blocks of 16x16 UV values.
+ // Each block in transmitted in turn, line-by-line.
+ for (y = 0; y < h; y += 16) {
+ for (x = 0; x < w; x += 8) {
+ for (i = 0; i < 16; i++) {
+ int idx = x + (y + i) * dstride;
+
+ dstu[idx+0] = src[0]; dstv[idx+0] = src[1];
+ dstu[idx+1] = src[2]; dstv[idx+1] = src[3];
+ dstu[idx+2] = src[4]; dstv[idx+2] = src[5];
+ dstu[idx+3] = src[6]; dstv[idx+3] = src[7];
+ dstu[idx+4] = src[8]; dstv[idx+4] = src[9];
+ dstu[idx+5] = src[10]; dstv[idx+5] = src[11];
+ dstu[idx+6] = src[12]; dstv[idx+6] = src[13];
+ dstu[idx+7] = src[14]; dstv[idx+7] = src[15];
+ src += 16;
+ }
+ }
+ }
+ }
+
+ /*************************************************************************/
+ int main(int argc, char **argv)
+ {
+ FILE *fin;
+ int i;
+
+ if (argc == 1) fin = stdin;
+ else fin = fopen(argv[1], "r");
+
+ if (fin == NULL) {
+ fprintf(stderr, "cannot open input\n");
+ exit(-1);
+ }
+ while (fread(frame, sizeof(frame), 1, fin) == 1) {
+ de_macro_y(framey, frame, 720, 720, 576);
+ de_macro_uv(frameu, framev, frame + 720 * 576, 720 / 2, 720 / 2, 576 / 2);
+ fwrite(framey, sizeof(framey), 1, stdout);
+ fwrite(framev, sizeof(framev), 1, stdout);
+ fwrite(frameu, sizeof(frameu), 1, stdout);
+ }
+ fclose(fin);
+ return 0;
+ }
diff --git a/Documentation/video4linux/cx2341x/README.hm12 b/Documentation/video4linux/cx2341x/README.hm12
deleted file mode 100644
index b36148ea0750..000000000000
--- a/Documentation/video4linux/cx2341x/README.hm12
+++ /dev/null
@@ -1,120 +0,0 @@
-The cx23416 can produce (and the cx23415 can also read) raw YUV output. The
-format of a YUV frame is specific to this chip and is called HM12. 'HM' stands
-for 'Hauppauge Macroblock', which is a misnomer as 'Conexant Macroblock' would
-be more accurate.
-
-The format is YUV 4:2:0 which uses 1 Y byte per pixel and 1 U and V byte per
-four pixels.
-
-The data is encoded as two macroblock planes, the first containing the Y
-values, the second containing UV macroblocks.
-
-The Y plane is divided into blocks of 16x16 pixels from left to right
-and from top to bottom. Each block is transmitted in turn, line-by-line.
-
-So the first 16 bytes are the first line of the top-left block, the
-second 16 bytes are the second line of the top-left block, etc. After
-transmitting this block the first line of the block on the right to the
-first block is transmitted, etc.
-
-The UV plane is divided into blocks of 16x8 UV values going from left
-to right, top to bottom. Each block is transmitted in turn, line-by-line.
-
-So the first 16 bytes are the first line of the top-left block and
-contain 8 UV value pairs (16 bytes in total). The second 16 bytes are the
-second line of 8 UV pairs of the top-left block, etc. After transmitting
-this block the first line of the block on the right to the first block is
-transmitted, etc.
-
-The code below is given as an example on how to convert HM12 to separate
-Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels.
-
-The width of a frame is always 720 pixels, regardless of the actual specified
-width.
-
-If the height is not a multiple of 32 lines, then the captured video is
-missing macroblocks at the end and is unusable. So the height must be a
-multiple of 32.
-
---------------------------------------------------------------------------
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-static unsigned char frame[576*720*3/2];
-static unsigned char framey[576*720];
-static unsigned char frameu[576*720 / 4];
-static unsigned char framev[576*720 / 4];
-
-static void de_macro_y(unsigned char* dst, unsigned char *src, int dstride, int w, int h)
-{
- unsigned int y, x, i;
-
- // descramble Y plane
- // dstride = 720 = w
- // The Y plane is divided into blocks of 16x16 pixels
- // Each block in transmitted in turn, line-by-line.
- for (y = 0; y < h; y += 16) {
- for (x = 0; x < w; x += 16) {
- for (i = 0; i < 16; i++) {
- memcpy(dst + x + (y + i) * dstride, src, 16);
- src += 16;
- }
- }
- }
-}
-
-static void de_macro_uv(unsigned char *dstu, unsigned char *dstv, unsigned char *src, int dstride, int w, int h)
-{
- unsigned int y, x, i;
-
- // descramble U/V plane
- // dstride = 720 / 2 = w
- // The U/V values are interlaced (UVUV...).
- // Again, the UV plane is divided into blocks of 16x16 UV values.
- // Each block in transmitted in turn, line-by-line.
- for (y = 0; y < h; y += 16) {
- for (x = 0; x < w; x += 8) {
- for (i = 0; i < 16; i++) {
- int idx = x + (y + i) * dstride;
-
- dstu[idx+0] = src[0]; dstv[idx+0] = src[1];
- dstu[idx+1] = src[2]; dstv[idx+1] = src[3];
- dstu[idx+2] = src[4]; dstv[idx+2] = src[5];
- dstu[idx+3] = src[6]; dstv[idx+3] = src[7];
- dstu[idx+4] = src[8]; dstv[idx+4] = src[9];
- dstu[idx+5] = src[10]; dstv[idx+5] = src[11];
- dstu[idx+6] = src[12]; dstv[idx+6] = src[13];
- dstu[idx+7] = src[14]; dstv[idx+7] = src[15];
- src += 16;
- }
- }
- }
-}
-
-/*************************************************************************/
-int main(int argc, char **argv)
-{
- FILE *fin;
- int i;
-
- if (argc == 1) fin = stdin;
- else fin = fopen(argv[1], "r");
-
- if (fin == NULL) {
- fprintf(stderr, "cannot open input\n");
- exit(-1);
- }
- while (fread(frame, sizeof(frame), 1, fin) == 1) {
- de_macro_y(framey, frame, 720, 720, 576);
- de_macro_uv(frameu, framev, frame + 720 * 576, 720 / 2, 720 / 2, 576 / 2);
- fwrite(framey, sizeof(framey), 1, stdout);
- fwrite(framev, sizeof(framev), 1, stdout);
- fwrite(frameu, sizeof(frameu), 1, stdout);
- }
- fclose(fin);
- return 0;
-}
-
---------------------------------------------------------------------------
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 13/18] [media] cx2341x.rst: add contents of README.vbi
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (11 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 12/18] [media] cx2341x: add contents of README.hm12 Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 14/18] [media] cx88.rst: add contents from not-in-cx2388x-datasheet.txt Mauro Carvalho Chehab
` (5 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
Finally, adds the content of README.vbi at cx2341x.rst after
its conversion to ReST format.
Now, add information about this chipset and its driver is
inside a single chapter at the media/v4l-drivers book.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/cx2341x.rst | 50 ++++++++++++++++++++++++++++
Documentation/video4linux/cx2341x/README.vbi | 45 -------------------------
2 files changed, 50 insertions(+), 45 deletions(-)
delete mode 100644 Documentation/video4linux/cx2341x/README.vbi
diff --git a/Documentation/media/v4l-drivers/cx2341x.rst b/Documentation/media/v4l-drivers/cx2341x.rst
index 15bfd345df48..e06d07ebdecd 100644
--- a/Documentation/media/v4l-drivers/cx2341x.rst
+++ b/Documentation/media/v4l-drivers/cx2341x.rst
@@ -3806,3 +3806,53 @@ Raw format c example
fclose(fin);
return 0;
}
+
+
+Format of embedded V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data
+---------------------------------------------------------
+
+Author: Hans Verkuil <hverkuil@xs4all.nl>
+
+
+This section describes the V4L2_MPEG_STREAM_VBI_FMT_IVTV format of the VBI data
+embedded in an MPEG-2 program stream. This format is in part dictated by some
+hardware limitations of the ivtv driver (the driver for the Conexant cx23415/6
+chips), in particular a maximum size for the VBI data. Anything longer is cut
+off when the MPEG stream is played back through the cx23415.
+
+The advantage of this format is it is very compact and that all VBI data for
+all lines can be stored while still fitting within the maximum allowed size.
+
+The stream ID of the VBI data is 0xBD. The maximum size of the embedded data is
+4 + 43 * 36, which is 4 bytes for a header and 2 * 18 VBI lines with a 1 byte
+header and a 42 bytes payload each. Anything beyond this limit is cut off by
+the cx23415/6 firmware. Besides the data for the VBI lines we also need 36 bits
+for a bitmask determining which lines are captured and 4 bytes for a magic cookie,
+signifying that this data package contains V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data.
+If all lines are used, then there is no longer room for the bitmask. To solve this
+two different magic numbers were introduced:
+
+'itv0': After this magic number two unsigned longs follow. Bits 0-17 of the first
+unsigned long denote which lines of the first field are captured. Bits 18-31 of
+the first unsigned long and bits 0-3 of the second unsigned long are used for the
+second field.
+
+'ITV0': This magic number assumes all VBI lines are captured, i.e. it implicitly
+implies that the bitmasks are 0xffffffff and 0xf.
+
+After these magic cookies (and the 8 byte bitmask in case of cookie 'itv0') the
+captured VBI lines start:
+
+For each line the least significant 4 bits of the first byte contain the data type.
+Possible values are shown in the table below. The payload is in the following 42
+bytes.
+
+Here is the list of possible data types:
+
+.. code-block:: c
+
+ #define IVTV_SLICED_TYPE_TELETEXT 0x1 // Teletext (uses lines 6-22 for PAL)
+ #define IVTV_SLICED_TYPE_CC 0x4 // Closed Captions (line 21 NTSC)
+ #define IVTV_SLICED_TYPE_WSS 0x5 // Wide Screen Signal (line 23 PAL)
+ #define IVTV_SLICED_TYPE_VPS 0x7 // Video Programming System (PAL) (line 16)
+
diff --git a/Documentation/video4linux/cx2341x/README.vbi b/Documentation/video4linux/cx2341x/README.vbi
deleted file mode 100644
index 5807cf156173..000000000000
--- a/Documentation/video4linux/cx2341x/README.vbi
+++ /dev/null
@@ -1,45 +0,0 @@
-
-Format of embedded V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data
-=========================================================
-
-This document describes the V4L2_MPEG_STREAM_VBI_FMT_IVTV format of the VBI data
-embedded in an MPEG-2 program stream. This format is in part dictated by some
-hardware limitations of the ivtv driver (the driver for the Conexant cx23415/6
-chips), in particular a maximum size for the VBI data. Anything longer is cut
-off when the MPEG stream is played back through the cx23415.
-
-The advantage of this format is it is very compact and that all VBI data for
-all lines can be stored while still fitting within the maximum allowed size.
-
-The stream ID of the VBI data is 0xBD. The maximum size of the embedded data is
-4 + 43 * 36, which is 4 bytes for a header and 2 * 18 VBI lines with a 1 byte
-header and a 42 bytes payload each. Anything beyond this limit is cut off by
-the cx23415/6 firmware. Besides the data for the VBI lines we also need 36 bits
-for a bitmask determining which lines are captured and 4 bytes for a magic cookie,
-signifying that this data package contains V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data.
-If all lines are used, then there is no longer room for the bitmask. To solve this
-two different magic numbers were introduced:
-
-'itv0': After this magic number two unsigned longs follow. Bits 0-17 of the first
-unsigned long denote which lines of the first field are captured. Bits 18-31 of
-the first unsigned long and bits 0-3 of the second unsigned long are used for the
-second field.
-
-'ITV0': This magic number assumes all VBI lines are captured, i.e. it implicitly
-implies that the bitmasks are 0xffffffff and 0xf.
-
-After these magic cookies (and the 8 byte bitmask in case of cookie 'itv0') the
-captured VBI lines start:
-
-For each line the least significant 4 bits of the first byte contain the data type.
-Possible values are shown in the table below. The payload is in the following 42
-bytes.
-
-Here is the list of possible data types:
-
-#define IVTV_SLICED_TYPE_TELETEXT 0x1 // Teletext (uses lines 6-22 for PAL)
-#define IVTV_SLICED_TYPE_CC 0x4 // Closed Captions (line 21 NTSC)
-#define IVTV_SLICED_TYPE_WSS 0x5 // Wide Screen Signal (line 23 PAL)
-#define IVTV_SLICED_TYPE_VPS 0x7 // Video Programming System (PAL) (line 16)
-
-Hans Verkuil <hverkuil@xs4all.nl>
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 14/18] [media] cx88.rst: add contents from not-in-cx2388x-datasheet.txt
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (12 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 13/18] [media] cx2341x.rst: add contents of README.vbi Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 15/18] [media] cx88.rst: add contents of hauppauge-wintv-cx88-ir.txt Mauro Carvalho Chehab
` (4 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet,
Randy Dunlap, Paul E. McKenney, Kees Cook, linux-doc
There are some information about missing/wrong documentation at
cx231xx datasheet. Add it to the cx88 chapter.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/cx88.rst | 42 ++++++++++++++++++++++
.../video4linux/not-in-cx2388x-datasheet.txt | 41 ---------------------
2 files changed, 42 insertions(+), 41 deletions(-)
delete mode 100644 Documentation/video4linux/not-in-cx2388x-datasheet.txt
diff --git a/Documentation/media/v4l-drivers/cx88.rst b/Documentation/media/v4l-drivers/cx88.rst
index ac83292776da..c89dbfa5f9d6 100644
--- a/Documentation/media/v4l-drivers/cx88.rst
+++ b/Documentation/media/v4l-drivers/cx88.rst
@@ -55,4 +55,46 @@ the driver. What to do then?
know which one the card has you can also have a look at the
list in CARDLIST.tuner
+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.
diff --git a/Documentation/video4linux/not-in-cx2388x-datasheet.txt b/Documentation/video4linux/not-in-cx2388x-datasheet.txt
deleted file mode 100644
index edbfe744d21d..000000000000
--- a/Documentation/video4linux/not-in-cx2388x-datasheet.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-=================================================================================
-MO_OUTPUT_FORMAT (0x310164)
-
- 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.
-
-=================================================================================
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 15/18] [media] cx88.rst: add contents of hauppauge-wintv-cx88-ir.txt
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (13 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 14/18] [media] cx88.rst: add contents from not-in-cx2388x-datasheet.txt Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 16/18] [media] get rid of Documentation/video4linux/lifeview.txt Mauro Carvalho Chehab
` (3 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet,
Randy Dunlap, Paul E. McKenney, Kees Cook, linux-doc
Import the contents of hauppauge-wintv-cx88-ir.txt, after
converted to ReST into cx88.rst file.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/cx88.rst | 62 ++++++++++++++++++++++
.../video4linux/cx88/hauppauge-wintv-cx88-ir.txt | 54 -------------------
.../video4linux/hauppauge-wintv-cx88-ir.txt | 54 -------------------
3 files changed, 62 insertions(+), 108 deletions(-)
delete mode 100644 Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt
delete mode 100644 Documentation/video4linux/hauppauge-wintv-cx88-ir.txt
diff --git a/Documentation/media/v4l-drivers/cx88.rst b/Documentation/media/v4l-drivers/cx88.rst
index c89dbfa5f9d6..97865007f51f 100644
--- a/Documentation/media/v4l-drivers/cx88.rst
+++ b/Documentation/media/v4l-drivers/cx88.rst
@@ -98,3 +98,65 @@ MO_OUTPUT_FORMAT (0x310164)
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/video4linux/cx88/hauppauge-wintv-cx88-ir.txt b/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt
deleted file mode 100644
index f4329a38878e..000000000000
--- a/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-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
-
-Of course, 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.
-
-http://www.atmel.com/dyn/resources/prod_documents/doc2817.pdf
-This data sheet (google search) seems to have a lovely description of the
-RC5 basics
-
-http://www.nenya.be/beor/electronics/rc5.htm and more data
-
-http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt
-and even a reference to how to decode a bi-phase data stream.
-
-http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm
-still more info
-
diff --git a/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt b/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt
deleted file mode 100644
index a2fd363c40c8..000000000000
--- a/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-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
-
-Of course, 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.
-
-http://www.atmel.com/dyn/resources/prod_documents/doc2817.pdf
-This data sheet (google search) seems to have a lovely description of the
-RC5 basics
-
-http://www.nenya.be/beor/electronics/rc5.htm and more data
-
-http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt
-and even a reference to how to decode a bi-phase data stream.
-
-http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm
-still more info
-
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 16/18] [media] get rid of Documentation/video4linux/lifeview.txt
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (14 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 15/18] [media] cx88.rst: add contents of hauppauge-wintv-cx88-ir.txt Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 17/18] [media] doc-rst: fix media kAPI documentation Mauro Carvalho Chehab
` (2 subsequent siblings)
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=true, Size: 4492 bytes --]
Move the contents of this file to bttv.rst and saa7134.rst.
With that, we can finally remove Documentation/video4linux.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/v4l-drivers/bttv.rst | 8 ++++++
Documentation/media/v4l-drivers/saa7134.rst | 36 +++++++++++++++++++++++++
Documentation/video4linux/lifeview.txt | 42 -----------------------------
3 files changed, 44 insertions(+), 42 deletions(-)
delete mode 100644 Documentation/video4linux/lifeview.txt
diff --git a/Documentation/media/v4l-drivers/bttv.rst b/Documentation/media/v4l-drivers/bttv.rst
index 611e8d529f16..f78c135b40e7 100644
--- a/Documentation/media/v4l-drivers/bttv.rst
+++ b/Documentation/media/v4l-drivers/bttv.rst
@@ -782,6 +782,14 @@ FlyVideo A2 (Elta 8680)= LR90 Rev.F (w/Remote, w/o FM, stereo TV by tda9821) {Ge
Lifeview 3000 (Elta 8681) as sold by Plus(April 2002), Germany = LR138 w/ saa7134
+lifeview config coding on gpio pins 0-9
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+- LR50 rev. Q ("PARTS: 7031505116), Tuner wurde als Nr. 5 erkannt, Eingänge
+ SVideo, TV, Composite, Audio, Remote:
+
+ - CP9..1=100001001 (1: 0-Ohm-Widerstand gegen GND unbestückt; 0: bestückt)
+
Typhoon TV card series:
~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/media/v4l-drivers/saa7134.rst b/Documentation/media/v4l-drivers/saa7134.rst
index 584caf8a3594..36b2ee9e0fdc 100644
--- a/Documentation/media/v4l-drivers/saa7134.rst
+++ b/Documentation/media/v4l-drivers/saa7134.rst
@@ -70,6 +70,42 @@ Some details about 30/34/35:
- 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
-------
diff --git a/Documentation/video4linux/lifeview.txt b/Documentation/video4linux/lifeview.txt
deleted file mode 100644
index 05f9eb57aac9..000000000000
--- a/Documentation/video4linux/lifeview.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-collecting data about the lifeview models and the config coding on
-gpio pins 0-9 ...
-==================================================================
-
-bt878:
- LR50 rev. Q ("PARTS: 7031505116), Tuner wurde als Nr. 5 erkannt, Eingänge
- SVideo, TV, Composite, Audio, Remote. CP9..1=100001001 (1: 0-Ohm-Widerstand
- gegen GND unbestückt; 0: bestückt)
-
-------------------------------------------------------------------------------
-
-saa7134:
- /* LifeView FlyTV Platinum FM (LR214WF) */
- /* "Peter Missel <peter.missel@onlinehome.de> */
- .name = "LifeView FlyTV Platinum FM",
- /* 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 pins
- to 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 */
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 17/18] [media] doc-rst: fix media kAPI documentation
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (15 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 16/18] [media] get rid of Documentation/video4linux/lifeview.txt Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-18 18:30 ` [PATCH 18/18] [media] doc-rst: better name the media books Mauro Carvalho Chehab
2016-07-19 9:19 ` [PATCH 00/18] Complete moving media documentation to ReST format Hans Verkuil
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet, linux-doc
I ended by adding twice each media header, because I saw some
missing stuff at the documents. It seems it was my mistake,
as everything seems to be there.
So, remove those extra stuff, to avoid duplicating the
documentation of the functions.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/media/kapi/dtv-core.rst | 4 ----
Documentation/media/kapi/mc-core.rst | 8 --------
Documentation/media/kapi/rc-core.rst | 3 +--
Documentation/media/kapi/v4l2-core.rst | 21 ---------------------
4 files changed, 1 insertion(+), 35 deletions(-)
diff --git a/Documentation/media/kapi/dtv-core.rst b/Documentation/media/kapi/dtv-core.rst
index 3291190c1865..11da77e141ed 100644
--- a/Documentation/media/kapi/dtv-core.rst
+++ b/Documentation/media/kapi/dtv-core.rst
@@ -130,7 +130,3 @@ Digital TV Conditional Access kABI
----------------------------------
.. kernel-doc:: drivers/media/dvb-core/dvb_ca_en50221.h
-
-
-.. kernel-doc:: drivers/media/dvb-core/dvb_ca_en50221.h
- :export: drivers/media/dvb-core/dvb_ca_en50221.c
diff --git a/Documentation/media/kapi/mc-core.rst b/Documentation/media/kapi/mc-core.rst
index 2ab541ba6e88..c1fe0d69207d 100644
--- a/Documentation/media/kapi/mc-core.rst
+++ b/Documentation/media/kapi/mc-core.rst
@@ -261,11 +261,3 @@ in the end provide a way to use driver-specific callbacks.
.. kernel-doc:: include/media/media-devnode.h
.. kernel-doc:: include/media/media-entity.h
-
-
-
-.. kernel-doc:: include/media/media-device.h
- :export: drivers/media/media-device.c
-
-.. kernel-doc:: include/media/media-entity.h
- :export: drivers/media/media-entity.c
diff --git a/Documentation/media/kapi/rc-core.rst b/Documentation/media/kapi/rc-core.rst
index 9c244ac9ce92..a45895886257 100644
--- a/Documentation/media/kapi/rc-core.rst
+++ b/Documentation/media/kapi/rc-core.rst
@@ -6,8 +6,7 @@ Remote Controller core
.. kernel-doc:: include/media/rc-core.h
-.. kernel-doc:: include/media/rc-core.h include/media/rc-map.h
- :export: drivers/media/rc/rc-main.c drivers/media/rc/rc-raw.c
+.. kernel-doc:: include/media/rc-map.h
LIRC
~~~~
diff --git a/Documentation/media/kapi/v4l2-core.rst b/Documentation/media/kapi/v4l2-core.rst
index 4e2aa721d9c8..a1b73e8d6795 100644
--- a/Documentation/media/kapi/v4l2-core.rst
+++ b/Documentation/media/kapi/v4l2-core.rst
@@ -34,24 +34,3 @@ Video2Linux devices
.. kernel-doc:: include/media/videobuf2-v4l2.h
.. kernel-doc:: include/media/videobuf2-memops.h
-
-
-
-
-.. kernel-doc:: include/media/tveeprom.h
- :export: drivers/media/common/tveeprom.c
-
-.. kernel-doc:: include/media/v4l2-ctrls.h
- :export: drivers/media/v4l2-core/v4l2-ctrls.c
-
-.. kernel-doc:: include/media/v4l2-dv-timings.h
- :export: drivers/media/v4l2-core/v4l2-dv-timings.c
-
-.. kernel-doc:: include/media/v4l2-flash-led-class.h
- :export: drivers/media/v4l2-core/v4l2-flash-led-class.c
-
-.. kernel-doc:: include/media/v4l2-mc.h
- :export: drivers/media/v4l2-core/v4l2-mc.c
-
-.. kernel-doc:: include/media/videobuf2-core.h
- :export: drivers/media/v4l2-core/videobuf2-core.c
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH 18/18] [media] doc-rst: better name the media books
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (16 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 17/18] [media] doc-rst: fix media kAPI documentation Mauro Carvalho Chehab
@ 2016-07-18 18:30 ` Mauro Carvalho Chehab
2016-07-19 9:19 ` [PATCH 00/18] Complete moving media documentation to ReST format Hans Verkuil
18 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-18 18:30 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, Jonathan Corbet,
Markus Heiser, linux-doc
The titles at the media books were misleading, and some books
were not numbered.
Rename the kAPI book to better reflect its contents, be more
consistent on the initial rst file for each book and better
name them.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/index.rst | 2 +-
Documentation/media/dvb-drivers/index.rst | 9 ++++++---
Documentation/media/{media_drivers.rst => media_kapi.rst} | 9 ++++++---
Documentation/media/media_uapi.rst | 10 +++++-----
Documentation/media/v4l-drivers/index.rst | 8 +++++---
5 files changed, 23 insertions(+), 15 deletions(-)
rename Documentation/media/{media_drivers.rst => media_kapi.rst} (76%)
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 31273cc2e0bc..43c722f15292 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -15,7 +15,7 @@ Contents:
kernel-documentation
media/media_uapi
- media/media_drivers
+ media/media_kapi
media/dvb-drivers/index
media/v4l-drivers/index
diff --git a/Documentation/media/dvb-drivers/index.rst b/Documentation/media/dvb-drivers/index.rst
index 14da36fe4d01..e1d4d87f2a47 100644
--- a/Documentation/media/dvb-drivers/index.rst
+++ b/Documentation/media/dvb-drivers/index.rst
@@ -2,9 +2,9 @@
.. include:: <isonum.txt>
-#############################################
-Linux Digital Video Broadcast (DVB) subsystem
-#############################################
+##############################################
+Linux Digital TV driver-specific documentation
+##############################################
**Copyright** |copy| 2001-2016 : LinuxTV Developers
@@ -17,6 +17,9 @@ License".
.. toctree::
:maxdepth: 5
+ :numbered:
+ :caption: Table of Contents
+ :name: dvb_mastertoc
intro
avermedia
diff --git a/Documentation/media/media_drivers.rst b/Documentation/media/media_kapi.rst
similarity index 76%
rename from Documentation/media/media_drivers.rst
rename to Documentation/media/media_kapi.rst
index 8e0f455ff6e0..0af80e90b7b5 100644
--- a/Documentation/media/media_drivers.rst
+++ b/Documentation/media/media_kapi.rst
@@ -2,9 +2,9 @@
.. include:: <isonum.txt>
-=========================
-Media subsystem core kAPI
-=========================
+===================================
+Media subsystem kernel internal API
+===================================
**Copyright** |copy| 2009-2016 : LinuxTV Developers
@@ -16,6 +16,9 @@ License".
.. toctree::
:maxdepth: 5
+ :numbered:
+ :caption: Table of Contents
+ :name: kapi_mastertoc
kapi/v4l2-framework
kapi/v4l2-controls
diff --git a/Documentation/media/media_uapi.rst b/Documentation/media/media_uapi.rst
index 5e872c8297b0..debe4531040b 100644
--- a/Documentation/media/media_uapi.rst
+++ b/Documentation/media/media_uapi.rst
@@ -2,9 +2,9 @@
.. include:: <isonum.txt>
-##############################
-Linux Media Infrastructure API
-##############################
+########################################
+Linux Media Infrastructure userspace API
+########################################
**Copyright** |copy| 2009-2016 : LinuxTV Developers
@@ -15,10 +15,10 @@ the license is included in the chapter entitled "GNU Free Documentation
License".
-.. contents::
-
.. toctree::
:maxdepth: 5
+ :caption: Table of Contents
+ :name: uapi_mastertoc
intro
uapi/v4l/v4l2
diff --git a/Documentation/media/v4l-drivers/index.rst b/Documentation/media/v4l-drivers/index.rst
index 34990b536d39..8d1710234e5a 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -2,9 +2,9 @@
.. include:: <isonum.txt>
-###########################
-Video4Linux (V4L) subsystem
-###########################
+################################################
+Video4Linux (V4L) driver-specific documentation
+################################################
**Copyright** |copy| 1999-2016 : LinuxTV Developers
@@ -18,6 +18,8 @@ License".
.. toctree::
:maxdepth: 5
:numbered:
+ :caption: Table of Contents
+ :name: v4l_mastertoc
fourcc
v4l-with-ir
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-18 18:30 [PATCH 00/18] Complete moving media documentation to ReST format Mauro Carvalho Chehab
` (17 preceding siblings ...)
2016-07-18 18:30 ` [PATCH 18/18] [media] doc-rst: better name the media books Mauro Carvalho Chehab
@ 2016-07-19 9:19 ` Hans Verkuil
2016-07-19 11:12 ` Mauro Carvalho Chehab
18 siblings, 1 reply; 36+ messages in thread
From: Hans Verkuil @ 2016-07-19 9:19 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Media Mailing List; +Cc: Mauro Carvalho Chehab
On 07/18/16 20:30, Mauro Carvalho Chehab wrote:
> This patch series finally ends the conversion of the media documents to ReST
> format.
>
> After this series, *all* media documentation will be inside a ReST book.
>
> They'll be:
>
> - Linux Media Infrastructure userspace API
> - With 5 parts:
> - Video for Linux API
> - Digital TV API
> - Remote Controller API
> - Media Controller API
> - CEC API
> - Media subsystem kernel internal API
> - Linux Digital TV driver-specific documentation
> - Video4Linux (V4L) driver-specific documentation
>
> All those documents are built automatically, once by day, at linuxtv.org:
>
> uAPI:
> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html
Erm, there is nothing there, only the top-level menu.
Regards,
Hans
>
> kAPI:
> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_kapi.html
>
> DVB drivers:
> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/dvb-drivers/index.html
>
> V4L drivers:
> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/v4l-drivers/index.html
>
> That's said, there are lots of old/deprecated information there. Also, as the books
> are actually an aggregation of stuff written on different times, by different people,
> they don't look all the same.
>
> I tried to fix some things while doing the documentation patch series, but there are
> still lots of things to be done, specially at the DVB and V4L drivers documentation.
>
> There are also several V4L2 core functions not documented at the kAPI book, and
> the V4L framework document there is not properly cross referenced.
>
> Anyway, now that everything can be seen on 4 books via html, maybe it will now
> be easier to identify and fix the gaps. I intend do do it for Kernel 4.9.
>
> I'm merging all stuff on my main development tree:
> https://git.linuxtv.org//mchehab/experimental.git/log/?h=docs-next
>
> I should be merge soon today what we currently have at media mainstream tree.
>
> Regards,
> Mauro
>
> Mauro Carvalho Chehab (18):
> [media] doc-rst: move bttv documentation to bttv.rst file
> [media] doc-rst: add documentation for bttv driver
> [media] doc-rst: add documentation for tuners
> [media] doc-rst: start adding documentation for cx2341x
> [media] cx2341x.rst: add fw-decoder-registers.txt content
> [media] cx2341x.rst: Add the contents of fw-encoder-api.txt
> [media] cx2341x.rst: add the contents of fw-calling.txt
> [media] cx2341x.rst: add contents of fw-dma.txt
> [media] cx2341x.rst: add contents of fw-memory.txt
> [media] cx2341x.rst: add the contents of fw-upload.txt
> [media] cx2341x.rst: add contents of fw-osd-api.txt
> [media] cx2341x: add contents of README.hm12
> [media] cx2341x.rst: add contents of README.vbi
> [media] cx88.rst: add contents from not-in-cx2388x-datasheet.txt
> [media] cx88.rst: add contents of hauppauge-wintv-cx88-ir.txt
> [media] get rid of Documentation/video4linux/lifeview.txt
> [media] doc-rst: fix media kAPI documentation
> [media] doc-rst: better name the media books
>
> Documentation/index.rst | 2 +-
> Documentation/media/dvb-drivers/index.rst | 9 +-
> Documentation/media/kapi/dtv-core.rst | 4 -
> Documentation/media/kapi/mc-core.rst | 8 -
> Documentation/media/kapi/rc-core.rst | 3 +-
> Documentation/media/kapi/v4l2-core.rst | 21 -
> .../media/{media_drivers.rst => media_kapi.rst} | 9 +-
> Documentation/media/media_uapi.rst | 10 +-
> Documentation/media/v4l-drivers/bttv.rst | 1923 ++++++++++
> Documentation/media/v4l-drivers/cx2341x.rst | 3858 ++++++++++++++++++++
> Documentation/media/v4l-drivers/cx88.rst | 104 +
> Documentation/media/v4l-drivers/index.rst | 11 +-
> Documentation/media/v4l-drivers/saa7134.rst | 36 +
> Documentation/media/v4l-drivers/tuners.rst | 131 +
> Documentation/video4linux/bttv/CONTRIBUTORS | 25 -
> Documentation/video4linux/bttv/Cards | 960 -----
> Documentation/video4linux/bttv/ICs | 37 -
> Documentation/video4linux/bttv/Insmod-options | 172 -
> Documentation/video4linux/bttv/MAKEDEV | 27 -
> Documentation/video4linux/bttv/Modprobe.conf | 11 -
> Documentation/video4linux/bttv/Modules.conf | 14 -
> Documentation/video4linux/bttv/PROBLEMS | 62 -
> Documentation/video4linux/bttv/README | 90 -
> Documentation/video4linux/bttv/README.WINVIEW | 33 -
> Documentation/video4linux/bttv/README.freeze | 74 -
> Documentation/video4linux/bttv/README.quirks | 83 -
> Documentation/video4linux/bttv/Sound-FAQ | 148 -
> Documentation/video4linux/bttv/Specs | 3 -
> Documentation/video4linux/bttv/THANKS | 24 -
> Documentation/video4linux/bttv/Tuners | 115 -
> Documentation/video4linux/cx2341x/README.hm12 | 120 -
> Documentation/video4linux/cx2341x/README.vbi | 45 -
> Documentation/video4linux/cx2341x/fw-calling.txt | 69 -
> .../video4linux/cx2341x/fw-decoder-api.txt | 297 --
> .../video4linux/cx2341x/fw-decoder-regs.txt | 817 -----
> Documentation/video4linux/cx2341x/fw-dma.txt | 96 -
> .../video4linux/cx2341x/fw-encoder-api.txt | 709 ----
> Documentation/video4linux/cx2341x/fw-memory.txt | 139 -
> Documentation/video4linux/cx2341x/fw-osd-api.txt | 350 --
> Documentation/video4linux/cx2341x/fw-upload.txt | 49 -
> .../video4linux/cx88/hauppauge-wintv-cx88-ir.txt | 54 -
> .../video4linux/hauppauge-wintv-cx88-ir.txt | 54 -
> Documentation/video4linux/lifeview.txt | 42 -
> .../video4linux/not-in-cx2388x-datasheet.txt | 41 -
> 44 files changed, 6079 insertions(+), 4810 deletions(-)
> rename Documentation/media/{media_drivers.rst => media_kapi.rst} (76%)
> create mode 100644 Documentation/media/v4l-drivers/bttv.rst
> create mode 100644 Documentation/media/v4l-drivers/cx2341x.rst
> create mode 100644 Documentation/media/v4l-drivers/tuners.rst
> delete mode 100644 Documentation/video4linux/bttv/CONTRIBUTORS
> delete mode 100644 Documentation/video4linux/bttv/Cards
> delete mode 100644 Documentation/video4linux/bttv/ICs
> delete mode 100644 Documentation/video4linux/bttv/Insmod-options
> delete mode 100644 Documentation/video4linux/bttv/MAKEDEV
> delete mode 100644 Documentation/video4linux/bttv/Modprobe.conf
> delete mode 100644 Documentation/video4linux/bttv/Modules.conf
> delete mode 100644 Documentation/video4linux/bttv/PROBLEMS
> delete mode 100644 Documentation/video4linux/bttv/README
> delete mode 100644 Documentation/video4linux/bttv/README.WINVIEW
> delete mode 100644 Documentation/video4linux/bttv/README.freeze
> delete mode 100644 Documentation/video4linux/bttv/README.quirks
> delete mode 100644 Documentation/video4linux/bttv/Sound-FAQ
> delete mode 100644 Documentation/video4linux/bttv/Specs
> delete mode 100644 Documentation/video4linux/bttv/THANKS
> delete mode 100644 Documentation/video4linux/bttv/Tuners
> delete mode 100644 Documentation/video4linux/cx2341x/README.hm12
> delete mode 100644 Documentation/video4linux/cx2341x/README.vbi
> delete mode 100644 Documentation/video4linux/cx2341x/fw-calling.txt
> delete mode 100644 Documentation/video4linux/cx2341x/fw-decoder-api.txt
> delete mode 100644 Documentation/video4linux/cx2341x/fw-decoder-regs.txt
> delete mode 100644 Documentation/video4linux/cx2341x/fw-dma.txt
> delete mode 100644 Documentation/video4linux/cx2341x/fw-encoder-api.txt
> delete mode 100644 Documentation/video4linux/cx2341x/fw-memory.txt
> delete mode 100644 Documentation/video4linux/cx2341x/fw-osd-api.txt
> delete mode 100644 Documentation/video4linux/cx2341x/fw-upload.txt
> delete mode 100644 Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt
> delete mode 100644 Documentation/video4linux/hauppauge-wintv-cx88-ir.txt
> delete mode 100644 Documentation/video4linux/lifeview.txt
> delete mode 100644 Documentation/video4linux/not-in-cx2388x-datasheet.txt
>
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-19 9:19 ` [PATCH 00/18] Complete moving media documentation to ReST format Hans Verkuil
@ 2016-07-19 11:12 ` Mauro Carvalho Chehab
2016-07-19 12:31 ` Markus Heiser
0 siblings, 1 reply; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-19 11:12 UTC (permalink / raw)
To: Hans Verkuil
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Jonathan Corbet,
linux-doc, Jani Nikula, Markus Heiser
Em Tue, 19 Jul 2016 11:19:11 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> > All those documents are built automatically, once by day, at linuxtv.org:
> >
> > uAPI:
> > https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html
>
> Erm, there is nothing there, only the top-level menu.
Gah! The problem is due to the Sphinx version. I added a patch yesterday
adding a caption to each book's toctree. This doesn't work with the
Sphinx version at the server (1.2.3). Instead of ignoring the option,
Sphinx decided to just drop the entire tag, with actually means to
drop all media pages!
I really hate stupid toolchains that require everybody to upgrade to
the very latest version of it every time. Maybe someone at linux-doc
may have an idea about how to add new markup attributes to the
documents without breaking for the ones using older versions of Sphinx.
The problem we're facing is due to a change meant to add a title before
each media's table of contents (provided via :toctree: markup).
All it needs is something that will be translated to HTML as:
<h1>Table of contents</h1>, without the need of creating any cross
reference, nor being added to the main TOC at Documentation/index.rst.
We can't simply use the normal way to generate <h1> tags:
--- a/Documentation/media/dvb-drivers/index.rst
+++ b/Documentation/media/dvb-drivers/index.rst
@@ -15,6 +15,10 @@ the license is included in the chapter entitled "GNU Free Documentation
License".
+#####################
+FOO Table of contents
+#####################
+
.. toctree::
:maxdepth: 5
:numbered:
The page itself would look OK, but this would produce a new entry at the
output/html/index.html:
* Linux Digital TV driver-specific documentation
* FOO Table of contents
1. Introdution
With is not what we want.
With Sphinx 1.4.5, the way of doing that is to add a :caption: tag
to the toctree, but this tag doesn't exist on 1.2.x. Also, as it
also convert captions on references, and all books are linked
together at Documentation/index.rst, it also needs a :name: tag,
in order to avoid warnings about duplicated tags when building the
main index.rst.
I have no idea about how to do that in a backward-compatible way.
Maybe Markus, Jani or someone else at linux-doc may have some
glue.
In the mean time, I attached a patch that the server applies before
building the documentation.
Thanks,
Mauro
doc-rst: Don't use :caption: or :name: tags for media documents
If Sphinx version is lower than 1.4.x (I tested with 1.4.5), this patch
is needed for it to build, as otherwise Sphinx will ignore the toctable
markups and won't build the media documentation, creating just an
empty page.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff --git a/Documentation/media/dvb-drivers/index.rst b/Documentation/media/dvb-drivers/index.rst
index e1d4d87f2a47..0e065533beb6 100644
--- a/Documentation/media/dvb-drivers/index.rst
+++ b/Documentation/media/dvb-drivers/index.rst
@@ -18,8 +18,6 @@ License".
.. toctree::
:maxdepth: 5
:numbered:
- :caption: Table of Contents
- :name: dvb_mastertoc
intro
avermedia
diff --git a/Documentation/media/media_kapi.rst b/Documentation/media/media_kapi.rst
index 0af80e90b7b5..556c0eb55c85 100644
--- a/Documentation/media/media_kapi.rst
+++ b/Documentation/media/media_kapi.rst
@@ -17,8 +17,6 @@ License".
.. toctree::
:maxdepth: 5
:numbered:
- :caption: Table of Contents
- :name: kapi_mastertoc
kapi/v4l2-framework
kapi/v4l2-controls
diff --git a/Documentation/media/media_uapi.rst b/Documentation/media/media_uapi.rst
index debe4531040b..aae8124defcc 100644
--- a/Documentation/media/media_uapi.rst
+++ b/Documentation/media/media_uapi.rst
@@ -17,8 +17,6 @@ License".
.. toctree::
:maxdepth: 5
- :caption: Table of Contents
- :name: uapi_mastertoc
intro
uapi/v4l/v4l2
diff --git a/Documentation/media/v4l-drivers/index.rst b/Documentation/media/v4l-drivers/index.rst
index 8d1710234e5a..b9c9c0911db9 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -18,8 +18,6 @@ License".
.. toctree::
:maxdepth: 5
:numbered:
- :caption: Table of Contents
- :name: v4l_mastertoc
fourcc
v4l-with-ir
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-19 11:12 ` Mauro Carvalho Chehab
@ 2016-07-19 12:31 ` Markus Heiser
2016-07-19 14:53 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 36+ messages in thread
From: Markus Heiser @ 2016-07-19 12:31 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
Jonathan Corbet, linux-doc, Jani Nikula
Am 19.07.2016 um 13:12 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
> Em Tue, 19 Jul 2016 11:19:11 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>
>>> All those documents are built automatically, once by day, at linuxtv.org:
>>>
>>> uAPI:
>>> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html
>>
>> Erm, there is nothing there, only the top-level menu.
>
> Gah! The problem is due to the Sphinx version. I added a patch yesterday
> adding a caption to each book's toctree. This doesn't work with the
> Sphinx version at the server (1.2.3). Instead of ignoring the option,
> Sphinx decided to just drop the entire tag, with actually means to
> drop all media pages!
>
> I really hate stupid toolchains that require everybody to upgrade to
> the very latest version of it every time.
Hi Mauro,
It might be annoying how sphinx handles errors, but normally a build
process should report errors to monitor.
> Maybe someone at linux-doc
> may have an idea about how to add new markup attributes to the
> documents without breaking for the ones using older versions of Sphinx.
see below
> The problem we're facing is due to a change meant to add a title before
> each media's table of contents (provided via :toctree: markup).
I think this is only ONE drawback, others see the changelog ..
* http://www.sphinx-doc.org/en/stable/changes.html
> All it needs is something that will be translated to HTML as:
> <h1>Table of contents</h1>, without the need of creating any cross
> reference, nor being added to the main TOC at Documentation/index.rst.
>
> We can't simply use the normal way to generate <h1> tags:
>
> --- a/Documentation/media/dvb-drivers/index.rst
> +++ b/Documentation/media/dvb-drivers/index.rst
> @@ -15,6 +15,10 @@ the license is included in the chapter entitled "GNU Free Documentation
> License".
>
>
> +#####################
> +FOO Table of contents
> +#####################
> +
> .. toctree::
> :maxdepth: 5
> :numbered:
>
> The page itself would look OK, but this would produce a new entry at the
> output/html/index.html:
>
> * Linux Digital TV driver-specific documentation
> * FOO Table of contents
>
> 1. Introdution
>
> With is not what we want.
>
> With Sphinx 1.4.5, the way of doing that is to add a :caption: tag
> to the toctree, but this tag doesn't exist on 1.2.x. Also, as it
> also convert captions on references, and all books are linked
> together at Documentation/index.rst, it also needs a :name: tag,
> in order to avoid warnings about duplicated tags when building the
> main index.rst.
>
> I have no idea about how to do that in a backward-compatible way.
>
> Maybe Markus, Jani or someone else at linux-doc may have some
> glue.
IMHO: A backward-compatible way for all linux distros and versions
out there is not the way.
If we use options or features of a new version, we have to
install the new version (independent which xml we used in the past
or python tool we want to use).
IMHO the main problem is, that we have not yet documented on which
Sphinx version we agree and how to get a build environment which
fullfills these requirements.
For build environments I recommend to set up a python virtualenv
* https://virtualenv.pypa.io/en/stable/
Additional:
At this time, the make file only checks if sphinx is installed.
With a small addition to the make file, we could check if all
requirements are fulfilled.
If you are interested in how, I could send a patch.
-- Markus --
> In the mean time, I attached a patch that the server applies before
> building the documentation.
>
>
> Thanks,
> Mauro
>
> doc-rst: Don't use :caption: or :name: tags for media documents
>
> If Sphinx version is lower than 1.4.x (I tested with 1.4.5), this patch
> is needed for it to build, as otherwise Sphinx will ignore the toctable
> markups and won't build the media documentation, creating just an
> empty page.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>
> diff --git a/Documentation/media/dvb-drivers/index.rst b/Documentation/media/dvb-drivers/index.rst
> index e1d4d87f2a47..0e065533beb6 100644
> --- a/Documentation/media/dvb-drivers/index.rst
> +++ b/Documentation/media/dvb-drivers/index.rst
> @@ -18,8 +18,6 @@ License".
> .. toctree::
> :maxdepth: 5
> :numbered:
> - :caption: Table of Contents
> - :name: dvb_mastertoc
>
> intro
> avermedia
> diff --git a/Documentation/media/media_kapi.rst b/Documentation/media/media_kapi.rst
> index 0af80e90b7b5..556c0eb55c85 100644
> --- a/Documentation/media/media_kapi.rst
> +++ b/Documentation/media/media_kapi.rst
> @@ -17,8 +17,6 @@ License".
> .. toctree::
> :maxdepth: 5
> :numbered:
> - :caption: Table of Contents
> - :name: kapi_mastertoc
>
> kapi/v4l2-framework
> kapi/v4l2-controls
> diff --git a/Documentation/media/media_uapi.rst b/Documentation/media/media_uapi.rst
> index debe4531040b..aae8124defcc 100644
> --- a/Documentation/media/media_uapi.rst
> +++ b/Documentation/media/media_uapi.rst
> @@ -17,8 +17,6 @@ License".
>
> .. toctree::
> :maxdepth: 5
> - :caption: Table of Contents
> - :name: uapi_mastertoc
>
> intro
> uapi/v4l/v4l2
> diff --git a/Documentation/media/v4l-drivers/index.rst b/Documentation/media/v4l-drivers/index.rst
> index 8d1710234e5a..b9c9c0911db9 100644
> --- a/Documentation/media/v4l-drivers/index.rst
> +++ b/Documentation/media/v4l-drivers/index.rst
> @@ -18,8 +18,6 @@ License".
> .. toctree::
> :maxdepth: 5
> :numbered:
> - :caption: Table of Contents
> - :name: v4l_mastertoc
>
> fourcc
> v4l-with-ir
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-19 12:31 ` Markus Heiser
@ 2016-07-19 14:53 ` Mauro Carvalho Chehab
2016-07-19 15:40 ` Mauro Carvalho Chehab
` (2 more replies)
0 siblings, 3 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-19 14:53 UTC (permalink / raw)
To: Markus Heiser
Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
Jonathan Corbet, linux-doc, Jani Nikula
Em Tue, 19 Jul 2016 14:31:18 +0200
Markus Heiser <markus.heiser@darmarit.de> escreveu:
> > I really hate stupid toolchains that require everybody to upgrade to
> > the very latest version of it every time.
>
> Hi Mauro,
>
> It might be annoying how sphinx handles errors, but normally a build
> process should report errors to monitor.
The documents are automatically built at linuxtv.org once a day. While
Sphinx doesn't build them without warnings, I won't enable any sort
of feedback from the server, as I don't want to be bothered all
days about the same warnings.
Also, for safety reasons, we only install packages on the server
that are shipped with the distribution.
> > Maybe someone at linux-doc
> > may have an idea about how to add new markup attributes to the
> > documents without breaking for the ones using older versions of Sphinx.
>
> see below
>
> > The problem we're facing is due to a change meant to add a title before
> > each media's table of contents (provided via :toctree: markup).
>
> I think this is only ONE drawback, others see the changelog ..
I had to remove captions from tables on a past patch, because of the
same reason: Sphinx 1.2.x doesn't support it.
> * http://www.sphinx-doc.org/en/stable/changes.html
What we miss is the documentation for Sphinx 1.2 and 1.3 versions. The
site only has documentation for the very latest version, making harder
to ensure that we're using only the tags supported by a certain version.
> > All it needs is something that will be translated to HTML as:
> > <h1>Table of contents</h1>, without the need of creating any cross
> > reference, nor being added to the main TOC at Documentation/index.rst.
> >
> > We can't simply use the normal way to generate <h1> tags:
> >
> > --- a/Documentation/media/dvb-drivers/index.rst
> > +++ b/Documentation/media/dvb-drivers/index.rst
> > @@ -15,6 +15,10 @@ the license is included in the chapter entitled "GNU Free Documentation
> > License".
> >
> >
> > +#####################
> > +FOO Table of contents
> > +#####################
> > +
> > .. toctree::
> > :maxdepth: 5
> > :numbered:
> >
> > The page itself would look OK, but this would produce a new entry at the
> > output/html/index.html:
> >
> > * Linux Digital TV driver-specific documentation
> > * FOO Table of contents
> >
> > 1. Introdution
> >
> > With is not what we want.
> >
> > With Sphinx 1.4.5, the way of doing that is to add a :caption: tag
> > to the toctree, but this tag doesn't exist on 1.2.x. Also, as it
> > also convert captions on references, and all books are linked
> > together at Documentation/index.rst, it also needs a :name: tag,
> > in order to avoid warnings about duplicated tags when building the
> > main index.rst.
> >
> > I have no idea about how to do that in a backward-compatible way.
> >
> > Maybe Markus, Jani or someone else at linux-doc may have some
> > glue.
>
> IMHO: A backward-compatible way for all linux distros and versions
> out there is not the way.
>
> If we use options or features of a new version, we have to
> install the new version (independent which xml we used in the past
> or python tool we want to use).
With DocBook this is clear: the document itself is bound against
an specific version of the spec. So, *all* versions of the DocBook
toolchains support the very same document, or, when it doesn't, the
toolchain aborts with an error and doesn't produce anything. Very
easy for a script to identify if the build succeeds or not.
Sphinx is very evil with that regards: it keeps generating the
files, except that the contents of the tags that contain unrecognized
fields will be empty (with is very bad for :toctree:) and a few
additional warnings will be generated. Very hard for a script to detect
if the doc was OK or got mangled by the toolchain, because of a version
incompatibility.
> IMHO the main problem is, that we have not yet documented on which
> Sphinx version we agree and how to get a build environment which
> fullfills these requirements.
Yes, the Sphinx minimal version should be documented at
Documentation/Changes.
I'd say that the minimal version should be the Sphinx version
found on the latest version of the main distributions, e .g.
at least Fedora, openSuse, Debian, Ubuntu.
(I guess distros like ArchLinux and Gentoo won't be a problem,
as they tend to use the newer versions of the sources).
On a quick check:
- Fedora 24 comes with 1.3.x
- openSuse 13.2 with 1.2.x
- Debian 8.5 with 1.2.x.
- Ubuntu 16.04 with 1.3.x
- Ubuntu 14.04 with 1.2.x
- Mageia 5 with 1.2.x
So, I guess we should set the minimal requirement to 1.2.x.
Btw, usually, on Kernel, we're very conservative to increment the
minimal version of a toolchain. So, for example, while GCC current
version is 6.1, the minimal requirement is gcc 3.2 (with was released
in 2003).
> For build environments I recommend to set up a python virtualenv
>
> * https://virtualenv.pypa.io/en/stable/
We can't assume that every Kernel developer would install a
python virtualenv. Instead, they'll just use whatever Sphinx
version is provided on their development machines.
> Additional:
>
> At this time, the make file only checks if sphinx is installed.
> With a small addition to the make file, we could check if all
> requirements are fulfilled.
>
> If you are interested in how, I could send a patch.
It is better to have an error than to build the documentation with
errors. Yet, as I said, this doesn't fix the issue, as anyone
can insert a tag that won't be recognized by the official
minimal version. Not sure how to address this.
Yet, this doesn't solve the specific issue for the TOC index
name. How this could be done in a way that would be backward
compatible to 1.2.x?
Thanks,
Mauro
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-19 14:53 ` Mauro Carvalho Chehab
@ 2016-07-19 15:40 ` Mauro Carvalho Chehab
2016-07-19 16:42 ` Markus Heiser
2016-07-19 22:49 ` Jonathan Corbet
2 siblings, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-19 15:40 UTC (permalink / raw)
To: Markus Heiser
Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
Jonathan Corbet, linux-doc, Jani Nikula
Em Tue, 19 Jul 2016 11:53:19 -0300
Mauro Carvalho Chehab <mchehab@s-opensource.com> escreveu:
> Yet, this doesn't solve the specific issue for the TOC index
> name. How this could be done in a way that would be backward
> compatible to 1.2.x?
Answering myself, the following patch should trick Sphinx to
allow the media books to be built against older versions of
the toolchain.
Regards,
Mauro
[PATCH] [media] doc-rst: backward compatibility with older Sphinx
versions
Sphinx is really evil when an older version finds an extra
attribute for the :toctree: tag: it simply ignores everything
and produce documents without any chapter inside!
As we're now using tags available only on Sphinx 1.4.x, we
need to use some creative ways to add a title before the
table of contents. Do that by using a css class.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff --git a/Documentation/media/dvb-drivers/index.rst b/Documentation/media/dvb-drivers/index.rst
index e1d4d87f2a47..e4c2e74db9dc 100644
--- a/Documentation/media/dvb-drivers/index.rst
+++ b/Documentation/media/dvb-drivers/index.rst
@@ -14,12 +14,13 @@ any later version published by the Free Software Foundation. A copy of
the license is included in the chapter entitled "GNU Free Documentation
License".
+.. class:: toc-title
+
+ Table of Contents
.. toctree::
:maxdepth: 5
:numbered:
- :caption: Table of Contents
- :name: dvb_mastertoc
intro
avermedia
diff --git a/Documentation/media/media_kapi.rst b/Documentation/media/media_kapi.rst
index 0af80e90b7b5..5414d2a7dfb8 100644
--- a/Documentation/media/media_kapi.rst
+++ b/Documentation/media/media_kapi.rst
@@ -14,11 +14,13 @@ any later version published by the Free Software Foundation. A copy of
the license is included in the chapter entitled "GNU Free Documentation
License".
+.. class:: toc-title
+
+ Table of Contents
+
.. toctree::
:maxdepth: 5
:numbered:
- :caption: Table of Contents
- :name: kapi_mastertoc
kapi/v4l2-framework
kapi/v4l2-controls
diff --git a/Documentation/media/media_uapi.rst b/Documentation/media/media_uapi.rst
index debe4531040b..aaa9a0e387c4 100644
--- a/Documentation/media/media_uapi.rst
+++ b/Documentation/media/media_uapi.rst
@@ -14,11 +14,12 @@ any later version published by the Free Software Foundation. A copy of
the license is included in the chapter entitled "GNU Free Documentation
License".
+.. class:: toc-title
+
+ Table of Contents
.. toctree::
:maxdepth: 5
- :caption: Table of Contents
- :name: uapi_mastertoc
intro
uapi/v4l/v4l2
diff --git a/Documentation/media/v4l-drivers/index.rst b/Documentation/media/v4l-drivers/index.rst
index 8d1710234e5a..2aab653905ce 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -14,12 +14,13 @@ any later version published by the Free Software Foundation. A copy of
the license is included in the chapter entitled "GNU Free Documentation
License".
+.. class:: toc-title
+
+ Table of Contents
.. toctree::
:maxdepth: 5
:numbered:
- :caption: Table of Contents
- :name: v4l_mastertoc
fourcc
v4l-with-ir
diff --git a/Documentation/sphinx-static/theme_overrides.css b/Documentation/sphinx-static/theme_overrides.css
index c97d8428302d..3a2ac4bcfd78 100644
--- a/Documentation/sphinx-static/theme_overrides.css
+++ b/Documentation/sphinx-static/theme_overrides.css
@@ -31,6 +31,11 @@
* - hide the permalink symbol as long as link is not hovered
*/
+ .toc-title {
+ font-size: 150%;
+ font-weight: bold;
+ }
+
caption, .wy-table caption, .rst-content table.field-list caption {
font-size: 100%;
}
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-19 14:53 ` Mauro Carvalho Chehab
2016-07-19 15:40 ` Mauro Carvalho Chehab
@ 2016-07-19 16:42 ` Markus Heiser
2016-07-19 17:18 ` Mauro Carvalho Chehab
2016-07-19 22:49 ` Jonathan Corbet
2 siblings, 1 reply; 36+ messages in thread
From: Markus Heiser @ 2016-07-19 16:42 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
Jonathan Corbet, linux-doc, Jani Nikula, Daniel Vetter
Am 19.07.2016 um 16:53 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
> Em Tue, 19 Jul 2016 14:31:18 +0200
> Markus Heiser <markus.heiser@darmarit.de> escreveu:
>
>
>>> I really hate stupid toolchains that require everybody to upgrade to
>>> the very latest version of it every time.
>>
>> Hi Mauro,
>>
>> It might be annoying how sphinx handles errors, but normally a build
>> process should report errors to monitor.
>
> The documents are automatically built at linuxtv.org once a day. While
> Sphinx doesn't build them without warnings, I won't enable any sort
> of feedback from the server, as I don't want to be bothered all
> days about the same warnings.
>
> Also, for safety reasons, we only install packages on the server
> that are shipped with the distribution.
OK, I understand .. but with this you have to run software with
known bugs or other drawbacks .. If I'am sloppy I would say:
this is your decision, other will find other decisions .. ;-) / sorry
>>> Maybe someone at linux-doc
>>> may have an idea about how to add new markup attributes to the
>>> documents without breaking for the ones using older versions of Sphinx.
>>
>> see below
>>
>>> The problem we're facing is due to a change meant to add a title before
>>> each media's table of contents (provided via :toctree: markup).
>>
>> I think this is only ONE drawback, others see the changelog ..
>
> I had to remove captions from tables on a past patch, because of the
> same reason: Sphinx 1.2.x doesn't support it.
>
>> * http://www.sphinx-doc.org/en/stable/changes.html
>
> What we miss is the documentation for Sphinx 1.2 and 1.3 versions. The
> site only has documentation for the very latest version, making harder
> to ensure that we're using only the tags supported by a certain version.
We could build the documentation of the (e.g.) 1.2 tag
https://github.com/sphinx-doc/sphinx/tree/1.2
by checkout the tag, cd to "./doc" and run "make html".
I haven't tested yet, but it should work this way.
>>> All it needs is something that will be translated to HTML as:
>>> <h1>Table of contents</h1>, without the need of creating any cross
>>> reference, nor being added to the main TOC at Documentation/index.rst.
>>>
>>> We can't simply use the normal way to generate <h1> tags:
>>>
>>> --- a/Documentation/media/dvb-drivers/index.rst
>>> +++ b/Documentation/media/dvb-drivers/index.rst
>>> @@ -15,6 +15,10 @@ the license is included in the chapter entitled "GNU Free Documentation
>>> License".
>>>
>>>
>>> +#####################
>>> +FOO Table of contents
>>> +#####################
>>> +
>>> .. toctree::
>>> :maxdepth: 5
>>> :numbered:
>>>
>>> The page itself would look OK, but this would produce a new entry at the
>>> output/html/index.html:
>>>
>>> * Linux Digital TV driver-specific documentation
>>> * FOO Table of contents
>>>
>>> 1. Introdution
>>>
>>> With is not what we want.
>>>
>>> With Sphinx 1.4.5, the way of doing that is to add a :caption: tag
>>> to the toctree, but this tag doesn't exist on 1.2.x. Also, as it
>>> also convert captions on references, and all books are linked
>>> together at Documentation/index.rst, it also needs a :name: tag,
>>> in order to avoid warnings about duplicated tags when building the
>>> main index.rst.
>>>
>>> I have no idea about how to do that in a backward-compatible way.
>>>
>>> Maybe Markus, Jani or someone else at linux-doc may have some
>>> glue.
>>
>> IMHO: A backward-compatible way for all linux distros and versions
>> out there is not the way.
>>
>> If we use options or features of a new version, we have to
>> install the new version (independent which xml we used in the past
>> or python tool we want to use).
>
> With DocBook this is clear: the document itself is bound against
> an specific version of the spec. So, *all* versions of the DocBook
> toolchains support the very same document, or, when it doesn't, the
> toolchain aborts with an error and doesn't produce anything. Very
> easy for a script to identify if the build succeeds or not.
OK, you are right ... for this, I suggested (below) to test the
requirements (e.g. sphinx 1.2, RTD-theme) ...
> Sphinx is very evil with that regards: it keeps generating the
> files, except that the contents of the tags that contain unrecognized
> fields will be empty (with is very bad for :toctree:) and a few
> additional warnings will be generated. Very hard for a script to detect
> if the doc was OK or got mangled by the toolchain, because of a version
> incompatibility.
On your build host, you could turn warnings into errors (Daniel posted
the -W option)
$ make SPHINXOPTS=-W htmldocs
But this will only be helpfull when the build is free of warnings
(and this will be more and more harder as more content is placed
into).
>> IMHO the main problem is, that we have not yet documented on which
>> Sphinx version we agree and how to get a build environment which
>> fullfills these requirements.
>
> Yes, the Sphinx minimal version should be documented at
> Documentation/Changes.
>
> I'd say that the minimal version should be the Sphinx version
> found on the latest version of the main distributions, e .g.
> at least Fedora, openSuse, Debian, Ubuntu.
> (I guess distros like ArchLinux and Gentoo won't be a problem,
> as they tend to use the newer versions of the sources).
>
> On a quick check:
>
> - Fedora 24 comes with 1.3.x
> - openSuse 13.2 with 1.2.x
> - Debian 8.5 with 1.2.x.
> - Ubuntu 16.04 with 1.3.x
> - Ubuntu 14.04 with 1.2.x
> - Mageia 5 with 1.2.x
>
> So, I guess we should set the minimal requirement to 1.2.x.
>
> Btw, usually, on Kernel, we're very conservative to increment the
> minimal version of a toolchain. So, for example, while GCC current
> version is 6.1, the minimal requirement is gcc 3.2 (with was released
> in 2003).
OK, I understand, but I have a differentiated meaning about *pure-kernel*
and toolchains to build kernel documentation. I know, that there is a
unclear boundary, but IMHO: while the key aspects of *pure-kernel* are stability,
backward compatibility etc. they key aspects of building documentation
are more on accessibility in multiple and modern output formats. E.g. there
was a discussion if javascript should be needed in HTML, or think about
output formats like ePub etc. ... when we want to get in use of all
this various, we need to follow up to date developments.
E.g. if we use Sphinx 1.2, we have to test how well it works with the RTD theme
we have to cover all the bugs and drawbacks of the old version and we will
get problems if we want to use modern builders. We have to write and test
our extensions with backward compatibility in mind etc. IMHO building a
toolchain with backward compatibility and fixed errors will take
much more time. IMHO we should not try to do what sphinx-doc & Co.
wan't do.
Will should also take in mind, that Sphinx-doc is (compared to gcc
or DocBook) a upcoming development, it first 1.0 release is from 2010.
Note:
Previous is my opinion, I'am not a *pure kernel* developer, please
correct if I oversee some of kernel developers needs or problems
raised with kernel development.
>> For build environments I recommend to set up a python virtualenv
>>
>> * https://virtualenv.pypa.io/en/stable/
>
> We can't assume that every Kernel developer would install a
> python virtualenv. Instead, they'll just use whatever Sphinx
> version is provided on their development machines.
>
>> Additional:
>>
>> At this time, the make file only checks if sphinx is installed.
>> With a small addition to the make file, we could check if all
>> requirements are fulfilled.
>>
>> If you are interested in how, I could send a patch.
>
> It is better to have an error than to build the documentation with
> errors. Yet, as I said, this doesn't fix the issue, as anyone
> can insert a tag that won't be recognized by the official
> minimal version. Not sure how to address this.
>
> Yet, this doesn't solve the specific issue for the TOC index
> name. How this could be done in a way that would be backward
> compatible to 1.2.x?
Ah. OK, sorry ... but in the meantime, you answered yourself ;-)
But take in mind, that your solution:
.. class:: toc-title
Table of Contents
--- a/Documentation/sphinx-static/theme_overrides.css
+++ b/Documentation/sphinx-static/theme_overrides.css
@@ -31,6 +31,11 @@
* - hide the permalink symbol as long as link is not hovered
*/
+ .toc-title {
+ font-size: 150%;
+ font-weight: bold;
+ }
+
caption, .wy-table caption, .rst-content table.field-list caption {
font-size: 100%;
}
only fits for HTML output.
As an alternative I recommend to simply add a line "**Table of Contents**"
before the toctree, but this might not be perfect, since it does not result
in a <h1> tag. If you only want to see the Header in the HTML output, a other
alternative is to use the ".. raw::" directive
* http://docutils.sourceforge.net/docs/ref/rst/directives.html#raw-data-pass-through
.. raw:: html
<h1>Table of Contents</h1>
But over all: IMHO there is no need for a Header "Table of Contents" ;-)
A bit OT, but I see that you often use tabs / I recommend to use
spaces for indentation:
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#whitespace
-- Markus --
>
> Thanks,
> Mauro
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-19 16:42 ` Markus Heiser
@ 2016-07-19 17:18 ` Mauro Carvalho Chehab
2016-07-21 15:17 ` Markus Heiser
0 siblings, 1 reply; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-19 17:18 UTC (permalink / raw)
To: Markus Heiser
Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
Jonathan Corbet, linux-doc, Jani Nikula, Daniel Vetter
Em Tue, 19 Jul 2016 18:42:50 +0200
Markus Heiser <markus.heiser@darmarit.de> escreveu:
> > What we miss is the documentation for Sphinx 1.2 and 1.3 versions. The
> > site only has documentation for the very latest version, making harder
> > to ensure that we're using only the tags supported by a certain version.
>
> We could build the documentation of the (e.g.) 1.2 tag
>
> https://github.com/sphinx-doc/sphinx/tree/1.2
>
> by checkout the tag, cd to "./doc" and run "make html".
> I haven't tested yet, but it should work this way.
Yep, but this should be placed somewhere and IMHO linked at the
kernel-documentation book as the reference to be used by Kernel
documentation developers.
> > Sphinx is very evil with that regards: it keeps generating the
> > files, except that the contents of the tags that contain unrecognized
> > fields will be empty (with is very bad for :toctree:) and a few
> > additional warnings will be generated. Very hard for a script to detect
> > if the doc was OK or got mangled by the toolchain, because of a version
> > incompatibility.
>
> On your build host, you could turn warnings into errors (Daniel posted
> the -W option)
>
> $ make SPHINXOPTS=-W htmldocs
>
> But this will only be helpfull when the build is free of warnings
> (and this will be more and more harder as more content is placed
> into).
We're very far away for getting it free of warnings, as I didn't
find a way yet to get rid of some of them.
Also, as you said, it is harder as more content is placed,
specially when it comes from other books that we don't maintain.
>
> >> IMHO the main problem is, that we have not yet documented on which
> >> Sphinx version we agree and how to get a build environment which
> >> fullfills these requirements.
> >
> > Yes, the Sphinx minimal version should be documented at
> > Documentation/Changes.
> >
> > I'd say that the minimal version should be the Sphinx version
> > found on the latest version of the main distributions, e .g.
> > at least Fedora, openSuse, Debian, Ubuntu.
> > (I guess distros like ArchLinux and Gentoo won't be a problem,
> > as they tend to use the newer versions of the sources).
> >
> > On a quick check:
> >
> > - Fedora 24 comes with 1.3.x
> > - openSuse 13.2 with 1.2.x
> > - Debian 8.5 with 1.2.x.
> > - Ubuntu 16.04 with 1.3.x
> > - Ubuntu 14.04 with 1.2.x
> > - Mageia 5 with 1.2.x
> >
> > So, I guess we should set the minimal requirement to 1.2.x.
> >
> > Btw, usually, on Kernel, we're very conservative to increment the
> > minimal version of a toolchain. So, for example, while GCC current
> > version is 6.1, the minimal requirement is gcc 3.2 (with was released
> > in 2003).
>
> OK, I understand, but I have a differentiated meaning about *pure-kernel*
> and toolchains to build kernel documentation. I know, that there is a
> unclear boundary, but IMHO: while the key aspects of *pure-kernel* are stability,
> backward compatibility etc. they key aspects of building documentation
> are more on accessibility in multiple and modern output formats. E.g. there
> was a discussion if javascript should be needed in HTML, or think about
> output formats like ePub etc. ... when we want to get in use of all
> this various, we need to follow up to date developments.
>
> E.g. if we use Sphinx 1.2, we have to test how well it works with the RTD theme
> we have to cover all the bugs and drawbacks of the old version and we will
> get problems if we want to use modern builders. We have to write and test
> our extensions with backward compatibility in mind etc. IMHO building a
> toolchain with backward compatibility and fixed errors will take
> much more time. IMHO we should not try to do what sphinx-doc & Co.
> wan't do.
>
> Will should also take in mind, that Sphinx-doc is (compared to gcc
> or DocBook) a upcoming development, it first 1.0 release is from 2010.
>
> Note:
>
> Previous is my opinion, I'am not a *pure kernel* developer, please
> correct if I oversee some of kernel developers needs or problems
> raised with kernel development.
I guess you missed the point. From my PoV, what I expect by using
a markup language is that a lot more developers will be able to
write patches improving the media documentation, as it is easier
to write a markup text than to write docs for DocBook.
However, this will only happen if the developers would be able
to test if their documentation changes will be recognized by
the toolchain.
If we raise the bar and require that every developer working on
documentation to be a Python expert and install their own virtualenv,
this will never happen, and even the current contributors won't do it,
as very few Kernel developers are also Python developers.
> >> For build environments I recommend to set up a python virtualenv
> >>
> >> * https://virtualenv.pypa.io/en/stable/
> >
> > We can't assume that every Kernel developer would install a
> > python virtualenv. Instead, they'll just use whatever Sphinx
> > version is provided on their development machines.
> >
> >> Additional:
> >>
> >> At this time, the make file only checks if sphinx is installed.
> >> With a small addition to the make file, we could check if all
> >> requirements are fulfilled.
> >>
> >> If you are interested in how, I could send a patch.
> >
> > It is better to have an error than to build the documentation with
> > errors. Yet, as I said, this doesn't fix the issue, as anyone
> > can insert a tag that won't be recognized by the official
> > minimal version. Not sure how to address this.
> >
> > Yet, this doesn't solve the specific issue for the TOC index
> > name. How this could be done in a way that would be backward
> > compatible to 1.2.x?
>
> Ah. OK, sorry ... but in the meantime, you answered yourself ;-)
>
> But take in mind, that your solution:
>
> .. class:: toc-title
>
> Table of Contents
>
> --- a/Documentation/sphinx-static/theme_overrides.css
> +++ b/Documentation/sphinx-static/theme_overrides.css
> @@ -31,6 +31,11 @@
> * - hide the permalink symbol as long as link is not hovered
> */
>
> + .toc-title {
> + font-size: 150%;
> + font-weight: bold;
> + }
> +
> caption, .wy-table caption, .rst-content table.field-list caption {
> font-size: 100%;
> }
>
> only fits for HTML output.
Hmm... it worked also for epub.
I know that some formats won't do the right thing here, but at least
it won't break if the book is generated on other formats.
>
> As an alternative I recommend to simply add a line "**Table of Contents**"
> before the toctree, but this might not be perfect, since it does not result
> in a <h1> tag. If you only want to see the Header in the HTML output, a other
> alternative is to use the ".. raw::" directive
>
> * http://docutils.sourceforge.net/docs/ref/rst/directives.html#raw-data-pass-through
>
> .. raw:: html
>
> <h1>Table of Contents</h1>
>
> But over all: IMHO there is no need for a Header "Table of Contents" ;-)
That seems a worse solution. It shouldn't be that hard for a PDF or latex
converter to do something with a ".. class::" markup, but I guess it would be
a way harder for them to handle a raw html.
> A bit OT, but I see that you often use tabs / I recommend to use
> spaces for indentation:
>
> http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#whitespace
The Kernel policies are to use tabs instead of spaces, and tabs have
size of 8. I have some git automation to avoid commit patches with
bad whitespaces, and some tools to convert spaces into tabs.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-19 17:18 ` Mauro Carvalho Chehab
@ 2016-07-21 15:17 ` Markus Heiser
2016-07-22 9:46 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 36+ messages in thread
From: Markus Heiser @ 2016-07-21 15:17 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
Jonathan Corbet, linux-doc, Jani Nikula, Daniel Vetter
Am 19.07.2016 um 19:18 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
>> A bit OT, but I see that you often use tabs / I recommend to use
>> spaces for indentation:
>>
>> http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#whitespace
>
> The Kernel policies are to use tabs instead of spaces,
Yes, but not in text files .. I think.
-- Markus --
> and tabs have
> size of 8. I have some git automation to avoid commit patches with
> bad whitespaces, and some tools to convert spaces into tabs.
>
>
> Thanks,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-21 15:17 ` Markus Heiser
@ 2016-07-22 9:46 ` Mauro Carvalho Chehab
2016-07-22 10:55 ` Markus Heiser
0 siblings, 1 reply; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-22 9:46 UTC (permalink / raw)
To: Markus Heiser
Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
Jonathan Corbet, linux-doc, Jani Nikula, Daniel Vetter
Em Thu, 21 Jul 2016 17:17:26 +0200
Markus Heiser <markus.heiser@darmarit.de> escreveu:
> Am 19.07.2016 um 19:18 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
>
> >> A bit OT, but I see that you often use tabs / I recommend to use
> >> spaces for indentation:
> >>
> >> http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#whitespace
> >
> > The Kernel policies are to use tabs instead of spaces,
>
> Yes, but not in text files .. I think.
See chapter 1 of Documentation/CodingStyle:
Chapter 1: Indentation
Tabs are 8 characters, and thus indentations are also 8 characters.
>
> -- Markus --
>
> > and tabs have
> > size of 8. I have some git automation to avoid commit patches with
> > bad whitespaces, and some tools to convert spaces into tabs.
>
> >
> >
> > Thanks,
> > Mauro
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Thanks,
Mauro
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-22 9:46 ` Mauro Carvalho Chehab
@ 2016-07-22 10:55 ` Markus Heiser
0 siblings, 0 replies; 36+ messages in thread
From: Markus Heiser @ 2016-07-22 10:55 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
Jonathan Corbet, linux-doc, Jani Nikula, Daniel Vetter
Am 22.07.2016 um 11:46 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
> Em Thu, 21 Jul 2016 17:17:26 +0200
> Markus Heiser <markus.heiser@darmarit.de> escreveu:
>
>> Am 19.07.2016 um 19:18 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
>>
>>>> A bit OT, but I see that you often use tabs / I recommend to use
>>>> spaces for indentation:
>>>>
>>>> http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#whitespace
>>>
>>> The Kernel policies are to use tabs instead of spaces,
>>
>> Yes, but not in text files .. I think.
>
> See chapter 1 of Documentation/CodingStyle:
>
> Chapter 1: Indentation
>
> Tabs are 8 characters, and thus indentations are also 8 characters.
Hi Mauro,
sorry if I'am pedantic, IMHO this is "Coding" style.
See end of chapter 1:
Outside of comments, documentation and except in Kconfig, spaces are never
used for indentation ...
As far as I can see, nearly all of the ASCII markups in the *.txt files use
space for indentation (some mix tabs and spaces). I don't know if
tab indentation in kernel-doc comments is a good choice.
--Markus
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-19 14:53 ` Mauro Carvalho Chehab
2016-07-19 15:40 ` Mauro Carvalho Chehab
2016-07-19 16:42 ` Markus Heiser
@ 2016-07-19 22:49 ` Jonathan Corbet
2016-07-20 0:00 ` Mauro Carvalho Chehab
2 siblings, 1 reply; 36+ messages in thread
From: Jonathan Corbet @ 2016-07-19 22:49 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Markus Heiser, Hans Verkuil, Linux Media Mailing List,
Mauro Carvalho Chehab, linux-doc, Jani Nikula
On Tue, 19 Jul 2016 11:53:19 -0300
Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote:
> So, I guess we should set the minimal requirement to 1.2.x.
*sigh*.
I hate to do that; things are happening quickly enough with Sphinx that
it would be nice to be able to count on a newer version. That said, one
of my goals in this whole thing was to make it *easier* for developers to
generate the docs; the DocBook toolchain has always been notoriously
difficult in that regard. Forcing people to install a newer sphinx by
hand is not the way to get there.
So I guess we need to make sure things work with 1.2 for now. I'd hope
we could push that to at least 1.3 before too long, though, once the
community distributions are there. I think we can be a *bit* more
aggressive with the docs than with the kernel as a whole.
jon
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-19 22:49 ` Jonathan Corbet
@ 2016-07-20 0:00 ` Mauro Carvalho Chehab
2016-07-20 6:07 ` Markus Heiser
0 siblings, 1 reply; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-20 0:00 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Markus Heiser, Hans Verkuil, Linux Media Mailing List,
Mauro Carvalho Chehab, linux-doc, Jani Nikula
Em Tue, 19 Jul 2016 16:49:16 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Tue, 19 Jul 2016 11:53:19 -0300
> Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote:
>
> > So, I guess we should set the minimal requirement to 1.2.x.
>
> *sigh*.
>
> I hate to do that; things are happening quickly enough with Sphinx that
> it would be nice to be able to count on a newer version. That said, one
> of my goals in this whole thing was to make it *easier* for developers to
> generate the docs; the DocBook toolchain has always been notoriously
> difficult in that regard. Forcing people to install a newer sphinx by
> hand is not the way to get there.
>
> So I guess we need to make sure things work with 1.2 for now. I'd hope
> we could push that to at least 1.3 before too long, though, once the
> community distributions are there. I think we can be a *bit* more
> aggressive with the docs than with the kernel as a whole.
Yeah, that seems to be the right strategy, IMHO. With the patch I sent,
the media books will again build fine with 1.2.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-20 0:00 ` Mauro Carvalho Chehab
@ 2016-07-20 6:07 ` Markus Heiser
2016-07-20 10:19 ` Mauro Carvalho Chehab
2016-07-20 23:28 ` Jonathan Corbet
0 siblings, 2 replies; 36+ messages in thread
From: Markus Heiser @ 2016-07-20 6:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Jonathan Corbet
Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
linux-doc, Jani Nikula
Am 20.07.2016 um 02:00 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
> Em Tue, 19 Jul 2016 16:49:16 -0600
> Jonathan Corbet <corbet@lwn.net> escreveu:
>
>> On Tue, 19 Jul 2016 11:53:19 -0300
>> Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote:
>>
>>> So, I guess we should set the minimal requirement to 1.2.x.
>>
>> *sigh*.
>>
>> I hate to do that; things are happening quickly enough with Sphinx that
>> it would be nice to be able to count on a newer version. That said, one
>> of my goals in this whole thing was to make it *easier* for developers to
>> generate the docs; the DocBook toolchain has always been notoriously
>> difficult in that regard. Forcing people to install a newer sphinx by
>> hand is not the way to get there.
>>
>> So I guess we need to make sure things work with 1.2 for now. I'd hope
>> we could push that to at least 1.3 before too long, though, once the
>> community distributions are there. I think we can be a *bit* more
>> aggressive with the docs than with the kernel as a whole.
>
> Yeah, that seems to be the right strategy, IMHO. With the patch I sent,
> the media books will again build fine with 1.2.
It is a difficult situation, whatever we do, we will get in trouble. To
handle this, (IMHO) at first we need a reference documentation.
> What we miss is the documentation for Sphinx 1.2 and 1.3 versions. The
> site only has documentation for the very latest version, making harder
> to ensure that we're using only the tags supported by a certain version.
We could build the documentation of the (e.g.) 1.2 tag
https://github.com/sphinx-doc/sphinx/tree/1.2
by checkout the tag, cd to "./doc" and run "make html".
I haven't tested yet, but it should work this way.
Jon, what do you think ... could we serve this 1.2 doc
on https://www.kernel.org/doc/ as reference?
And whats about those who have 1.3 (or any version >1.2) as default
in the linux distro? Should they install a virtualenv? ... it is
a dilemma.
Sorry that I have not identified this earlier ... I'am using python
a long time and for me it is common to set up build processes
with a version decoupled from the OS version, mostly the up to date
version .. thats why I have neglected any version problems :(
-- Markus --
>
> Thanks,
> Mauro
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-20 6:07 ` Markus Heiser
@ 2016-07-20 10:19 ` Mauro Carvalho Chehab
2016-07-20 23:28 ` Jonathan Corbet
1 sibling, 0 replies; 36+ messages in thread
From: Mauro Carvalho Chehab @ 2016-07-20 10:19 UTC (permalink / raw)
To: Markus Heiser
Cc: Jonathan Corbet, Hans Verkuil, Linux Media Mailing List,
Mauro Carvalho Chehab, linux-doc, Jani Nikula
Em Wed, 20 Jul 2016 08:07:54 +0200
Markus Heiser <markus.heiser@darmarit.de> escreveu:
> Am 20.07.2016 um 02:00 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
>
> > Em Tue, 19 Jul 2016 16:49:16 -0600
> > Jonathan Corbet <corbet@lwn.net> escreveu:
> >
> >> On Tue, 19 Jul 2016 11:53:19 -0300
> >> Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote:
> >>
> >>> So, I guess we should set the minimal requirement to 1.2.x.
> >>
> >> *sigh*.
> >>
> >> I hate to do that; things are happening quickly enough with Sphinx that
> >> it would be nice to be able to count on a newer version. That said, one
> >> of my goals in this whole thing was to make it *easier* for developers to
> >> generate the docs; the DocBook toolchain has always been notoriously
> >> difficult in that regard. Forcing people to install a newer sphinx by
> >> hand is not the way to get there.
> >>
> >> So I guess we need to make sure things work with 1.2 for now. I'd hope
> >> we could push that to at least 1.3 before too long, though, once the
> >> community distributions are there. I think we can be a *bit* more
> >> aggressive with the docs than with the kernel as a whole.
> >
> > Yeah, that seems to be the right strategy, IMHO. With the patch I sent,
> > the media books will again build fine with 1.2.
>
>
> It is a difficult situation, whatever we do, we will get in trouble. To
> handle this, (IMHO) at first we need a reference documentation.
>
> > What we miss is the documentation for Sphinx 1.2 and 1.3 versions. The
> > site only has documentation for the very latest version, making harder
> > to ensure that we're using only the tags supported by a certain version.
>
> We could build the documentation of the (e.g.) 1.2 tag
>
> https://github.com/sphinx-doc/sphinx/tree/1.2
>
> by checkout the tag, cd to "./doc" and run "make html".
> I haven't tested yet, but it should work this way.
>
> Jon, what do you think ... could we serve this 1.2 doc
> on https://www.kernel.org/doc/ as reference?
Yeah, building the documentation for 1.2.3 worked. I added the
documentation at linuxtv.org:
https://linuxtv.org/downloads/sphinx-1.2.3/
Yet, I agree that the best would be to host it at kernel.org,
and add a link for it at kernel-documentation.rst.
> And whats about those who have 1.3 (or any version >1.2) as default
> in the linux distro? Should they install a virtualenv? ... it is
> a dilemma.
Well, they won't notice if a newer tag is used. IMHO, the best would
be if we had some tag at the configuration file or at the book itself
that would specify the sphinx version, and produce an ERROR if a
tag for newer versions would be used.
Not having that means more work for maintainers, as we'll need to
check it when merging patches for documentation.
>
> Sorry that I have not identified this earlier ... I'am using python
> a long time and for me it is common to set up build processes
> with a version decoupled from the OS version, mostly the up to date
> version .. thats why I have neglected any version problems :(
>
> -- Markus --
>
>
>
> >
> > Thanks,
> > Mauro
>
Thanks,
Mauro
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-20 6:07 ` Markus Heiser
2016-07-20 10:19 ` Mauro Carvalho Chehab
@ 2016-07-20 23:28 ` Jonathan Corbet
2016-07-21 14:41 ` Markus Heiser
1 sibling, 1 reply; 36+ messages in thread
From: Jonathan Corbet @ 2016-07-20 23:28 UTC (permalink / raw)
To: Markus Heiser
Cc: Mauro Carvalho Chehab, Hans Verkuil, Linux Media Mailing List,
Mauro Carvalho Chehab, linux-doc, Jani Nikula
On Wed, 20 Jul 2016 08:07:54 +0200
Markus Heiser <markus.heiser@darmarit.de> wrote:
> Jon, what do you think ... could we serve this 1.2 doc
> on https://www.kernel.org/doc/ as reference?
Seems like a good idea. I don't really know who controls that directory,
though; I can ping Konstantin and see what can be done there. Failing
that, I'd be more than happy to put it up on lwn, of course.
> And whats about those who have 1.3 (or any version >1.2) as default
> in the linux distro? Should they install a virtualenv? ... it is
> a dilemma.
I would hope that most people wouldn't have to worry about it, and would
be able to just use what their distribution provides - that's the reason
for the 1.2 compatibility requirement in the first place. I'll make a
point of having a 1.2 installation around that I can test things with;
that should suffice to catch any problems that sneak in.
Thanks,
jon
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-20 23:28 ` Jonathan Corbet
@ 2016-07-21 14:41 ` Markus Heiser
2016-07-21 16:59 ` Jonathan Corbet
0 siblings, 1 reply; 36+ messages in thread
From: Markus Heiser @ 2016-07-21 14:41 UTC (permalink / raw)
To: Jonathan Corbet, Mauro Carvalho Chehab
Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
linux-doc, Jani Nikula
Am 21.07.2016 um 01:28 schrieb Jonathan Corbet <corbet@lwn.net>:
> On Wed, 20 Jul 2016 08:07:54 +0200
> Markus Heiser <markus.heiser@darmarit.de> wrote:
>
>> Jon, what do you think ... could we serve this 1.2 doc
>> on https://www.kernel.org/doc/ as reference?
>
> Seems like a good idea. I don't really know who controls that directory,
> though; I can ping Konstantin and see what can be done there. Failing
> that, I'd be more than happy to put it up on lwn, of course.
>
>> And whats about those who have 1.3 (or any version >1.2) as default
>> in the linux distro? Should they install a virtualenv? ... it is
>> a dilemma.
>
> I would hope that most people wouldn't have to worry about it, and would
> be able to just use what their distribution provides - that's the reason
> for the 1.2 compatibility requirement in the first place.
Yes, but this is not what I mean ;) ... if someone use a distro
with a version > 1.2 and he use features not in 1.2, you -- the
maintainer -- will get into trouble.
IMHO contributors need a reference documentation (e.g. at kernel.org)
and a reference build environment (like you, see below).
> I'll make a
> point of having a 1.2 installation around that I can test things with;
> that should suffice to catch any problems that sneak in.
This is what I called the reference build environment. IMHO a
ref build env could only be assert by a virtualenv instance.
Here is what I tried to get one ....
first: create instance:
$ virtualenv /share/sph12env
second: source the virtualenv
$ source /share/sph12env/bin/activate
$ which pip
/share/sph12env/bin/pip
third: install Sphinx 1.2
$ pip install Sphinx==1.2
$ sphinx-build --version
Sphinx (sphinx-build) 1.2
seems fine ... now install rtd theme :-o
$ pip install sphinx_rtd_theme==0.1.8
Collecting sphinx_rtd_theme==0.1.8
Downloading sphinx_rtd_theme-0.1.8-py2.py3-none-any.whl (418kB)
Collecting sphinx>=1.3 (from sphinx_rtd_theme==0.1.8)
...
since sphinx>=1.3 is a requirement [1] of the sphinx_rtd_theme package
sphinx has been updated:
$ sphinx-build --version
Sphinx (sphinx-build) 1.4.5
Aaargh ... at the least now, I have strong doubts if it is a clever
decision to use an old sphinx version as reference.
Lets lean back and remember why we need this ... whatever
sphinx version a distro ships (with it's next update) you need a
reference environment ... version 1.2 or the latest version ... equal
if you are a maintainer or a contributor ...
So why not installing a updated version in a virtualenv on the build
server, may be in a jail. If contributors have installed older versions,
this is not a problem, the updated one is downward compatible.
[1] https://github.com/snide/sphinx_rtd_theme/blob/0.1.8/requirements.txt
-- Markus --
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 00/18] Complete moving media documentation to ReST format
2016-07-21 14:41 ` Markus Heiser
@ 2016-07-21 16:59 ` Jonathan Corbet
0 siblings, 0 replies; 36+ messages in thread
From: Jonathan Corbet @ 2016-07-21 16:59 UTC (permalink / raw)
To: Markus Heiser
Cc: Mauro Carvalho Chehab, Hans Verkuil, Linux Media Mailing List,
Mauro Carvalho Chehab, linux-doc, Jani Nikula
On Thu, 21 Jul 2016 16:41:53 +0200
Markus Heiser <markus.heiser@darmarit.de> wrote:
> Am 21.07.2016 um 01:28 schrieb Jonathan Corbet <corbet@lwn.net>:
>
> > I would hope that most people wouldn't have to worry about it, and would
> > be able to just use what their distribution provides - that's the reason
> > for the 1.2 compatibility requirement in the first place.
>
> Yes, but this is not what I mean ;) ... if someone use a distro
> with a version > 1.2 and he use features not in 1.2, you -- the
> maintainer -- will get into trouble.
Well, that's what we keep maintainers around. The same holds for any
maintainer if somebody adds a dependency on a too-new version of some other
tool. Such things happen, we simply fix them when they do.
> IMHO contributors need a reference documentation (e.g. at kernel.org)
> and a reference build environment (like you, see below).
Reference documentation, yes. But I don't think every developer needs a
Sphinx 1.2 installation, just like they don't need to have gcc 3.2 around.
It's enough that somebody has it and will catch problems.
jon
^ permalink raw reply [flat|nested] 36+ messages in thread