18 Dec, 2017
1 commit
-
This struct is lacking documentation. Add it.
Acked-by: Sakari Ailus
Signed-off-by: Mauro Carvalho Chehab
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
18 Jul, 2016
1 commit
-
The conversion from DocBook lead into some conversion issues,
basically due to the lack of proper support at kernel-doc.So, address them:
- Now, the C files with the exported symbols also need to be
added. So, all headers need to be included twice: one to
get the structs/enums/.. and another one for the functions;- Notes should use the ReST tag, as kernel-doc doesn't
recognizes it anymore;- Identation needs to be fixed, as ReST uses it to identify
when a format "tag" ends.- kernel-doc doesn't escape things like *pointer, so we
need to manually add a escape char before it.- On some cases, kernel-doc conversion requires violating
the 80-cols, as otherwise it won't properly parse the
source code.Signed-off-by: Mauro Carvalho Chehab
05 Oct, 2015
2 commits
-
The tuner-types.h is part of the V4L2 core and should be
touched for every new tuner added. So, it deserves to be
documented at the device-drivers DocBook.Add it to device-drivers.tmpl and add descriptions for
enum param_type and struct tuner_range.Signed-off-by: Mauro Carvalho Chehab
-
The struct tuner_params is almost fully documented, but
using a non-standard way. Convert it to doc-nano format,
and add descriptions for the parameters that aren't
documented yet.Signed-off-by: Mauro Carvalho Chehab
25 Apr, 2008
3 commits
-
Enable digital tuning support within tuner-simple. This will allow for a
single tuner module to manage the hardware, without having dvb-pll loaded.Signed-off-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab -
taken from dvb-pll
Signed-off-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab -
Add entry points used for digital tuning via the dvb_frontend.
Share state data between multiple instances of the driver for hybrid
tuners.Signed-off-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab
10 Oct, 2007
1 commit
-
Add radio support for the Thomson DTT7612 tuner.
This tuner uses a different 1st intermediate frequency than the other radio
tuners supported (a lot of NTSC radio tuners probably need this change too).Add a new tuner-simple parameter, radio_if. It selects the 1st IF used for
radio reception. The radio frequency setting code in tuner-simple now uses
this field, instead of a special case select() block for each tuner with radio
support.The tuner parameters for tuners that used a 33.3 MHz RIF now set radio_if to 1
in tuner-types.c.The Thomson DTT7612 gets radio_if = 2, also add has_tda9887 = 1 and
fm_gain_normal = 1.Add some defines for tda9887 bits that control IF setting in radio mode.
Add a new tda9887 config option, TDA9887_RIF_41_3, that selects a 41.3 MHz
radio IF.Fix the way tda9887 radio options work. The driver was modifying the default
radio mode config templates based on the TDA9887_XXXX flags. This means that
_all_ tuners would get the same settings. If you had a one tuner than used
TDA9887_GAIN_NORMAL and one that didn't, both would get the setting. Now the
tda9987 driver just checks if tuner mode is radio and then applies the config
settings directly to the data being sent, just like how all the TV mode
settings already work.The PLL setting math is made a little more accurate.
And a grammar error in a printk is fixed.
Signed-off-by: Trent Piepho
Signed-off-by: Mauro Carvalho Chehab
10 Dec, 2006
1 commit
-
Some tuners require using cGainNormal instead of cGainLow for
high sensibility on FM reception.Signed-off-by: Mauro Carvalho Chehab
26 Sep, 2006
1 commit
-
Add a tuner config parameter for TDA9887, default_pll_gating_18, that
changes the L standard PLL gating value from 36% to 0% (datasheet says
0%, tda9887 code says 18%).
Turn this on for Microtune 4049FM5, as recomended by tuner datasheet.Signed-off-by: Trent Piepho
Signed-off-by: Mauro Carvalho Chehab
01 Jul, 2006
1 commit
-
Many tda9887 settings depend on the chosen tuner. Expand the tuner parameters
to include these tda9887 settings.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
06 Feb, 2006
1 commit
-
The tuner_params element is an array of undefined length,
with each array member being a set of parameters for each
video standard type.
The number of members in the tuner_params array
will be stored in tuners[]->countSigned-off-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab
24 Jan, 2006
1 commit
-
- Move config byte from tuner_params to tuner_range struct.
- dvb tuners must be able to set different config byte for each range.Signed-off-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab
16 Jan, 2006
4 commits
-
- Tuner_params->tda988x is unused right now, so let's disable it for 2.6.16
- This is currently happening at the card level, but the plan
is to move this configuration into the tuner_params configuration.Signed-off-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab -
- clean up some comments
Signed-off-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab -
- Moved MSP_SET_MATRIX to v4l2-common.h
- Fix typos and integer overflows in tea5767.c
- Split old freq field into a tv_freq and a radio_freq. Prevents
that a radio tuner is initialized with a tv frequency or vice versa.
- When switching to radio mode initialize the tuner with the last
used radio frequency (this was already done for the TV mode).
As a result of these changes the tuner module now remembers the
last set radio and TV frequencies, which is what you would expect
to happen.
- Move out of range frequencies to the closest valid frequency as per
v4l2 API spec.
- Fix incorrect initial radio frequency (multiplier is 16000, not 16)
- Add boundary check for out of range frequencies.
- Use new flag to check if the order of the CB and freq. depends on
the last set frequency. That is needed for some tuners or you can
get static as a result. The flag is added for those tuners where I know
that the datasheet indicates that this is necessary.
- For this new check use the last set div value, not the last frequency
as radio frequencies are always much higher due to the 16000 multiplier.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab -
- Tda988x parameters should be defined per tuner_param_type,
for each tuner_params array member.Signed-off-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab
14 Jan, 2006
2 commits
-
- Add param_type dvbs2
- disable all dvb param_types, which will not
be needed until we merge dvb-pll.Signed-off-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab -
- Tunertype struct redefined to allow one or more tuner_params structs
per tuner definition, one for each video standard.
- Each tuner_params struct has an element containing an arbitrary
amount of tuner_ranges.
(this is needed for dvb tuners - to be handled later)
- A tuner_range may be referenced by multiple tuner_params structs.
There are many duplicates in here. Reusing tuner_range structs,
rather than defining new ones for each tuner, will cut down on
memory usage, and is preferred when possible.
- tunertype struct contains an element, has_tda988x.
We must set this for all tunertypes that contain a tda988x
chip, and then we can remove this setting from the various
card structs.
- Improves tuners array memory usage efficiency.
- Right now, all tuners are using the first tuner_params[] array element
for analog mode. In the future, we will be merging similar tuner
definitions together, such that each tuner definition will have a
tuner_params struct for each available video standard. At that point,
the tuner_params[] array element will be chosen based on the video
standard in use.Signed-off-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab