lastdragon/linux-kernel
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Resguardo inicial

Browse Source
This commit is contained in:
lastdragon
2026-09-06 12:53:21 -06:00
parent 662efe3c2a
commit ad2088d178
94853 changed files with 43200404 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
linux-7.2.3/Documentation/driver-api/media/drivers/bttv-devel.rst
+116
View File
@@ -0,0 +1,116 @@
.. SPDX-License-Identifier: GPL-2.0
The bttv driver
===============
bttv and sound mini howto
-------------------------
There are a lot of different bt848/849/878/879 based boards available.
Making video work often is not a big deal, because this is handled
completely by the bt8xx chip, which is common on all boards. But
sound is handled in slightly different ways on each board.
To handle the grabber boards correctly, there is a array tvcards[] in
bttv-cards.c, which holds the information required for each board.
Sound will work only, if the correct entry is used (for video it often
makes no difference). The bttv driver prints a line to the kernel
log, telling which card type is used. Like this one::
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 Documentation/admin-guide/media/bttv-cardlist.rst 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`` 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 http://btwincap.sourceforge.net/download.html.
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
linux-7.2.3/Documentation/driver-api/media/drivers/ccs/ccs-regs.asc
+1041
View File
File diff suppressed because it is too large Load Diff
linux-7.2.3/Documentation/driver-api/media/drivers/ccs/ccs.rst
+82
View File
@@ -0,0 +1,82 @@
.. SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause
.. include:: <isonum.txt>
.. _media-ccs-driver:
MIPI CCS camera sensor driver
=============================
The MIPI CCS camera sensor driver is a generic driver for `MIPI CCS
<https://www.mipi.org/specifications/camera-command-set>`_ compliant
camera sensors.
Also see :ref:`the CCS driver UAPI documentation <media-ccs-uapi>`.
CCS static data
---------------
The MIPI CCS driver supports CCS static data for all compliant devices,
including not just those compliant with CCS 1.1 but also CCS 1.0 and SMIA(++).
For CCS the file names are formed as
ccs/ccs-sensor-vvvv-mmmm-rrrr.fw (sensor) and
ccs/ccs-module-vvvv-mmmm-rrrr.fw (module).
For SMIA++ compliant devices the corresponding file names are
ccs/smiapp-sensor-vv-mmmm-rr.fw (sensor) and
ccs/smiapp-module-vv-mmmm-rrrr.fw (module).
For SMIA (non-++) compliant devices the static data file name is
ccs/smia-sensor-vv-mmmm-rr.fw (sensor).
vvvv or vv denotes MIPI and SMIA manufacturer IDs respectively, mmmm model ID
and rrrr or rr revision number.
CCS tools
~~~~~~~~~
`CCS tools <https://github.com/MIPI-Alliance/ccs-tools/>`_ is a set of
tools for working with CCS static data files. CCS tools includes a
definition of the human-readable CCS static data YAML format and includes a
program to convert it to a binary.
Register definition generator
-----------------------------
The ccs-regs.asc file contains MIPI CCS register definitions that are used
to produce C source code files for definitions that can be better used by
programs written in C language. As there are many dependencies between the
produced files, please do not modify them manually as it's error-prone and
in vain, but instead change the script producing them.
Usage
~~~~~
Conventionally the script is called this way to update the CCS driver
definitions:
.. code-block:: none
$ Documentation/driver-api/media/drivers/ccs/mk-ccs-regs -k \
-e drivers/media/i2c/ccs/ccs-regs.h \
-L drivers/media/i2c/ccs/ccs-limits.h \
-l drivers/media/i2c/ccs/ccs-limits.c \
-c Documentation/driver-api/media/drivers/ccs/ccs-regs.asc
CCS PLL calculator
==================
The CCS PLL calculator is used to compute the PLL configuration, given sensor's
capabilities as well as board configuration and user specified configuration. As
the configuration space that encompasses all these configurations is vast, the
PLL calculator isn't entirely trivial. Yet it is relatively simple to use for a
driver.
The PLL model implemented by the PLL calculator corresponds to MIPI CCS 1.1.
.. kernel-doc:: drivers/media/i2c/ccs-pll.h
**Copyright** |copy| 2020 Intel Corporation
linux-7.2.3/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs
Executable
+480
View File
@@ -0,0 +1,480 @@
#!/usr/bin/perl -w
# SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause
# Copyright (C) 2019--2020 Intel Corporation
use Getopt::Long qw(:config no_ignore_case);
use File::Basename;
my $ccsregs = "ccs-regs.asc";
my $header;
my $regarray;
my $limitc;
my $limith;
my $kernel;
my $help;
GetOptions("ccsregs|c=s" => \$ccsregs,
"header|e=s" => \$header,
"regarray|r=s" => \$regarray,
"limitc|l=s" => \$limitc,
"limith|L=s" => \$limith,
"kernel|k" => \$kernel,
"help|h" => \$help) or die "can't parse options";
$help = 1 if ! defined $header || ! defined $limitc || ! defined $limith;
if (defined $help) {
print <<EOH
$0 - Create CCS register definitions for C
usage: $0 -c ccs-regs.asc -e header -r regarray -l limit-c -L limit-header [-k]
-c ccs register file
-e header file name
-r register description array file name
-l limit and capability array file name
-L limit and capability header file name
-k generate files for kernel space consumption
EOH
;
exit 0;
}
my $lh_hdr = ! defined $kernel
? '#include "ccs-os.h"' . "\n"
: "#include <linux/bits.h>\n#include <linux/types.h>\n";
my $uint32_t = ! defined $kernel ? 'uint32_t' : 'u32';
my $uint16_t = ! defined $kernel ? 'uint16_t' : 'u16';
open(my $R, "< $ccsregs") or die "can't open $ccsregs";
open(my $H, "> $header") or die "can't open $header";
my $A;
if (defined $regarray) {
open($A, "> $regarray") or die "can't open $regarray";
}
open(my $LC, "> $limitc") or die "can't open $limitc";
open(my $LH, "> $limith") or die "can't open $limith";
my %this;
sub is_limit_reg($) {
my $addr = hex $_[0];
return 0 if $addr < 0x40; # weed out status registers
return 0 if $addr >= 0x100 && $addr < 0xfff; # weed out configuration registers
return 1;
}
my $uc_header = basename uc $header;
$uc_header =~ s/[^A-Z0-9]/_/g;
my $copyright = "/* Copyright (C) 2019--2020 Intel Corporation */\n";
my $license = "SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause";
my $note = "/*\n * Generated by $0;\n * do not modify.\n */\n";
for my $fh ($A, $LC) {
print $fh "// $license\n$copyright$note\n" if defined $fh;
}
for my $fh ($H, $LH) {
print $fh "/* $license */\n$copyright$note\n";
}
print $H <<EOF
#ifndef __${uc_header}__
#define __${uc_header}__
EOF
;
print $H <<EOF
#include <linux/bits.h>
#include <media/v4l2-cci.h>
EOF
if defined $kernel;
print $H "#define CCS_FL_BASE " .
(defined $kernel ? "CCI_REG_PRIVATE_SHIFT" : 16) . "\n";
my $flag = -1;
my $all_flags;
sub bit_def($) {
my $bit = shift @_;
if (defined $kernel) {
return "BIT$bit" if $bit =~ /^\(.*\)$/;
return "BIT($bit)";
}
return "(1U << $bit)";
}
sub flag_str($$) {
my ($flag, $check) = @_;
$$flag++;
my $flag_str = !$$flag ? "CCS_FL_BASE" : "(CCS_FL_BASE + $$flag)";
$flag_str = bit_def($flag_str);
$$check .= " | " if defined $$check;
$$check .= $flag_str;
return $flag_str;
}
if (! defined $kernel) {
print $H "#define CCS_FL_16BIT " . flag_str(\$flag, \$all_flags) . "\n";
print $H "#define CCS_FL_32BIT " . flag_str(\$flag, \$all_flags) . "\n";
}
print $H "#define CCS_FL_FLOAT_IREAL " . flag_str(\$flag, \$all_flags) . "\n";
print $H "#define CCS_FL_IREAL " . flag_str(\$flag, \$all_flags) . "\n";
print $H "#define CCS_BUILD_BUG \\
BUILD_BUG_ON(~CCI_REG_PRIVATE_MASK & ($all_flags))\n"
if defined $kernel;
print $H <<EOF
#define CCS_R_ADDR(r) ((r) & 0xffff)
EOF
if ! defined $kernel;
print $A <<EOF
#include <stdint.h>
#include <stdio.h>
#include "ccs-extra.h"
#include "ccs-regs.h"
EOF
if defined $A;
my $uc_limith = basename uc $limith;
$uc_limith =~ s/[^A-Z0-9]/_/g;
print $LH <<EOF
#ifndef __${uc_limith}__
#define __${uc_limith}__
$lh_hdr
struct ccs_limit {
$uint32_t reg;
$uint16_t size;
$uint16_t flags;
const char *name;
};
EOF
;
print $LH "#define CCS_L_FL_SAME_REG " . bit_def(0) . "\n\n";
print $LH <<EOF
extern const struct ccs_limit ccs_limits[];
EOF
;
print $LC <<EOF
#include "ccs-limits.h"
#include "ccs-regs.h"
const struct ccs_limit ccs_limits[] = {
EOF
;
my $limitcount = 0;
my $argdescs;
my $reglist = "const struct ccs_reg_desc ccs_reg_desc[] = {\n";
sub name_split($$) {
my ($name, $addr) = @_;
my $args;
$name =~ /([^\(]+?)(\(.*)/;
($name, $args) = ($1, $2);
$args = [split /,\s*/, $args];
foreach my $t (@$args) {
$t =~ s/[\(\)]//g;
$t =~ s/\//\\\//g;
}
return ($name, $addr, $args);
}
sub tabconv($) {
$_ = shift;
my @l = split "\n", $_;
map {
s/ {8,8}/\t/g;
s/\t\K +//;
} @l;
return (join "\n", @l) . "\n";
}
sub elem_bits(@) {
my @flags = @_;
return 16 if grep /^16$/, @flags;
return 32 if grep /^32$/, @flags;
return 8;
}
sub arr_size($) {
my $this = $_[0];
my $size = $this->{elsize};
my $h = $this->{argparams};
foreach my $arg (@{$this->{args}}) {
my $apref = $h->{$arg};
$size *= $apref->{max} - $apref->{min} + 1;
}
return $size;
}
sub print_args($$$) {
my ($this, $postfix, $is_same_reg) = @_;
my ($args, $argparams, $name) =
($this->{args}, $this->{argparams}, $this->{name});
my $varname = "ccs_reg_arg_" . (lc $name) . $postfix;
my @mins;
my @sorted_args = @{$this->{sorted_args}};
my $lim_arg;
my $size = arr_size($this);
$argdescs .= "static const struct ccs_reg_arg " . $varname . "[] = {\n";
foreach my $sorted_arg (@sorted_args) {
push @mins, $argparams->{$sorted_arg}->{min};
}
foreach my $sorted_arg (@sorted_args) {
my $h = $argparams->{$sorted_arg};
$argdescs .= "\t{ \"$sorted_arg\", $h->{min}, $h->{max}, $h->{elsize} },\n";
$lim_arg .= defined $lim_arg ? ", $h->{min}" : "$h->{min}";
}
$argdescs .= "};\n\n";
$reglist .= "\t{ CCS_R_" . (uc $name) . "(" . (join ",", (@mins)) .
"), $size, sizeof($varname) / sizeof(*$varname)," .
" \"" . (lc $name) . "\", $varname },\n";
print $LC tabconv sprintf "\t{ CCS_R_" . (uc $name) . "($lim_arg), " .
$size . ", " . ($is_same_reg ? "CCS_L_FL_SAME_REG" : "0") .
", \"$name" . (defined $this->{discontig} ? " $lim_arg" : "") . "\" },\n"
if is_limit_reg $this->{base_addr};
}
my $hdr_data;
while (<$R>) {
chop;
s/^\s*//;
next if /^[#;]/ || /^$/;
if (s/^-\s*//) {
if (s/^b\s*//) {
my ($bit, $addr) = split /\t+/;
$bit = uc $bit;
$hdr_data .= sprintf "#define %-62s %s", "CCS_" . (uc ${this{name}}) ."_$bit", bit_def($addr) . "\n";
} elsif (s/^f\s*//) {
s/[,\.-]/_/g;
my @a = split /\s+/;
my ($msb, $lsb, $this_field) = reverse @a;
@a = ( { "name" => "SHIFT", "addr" => $lsb, "fmt" => "%uU", },
{ "name" => "MASK", "addr" => (1 << ($msb + 1)) - 1 - ((1 << $lsb) - 1), "fmt" => "0x%" . join(".", ($this{"elsize"} >> 2) x 2) . "x" } );
$this{"field"} = $this_field;
foreach my $ar (@a) {
#print $ar->{fmt}."\n";
$hdr_data .= sprintf "#define %-62s " . $ar->{"fmt"} . "\n", "CCS_" . (uc $this{"name"}) . (defined $this_field ? "_" . uc $this_field : "") . "_" . $ar->{"name"}, $ar->{"addr"} . "\n";
}
} elsif (s/^e\s*//) {
s/[,\.-]/_/g;
my ($enum, $addr) = split /\s+/;
$enum = uc $enum;
$hdr_data .= sprintf "#define %-62s %s", "CCS_" . (uc ${this{name}}) . (defined $this{"field"} ? "_" . uc $this{"field"} : "") ."_$enum", $addr . ($addr =~ /0x/i ? "" : "U") . "\n";
} elsif (s/^l\s*//) {
my ($arg, $min, $max, $elsize, @discontig) = split /\s+/;
my $size;
foreach my $num ($min, $max) {
$num = hex $num if $num =~ /0x/i;
}
$hdr_data .= sprintf "#define %-62s %s", "CCS_LIM_" . (uc ${this{name}} . "_MIN_$arg"), $min . ($min =~ /0x/i ? "" : "U") . "\n";
$hdr_data .= sprintf "#define %-62s %s", "CCS_LIM_" . (uc ${this{name}} . "_MAX_$arg"), $max . ($max =~ /0x/i ? "" : "U") . "\n";
my $h = $this{argparams};
$h->{$arg} = { "min" => $min,
"max" => $max,
"elsize" => $elsize =~ /^0x/ ? hex $elsize : $elsize,
"discontig" => \@discontig };
$this{discontig} = $arg if @discontig;
next if $#{$this{args}} + 1 != scalar keys %{$this{argparams}};
my $reg_formula = "$this{addr}";
my $lim_formula;
chop $reg_formula;
$reg_formula = "(" . $reg_formula if $this{flagstring} ne "";
foreach my $arg (@{$this{args}}) {
my $d = $h->{$arg}->{discontig};
my $times = $h->{$arg}->{elsize} != 1 ?
" * " . $h->{$arg}->{elsize} : "";
if (@$d) {
my ($lim, $offset) = split /,/, $d->[0];
$reg_formula .= " + (($arg) < $lim ? ($arg)$times : $offset + (($arg) - $lim)$times)";
} else {
$reg_formula .= " + ($arg)$times";
}
$lim_formula .= (defined $lim_formula ? " + " : "") . "($arg)$times";
}
$reg_formula .= ")";
$lim_formula =~ s/^\(([a-z0-9]+)\)$/$1/i;
print $H tabconv sprintf("#define %-62s %s", "CCS_R_" . (uc $this{name}) .
$this{arglist}, $reg_formula .
(($this{flagstring} eq "") ? "" :
" | " . $this{flagstring} . ")") . "\n");
print $H tabconv $hdr_data;
undef $hdr_data;
# Sort arguments in descending order by size
@{$this{sorted_args}} = sort {
$h->{$a}->{elsize} <= $h->{$b}->{elsize}
} @{$this{args}};
if (defined $this{discontig}) {
my $da = $this{argparams}->{$this{discontig}};
my ($first_discontig) = split /,/, $da->{discontig}->[0];
my $max = $da->{max};
$da->{max} = $first_discontig - 1;
print_args(\%this, "", 0);
$da->{min} = $da->{max} + 1;
$da->{max} = $max;
print_args(\%this, $first_discontig, 1);
} else {
print_args(\%this, "", 0);
}
next unless is_limit_reg $this{base_addr};
print $LH tabconv sprintf "#define %-63s%s\n",
"CCS_L_" . (uc $this{name}) . "_OFFSET(" .
(join ", ", @{$this{args}}) . ")", "($lim_formula)";
}
if (! @{$this{args}}) {
print $H tabconv($hdr_data);
undef $hdr_data;
}
next;
}
my ($name, $addr, @flags) = split /\t+/, $_;
my $args = [];
my $sp;
($name, $addr, $args) = name_split($name, $addr) if /\(.*\)/;
$name =~ s/[,\.-]/_/g;
my $flagstring = "";
my $bits = elem_bits(@flags);
if (! defined $kernel) {
$flagstring .= "| CCS_FL_16BIT " if $bits == 16;
$flagstring .= "| CCS_FL_32BIT " if $bits == 32;
}
$flagstring .= "| CCS_FL_FLOAT_IREAL " if grep /^float_ireal$/, @flags;
$flagstring .= "| CCS_FL_IREAL " if grep /^ireal$/, @flags;
$flagstring =~ s/^\| //;
$flagstring =~ s/ $//;
$flagstring = "($flagstring)" if $flagstring =~ /\|/;
my $base_addr = $addr;
$addr = "CCI_REG$bits($addr)" if defined $kernel;
if ($flagstring ne "" && !@$args) {
$addr = "($addr | $flagstring)";
$flagstring = "";
}
my $arglist = @$args ? "(" . (join ", ", @$args) . ")" : "";
$hdr_data .= sprintf "#define %-62s %s\n", "CCS_R_" . (uc $name), $addr
if !@$args;
$name =~ s/\(.*//;
%this = ( name => $name,
addr => $addr,
flagstring => $flagstring,
base_addr => $base_addr,
argparams => {},
args => $args,
arglist => $arglist,
elsize => $bits / 8,
);
if (!@$args) {
$reglist .= "\t{ CCS_R_" . (uc $name) . ", 1, 0, \"" . (lc $name) . "\", NULL },\n";
print $H tabconv $hdr_data;
undef $hdr_data;
print $LC tabconv sprintf "\t{ CCS_R_" . (uc $name) . ", " .
$this{elsize} . ", 0, \"$name\" },\n"
if is_limit_reg $this{base_addr};
}
print $LH tabconv sprintf "#define %-63s%s\n",
"CCS_L_" . (uc $this{name}), $limitcount++
if is_limit_reg $this{base_addr};
}
if (defined $A) {
print $A $argdescs, $reglist;
print $A "\t{ 0 }\n";
print $A "};\n";
}
print $H "\n#endif /* __${uc_header}__ */\n";
print $LH tabconv sprintf "#define %-63s%s\n", "CCS_L_LAST", $limitcount;
print $LH "\n#endif /* __${uc_limith}__ */\n";
print $LC "\t{ 0 } /* Guardian */\n";
print $LC "};\n";
close($R);
close($H);
close($A) if defined $A;
close($LC);
close($LH);
linux-7.2.3/Documentation/driver-api/media/drivers/contributors.rst
+131
View File
@@ -0,0 +1,131 @@
.. SPDX-License-Identifier: GPL-2.0
Contributors
============
.. note::
This documentation is outdated. There are several other DVB contributors
that aren't listed below.
Thanks go to the following people for patches and contributions:
- Michael Hunold <m.hunold@gmx.de>
- for the initial saa7146 driver and its recent overhaul
- Christian Theiss
- for his work on the initial Linux DVB driver
- Marcus Metzler <mocm@metzlerbros.de> and
Ralph Metzler <rjkm@metzlerbros.de>
- for their continuing work on the DVB driver
- Michael Holzt <kju@debian.org>
- for his contributions to the dvb-net driver
- Diego Picciani <d.picciani@novacomp.it>
- for CyberLogin for Linux which allows logging onto EON
(in case you are wondering where CyberLogin is, EON changed its login
procedure and CyberLogin is no longer used.)
- Martin Schaller <martin@smurf.franken.de>
- for patching the cable card decoder driver
- Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>
- for various fixes regarding tuning, OSD and CI stuff and his work on VDR
- Steve Brown <sbrown@cortland.com>
- for his AFC kernel thread
- Christoph Martin <martin@uni-mainz.de>
- for his LIRC infrared handler
- Andreas Oberritter <obi@linuxtv.org>,
Dennis Noermann <dennis.noermann@noernet.de>,
Felix Domke <tmbinc@elitedvb.net>,
Florian Schirmer <jolt@tuxbox.org>,
Ronny Strutz <3des@elitedvb.de>,
Wolfram Joost <dbox2@frokaschwei.de>
and all the other dbox2 people
- for many bugfixes in the generic DVB Core, frontend drivers and
their work on the dbox2 port of the DVB driver
- Oliver Endriss <o.endriss@gmx.de>
- for many bugfixes
- Andrew de Quincey <adq_dvb@lidskialf.net>
- for the tda1004x frontend driver, and various bugfixes
- Peter Schildmann <peter.schildmann@web.de>
- for the driver for the Technisat SkyStar2 PCI DVB card
- Vadim Catana <skystar@moldova.cc>,
Roberto Ragusa <r.ragusa@libero.it> and
Augusto Cardoso <augusto@carhil.net>
- for all the work for the FlexCopII chipset by B2C2,Inc.
- Davor Emard <emard@softhome.net>
- for his work on the budget drivers, the demux code,
the module unloading problems, ...
- Hans-Frieder Vogt <hfvogt@arcor.de>
- for his work on calculating and checking the crc's for the
TechnoTrend/Hauppauge DEC driver firmware
- Michael Dreher <michael@5dot1.de> and
Andreas 'randy' Weinberger
- for the support of the Fujitsu-Siemens Activy budget DVB-S
- Kenneth Aafløy <ke-aa@frisurf.no>
- for adding support for Typhoon DVB-S budget card
- Ernst Peinlich <e.peinlich@inode.at>
- for tuning/DiSEqC support for the DEC 3000-s
- Peter Beutner <p.beutner@gmx.net>
- for the IR code for the ttusb-dec driver
- Wilson Michaels <wilsonmichaels@earthlink.net>
- for the lgdt330x frontend driver, and various bugfixes
- Michael Krufky <mkrufky@linuxtv.org>
- for maintaining v4l/dvb inter-tree dependencies
- Taylor Jacob <rtjacob@earthlink.net>
- for the nxt2002 frontend driver
- Jean-Francois Thibert <jeanfrancois@sagetv.com>
- for the nxt2004 frontend driver
- Kirk Lapray <kirk.lapray@gmail.com>
- for the or51211 and or51132 frontend drivers, and
for merging the nxt2002 and nxt2004 modules into a
single nxt200x frontend driver.
(If you think you should be in this list, but you are not, drop a
line to the DVB mailing list)
linux-7.2.3/Documentation/driver-api/media/drivers/cx2341x-devel.rst
+3685
View File
File diff suppressed because it is too large Load Diff
linux-7.2.3/Documentation/driver-api/media/drivers/cx88-devel.rst
+113
View File
@@ -0,0 +1,113 @@
.. SPDX-License-Identifier: GPL-2.0
The cx88 driver
===============
Author: Gerd Hoffmann
Documentation missing at the cx88 datasheet
-------------------------------------------
MO_OUTPUT_FORMAT (0x310164)
.. code-block:: none
Previous default from DScaler: 0x1c1f0008
Digit 8: 31-28
28: PREVREMOD = 1
Digit 7: 27-24 (0xc = 12 = b1100 )
27: COMBALT = 1
26: PAL_INV_PHASE
(DScaler apparently set this to 1, resulted in sucky picture)
Digits 6,5: 23-16
25-16: COMB_RANGE = 0x1f [default] (9 bits -> max 512)
Digit 4: 15-12
15: DISIFX = 0
14: INVCBF = 0
13: DISADAPT = 0
12: NARROWADAPT = 0
Digit 3: 11-8
11: FORCE2H
10: FORCEREMD
9: NCHROMAEN
8: NREMODEN
Digit 2: 7-4
7-6: YCORE
5-4: CCORE
Digit 1: 3-0
3: RANGE = 1
2: HACTEXT
1: HSFMT
0x47 is the sync byte for MPEG-2 transport stream packets.
Datasheet incorrectly states to use 47 decimal. 188 is the length.
All DVB compliant frontends output packets with this start code.
Hauppauge WinTV cx88 IR information
-----------------------------------
The controls for the mux are GPIO [0,1] for source, and GPIO 2 for muting.
====== ======== =================================================
GPIO0 GPIO1
====== ======== =================================================
0 0 TV Audio
1 0 FM radio
0 1 Line-In
1 1 Mono tuner bypass or CD passthru (tuner specific)
====== ======== =================================================
GPIO 16(I believe) is tied to the IR port (if present).
From the data sheet:
- Register 24'h20004 PCI Interrupt Status
- bit [18] IR_SMP_INT Set when 32 input samples have been collected over
- gpio[16] pin into GP_SAMPLE register.
What's missing from the data sheet:
- Setup 4KHz sampling rate (roughly 2x oversampled; good enough for our RC5
compat remote)
- set register 0x35C050 to 0xa80a80
- enable sampling
- set register 0x35C054 to 0x5
- enable the IRQ bit 18 in the interrupt mask register (and
provide for a handler)
GP_SAMPLE register is at 0x35C058
Bits are then right shifted into the GP_SAMPLE register at the specified
rate; you get an interrupt when a full DWORD is received.
You need to recover the actual RC5 bits out of the (oversampled) IR sensor
bits. (Hint: look for the 0/1and 1/0 crossings of the RC5 bi-phase data) An
actual raw RC5 code will span 2-3 DWORDS, depending on the actual alignment.
I'm pretty sure when no IR signal is present the receiver is always in a
marking state(1); but stray light, etc can cause intermittent noise values
as well. Remember, this is a free running sample of the IR receiver state
over time, so don't assume any sample starts at any particular place.
Additional info
~~~~~~~~~~~~~~~
This data sheet (google search) seems to have a lovely description of the
RC5 basics:
http://www.atmel.com/dyn/resources/prod_documents/doc2817.pdf
This document has more data:
http://www.nenya.be/beor/electronics/rc5.htm
This document has a how to decode a bi-phase data stream:
http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt
This document has still more info:
http://www.xs4all.nl/~sbp/knowledge/ir/rc5.htm
linux-7.2.3/Documentation/driver-api/media/drivers/dvb-usb.rst
+357
View File
@@ -0,0 +1,357 @@
.. SPDX-License-Identifier: GPL-2.0
Idea behind the dvb-usb-framework
=================================
.. note::
#) This documentation is outdated. Please check at the DVB wiki
at https://linuxtv.org/wiki for more updated info.
#) **deprecated:** Newer DVB USB drivers should use the dvb-usb-v2 framework.
In March 2005 I got the new Twinhan USB2.0 DVB-T device. They provided specs
and a firmware.
Quite keen I wanted to put the driver (with some quirks of course) into dibusb.
After reading some specs and doing some USB snooping, it realized, that the
dibusb-driver would be a complete mess afterwards. So I decided to do it in a
different way: With the help of a dvb-usb-framework.
The framework provides generic functions (mostly kernel API calls), such as:
- Transport Stream URB handling in conjunction with dvb-demux-feed-control
(bulk and isoc are supported)
- registering the device for the DVB-API
- registering an I2C-adapter if applicable
- remote-control/input-device handling
- firmware requesting and loading (currently just for the Cypress USB
controllers)
- other functions/methods which can be shared by several drivers (such as
functions for bulk-control-commands)
- TODO: a I2C-chunker. It creates device-specific chunks of register-accesses
depending on length of a register and the number of values that can be
multi-written and multi-read.
The source code of the particular DVB USB devices does just the communication
with the device via the bus. The connection between the DVB-API-functionality
is done via callbacks, assigned in a static device-description (struct
dvb_usb_device) each device-driver has to have.
For an example have a look in drivers/media/usb/dvb-usb/vp7045*.
Objective is to migrate all the usb-devices (dibusb, cinergyT2, maybe the
ttusb; flexcop-usb already benefits from the generic flexcop-device) to use
the dvb-usb-lib.
TODO: dynamic enabling and disabling of the pid-filter in regard to number of
feeds requested.
Supported devices
-----------------
See the LinuxTV DVB Wiki at https://linuxtv.org for a complete list of
cards/drivers/firmwares:
https://linuxtv.org/wiki/index.php/DVB_USB
0. History & News:
2005-06-30
- added support for WideView WT-220U (Thanks to Steve Chang)
2005-05-30
- added basic isochronous support to the dvb-usb-framework
- added support for Conexant Hybrid reference design and Nebula
DigiTV USB
2005-04-17
- all dibusb devices ported to make use of the dvb-usb-framework
2005-04-02
- re-enabled and improved remote control code.
2005-03-31
- ported the Yakumo/Hama/Typhoon DVB-T USB2.0 device to dvb-usb.
2005-03-30
- first commit of the dvb-usb-module based on the dibusb-source.
First device is a new driver for the
TwinhanDTV Alpha / MagicBox II USB2.0-only DVB-T device.
- (change from dvb-dibusb to dvb-usb)
2005-03-28
- added support for the AVerMedia AverTV DVB-T USB2.0 device
(Thanks to Glen Harris and Jiun-Kuei Jung, AVerMedia)
2005-03-14
- added support for the Typhoon/Yakumo/HAMA DVB-T mobile USB2.0
2005-02-11
- added support for the KWorld/ADSTech Instant DVB-T USB2.0.
Thanks a lot to Joachim von Caron
2005-02-02
- added support for the Hauppauge Win-TV Nova-T USB2
2005-01-31
- distorted streaming is gone for USB1.1 devices
2005-01-13
- moved the mirrored pid_filter_table back to dvb-dibusb
first almost working version for HanfTek UMT-010
found out, that Yakumo/HAMA/Typhoon are predecessors of the HanfTek UMT-010
2005-01-10
- refactoring completed, now everything is very delightful
- tuner quirks for some weird devices (Artec T1 AN2235 device has sometimes a
Panasonic Tuner assembled). Tunerprobing implemented.
Thanks a lot to Gunnar Wittich.
2004-12-29
- after several days of struggling around bug of no returning URBs fixed.
2004-12-26
- refactored the dibusb-driver, split into separate files
- i2c-probing enabled
2004-12-06
- possibility for demod i2c-address probing
- new usb IDs (Compro, Artec)
2004-11-23
- merged changes from DiB3000MC_ver2.1
- revised the debugging
- possibility to deliver the complete TS for USB2.0
2004-11-21
- first working version of the dib3000mc/p frontend driver.
2004-11-12
- added additional remote control keys. Thanks to Uwe Hanke.
2004-11-07
- added remote control support. Thanks to David Matthews.
2004-11-05
- added support for a new devices (Grandtec/Avermedia/Artec)
- merged my changes (for dib3000mb/dibusb) to the FE_REFACTORING, because it became HEAD
- moved transfer control (pid filter, fifo control) from usb driver to frontend, it seems
better settled there (added xfer_ops-struct)
- created a common files for frontends (mc/p/mb)
2004-09-28
- added support for a new device (Unknown, vendor ID is Hyper-Paltek)
2004-09-20
- added support for a new device (Compro DVB-U2000), thanks
to Amaury Demol for reporting
- changed usb TS transfer method (several urbs, stopping transfer
before setting a new pid)
2004-09-13
- added support for a new device (Artec T1 USB TVBOX), thanks
to Christian Motschke for reporting
2004-09-05
- released the dibusb device and dib3000mb-frontend driver
(old news for vp7041.c)
2004-07-15
- found out, by accident, that the device has a TUA6010XS for PLL
2004-07-12
- figured out, that the driver should also work with the
CTS Portable (Chinese Television System)
2004-07-08
- firmware-extraction-2.422-problem solved, driver is now working
properly with firmware extracted from 2.422
- #if for 2.6.4 (dvb), compile issue
- changed firmware handling, see vp7041.txt sec 1.1
2004-07-02
- some tuner modifications, v0.1, cleanups, first public
2004-06-28
- now using the dvb_dmx_swfilter_packets, everything runs fine now
2004-06-27
- able to watch and switching channels (pre-alpha)
- no section filtering yet
2004-06-06
- first TS received, but kernel oops :/
2004-05-14
- firmware loader is working
2004-05-11
- start writing the driver
How to use?
-----------
Firmware
~~~~~~~~
Most of the USB drivers need to download a firmware to the device before start
working.
Have a look at the Wikipage for the DVB-USB-drivers to find out, which firmware
you need for your device:
https://linuxtv.org/wiki/index.php/DVB_USB
Compiling
~~~~~~~~~
Since the driver is in the linux kernel, activating the driver in
your favorite config-environment should sufficient. I recommend
to compile the driver as module. Hotplug does the rest.
If you use dvb-kernel enter the build-2.6 directory run 'make' and 'insmod.sh
load' afterwards.
Loading the drivers
~~~~~~~~~~~~~~~~~~~
Hotplug is able to load the driver, when it is needed (because you plugged
in the device).
If you want to enable debug output, you have to load the driver manually and
from within the dvb-kernel cvs repository.
first have a look, which debug level are available:
.. code-block:: none
# modinfo dvb-usb
# modinfo dvb-usb-vp7045
etc.
.. code-block:: none
modprobe dvb-usb debug=<level>
modprobe dvb-usb-vp7045 debug=<level>
etc.
should do the trick.
When the driver is loaded successfully, the firmware file was in
the right place and the device is connected, the "Power"-LED should be
turned on.
At this point you should be able to start a dvb-capable application. I'm use
(t|s)zap, mplayer and dvbscan to test the basics. VDR-xine provides the
long-term test scenario.
Known problems and bugs
-----------------------
- Don't remove the USB device while running an DVB application, your system
will go crazy or die most likely.
Adding support for devices
~~~~~~~~~~~~~~~~~~~~~~~~~~
TODO
USB1.1 Bandwidth limitation
~~~~~~~~~~~~~~~~~~~~~~~~~~~
A lot of the currently supported devices are USB1.1 and thus they have a
maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub.
This is not enough for receiving the complete transport stream of a
DVB-T channel (which is about 16 MBit/s). Normally this is not a
problem, if you only want to watch TV (this does not apply for HDTV),
but watching a channel while recording another channel on the same
frequency simply does not work very well. This applies to all USB1.1
DVB-T devices, not just the dvb-usb-devices)
The bug, where the TS is distorted by a heavy usage of the device is gone
definitely. All dvb-usb-devices I was using (Twinhan, Kworld, DiBcom) are
working like charm now with VDR. Sometimes I even was able to record a channel
and watch another one.
Comments
~~~~~~~~
Patches, comments and suggestions are very very welcome.
3. Acknowledgements
-------------------
Amaury Demol (Amaury.Demol@parrot.com) and Francois Kanounnikoff from DiBcom for
providing specs, code and help, on which the dvb-dibusb, dib3000mb and
dib3000mc are based.
David Matthews for identifying a new device type (Artec T1 with AN2235)
and for extending dibusb with remote control event handling. Thank you.
Alex Woods for frequently answering question about usb and dvb
stuff, a big thank you.
Bernd Wagner for helping with huge bug reports and discussions.
Gunnar Wittich and Joachim von Caron for their trust for providing
root-shells on their machines to implement support for new devices.
Allan Third and Michael Hutchinson for their help to write the Nebula
digitv-driver.
Glen Harris for bringing up, that there is a new dibusb-device and Jiun-Kuei
Jung from AVerMedia who kindly provided a special firmware to get the device
up and running in Linux.
Jennifer Chen, Jeff and Jack from Twinhan for kindly supporting by
writing the vp7045-driver.
Steve Chang from WideView for providing information for new devices and
firmware files.
Michael Paxton for submitting remote control keymaps.
Some guys on the linux-dvb mailing list for encouraging me.
Peter Schildmann >peter.schildmann-nospam-at-web.de< for his
user-level firmware loader, which saves a lot of time
(when writing the vp7041 driver)
Ulf Hermenau for helping me out with traditional chinese.
André Smoktun and Christian Frömmel for supporting me with
hardware and listening to my problems very patiently.
linux-7.2.3/Documentation/driver-api/media/drivers/fimc-devel.rst
+33
View File
@@ -0,0 +1,33 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
The Samsung S5P/EXYNOS4 FIMC driver
===================================
Copyright |copy| 2012 - 2013 Samsung Electronics Co., Ltd.
Files partitioning
------------------
- media device driver
drivers/media/platform/samsung/exynos4-is/media-dev.[ch]
- camera capture video device driver
drivers/media/platform/samsung/exynos4-is/fimc-capture.c
- MIPI-CSI2 receiver subdev
drivers/media/platform/samsung/exynos4-is/mipi-csis.[ch]
- video post-processor (mem-to-mem)
drivers/media/platform/samsung/exynos4-is/fimc-core.c
- common files
drivers/media/platform/samsung/exynos4-is/fimc-core.h
drivers/media/platform/samsung/exynos4-is/fimc-reg.h
drivers/media/platform/samsung/exynos4-is/regs-fimc.h
linux-7.2.3/Documentation/driver-api/media/drivers/frontends.rst
+32
View File
@@ -0,0 +1,32 @@
.. SPDX-License-Identifier: GPL-2.0
****************
Frontend drivers
****************
Frontend attach headers
***********************
.. Keep it on alphabetic order
.. kernel-doc:: drivers/media/dvb-frontends/a8293.h
.. kernel-doc:: drivers/media/dvb-frontends/af9013.h
.. kernel-doc:: drivers/media/dvb-frontends/ascot2e.h
.. kernel-doc:: drivers/media/dvb-frontends/cxd2820r.h
.. kernel-doc:: drivers/media/dvb-frontends/drxk.h
.. kernel-doc:: drivers/media/dvb-frontends/dvb-pll.h
.. kernel-doc:: drivers/media/dvb-frontends/helene.h
.. kernel-doc:: drivers/media/dvb-frontends/horus3a.h
.. kernel-doc:: drivers/media/dvb-frontends/ix2505v.h
.. kernel-doc:: drivers/media/dvb-frontends/m88ds3103.h
.. kernel-doc:: drivers/media/dvb-frontends/mb86a20s.h
.. kernel-doc:: drivers/media/dvb-frontends/mn88472.h
.. kernel-doc:: drivers/media/dvb-frontends/rtl2830.h
.. kernel-doc:: drivers/media/dvb-frontends/rtl2832.h
.. kernel-doc:: drivers/media/dvb-frontends/rtl2832_sdr.h
.. kernel-doc:: drivers/media/dvb-frontends/stb6000.h
.. kernel-doc:: drivers/media/dvb-frontends/tda10071.h
.. kernel-doc:: drivers/media/dvb-frontends/tda826x.h
.. kernel-doc:: drivers/media/dvb-frontends/zd1301_demod.h
.. kernel-doc:: drivers/media/dvb-frontends/zl10036.h
linux-7.2.3/Documentation/driver-api/media/drivers/index.rst
+41
View File
@@ -0,0 +1,41 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
===================================
Media driver-specific documentation
===================================
Video4Linux (V4L) drivers
=========================
.. toctree::
:maxdepth: 5
bttv-devel
cx2341x-devel
cx88-devel
fimc-devel
pvrusb2
pxa_camera
radiotrack
rkisp1
saa7134-devel
sh_mobile_ceu_camera
tuners
vimc-devel
zoran
ccs/ccs
ipu6
Digital TV drivers
==================
.. toctree::
:maxdepth: 5
dvb-usb
frontends
vidtv
contributors
linux-7.2.3/Documentation/driver-api/media/drivers/ipu6.rst
+190
View File
@@ -0,0 +1,190 @@
.. SPDX-License-Identifier: GPL-2.0
==================
Intel IPU6 Driver
==================
Author: Bingbu Cao <bingbu.cao@intel.com>
Overview
=========
Intel IPU6 is the sixth generation of Intel Image Processing Unit used in some
Intel Chipsets such as Tiger Lake, Jasper Lake, Alder Lake, Raptor Lake and
Meteor Lake. IPU6 consists of two major systems: Input System (ISYS) and
Processing System (PSYS). IPU6 are visible on the PCI bus as a single device, it
can be found by ``lspci``:
``0000:00:05.0 Multimedia controller: Intel Corporation Device xxxx (rev xx)``
IPU6 has a 16 MB BAR in PCI configuration Space for MMIO registers which is
visible for driver.
Buttress
=========
The IPU6 is connecting to the system fabric with Buttress which is enabling host
driver to control the IPU6, it also allows IPU6 access the system memory to
store and load frame pixel streams and any other metadata.
Buttress mainly manages several system functionalities: power management,
interrupt handling, firmware authentication and global timer sync.
ISYS and PSYS Power flow
------------------------
IPU6 driver initialize the ISYS and PSYS power up or down request by setting the
Buttress frequency control register for ISYS and PSYS
(``IPU6_BUTTRESS_REG_IS_FREQ_CTL`` and ``IPU6_BUTTRESS_REG_PS_FREQ_CTL``) in
function:
.. c:function:: int ipu6_buttress_power(...)
Buttress forwards the request to Punit, after Punit execute the power up flow,
Buttress indicates driver that ISYS or PSYS is powered up by updating the power
status registers.
.. Note:: ISYS power up needs take place prior to PSYS power up, ISYS power down
needs take place after PSYS power down due to hardware limitation.
Interrupt
---------
IPU6 interrupt can be generated as MSI or INTA, interrupt will be triggered when
ISYS, PSYS, Buttress event or error happen, driver can get the interrupt cause
by reading the interrupt status register ``BUTTRESS_REG_ISR_STATUS``, driver
clears the irq status and then calls specific ISYS or PSYS irq handler.
.. c:function:: irqreturn_t ipu6_buttress_isr(int irq, ...)
Security and firmware authentication
-------------------------------------
To address the IPU6 firmware security concerns, the IPU6 firmware needs to
undergo an authentication process before it is allowed to executed on the IPU6
internal processors. The IPU6 driver will work with Converged Security Engine
(CSE) to complete authentication process. The CSE is responsible of
authenticating the IPU6 firmware. The authenticated firmware binary is copied
into an isolated memory region. Firmware authentication process is implemented
by CSE following an IPC handshake with the IPU6 driver. There are some Buttress
registers used by the CSE and the IPU6 driver to communicate with each other via
IPC.
.. c:function:: int ipu6_buttress_authenticate(...)
Global timer sync
-----------------
The IPU6 driver initiates a Hammock Harbor synchronization flow each time it
starts camera operation. The IPU6 will synchronizes an internal counter in the
Buttress with a copy of the SoC time, this counter maintains the up-to-date time
until camera operation is stopped. The IPU6 driver can use this time counter to
calibrate the timestamp based on the timestamp in response event from firmware.
.. c:function:: int ipu6_buttress_start_tsc_sync(...)
DMA and MMU
============
The IPU6 has its own scalar processor where the firmware run at and an internal
32-bit virtual address space. The IPU6 has MMU address translation hardware to
allow that scalar processors to access the internal memory and external system
memory through IPU6 virtual address. The address translation is based on two
levels of page lookup tables stored in system memory which are maintained by the
IPU6 driver. The IPU6 driver sets the level-1 page table base address to MMU
register and allows MMU to perform page table lookups.
The IPU6 driver exports its own DMA operations. The IPU6 driver will update the
page table entries for each DMA operation and invalidate the MMU TLB after each
unmap and free.
Firmware file format
====================
The IPU6 firmware is in Code Partition Directory (CPD) file format. The CPD
firmware contains a CPD header, several CPD entries and components. The CPD
component includes 3 entries - manifest, metadata and module data. Manifest and
metadata are defined by CSE and used by CSE for authentication. Module data is
specific to IPU6 which holds the binary data of firmware called package
directory. The IPU6 driver (``ipu6-cpd.c`` in particular) parses and validates
the CPD firmware file and gets the package directory binary data of the IPU6
firmware, copies it to specific DMA buffer and sets its base address to Buttress
``FW_SOURCE_BASE`` register. Finally the CSE will do authentication for this
firmware binary.
Syscom interface
================
The IPU6 driver communicates with firmware via the Syscom ABI. Syscom is an
inter-processor communication mechanism between the IPU scalar processors and
the CPU. There are a number of resources shared between firmware and software.
A system memory region where the message queues reside, firmware can access the
memory region via the IPU MMU. The Syscom queues are FIFO fixed depth queues
with a configurable number of tokens (messages). There are also common IPU6 MMIO
registers where the queue read and write indices reside. Software and firmware
function as producer and consumer of tokens in the queues and update the write
and read indices separately when sending or receiving each message.
The IPU6 driver must prepare and configure the number of input and output
queues, configure the count of tokens per queue and the size of per token before
initiating and starting the communication with firmware. Firmware and software
must use same configurations. The IPU6 Buttress has a number of firmware boot
parameter registers which can be used to store the address of configuration and
initialise the Syscom state, then driver can request firmware to start and run via
setting the scalar processor control status register.
Input System
============
IPU6 input system consists of MIPI D-PHY and several CSI-2 receivers. It can
capture image pixel data from camera sensors or other MIPI CSI-2 output devices.
D-PHYs and CSI-2 ports lane mapping
-----------------------------------
The IPU6 integrates different D-PHY IPs on different SoCs, on Tiger Lake and
Alder Lake, IPU6 integrates MCD10 D-PHY, IPU6SE on Jasper Lake integrates JSL
D-PHY and IPU6EP on Meteor Lake integrates a Synopsys DWC D-PHY. There is an
adaptional layer between D-PHY and CSI-2 receiver controller which includes port
configuration, PHY wrapper or private test interfaces for D-PHY. There are 3
D-PHY drivers ``ipu6-isys-mcd-phy.c``, ``ipu6-isys-jsl-phy.c`` and
``ipu6-isys-dwc-phy.c`` program the above 3 D-PHYs in IPU6.
Different IPU6 versions have different D-PHY lanes mappings, On Tiger Lake,
there are 12 data lanes and 8 clock lanes, IPU6 support maximum 8 CSI-2 ports,
see the PPI mmapping in ``ipu6-isys-mcd-phy.c`` for more information. On Jasper
Lake and Alder Lake, D-PHY has 8 data lanes and 4 clock lanes, the IPU6 supports
maximum 4 CSI-2 ports. For Meteor Lake, D-PHY has 12 data lanes and 6 clock
lanes so IPU6 support maximum 6 CSI-2 ports.
.. Note:: Each pair of CSI-2 two ports is a single unit that can share the data
lanes. For example, for CSI-2 port 0 and 1, CSI-2 port 0 support
maximum 4 data lanes, CSI-2 port 1 support maximum 2 data lanes, CSI-2
port 0 with 2 data lanes can work together with CSI-2 port 1 with 2
data lanes. If trying to use CSI-2 port 0 with 4 lanes, CSI-2 port 1
will not be available as the 4 data lanes are shared by CSI-2 port 0
and 1. The same applies to CSI ports 2/3, 4/5 and 7/8.
ISYS firmware ABIs
------------------
The IPU6 firmware implements a series of ABIs for software access. In general,
software firstly prepares the stream configuration ``struct
ipu6_fw_isys_stream_cfg_data_abi`` and sends the configuration to firmware via
sending ``STREAM_OPEN`` command. Stream configuration includes input pins and
output pins, input pin ``struct ipu6_fw_isys_input_pin_info_abi`` defines the
resolution and data type of input source, output pin ``struct
ipu6_fw_isys_output_pin_info_abi`` defines the output resolution, stride and
frame format, etc.
Once the driver gets the interrupt from firmware that indicates stream open
successfully, the driver will send the ``STREAM_START`` and ``STREAM_CAPTURE``
command to request firmware to start capturing image frames. ``STREAM_CAPTURE``
command queues the buffers to firmware with ``struct
ipu6_fw_isys_frame_buff_set``, software then waits for the interrupt and
response from firmware, ``PIN_DATA_READY`` means a buffer is ready on a specific
output pin and then software can return the buffer to user.
.. Note:: See :ref:`Examples<ipu6_isys_capture_examples>` about how to do
capture by IPU6 ISYS driver.
linux-7.2.3/Documentation/driver-api/media/drivers/pvrusb2.rst
+202
View File
@@ -0,0 +1,202 @@
.. SPDX-License-Identifier: GPL-2.0
The pvrusb2 driver
==================
Author: Mike Isely <isely@pobox.com>
Background
----------
This driver is intended for the "Hauppauge WinTV PVR USB 2.0", which
is a USB 2.0 hosted TV Tuner. This driver is a work in progress.
Its history started with the reverse-engineering effort by Björn
Danielsson <pvrusb2@dax.nu> whose web page can be found here:
http://pvrusb2.dax.nu/
From there Aurelien Alleaume <slts@free.fr> began an effort to
create a video4linux compatible driver. I began with Aurelien's
last known snapshot and evolved the driver to the state it is in
here.
More information on this driver can be found at:
https://www.isely.net/pvrusb2.html
This driver has a strong separation of layers. They are very
roughly:
1. Low level wire-protocol implementation with the device.
2. I2C adaptor implementation and corresponding I2C client drivers
implemented elsewhere in V4L.
3. High level hardware driver implementation which coordinates all
activities that ensure correct operation of the device.
4. A "context" layer which manages instancing of driver, setup,
tear-down, arbitration, and interaction with high level
interfaces appropriately as devices are hotplugged in the
system.
5. High level interfaces which glue the driver to various published
Linux APIs (V4L, sysfs, maybe DVB in the future).
The most important shearing layer is between the top 2 layers. A
lot of work went into the driver to ensure that any kind of
conceivable API can be laid on top of the core driver. (Yes, the
driver internally leverages V4L to do its work but that really has
nothing to do with the API published by the driver to the outside
world.) The architecture allows for different APIs to
simultaneously access the driver. I have a strong sense of fairness
about APIs and also feel that it is a good design principle to keep
implementation and interface isolated from each other. Thus while
right now the V4L high level interface is the most complete, the
sysfs high level interface will work equally well for similar
functions, and there's no reason I see right now why it shouldn't be
possible to produce a DVB high level interface that can sit right
alongside V4L.
Building
--------
To build these modules essentially amounts to just running "Make",
but you need the kernel source tree nearby and you will likely also
want to set a few controlling environment variables first in order
to link things up with that source tree. Please see the Makefile
here for comments that explain how to do that.
Source file list / functional overview
--------------------------------------
(Note: The term "module" used below generally refers to loosely
defined functional units within the pvrusb2 driver and bears no
relation to the Linux kernel's concept of a loadable module.)
pvrusb2-audio.[ch] - This is glue logic that resides between this
driver and the msp3400.ko I2C client driver (which is found
elsewhere in V4L).
pvrusb2-context.[ch] - This module implements the context for an
instance of the driver. Everything else eventually ties back to
or is otherwise instanced within the data structures implemented
here. Hotplugging is ultimately coordinated here. All high level
interfaces tie into the driver through this module. This module
helps arbitrate each interface's access to the actual driver core,
and is designed to allow concurrent access through multiple
instances of multiple interfaces (thus you can for example change
the tuner's frequency through sysfs while simultaneously streaming
video through V4L out to an instance of mplayer).
pvrusb2-debug.h - This header defines a printk() wrapper and a mask
of debugging bit definitions for the various kinds of debug
messages that can be enabled within the driver.
pvrusb2-debugifc.[ch] - This module implements a crude command line
oriented debug interface into the driver. Aside from being part
of the process for implementing manual firmware extraction (see
the pvrusb2 web site mentioned earlier), probably I'm the only one
who has ever used this. It is mainly a debugging aid.
pvrusb2-eeprom.[ch] - This is glue logic that resides between this
driver the tveeprom.ko module, which is itself implemented
elsewhere in V4L.
pvrusb2-encoder.[ch] - This module implements all protocol needed to
interact with the Conexant mpeg2 encoder chip within the pvrusb2
device. It is a crude echo of corresponding logic in ivtv,
however the design goals (strict isolation) and physical layer
(proxy through USB instead of PCI) are enough different that this
implementation had to be completely different.
pvrusb2-hdw-internal.h - This header defines the core data structure
in the driver used to track ALL internal state related to control
of the hardware. Nobody outside of the core hardware-handling
modules should have any business using this header. All external
access to the driver should be through one of the high level
interfaces (e.g. V4L, sysfs, etc), and in fact even those high
level interfaces are restricted to the API defined in
pvrusb2-hdw.h and NOT this header.
pvrusb2-hdw.h - This header defines the full internal API for
controlling the hardware. High level interfaces (e.g. V4L, sysfs)
will work through here.
pvrusb2-hdw.c - This module implements all the various bits of logic
that handle overall control of a specific pvrusb2 device.
(Policy, instantiation, and arbitration of pvrusb2 devices fall
within the jurisdiction of pvrusb-context not here).
pvrusb2-i2c-chips-\*.c - These modules implement the glue logic to
tie together and configure various I2C modules as they attach to
the I2C bus. There are two versions of this file. The "v4l2"
version is intended to be used in-tree alongside V4L, where we
implement just the logic that makes sense for a pure V4L
environment. The "all" version is intended for use outside of
V4L, where we might encounter other possibly "challenging" modules
from ivtv or older kernel snapshots (or even the support modules
in the standalone snapshot).
pvrusb2-i2c-cmd-v4l1.[ch] - This module implements generic V4L1
compatible commands to the I2C modules. It is here where state
changes inside the pvrusb2 driver are translated into V4L1
commands that are in turn send to the various I2C modules.
pvrusb2-i2c-cmd-v4l2.[ch] - This module implements generic V4L2
compatible commands to the I2C modules. It is here where state
changes inside the pvrusb2 driver are translated into V4L2
commands that are in turn send to the various I2C modules.
pvrusb2-i2c-core.[ch] - This module provides an implementation of a
kernel-friendly I2C adaptor driver, through which other external
I2C client drivers (e.g. msp3400, tuner, lirc) may connect and
operate corresponding chips within the pvrusb2 device. It is
through here that other V4L modules can reach into this driver to
operate specific pieces (and those modules are in turn driven by
glue logic which is coordinated by pvrusb2-hdw, doled out by
pvrusb2-context, and then ultimately made available to users
through one of the high level interfaces).
pvrusb2-io.[ch] - This module implements a very low level ring of
transfer buffers, required in order to stream data from the
device. This module is *very* low level. It only operates the
buffers and makes no attempt to define any policy or mechanism for
how such buffers might be used.
pvrusb2-ioread.[ch] - This module layers on top of pvrusb2-io.[ch]
to provide a streaming API usable by a read() system call style of
I/O. Right now this is the only layer on top of pvrusb2-io.[ch],
however the underlying architecture here was intended to allow for
other styles of I/O to be implemented with additional modules, like
mmap()'ed buffers or something even more exotic.
pvrusb2-main.c - This is the top level of the driver. Module level
and USB core entry points are here. This is our "main".
pvrusb2-sysfs.[ch] - This is the high level interface which ties the
pvrusb2 driver into sysfs. Through this interface you can do
everything with the driver except actually stream data.
pvrusb2-tuner.[ch] - This is glue logic that resides between this
driver and the tuner.ko I2C client driver (which is found
elsewhere in V4L).
pvrusb2-util.h - This header defines some common macros used
throughout the driver. These macros are not really specific to
the driver, but they had to go somewhere.
pvrusb2-v4l2.[ch] - This is the high level interface which ties the
pvrusb2 driver into video4linux. It is through here that V4L
applications can open and operate the driver in the usual V4L
ways. Note that **ALL** V4L functionality is published only
through here and nowhere else.
pvrusb2-video-\*.[ch] - This is glue logic that resides between this
driver and the saa711x.ko I2C client driver (which is found
elsewhere in V4L). Note that saa711x.ko used to be known as
saa7115.ko in ivtv. There are two versions of this; one is
selected depending on the particular saa711[5x].ko that is found.
pvrusb2.h - This header contains compile time tunable parameters
(and at the moment the driver has very little that needs to be
tuned).
linux-7.2.3/Documentation/driver-api/media/drivers/pxa_camera.rst
+194
View File
@@ -0,0 +1,194 @@
.. SPDX-License-Identifier: GPL-2.0
PXA-Camera Host Driver
======================
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Constraints
-----------
a) Image size for YUV422P format
All YUV422P images are enforced to have width x height % 16 = 0.
This is due to DMA constraints, which transfers only planes of 8 byte
multiples.
Global video workflow
---------------------
a) QCI stopped
Initially, the QCI interface is stopped.
When a buffer is queued, start_streaming is called and the QCI starts.
b) QCI started
More buffers can be queued while the QCI is started without halting the
capture. The new buffers are "appended" at the tail of the DMA chain, and
smoothly captured one frame after the other.
Once a buffer is filled in the QCI interface, it is marked as "DONE" and
removed from the active buffers list. It can be then requeud or dequeued by
userland application.
Once the last buffer is filled in, the QCI interface stops.
c) Capture global finite state machine schema
.. code-block:: none
+----+ +---+ +----+
| DQ | | Q | | DQ |
| v | v | v
+-----------+ +------------------------+
| STOP | | Wait for capture start |
+-----------+ Q +------------------------+
+-> | QCI: stop | ------------------> | QCI: run | <------------+
| | DMA: stop | | DMA: stop | |
| +-----------+ +-----> +------------------------+ |
| / | |
| / +---+ +----+ | |
|capture list empty / | Q | | DQ | | QCI Irq EOF |
| / | v | v v |
| +--------------------+ +----------------------+ |
| | DMA hotlink missed | | Capture running | |
| +--------------------+ +----------------------+ |
| | QCI: run | +-----> | QCI: run | <-+ |
| | DMA: stop | / | DMA: run | | |
| +--------------------+ / +----------------------+ | Other |
| ^ /DMA still | | channels |
| | capture list / running | DMA Irq End | not |
| | not empty / | | finished |
| | / v | yet |
| +----------------------+ +----------------------+ | |
| | Videobuf released | | Channel completed | | |
| +----------------------+ +----------------------+ | |
+-- | QCI: run | | QCI: run | --+ |
| DMA: run | | DMA: run | |
+----------------------+ +----------------------+ |
^ / | |
| no overrun / | overrun |
| / v |
+--------------------+ / +----------------------+ |
| Frame completed | / | Frame overran | |
+--------------------+ <-----+ +----------------------+ restart frame |
| QCI: run | | QCI: stop | --------------+
| DMA: run | | DMA: stop |
+--------------------+ +----------------------+
Legend: - each box is a FSM state
- each arrow is the condition to transition to another state
- an arrow with a comment is a mandatory transition (no condition)
- arrow "Q" means : a buffer was enqueued
- arrow "DQ" means : a buffer was dequeued
- "QCI: stop" means the QCI interface is not enabled
- "DMA: stop" means all 3 DMA channels are stopped
- "DMA: run" means at least 1 DMA channel is still running
DMA usage
---------
a) DMA flow
- first buffer queued for capture
Once a first buffer is queued for capture, the QCI is started, but data
transfer is not started. On "End Of Frame" interrupt, the irq handler
starts the DMA chain.
- capture of one videobuffer
The DMA chain starts transferring data into videobuffer RAM pages.
When all pages are transferred, the DMA irq is raised on "ENDINTR" status
- finishing one videobuffer
The DMA irq handler marks the videobuffer as "done", and removes it from
the active running queue
Meanwhile, the next videobuffer (if there is one), is transferred by DMA
- finishing the last videobuffer
On the DMA irq of the last videobuffer, the QCI is stopped.
b) DMA prepared buffer will have this structure
.. code-block:: none
+------------+-----+---------------+-----------------+
| desc-sg[0] | ... | desc-sg[last] | finisher/linker |
+------------+-----+---------------+-----------------+
This structure is pointed by dma->sg_cpu.
The descriptors are used as follows:
- desc-sg[i]: i-th descriptor, transferring the i-th sg
element to the video buffer scatter gather
- finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
- linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0
For the next schema, let's assume d0=desc-sg[0] .. dN=desc-sg[N],
"f" stands for finisher and "l" for linker.
A typical running chain is :
.. code-block:: none
Videobuffer 1 Videobuffer 2
+---------+----+---+ +----+----+----+---+
| d0 | .. | dN | l | | d0 | .. | dN | f |
+---------+----+-|-+ ^----+----+----+---+
| |
+----+
After the chaining is finished, the chain looks like :
.. code-block:: none
Videobuffer 1 Videobuffer 2 Videobuffer 3
+---------+----+---+ +----+----+----+---+ +----+----+----+---+
| d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
+---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
| | | |
+----+ +----+
new_link
c) DMA hot chaining timeslice issue
As DMA chaining is done while DMA _is_ running, the linking may be done
while the DMA jumps from one Videobuffer to another. On the schema, that
would be a problem if the following sequence is encountered :
- DMA chain is Videobuffer1 + Videobuffer2
- pxa_videobuf_queue() is called to queue Videobuffer3
- DMA controller finishes Videobuffer2, and DMA stops
.. code-block:: none
=>
Videobuffer 1 Videobuffer 2
+---------+----+---+ +----+----+----+---+
| d0 | .. | dN | l | | d0 | .. | dN | f |
+---------+----+-|-+ ^----+----+----+-^-+
| | |
+----+ +-- DMA DDADR loads DDADR_STOP
- pxa_dma_add_tail_buf() is called, the Videobuffer2 "finisher" is
replaced by a "linker" to Videobuffer3 (creation of new_link)
- pxa_videobuf_queue() finishes
- the DMA irq handler is called, which terminates Videobuffer2
- Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!)
.. code-block:: none
Videobuffer 1 Videobuffer 2 Videobuffer 3
+---------+----+---+ +----+----+----+---+ +----+----+----+---+
| d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
+---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
| | | |
+----+ +----+
new_link
DMA DDADR still is DDADR_STOP
- pxa_camera_check_link_miss() is called
This checks if the DMA is finished and a buffer is still on the
pcdev->capture list. If that's the case, the capture will be restarted,
and Videobuffer3 is scheduled on DMA chain.
- the DMA irq handler finishes
.. note::
If DMA stops just after pxa_camera_check_link_miss() reads DDADR()
value, we have the guarantee that the DMA irq handler will be called back
when the DMA will finish the buffer, and pxa_camera_check_link_miss() will
be called again, to reschedule Videobuffer3.
linux-7.2.3/Documentation/driver-api/media/drivers/radiotrack.rst
+168
View File
@@ -0,0 +1,168 @@
.. SPDX-License-Identifier: GPL-2.0
The Radiotrack radio driver
===========================
Author: Stephen M. Benoit <benoits@servicepro.com>
Date: Dec 14, 1996
ACKNOWLEDGMENTS
----------------
This document was made based on 'C' code for Linux from Gideon le Grange
(legrang@active.co.za or legrang@cs.sun.ac.za) in 1994, and elaborations from
Frans Brinkman (brinkman@esd.nl) in 1996. The results reported here are from
experiments that the author performed on his own setup, so your mileage may
vary... I make no guarantees, claims or warranties to the suitability or
validity of this information. No other documentation on the AIMS
Lab (http://www.aimslab.com/) RadioTrack card was made available to the
author. This document is offered in the hopes that it might help users who
want to use the RadioTrack card in an environment other than MS Windows.
WHY THIS DOCUMENT?
------------------
I have a RadioTrack card from back when I ran an MS-Windows platform. After
converting to Linux, I found Gideon le Grange's command-line software for
running the card, and found that it was good! Frans Brinkman made a
comfortable X-windows interface, and added a scanning feature. For hack
value, I wanted to see if the tuner could be tuned beyond the usual FM radio
broadcast band, so I could pick up the audio carriers from North American
broadcast TV channels, situated just below and above the 87.0-109.0 MHz range.
I did not get much success, but I learned about programming ioports under
Linux and gained some insights about the hardware design used for the card.
So, without further delay, here are the details.
PHYSICAL DESCRIPTION
--------------------
The RadioTrack card is an ISA 8-bit FM radio card. The radio frequency (RF)
input is simply an antenna lead, and the output is a power audio signal
available through a miniature phone plug. Its RF frequencies of operation are
more or less limited from 87.0 to 109.0 MHz (the commercial FM broadcast
band). Although the registers can be programmed to request frequencies beyond
these limits, experiments did not give promising results. The variable
frequency oscillator (VFO) that demodulates the intermediate frequency (IF)
signal probably has a small range of useful frequencies, and wraps around or
gets clipped beyond the limits mentioned above.
CONTROLLING THE CARD WITH IOPORT
--------------------------------
The RadioTrack (base) ioport is configurable for 0x30c or 0x20c. Only one
ioport seems to be involved. The ioport decoding circuitry must be pretty
simple, as individual ioport bits are directly matched to specific functions
(or blocks) of the radio card. This way, many functions can be changed in
parallel with one write to the ioport. The only feedback available through
the ioports appears to be the "Stereo Detect" bit.
The bits of the ioport are arranged as follows:
.. code-block:: none
MSb LSb
+------+------+------+--------+--------+-------+---------+--------+
| VolA | VolB | ???? | Stereo | Radio | TuneA | TuneB | Tune |
| (+) | (-) | | Detect | Audio | (bit) | (latch) | Update |
| | | | Enable | Enable | | | Enable |
+------+------+------+--------+--------+-------+---------+--------+
==== ==== =================================
VolA VolB Description
==== ==== =================================
0 0 audio mute
0 1 volume + (some delay required)
1 0 volume - (some delay required)
1 1 stay at present volume
==== ==== =================================
==================== ===========
Stereo Detect Enable Description
==================== ===========
0 No Detect
1 Detect
==================== ===========
Results available by reading ioport >60 msec after last port write.
0xff ==> no stereo detected, 0xfd ==> stereo detected.
============================= =============================
Radio to Audio (path) Enable Description
============================= =============================
0 Disable path (silence)
1 Enable path (audio produced)
============================= =============================
===== ===== ==================
TuneA TuneB Description
===== ===== ==================
0 0 "zero" bit phase 1
0 1 "zero" bit phase 2
1 0 "one" bit phase 1
1 1 "one" bit phase 2
===== ===== ==================
24-bit code, where bits = (freq*40) + 10486188.
The Most Significant 11 bits must be 1010 xxxx 0x0 to be valid.
The bits are shifted in LSb first.
================== ===========================
Tune Update Enable Description
================== ===========================
0 Tuner held constant
1 Tuner updating in progress
================== ===========================
PROGRAMMING EXAMPLES
--------------------
.. code-block:: none
Default: BASE <-- 0xc8 (current volume, no stereo detect,
radio enable, tuner adjust disable)
Card Off: BASE <-- 0x00 (audio mute, no stereo detect,
radio disable, tuner adjust disable)
Card On: BASE <-- 0x00 (see "Card Off", clears any unfinished business)
BASE <-- 0xc8 (see "Default")
Volume Down: BASE <-- 0x48 (volume down, no stereo detect,
radio enable, tuner adjust disable)
wait 10 msec
BASE <-- 0xc8 (see "Default")
Volume Up: BASE <-- 0x88 (volume up, no stereo detect,
radio enable, tuner adjust disable)
wait 10 msec
BASE <-- 0xc8 (see "Default")
Check Stereo: BASE <-- 0xd8 (current volume, stereo detect,
radio enable, tuner adjust disable)
wait 100 msec
x <-- BASE (read ioport)
BASE <-- 0xc8 (see "Default")
x=0xff ==> "not stereo", x=0xfd ==> "stereo detected"
Set Frequency: code = (freq*40) + 10486188
foreach of the 24 bits in code,
(from Least to Most Significant):
to write a "zero" bit,
BASE <-- 0x01 (audio mute, no stereo detect, radio
disable, "zero" bit phase 1, tuner adjust)
BASE <-- 0x03 (audio mute, no stereo detect, radio
disable, "zero" bit phase 2, tuner adjust)
to write a "one" bit,
BASE <-- 0x05 (audio mute, no stereo detect, radio
disable, "one" bit phase 1, tuner adjust)
BASE <-- 0x07 (audio mute, no stereo detect, radio
disable, "one" bit phase 2, tuner adjust)
linux-7.2.3/Documentation/driver-api/media/drivers/rkisp1.rst
+43
View File
@@ -0,0 +1,43 @@
.. SPDX-License-Identifier: GPL-2.0
The Rockchip Image Signal Processor Driver (rkisp1)
===================================================
Versions and their differences
------------------------------
The rkisp1 block underwent some changes between SoC implementations.
The vendor designates them as:
- V10: used at least in rk3288 and rk3399
- V11: declared in the original vendor code, but not used
- V12: used at least in rk3326 and px30
- V13: used at least in rk1808
- V20: used in rk3568 and beyond
Right now the kernel supports rkisp1 implementations based
on V10 and V12 variants. V11 does not seem to be actually used
and V13 will need some more additions but isn't researched yet,
especially as it seems to be limited to the rk1808 which hasn't
reached much market spread.
V20 on the other hand will probably be used in future SoCs and
has seen really big changes in the vendor kernel, so will need
quite a bit of research.
Changes from V10 to V12
-----------------------
- V12 supports a new CSI-host implementation but can still
also use the same implementation from V10
- The module for lens shading correction got changed
from 12bit to 13bit width
- The AWB and AEC modules got replaced to support finer
grained data collection
Changes from V12 to V13
-----------------------
The list for V13 is incomplete and needs further investigation.
- V13 does not support the old CSI-host implementation anymore
linux-7.2.3/Documentation/driver-api/media/drivers/saa7134-devel.rst
+67
View File
@@ -0,0 +1,67 @@
.. SPDX-License-Identifier: GPL-2.0
The saa7134 driver
==================
Author Gerd Hoffmann
Card Variations:
----------------
Cards can use either of these two crystals (xtal):
- 32.11 MHz -> .audio_clock=0x187de7
- 24.576MHz -> .audio_clock=0x200000 (xtal * .audio_clock = 51539600)
Some details about 30/34/35:
- saa7130 - low-price chip, doesn't have mute, that is why all those
cards should have .mute field defined in their tuner structure.
- saa7134 - usual chip
- saa7133/35 - saa7135 is probably a marketing decision, since all those
chips identifies itself as 33 on pci.
LifeView GPIOs
--------------
This section was authored by: Peter Missel <peter.missel@onlinehome.de>
- LifeView FlyTV Platinum FM (LR214WF)
- GP27 MDT2005 PB4 pin 10
- GP26 MDT2005 PB3 pin 9
- GP25 MDT2005 PB2 pin 8
- GP23 MDT2005 PB1 pin 7
- GP22 MDT2005 PB0 pin 6
- GP21 MDT2005 PB5 pin 11
- GP20 MDT2005 PB6 pin 12
- GP19 MDT2005 PB7 pin 13
- nc MDT2005 PA3 pin 2
- Remote MDT2005 PA2 pin 1
- GP18 MDT2005 PA1 pin 18
- nc MDT2005 PA0 pin 17 strap low
- GP17 Strap "GP7"=High
- GP16 Strap "GP6"=High
- 0=Radio 1=TV
- Drives SA630D ENCH1 and HEF4052 A1 pinsto do FM radio through
SIF input
- GP15 nc
- GP14 nc
- GP13 nc
- GP12 Strap "GP5" = High
- GP11 Strap "GP4" = High
- GP10 Strap "GP3" = High
- GP09 Strap "GP2" = Low
- GP08 Strap "GP1" = Low
- GP07.00 nc
Credits
-------
andrew.stevens@philips.com + werner.leeb@philips.com for providing
saa7134 hardware specs and sample board.
linux-7.2.3/Documentation/driver-api/media/drivers/sh_mobile_ceu_camera.rst
+142
View File
@@ -0,0 +1,142 @@
.. SPDX-License-Identifier: GPL-2.0
Cropping and Scaling algorithm, used in the sh_mobile_ceu_camera driver
=======================================================================
Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Terminology
-----------
sensor scales: horizontal and vertical scales, configured by the sensor driver
host scales: -"- host driver
combined scales: sensor_scale * host_scale
Generic scaling / cropping scheme
---------------------------------
.. code-block:: none
-1--
|
-2-- -\
| --\
| --\
+-5-- . -- -3-- -\
| `... -\
| `... -4-- . - -7..
| `.
| `. .6--
|
| . .6'-
| .´
| ... -4'- .´
| ...´ - -7'.
+-5'- .´ -/
| -- -3'- -/
| --/
| --/
-2'- -/
|
|
-1'-
In the above chart minuses and slashes represent "real" data amounts, points and
accents represent "useful" data, basically, CEU scaled and cropped output,
mapped back onto the client's source plane.
Such a configuration can be produced by user requests:
S_CROP(left / top = (5) - (1), width / height = (5') - (5))
S_FMT(width / height = (6') - (6))
Here:
(1) to (1') - whole max width or height
(1) to (2) - sensor cropped left or top
(2) to (2') - sensor cropped width or height
(3) to (3') - sensor scale
(3) to (4) - CEU cropped left or top
(4) to (4') - CEU cropped width or height
(5) to (5') - reverse sensor scale applied to CEU cropped width or height
(2) to (5) - reverse sensor scale applied to CEU cropped left or top
(6) to (6') - CEU scale - user window
S_FMT
-----
Do not touch input rectangle - it is already optimal.
1. Calculate current sensor scales:
scale_s = ((2') - (2)) / ((3') - (3))
2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
current sensor scales onto input window - this is user S_CROP:
width_u = (5') - (5) = ((4') - (4)) * scale_s
3. Calculate new combined scales from "effective" input window to requested user
window:
scale_comb = width_u / ((6') - (6))
4. Calculate sensor output window by applying combined scales to real input
window:
width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb
5. Apply iterative sensor S_FMT for sensor output window.
subdev->video_ops->s_fmt(.width = width_s_out)
6. Retrieve sensor output window (g_fmt)
7. Calculate new sensor scales:
scale_s_new = ((3')_new - (3)_new) / ((2') - (2))
8. Calculate new CEU crop - apply sensor scales to previously calculated
"effective" crop:
width_ceu = (4')_new - (4)_new = width_u / scale_s_new
left_ceu = (4)_new - (3)_new = ((5) - (2)) / scale_s_new
9. Use CEU cropping to crop to the new window:
ceu_crop(.width = width_ceu, .left = left_ceu)
10. Use CEU scaling to scale to the requested user window:
scale_ceu = width_ceu / width
S_CROP
------
The :ref:`V4L2 crop API <crop-scale>` says:
"...specification does not define an origin or units. However by convention
drivers should horizontally count unscaled samples relative to 0H."
We choose to follow the advise and interpret cropping units as client input
pixels.
Cropping is performed in the following 6 steps:
1. Request exactly user rectangle from the sensor.
2. If smaller - iterate until a larger one is obtained. Result: sensor cropped
to 2 : 2', target crop 5 : 5', current output format 6' - 6.
3. In the previous step the sensor has tried to preserve its output frame as
good as possible, but it could have changed. Retrieve it again.
4. Sensor scaled to 3 : 3'. Sensor's scale is (2' - 2) / (3' - 3). Calculate
intermediate window: 4' - 4 = (5' - 5) * (3' - 3) / (2' - 2)
5. Calculate and apply host scale = (6' - 6) / (4' - 4)
6. Calculate and apply host crop: 6 - 7 = (5 - 2) * (6' - 6) / (5' - 5)
linux-7.2.3/Documentation/driver-api/media/drivers/tuners.rst
+133
View File
@@ -0,0 +1,133 @@
.. SPDX-License-Identifier: GPL-2.0
Tuner drivers
=============
Simple tuner Programming
------------------------
There are some flavors of Tuner programming APIs.
These differ mainly by the bandswitch byte.
- L= LG_API (VHF_LO=0x01, VHF_HI=0x02, UHF=0x08, radio=0x04)
- P= PHILIPS_API (VHF_LO=0xA0, VHF_HI=0x90, UHF=0x30, radio=0x04)
- T= TEMIC_API (VHF_LO=0x02, VHF_HI=0x04, UHF=0x01)
- A= ALPS_API (VHF_LO=0x14, VHF_HI=0x12, UHF=0x11)
- M= PHILIPS_MK3 (VHF_LO=0x01, VHF_HI=0x02, UHF=0x04, radio=0x19)
Tuner Manufacturers
-------------------
- Samsung Tuner identification: (e.g. TCPM9091PD27)
.. code-block:: none
TCP [ABCJLMNQ] 90[89][125] [DP] [ACD] 27 [ABCD]
[ABCJLMNQ]:
A= BG+DK
B= BG
C= I+DK
J= NTSC-Japan
L= Secam LL
M= BG+I+DK
N= NTSC
Q= BG+I+DK+LL
[89]: ?
[125]:
2: No FM
5: With FM
[DP]:
D= NTSC
P= PAL
[ACD]:
A= F-connector
C= Phono connector
D= Din Jack
[ABCD]:
3-wire/I2C tuning, 2-band/3-band
These Tuners are PHILIPS_API compatible.
Philips Tuner identification: (e.g. FM1216MF)
.. code-block:: none
F[IRMQ]12[1345]6{MF|ME|MP}
F[IRMQ]:
FI12x6: Tuner Series
FR12x6: Tuner + Radio IF
FM12x6: Tuner + FM
FQ12x6: special
FMR12x6: special
TD15xx: Digital Tuner ATSC
12[1345]6:
1216: PAL BG
1236: NTSC
1246: PAL I
1256: Pal DK
{MF|ME|MP}
MF: BG LL w/ Secam (Multi France)
ME: BG DK I LL (Multi Europe)
MP: BG DK I (Multi PAL)
MR: BG DK M (?)
MG: BG DKI M (?)
MK2 series PHILIPS_API, most tuners are compatible to this one !
MK3 series introduced in 2002 w/ PHILIPS_MK3_API
Temic Tuner identification: (.e.g 4006FH5)
.. code-block:: none
4[01][0136][269]F[HYNR]5
40x2: Tuner (5V/33V), TEMIC_API.
40x6: Tuner 5V
41xx: Tuner compact
40x9: Tuner+FM compact
[0136]
xx0x: PAL BG
xx1x: Pal DK, Secam LL
xx3x: NTSC
xx6x: PAL I
F[HYNR]5
FH5: Pal BG
FY5: others
FN5: multistandard
FR5: w/ FM radio
3X xxxx: order number with specific connector
Note: Only 40x2 series has TEMIC_API, all newer tuners have PHILIPS_API.
LG Innotek Tuner:
- TPI8NSR11 : NTSC J/M (TPI8NSR01 w/FM) (P,210/497)
- TPI8PSB11 : PAL B/G (TPI8PSB01 w/FM) (P,170/450)
- TAPC-I701 : PAL I (TAPC-I001 w/FM) (P,170/450)
- TPI8PSB12 : PAL D/K+B/G (TPI8PSB02 w/FM) (P,170/450)
- TAPC-H701P: NTSC_JP (TAPC-H001P w/FM) (L,170/450)
- TAPC-G701P: PAL B/G (TAPC-G001P w/FM) (L,170/450)
- TAPC-W701P: PAL I (TAPC-W001P w/FM) (L,170/450)
- TAPC-Q703P: PAL D/K (TAPC-Q001P w/FM) (L,170/450)
- TAPC-Q704P: PAL D/K+I (L,170/450)
- TAPC-G702P: PAL D/K+B/G (L,170/450)
- TADC-H002F: NTSC (L,175/410?; 2-B, C-W+11, W+12-69)
- TADC-M201D: PAL D/K+B/G+I (L,143/425) (sound control at I2C address 0xc8)
- TADC-T003F: NTSC Taiwan (L,175/410?; 2-B, C-W+11, W+12-69)
Suffix:
- P= Standard phono female socket
- D= IEC female socket
- F= F-connector
Other Tuners:
- TCL2002MB-1 : PAL BG + DK =TUNER_LG_PAL_NEW_TAPC
- TCL2002MB-1F: PAL BG + DK w/FM =PHILIPS_PAL
- TCL2002MI-2 : PAL I = ??
ALPS Tuners:
- Most are LG_API compatible
- TSCH6 has ALPS_API (TSCH5 ?)
- TSBE1 has extra API 05,02,08 Control_byte=0xCB Source:[#f1]_
.. [#f1] conexant100029b-PCI-Decoder-ApplicationNote.pdf
linux-7.2.3/Documentation/driver-api/media/drivers/vidtv.rst
+513
View File
@@ -0,0 +1,513 @@
.. SPDX-License-Identifier: GPL-2.0
================================
vidtv: Virtual Digital TV driver
================================
Author: Daniel W. S. Almeida <dwlsalmeida@gmail.com>, June 2020.
Background
----------
Vidtv is a virtual DVB driver that aims to serve as a reference for driver
writers by serving as a template. It also validates the existing media DVB
APIs, thus helping userspace application writers.
Currently, it consists of:
- A fake tuner driver, which will report a bad signal quality if the chosen
frequency is too far away from a table of valid frequencies for a
particular delivery system.
- A fake demod driver, which will constantly poll the fake signal quality
returned by the tuner, simulating a device that can lose/reacquire a lock
on the signal depending on the CNR levels.
- A fake bridge driver, which is the module responsible for modprobing the
fake tuner and demod modules and implementing the demux logic. This module
takes parameters at initialization that will dictate how the simulation
behaves.
- Code responsible for encoding a valid MPEG Transport Stream, which is then
passed to the bridge driver. This fake stream contains some hardcoded content.
For now, we have a single, audio-only channel containing a single MPEG
Elementary Stream, which in turn contains a SMPTE 302m encoded sine-wave.
Note that this particular encoder was chosen because it is the easiest
way to encode PCM audio data in a MPEG Transport Stream.
Building vidtv
--------------
vidtv is a test driver and thus is **not** enabled by default when
compiling the kernel.
In order to enable compilation of vidtv:
- Enable **DVB_TEST_DRIVERS**, then
- Enable **DVB_VIDTV**
When compiled as a module, expect the following .ko files:
- dvb_vidtv_tuner.ko
- dvb_vidtv_demod.ko
- dvb_vidtv_bridge.ko
Running vidtv
-------------
When compiled as a module, run::
modprobe vidtv
That's it! The bridge driver will initialize the tuner and demod drivers as
part of its own initialization.
By default, it will accept the following frequencies:
- 474 MHz for DVB-T/T2/C;
- 11,362 GHz for DVB-S/S2.
For satellite systems, the driver simulates an universal extended
LNBf, with frequencies at Ku-Band, ranging from 10.7 GHz to 12.75 GHz.
You can optionally define some command-line arguments to vidtv.
Command-line arguments to vidtv
-------------------------------
Below is a list of all arguments that can be supplied to vidtv:
drop_tslock_prob_on_low_snr
Probability of losing the TS lock if the signal quality is bad.
This probability be used by the fake demodulator driver to
eventually return a status of 0 when the signal quality is not
good.
recover_tslock_prob_on_good_snr:
Probability recovering the TS lock when the signal improves. This
probability be used by the fake demodulator driver to eventually
return a status of 0x1f when/if the signal quality improves.
mock_power_up_delay_msec
Simulate a power up delay. Default: 0.
mock_tune_delay_msec
Simulate a tune delay. Default 0.
vidtv_valid_dvb_t_freqs
Valid DVB-T frequencies to simulate, in Hz.
vidtv_valid_dvb_c_freqs
Valid DVB-C frequencies to simulate, in Hz.
vidtv_valid_dvb_s_freqs
Valid DVB-S/S2 frequencies to simulate at Ku-Band, in kHz.
max_frequency_shift_hz,
Maximum shift in HZ allowed when tuning in a channel.
si_period_msec
How often to send SI packets. Default: 40ms.
pcr_period_msec
How often to send PCR packets. Default: 40ms.
mux_rate_kbytes_sec
Attempt to maintain this bit rate by inserting TS null packets, if
necessary. Default: 4096.
pcr_pid,
PCR PID for all channels. Default: 0x200.
mux_buf_sz_pkts,
Size for the mux buffer in multiples of 188 bytes.
vidtv internal structure
------------------------
The kernel modules are split in the following way:
vidtv_tuner.[ch]
Implements a fake tuner DVB driver.
vidtv_demod.[ch]
Implements a fake demodulator DVB driver.
vidtv_bridge.[ch]
Implements a bridge driver.
The MPEG related code is split in the following way:
vidtv_ts.[ch]
Code to work with MPEG TS packets, such as TS headers, adaptation
fields, PCR packets and NULL packets.
vidtv_psi.[ch]
This is the PSI generator. PSI packets contain general information
about a MPEG Transport Stream. A PSI generator is needed so
userspace apps can retrieve information about the Transport Stream
and eventually tune into a (dummy) channel.
Because the generator is implemented in a separate file, it can be
reused elsewhere in the media subsystem.
Currently vidtv supports working with 5 PSI tables: PAT, PMT,
SDT, NIT and EIT.
The specification for PAT and PMT can be found in *ISO 13818-1:
Systems*, while the specification for the SDT, NIT, EIT can be found in *ETSI
EN 300 468: Specification for Service Information (SI) in DVB
systems*.
It isn't strictly necessary, but using a real TS file helps when
debugging PSI tables. Vidtv currently tries to replicate the PSI
structure found in this file: `TS1Globo.ts
<https://tsduck.io/streams/brazil-isdb-tb/TS1globo.ts>`_.
A good way to visualize the structure of streams is by using
`DVBInspector <https://sourceforge.net/projects/dvbinspector/>`_.
vidtv_pes.[ch]
Implements the PES logic to convert encoder data into MPEG TS
packets. These can then be fed into a TS multiplexer and eventually
into userspace.
vidtv_encoder.h
An interface for vidtv encoders. New encoders can be added to this
driver by implementing the calls in this file.
vidtv_s302m.[ch]
Implements a S302M encoder to make it possible to insert PCM audio
data in the generated MPEG Transport Stream. The relevant
specification is available online as *SMPTE 302M-2007: Television -
Mapping of AES3 Data into MPEG-2 Transport Stream*.
The resulting MPEG Elementary Stream is conveyed in a private
stream with a S302M registration descriptor attached.
This shall enable passing an audio signal into userspace so it can
be decoded and played by media software. The corresponding decoder
in ffmpeg is located in 'libavcodec/s302m.c' and is experimental.
vidtv_channel.[ch]
Implements a 'channel' abstraction.
When vidtv boots, it will create some hardcoded channels:
#. Their services will be concatenated to populate the SDT.
#. Their programs will be concatenated to populate the PAT
#. Their events will be concatenated to populate the EIT
#. For each program in the PAT, a PMT section will be created
#. The PMT section for a channel will be assigned its streams.
#. Every stream will have its corresponding encoder polled in a
loop to produce TS packets.
These packets may be interleaved by the muxer and then delivered
to the bridge.
vidtv_mux.[ch]
Implements a MPEG TS mux, loosely based on the ffmpeg
implementation in "libavcodec/mpegtsenc.c"
The muxer runs a loop which is responsible for:
#. Keeping track of the amount of time elapsed since the last
iteration.
#. Polling encoders in order to fetch 'elapsed_time' worth of data.
#. Inserting PSI and/or PCR packets, if needed.
#. Padding the resulting stream with NULL packets if
necessary in order to maintain the chosen bit rate.
#. Delivering the resulting TS packets to the bridge
driver so it can pass them to the demux.
Testing vidtv with v4l-utils
----------------------------
Using the tools in v4l-utils is a great way to test and inspect the output of
vidtv. It is hosted here: `v4l-utils Documentation
<https://linuxtv.org/wiki/index.php/V4l-utils>`_.
From its webpage::
The v4l-utils are a series of packages for handling media devices.
It is hosted at http://git.linuxtv.org/v4l-utils.git, and packaged
on most distributions.
It provides a series of libraries and utilities to be used to
control several aspect of the media boards.
Start by installing v4l-utils and then modprobing vidtv::
modprobe dvb_vidtv_bridge
If the driver is OK, it should load and its probing code will run. This will
pull in the tuner and demod drivers.
Using dvb-fe-tool
~~~~~~~~~~~~~~~~~
The first step to check whether the demod loaded successfully is to run::
$ dvb-fe-tool
Device Dummy demod for DVB-T/T2/C/S/S2 (/dev/dvb/adapter0/frontend0) capabilities:
CAN_FEC_1_2
CAN_FEC_2_3
CAN_FEC_3_4
CAN_FEC_4_5
CAN_FEC_5_6
CAN_FEC_6_7
CAN_FEC_7_8
CAN_FEC_8_9
CAN_FEC_AUTO
CAN_GUARD_INTERVAL_AUTO
CAN_HIERARCHY_AUTO
CAN_INVERSION_AUTO
CAN_QAM_16
CAN_QAM_32
CAN_QAM_64
CAN_QAM_128
CAN_QAM_256
CAN_QAM_AUTO
CAN_QPSK
CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.11, Current v5 delivery system: DVBC/ANNEX_A
Supported delivery systems:
DVBT
DVBT2
[DVBC/ANNEX_A]
DVBS
DVBS2
Frequency range for the current standard:
From: 51.0 MHz
To: 2.15 GHz
Step: 62.5 kHz
Tolerance: 29.5 MHz
Symbol rate ranges for the current standard:
From: 1.00 MBauds
To: 45.0 MBauds
This should return what is currently set up at the demod struct, i.e.::
static const struct dvb_frontend_ops vidtv_demod_ops = {
.delsys = {
SYS_DVBT,
SYS_DVBT2,
SYS_DVBC_ANNEX_A,
SYS_DVBS,
SYS_DVBS2,
},
.info = {
.name = "Dummy demod for DVB-T/T2/C/S/S2",
.frequency_min_hz = 51 * MHz,
.frequency_max_hz = 2150 * MHz,
.frequency_stepsize_hz = 62500,
.frequency_tolerance_hz = 29500 * kHz,
.symbol_rate_min = 1000000,
.symbol_rate_max = 45000000,
.caps = FE_CAN_FEC_1_2 |
FE_CAN_FEC_2_3 |
FE_CAN_FEC_3_4 |
FE_CAN_FEC_4_5 |
FE_CAN_FEC_5_6 |
FE_CAN_FEC_6_7 |
FE_CAN_FEC_7_8 |
FE_CAN_FEC_8_9 |
FE_CAN_QAM_16 |
FE_CAN_QAM_64 |
FE_CAN_QAM_32 |
FE_CAN_QAM_128 |
FE_CAN_QAM_256 |
FE_CAN_QAM_AUTO |
FE_CAN_QPSK |
FE_CAN_FEC_AUTO |
FE_CAN_INVERSION_AUTO |
FE_CAN_TRANSMISSION_MODE_AUTO |
FE_CAN_GUARD_INTERVAL_AUTO |
FE_CAN_HIERARCHY_AUTO,
}
....
For more information on dvb-fe-tools check its online documentation here:
`dvb-fe-tool Documentation
<https://www.linuxtv.org/wiki/index.php/Dvb-fe-tool>`_.
Using dvb-scan
~~~~~~~~~~~~~~
In order to tune into a channel and read the PSI tables, we can use dvb-scan.
For this, one should provide a configuration file known as a 'scan file',
here's an example::
[Channel]
FREQUENCY = 474000000
MODULATION = QAM/AUTO
SYMBOL_RATE = 6940000
INNER_FEC = AUTO
DELIVERY_SYSTEM = DVBC/ANNEX_A
.. note::
The parameters depend on the video standard you're testing.
.. note::
Vidtv is a fake driver and does not validate much of the information
in the scan file. Just specifying 'FREQUENCY' and 'DELIVERY_SYSTEM'
should be enough for DVB-T/DVB-T2. For DVB-S/DVB-C however, you
should also provide 'SYMBOL_RATE'.
You can browse scan tables online here: `dvb-scan-tables
<https://git.linuxtv.org/dtv-scan-tables.git>`_.
Assuming this channel is named 'channel.conf', you can then run::
$ dvbv5-scan channel.conf
dvbv5-scan ~/vidtv.conf
ERROR command BANDWIDTH_HZ (5) not found during retrieve
Cannot calc frequency shift. Either bandwidth/symbol-rate is unavailable (yet).
Scanning frequency #1 330000000
(0x00) Signal= -68.00dBm
Scanning frequency #2 474000000
Lock (0x1f) Signal= -34.45dBm C/N= 33.74dB UCB= 0
Service Beethoven, provider LinuxTV.org: digital television
For more information on dvb-scan, check its documentation online here:
`dvb-scan Documentation <https://www.linuxtv.org/wiki/index.php/Dvbscan>`_.
Using dvb-zap
~~~~~~~~~~~~~
dvbv5-zap is a command line tool that can be used to record MPEG-TS to disk. The
typical use is to tune into a channel and put it into record mode. The example
below - which is taken from the documentation - illustrates that\ [1]_::
$ dvbv5-zap -c dvb_channel.conf "beethoven" -o music.ts -P -t 10
using demux 'dvb0.demux0'
reading channels from file 'dvb_channel.conf'
tuning to 474000000 Hz
pass all PID's to TS
dvb_set_pesfilter 8192
dvb_dev_set_bufsize: buffer set to 6160384
Lock (0x1f) Quality= Good Signal= -34.66dBm C/N= 33.41dB UCB= 0 postBER= 0 preBER= 1.05x10^-3 PER= 0
Lock (0x1f) Quality= Good Signal= -34.57dBm C/N= 33.46dB UCB= 0 postBER= 0 preBER= 1.05x10^-3 PER= 0
Record to file 'music.ts' started
received 24587768 bytes (2401 Kbytes/sec)
Lock (0x1f) Quality= Good Signal= -34.42dBm C/N= 33.89dB UCB= 0 postBER= 0 preBER= 2.44x10^-3 PER= 0
.. [1] In this example, it records 10 seconds with all program ID's stored
at the music.ts file.
The channel can be watched by playing the contents of the stream with some
player that recognizes the MPEG-TS format, such as ``mplayer`` or ``vlc``.
By playing the contents of the stream one can visually inspect the workings of
vidtv, e.g., to play a recorded TS file with::
$ mplayer music.ts
or, alternatively, running this command on one terminal::
$ dvbv5-zap -c dvb_channel.conf "beethoven" -P -r &
And, on a second terminal, playing the contents from DVR interface with::
$ mplayer /dev/dvb/adapter0/dvr0
For more information on dvb-zap check its online documentation here:
`dvb-zap Documentation
<https://www.linuxtv.org/wiki/index.php/Dvbv5-zap>`_.
See also: `zap <https://www.linuxtv.org/wiki/index.php/Zap>`_.
What can still be improved in vidtv
-----------------------------------
Add *debugfs* integration
~~~~~~~~~~~~~~~~~~~~~~~~~
Although frontend drivers provide DVBv5 statistics via the .read_status
call, a nice addition would be to make additional statistics available to
userspace via debugfs, which is a simple-to-use, RAM-based filesystem
specifically designed for debug purposes.
The logic for this would be implemented on a separate file so as not to
pollute the frontend driver. These statistics are driver-specific and can
be useful during tests.
The Siano driver is one example of a driver using
debugfs to convey driver-specific statistics to userspace and it can be
used as a reference.
This should be further enabled and disabled via a Kconfig
option for convenience.
Add a way to test video
~~~~~~~~~~~~~~~~~~~~~~~
Currently, vidtv can only encode PCM audio. It would be great to implement
a barebones version of MPEG-2 video encoding so we can also test video. The
first place to look into is *ISO 13818-2: Information technology — Generic
coding of moving pictures and associated audio information — Part 2: Video*,
which covers the encoding of compressed video in MPEG Transport Streams.
This might optionally use the Video4Linux2 Test Pattern Generator, v4l2-tpg,
which resides at::
drivers/media/common/v4l2-tpg/
Add white noise simulation
~~~~~~~~~~~~~~~~~~~~~~~~~~
The vidtv tuner already has code to identify whether the chosen frequency
is too far away from a table of valid frequencies. For now, this means that
the demodulator can eventually lose the lock on the signal, since the tuner will
report a bad signal quality.
A nice addition is to simulate some noise when the signal quality is bad by:
- Randomly dropping some TS packets. This will trigger a continuity error if the
continuity counter is updated but the packet is not passed on to the demux.
- Updating the error statistics accordingly (e.g. BER, etc).
- Simulating some noise in the encoded data.
Functions and structs used within vidtv
---------------------------------------
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_bridge.h
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_channel.h
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_demod.h
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_encoder.h
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_mux.h
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_pes.h
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_psi.h
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_s302m.h
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_ts.h
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_tuner.h
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_common.c
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_tuner.c
linux-7.2.3/Documentation/driver-api/media/drivers/vimc-devel.rst
+15
View File
@@ -0,0 +1,15 @@
.. SPDX-License-Identifier: GPL-2.0
The Virtual Media Controller Driver (vimc)
==========================================
Source code documentation
-------------------------
vimc-streamer
~~~~~~~~~~~~~
.. kernel-doc:: drivers/media/test-drivers/vimc/vimc-streamer.h
:internal:
.. kernel-doc:: drivers/media/test-drivers/vimc/vimc-streamer.c
linux-7.2.3/Documentation/driver-api/media/drivers/zoran.rst
+575
View File
@@ -0,0 +1,575 @@
.. SPDX-License-Identifier: GPL-2.0
The Zoran driver
================
unified zoran driver (zr360x7, zoran, buz, dc10(+), dc30(+), lml33)
website: http://mjpeg.sourceforge.net/driver-zoran/
Frequently Asked Questions
--------------------------
What cards are supported
------------------------
Iomega Buz, Linux Media Labs LML33/LML33R10, Pinnacle/Miro
DC10/DC10+/DC30/DC30+ and related boards (available under various names).
Iomega Buz
~~~~~~~~~~
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7111 TV decoder
* Philips saa7185 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7111, saa7185, zr36060, zr36067
Inputs/outputs: Composite and S-video
Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
Card number: 7
AverMedia 6 Eyes AVS6EYES
~~~~~~~~~~~~~~~~~~~~~~~~~
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Samsung ks0127 TV decoder
* Conexant bt866 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, ks0127, bt866, zr36060, zr36067
Inputs/outputs:
Six physical inputs. 1-6 are composite,
1-2, 3-4, 5-6 doubles as S-video,
1-3 triples as component.
One composite output.
Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
Card number: 8
.. note::
Not autodetected, card=8 is necessary.
Linux Media Labs LML33
~~~~~~~~~~~~~~~~~~~~~~
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Brooktree bt819 TV decoder
* Brooktree bt856 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, bt819, bt856, zr36060, zr36067
Inputs/outputs: Composite and S-video
Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
Card number: 5
Linux Media Labs LML33R10
~~~~~~~~~~~~~~~~~~~~~~~~~
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7114 TV decoder
* Analog Devices adv7170 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7114, adv7170, zr36060, zr36067
Inputs/outputs: Composite and S-video
Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
Card number: 6
Pinnacle/Miro DC10(new)
~~~~~~~~~~~~~~~~~~~~~~~
* Zoran zr36057 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7110a TV decoder
* Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7110, adv7175, zr36060, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 1
Pinnacle/Miro DC10+
~~~~~~~~~~~~~~~~~~~
* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7110a TV decoder
* Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7110, adv7175, zr36060, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 2
Pinnacle/Miro DC10(old)
~~~~~~~~~~~~~~~~~~~~~~~
* Zoran zr36057 PCI controller
* Zoran zr36050 MJPEG codec
* Zoran zr36016 Video Front End or Fuji md0211 Video Front End (clone?)
* Micronas vpx3220a TV decoder
* mse3000 TV encoder or Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, vpx3220, mse3000/adv7175, zr36050, zr36016, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 0
Pinnacle/Miro DC30
~~~~~~~~~~~~~~~~~~
* Zoran zr36057 PCI controller
* Zoran zr36050 MJPEG codec
* Zoran zr36016 Video Front End
* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
* Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36016, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 3
Pinnacle/Miro DC30+
~~~~~~~~~~~~~~~~~~~
* Zoran zr36067 PCI controller
* Zoran zr36050 MJPEG codec
* Zoran zr36016 Video Front End
* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
* Analog Devices adv7176 TV encoder
Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36015, zr36067
Inputs/outputs: Composite, S-video and Internal
Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
Card number: 4
.. note::
#) No module for the mse3000 is available yet
#) No module for the vpx3224 is available yet
1.1 What the TV decoder can do an what not
------------------------------------------
The best know TV standards are NTSC/PAL/SECAM. but for decoding a frame that
information is not enough. There are several formats of the TV standards.
And not every TV decoder is able to handle every format. Also the every
combination is supported by the driver. There are currently 11 different
tv broadcast formats all aver the world.
The CCIR defines parameters needed for broadcasting the signal.
The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,...
The CCIR says not much about the colorsystem used !!!
And talking about a colorsystem says not to much about how it is broadcast.
The CCIR standards A,E,F are not used any more.
When you speak about NTSC, you usually mean the standard: CCIR - M using
the NTSC colorsystem which is used in the USA, Japan, Mexico, Canada
and a few others.
When you talk about PAL, you usually mean: CCIR - B/G using the PAL
colorsystem which is used in many Countries.
When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem
which is used in France, and a few others.
There the other version of SECAM, CCIR - D/K is used in Bulgaria, China,
Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others.
The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in
Egypt, Libya, Sri Lanka, Syrain Arab. Rep.
The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong,
Ireland, Nigeria, South Africa.
The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate,
and is used in Argentina, Uruguay, and a few others
We do not talk about how the audio is broadcast !
A rather good sites about the TV standards are:
http://www.sony.jp/support/
http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/
and http://www.cabl.com/restaurant/channel.html
Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly
used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same
as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would
be the same as NTSC 4.43.
NTSC Combs seems to be a decoder mode where the decoder uses a comb filter
to split coma and luma instead of a Delay line.
But I did not defiantly find out what NTSC Comb is.
Philips saa7111 TV decoder
~~~~~~~~~~~~~~~~~~~~~~~~~~
- was introduced in 1997, is used in the BUZ and
- can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM
Philips saa7110a TV decoder
~~~~~~~~~~~~~~~~~~~~~~~~~~~
- was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and
- can handle: PAL B/G, NTSC M and SECAM
Philips saa7114 TV decoder
~~~~~~~~~~~~~~~~~~~~~~~~~~
- was introduced in 2000, is used in the LML33R10 and
- can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM
Brooktree bt819 TV decoder
~~~~~~~~~~~~~~~~~~~~~~~~~~
- was introduced in 1996, and is used in the LML33 and
- can handle: PAL B/D/G/H/I, NTSC M
Micronas vpx3220a TV decoder
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- was introduced in 1996, is used in the DC30 and DC30+ and
- can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC 44, PAL 60, SECAM,NTSC Comb
Samsung ks0127 TV decoder
~~~~~~~~~~~~~~~~~~~~~~~~~
- is used in the AVS6EYES card and
- can handle: NTSC-M/N/44, PAL-M/N/B/G/H/I/D/K/L and SECAM
What the TV encoder can do an what not
--------------------------------------
The TV encoder is doing the "same" as the decoder, but in the other direction.
You feed them digital data and the generate a Composite or SVHS signal.
For information about the colorsystems and TV norm take a look in the
TV decoder section.
Philips saa7185 TV Encoder
~~~~~~~~~~~~~~~~~~~~~~~~~~
- was introduced in 1996, is used in the BUZ
- can generate: PAL B/G, NTSC M
Brooktree bt856 TV Encoder
~~~~~~~~~~~~~~~~~~~~~~~~~~
- was introduced in 1994, is used in the LML33
- can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL-N (Argentina)
Analog Devices adv7170 TV Encoder
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- was introduced in 2000, is used in the LML300R10
- can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL 60
Analog Devices adv7175 TV Encoder
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- was introduced in 1996, is used in the DC10, DC10+, DC10 old, DC30, DC30+
- can generate: PAL B/D/G/H/I/N, PAL M, NTSC M
ITT mse3000 TV encoder
~~~~~~~~~~~~~~~~~~~~~~
- was introduced in 1991, is used in the DC10 old
- can generate: PAL , NTSC , SECAM
Conexant bt866 TV encoder
~~~~~~~~~~~~~~~~~~~~~~~~~
- is used in AVS6EYES, and
- can generate: NTSC/PAL, PAL-M, PAL-N
The adv717x, should be able to produce PAL N. But you find nothing PAL N
specific in the registers. Seem that you have to reuse a other standard
to generate PAL N, maybe it would work if you use the PAL M settings.
How do I get this damn thing to work
------------------------------------
Load zr36067.o. If it can't autodetect your card, use the card=X insmod
option with X being the card number as given in the previous section.
To have more than one card, use card=X1[,X2[,X3,[X4[..]]]]
To automate this, add the following to your /etc/modprobe.d/zoran.conf:
options zr36067 card=X1[,X2[,X3[,X4[..]]]]
alias char-major-81-0 zr36067
One thing to keep in mind is that this doesn't load zr36067.o itself yet. It
just automates loading. If you start using xawtv, the device won't load on
some systems, since you're trying to load modules as a user, which is not
allowed ("permission denied"). A quick workaround is to add 'Load "v4l"' to
XF86Config-4 when you use X by default, or to run 'v4l-conf -c <device>' in
one of your startup scripts (normally rc.local) if you don't use X. Both
make sure that the modules are loaded on startup, under the root account.
What mainboard should I use (or why doesn't my card work)
---------------------------------------------------------
<insert lousy disclaimer here>. In short: good=SiS/Intel, bad=VIA.
Experience tells us that people with a Buz, on average, have more problems
than users with a DC10+/LML33. Also, it tells us that people owning a VIA-
based mainboard (ktXXX, MVP3) have more problems than users with a mainboard
based on a different chipset. Here's some notes from Andrew Stevens:
Here's my experience of using LML33 and Buz on various motherboards:
- VIA MVP3
- Forget it. Pointless. Doesn't work.
- Intel 430FX (Pentium 200)
- LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie)
- Intel 440BX (early stepping)
- LML33 tolerable. Buz starting to get annoying (6-10 frames/hour)
- Intel 440BX (late stepping)
- Buz tolerable, LML3 almost perfect (occasional single frame drops)
- SiS735
- LML33 perfect, Buz tolerable.
- VIA KT133(*)
- LML33 starting to get annoying, Buz poor enough that I have up.
- Both 440BX boards were dual CPU versions.
Bernhard Praschinger later added:
- AMD 751
- Buz perfect-tolerable
- AMD 760
- Buz perfect-tolerable
In general, people on the user mailinglist won't give you much of a chance
if you have a VIA-based motherboard. They may be cheap, but sometimes, you'd
rather want to spend some more money on better boards. In general, VIA
mainboard's IDE/PCI performance will also suck badly compared to others.
You'll noticed the DC10+/DC30+ aren't mentioned anywhere in the overview.
Basically, you can assume that if the Buz works, the LML33 will work too. If
the LML33 works, the DC10+/DC30+ will work too. They're most tolerant to
different mainboard chipsets from all of the supported cards.
If you experience timeouts during capture, buy a better mainboard or lower
the quality/buffersize during capture (see 'Concerning buffer sizes, quality,
output size etc.'). If it hangs, there's little we can do as of now. Check
your IRQs and make sure the card has its own interrupts.
Programming interface
---------------------
This driver conforms to video4linux2. Support for V4L1 and for the custom
zoran ioctls has been removed in kernel 2.6.38.
For programming example, please, look at lavrec.c and lavplay.c code in
the MJPEG-tools (http://mjpeg.sf.net/).
Additional notes for software developers:
The driver returns maxwidth and maxheight parameters according to
the current TV standard (norm). Therefore, the software which
communicates with the driver and "asks" for these parameters should
first set the correct norm. Well, it seems logically correct: TV
standard is "more constant" for current country than geometry
settings of a variety of TV capture cards which may work in ITU or
square pixel format.
Applications
------------
Applications known to work with this driver:
TV viewing:
* xawtv
* kwintv
* probably any TV application that supports video4linux or video4linux2.
MJPEG capture/playback:
* mjpegtools/lavtools (or Linux Video Studio)
* gstreamer
* mplayer
General raw capture:
* xawtv
* gstreamer
* probably any application that supports video4linux or video4linux2
Video editing:
* Cinelerra
* MainActor
* mjpegtools (or Linux Video Studio)
Concerning buffer sizes, quality, output size etc.
--------------------------------------------------
The zr36060 can do 1:2 JPEG compression. This is really the theoretical
maximum that the chipset can reach. The driver can, however, limit compression
to a maximum (size) of 1:4. The reason for this is that some cards (e.g. Buz)
can't handle 1:2 compression without stopping capture after only a few minutes.
With 1:4, it'll mostly work. If you have a Buz, use 'low_bitrate=1' to go into
1:4 max. compression mode.
100% JPEG quality is thus 1:2 compression in practice. So for a full PAL frame
(size 720x576). The JPEG fields are stored in YUY2 format, so the size of the
fields are 720x288x16/2 bits/field (2 fields/frame) = 207360 bytes/field x 2 =
414720 bytes/frame (add some more bytes for headers and DHT (huffman)/DQT
(quantization) tables, and you'll get to something like 512kB per frame for
1:2 compression. For 1:4 compression, you'd have frames of half this size.
Some additional explanation by Martin Samuelsson, which also explains the
importance of buffer sizes:
--
> Hmm, I do not think it is really that way. With the current (downloaded
> at 18:00 Monday) driver I get that output sizes for 10 sec:
> -q 50 -b 128 : 24.283.332 Bytes
> -q 50 -b 256 : 48.442.368
> -q 25 -b 128 : 24.655.992
> -q 25 -b 256 : 25.859.820
I woke up, and can't go to sleep again. I'll kill some time explaining why
this doesn't look strange to me.
Let's do some math using a width of 704 pixels. I'm not sure whether the Buz
actually use that number or not, but that's not too important right now.
704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block;
3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block;
1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum
output becomes 512 bits per block. Actually 510, but 512 is simpler to use
for calculations.
Let's say that we specify d1q50. We thus want 256 bits per block; times 3168
becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes
here, so we don't need to do any fancy corrections for bits-per-pixel or such
things. 101376 bytes per field.
d1 video contains two fields per frame. Those sum up to 202752 bytes per
frame, and one of those frames goes into each buffer.
But wait a second! -b128 gives 128kB buffers! It's not possible to cram
202752 bytes of JPEG data into 128kB!
This is what the driver notice and automatically compensate for in your
examples. Let's do some math using this information:
128kB is 131072 bytes. In this buffer, we want to store two fields, which
leaves 65536 bytes for each field. Using 3168 blocks per field, we get
20.68686868... available bytes per block; 165 bits. We can't allow the
request for 256 bits per block when there's only 165 bits available! The -q50
option is silently overridden, and the -b128 option takes precedence, leaving
us with the equivalence of -q32.
This gives us a data rate of 165 bits per block, which, times 3168, sums up
to 65340 bytes per field, out of the allowed 65536. The current driver has
another level of rate limiting; it won't accept -q values that fill more than
6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be
a safe bet. Personally, I think I would have lowered requested-bits-per-block
by one, or something like that.) We can't use 165 bits per block, but have to
lower it again, to 6/8 of the available buffer space: We end up with 124 bits
per block, the equivalence of -q24. With 128kB buffers, you can't use greater
than -q24 at -d1. (And PAL, and 704 pixels width...)
The third example is limited to -q24 through the same process. The second
example, using very similar calculations, is limited to -q48. The only
example that actually grab at the specified -q value is the last one, which
is clearly visible, looking at the file size.
--
Conclusion: the quality of the resulting movie depends on buffer size, quality,
whether or not you use 'low_bitrate=1' as insmod option for the zr36060.c
module to do 1:4 instead of 1:2 compression, etc.
If you experience timeouts, lowering the quality/buffersize or using
'low_bitrate=1 as insmod option for zr36060.o might actually help, as is
proven by the Buz.
It hangs/crashes/fails/whatevers! Help!
---------------------------------------
Make sure that the card has its own interrupts (see /proc/interrupts), check
the output of dmesg at high verbosity (load zr36067.o with debug=2,
load all other modules with debug=1). Check that your mainboard is favorable
(see question 2) and if not, test the card in another computer. Also see the
notes given in question 3 and try lowering quality/buffersize/capturesize
if recording fails after a period of time.
If all this doesn't help, give a clear description of the problem including
detailed hardware information (memory+brand, mainboard+chipset+brand, which
MJPEG card, processor, other PCI cards that might be of interest), give the
system PnP information (/proc/interrupts, /proc/dma, /proc/devices), and give
the kernel version, driver version, glibc version, gcc version and any other
information that might possibly be of interest. Also provide the dmesg output
at high verbosity. See 'Contacting' on how to contact the developers.
Maintainers/Contacting
----------------------
Previous maintainers/developers of this driver are
- Laurent Pinchart <laurent.pinchart@skynet.be>
- Ronald Bultje rbultje@ronald.bitfreak.net
- Serguei Miridonov <mirsev@cicese.mx>
- Wolfgang Scherr <scherr@net4you.net>
- Dave Perks <dperks@ibm.net>
- Rainer Johanni <Rainer@Johanni.de>
Driver's License
----------------
This driver is distributed under the terms of the General Public License.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
See http://www.gnu.org/ for more information.