^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) The bttv driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) ===============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) bttv and sound mini howto
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) -------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) There are a lot of different bt848/849/878/879 based boards available.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) Making video work often is not a big deal, because this is handled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) completely by the bt8xx chip, which is common on all boards. But
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) sound is handled in slightly different ways on each board.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) To handle the grabber boards correctly, there is a array tvcards[] in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) bttv-cards.c, which holds the information required for each board.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) Sound will work only, if the correct entry is used (for video it often
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) makes no difference). The bttv driver prints a line to the kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) log, telling which card type is used. Like this one::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) bttv0: model: BT848(Hauppauge old) [autodetected]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) You should verify this is correct. If it isn't, you have to pass the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) correct board type as insmod argument, ``insmod bttv card=2`` for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) example. The file :doc:`/admin-guide/media/bttv-cardlist` has a list
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) of valid arguments for card.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) If your card isn't listed there, you might check the source code for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) new entries which are not listed yet. If there isn't one for your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) card, you can check if one of the existing entries does work for you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) (just trial and error...).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) Some boards have an extra processor for sound to do stereo decoding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) and other nice features. The msp34xx chips are used by Hauppauge for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) example. If your board has one, you might have to load a helper
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) module like ``msp3400`` to make sound work. If there isn't one for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) chip used on your board: Bad luck. Start writing a new one. Well,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) you might want to check the video4linux mailing list archive first...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) Of course you need a correctly installed soundcard unless you have the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) speakers connected directly to the grabber board. Hint: check the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) mixer settings too. ALSA for example has everything muted by default.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) How sound works in detail
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) ~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) Still doesn't work? Looks like some driver hacking is required.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) Below is a do-it-yourself description for you.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) The bt8xx chips have 32 general purpose pins, and registers to control
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) these pins. One register is the output enable register
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) (``BT848_GPIO_OUT_EN``), it says which pins are actively driven by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) bt848 chip. Another one is the data register (``BT848_GPIO_DATA``), where
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) you can get/set the status if these pins. They can be used for input
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) and output.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) Most grabber board vendors use these pins to control an external chip
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) which does the sound routing. But every board is a little different.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) These pins are also used by some companies to drive remote control
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) receiver chips. Some boards use the i2c bus instead of the gpio pins
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) to connect the mux chip.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) As mentioned above, there is a array which holds the required
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) information for each known board. You basically have to create a new
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) line for your board. The important fields are these two::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) struct tvcard
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) [ ... ]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) u32 gpiomask;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) u32 audiomux[6]; /* Tuner, Radio, external, internal, mute, stereo */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) gpiomask specifies which pins are used to control the audio mux chip.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) The corresponding bits in the output enable register
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) (``BT848_GPIO_OUT_EN``) will be set as these pins must be driven by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) bt848 chip.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) The ``audiomux[]`` array holds the data values for the different inputs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) (i.e. which pins must be high/low for tuner/mute/...). This will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) written to the data register (``BT848_GPIO_DATA``) to switch the audio
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) mux.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) What you have to do is figure out the correct values for gpiomask and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) the audiomux array. If you have Windows and the drivers four your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) card installed, you might to check out if you can read these registers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) values used by the windows driver. A tool to do this is available
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) from http://btwincap.sourceforge.net/download.html.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) You might also dig around in the ``*.ini`` files of the Windows applications.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) You can have a look at the board to see which of the gpio pins are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) connected at all and then start trial-and-error ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) Starting with release 0.7.41 bttv has a number of insmod options to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) make the gpio debugging easier:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) ================= ==============================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) bttv_gpio=0/1 enable/disable gpio debug messages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) gpiomask=n set the gpiomask value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) audiomux=i,j,... set the values of the audiomux array
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) audioall=a set the values of the audiomux array (one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) value for all array elements, useful to check
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) out which effect the particular value has).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) ================= ==============================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) The messages printed with ``bttv_gpio=1`` look like this::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) bttv0: gpio: en=00000027, out=00000024 in=00ffffd8 [audio: off]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) en = output _en_able register (BT848_GPIO_OUT_EN)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) out = _out_put bits of the data register (BT848_GPIO_DATA),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) i.e. BT848_GPIO_DATA & BT848_GPIO_OUT_EN
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) in = _in_put bits of the data register,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) i.e. BT848_GPIO_DATA & ~BT848_GPIO_OUT_EN
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags