diff options
Diffstat (limited to 'linux/Documentation/video4linux/bttv')
| -rw-r--r-- | linux/Documentation/video4linux/bttv/CONTRIBUTORS | 25 | ||||
| -rw-r--r-- | linux/Documentation/video4linux/bttv/ICs | 37 | ||||
| -rw-r--r-- | linux/Documentation/video4linux/bttv/Modprobe.conf | 11 | ||||
| -rw-r--r-- | linux/Documentation/video4linux/bttv/Modules.conf | 14 | ||||
| -rw-r--r-- | linux/Documentation/video4linux/bttv/PROBLEMS | 62 | ||||
| -rw-r--r-- | linux/Documentation/video4linux/bttv/README.WINVIEW | 33 | ||||
| -rw-r--r-- | linux/Documentation/video4linux/bttv/README.freeze | 74 | ||||
| -rw-r--r-- | linux/Documentation/video4linux/bttv/README.quirks | 83 | ||||
| -rw-r--r-- | linux/Documentation/video4linux/bttv/Specs | 3 | ||||
| -rw-r--r-- | linux/Documentation/video4linux/bttv/THANKS | 24 |
10 files changed, 366 insertions, 0 deletions
diff --git a/linux/Documentation/video4linux/bttv/CONTRIBUTORS b/linux/Documentation/video4linux/bttv/CONTRIBUTORS new file mode 100644 index 000000000..aef49db88 --- /dev/null +++ b/linux/Documentation/video4linux/bttv/CONTRIBUTORS @@ -0,0 +1,25 @@ +Contributors to bttv: + +Michael Chu <mmchu@pobox.com> + AverMedia fix and more flexible card recognition + +Alan Cox <alan@redhat.com> + 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/linux/Documentation/video4linux/bttv/ICs b/linux/Documentation/video4linux/bttv/ICs new file mode 100644 index 000000000..611315f87 --- /dev/null +++ b/linux/Documentation/video4linux/bttv/ICs @@ -0,0 +1,37 @@ +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/linux/Documentation/video4linux/bttv/Modprobe.conf b/linux/Documentation/video4linux/bttv/Modprobe.conf new file mode 100644 index 000000000..55f14650d --- /dev/null +++ b/linux/Documentation/video4linux/bttv/Modprobe.conf @@ -0,0 +1,11 @@ +# 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/linux/Documentation/video4linux/bttv/Modules.conf b/linux/Documentation/video4linux/bttv/Modules.conf new file mode 100644 index 000000000..753f15956 --- /dev/null +++ b/linux/Documentation/video4linux/bttv/Modules.conf @@ -0,0 +1,14 @@ +# For modern kernels (2.6 or above), this belongs in /etc/modprobe.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/linux/Documentation/video4linux/bttv/PROBLEMS b/linux/Documentation/video4linux/bttv/PROBLEMS new file mode 100644 index 000000000..2b8b0079f --- /dev/null +++ b/linux/Documentation/video4linux/bttv/PROBLEMS @@ -0,0 +1,62 @@ +- 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/linux/Documentation/video4linux/bttv/README.WINVIEW b/linux/Documentation/video4linux/bttv/README.WINVIEW new file mode 100644 index 000000000..c61cf2864 --- /dev/null +++ b/linux/Documentation/video4linux/bttv/README.WINVIEW @@ -0,0 +1,33 @@ + +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/linux/Documentation/video4linux/bttv/README.freeze b/linux/Documentation/video4linux/bttv/README.freeze new file mode 100644 index 000000000..4259dccc8 --- /dev/null +++ b/linux/Documentation/video4linux/bttv/README.freeze @@ -0,0 +1,74 @@ + +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 alot 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/linux/Documentation/video4linux/bttv/README.quirks b/linux/Documentation/video4linux/bttv/README.quirks new file mode 100644 index 000000000..92e03929a --- /dev/null +++ b/linux/Documentation/video4linux/bttv/README.quirks @@ -0,0 +1,83 @@ + +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/linux/Documentation/video4linux/bttv/Specs b/linux/Documentation/video4linux/bttv/Specs new file mode 100644 index 000000000..79b9e576f --- /dev/null +++ b/linux/Documentation/video4linux/bttv/Specs @@ -0,0 +1,3 @@ +Philips http://www.Semiconductors.COM/pip/ +Conexant http://www.conexant.com/techinfo/default.asp +Micronas http://www.micronas.de/pages/product_documentation/index.html diff --git a/linux/Documentation/video4linux/bttv/THANKS b/linux/Documentation/video4linux/bttv/THANKS new file mode 100644 index 000000000..950aa781c --- /dev/null +++ b/linux/Documentation/video4linux/bttv/THANKS @@ -0,0 +1,24 @@ +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. + + |