The code to set the norm for the TDA9880 analog demod was comparing
btv->norm, an index into the bttv driver's norm array, to V4L2_STD_NTSC,
which is a bit flag that's part of the V4L2 API. This doesn't work of
course and results in the PAL path always being taken.
What's more, it modified the bttv_tvcards[] entries for cards using the
TDA9880. This is wrong because changing the norm on one card will also
affect other cards of the same type. Writing to bttv_tvcards is also bad
because it should be read-only or even devinitdata.
Changing the norm would also cause the audio to become unmuted.
Have the code get called for both norm setting and audio input setting
(which where the gpios are set) to avoid needed to modify bttv_tvcards.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The norm value in the driver is an index into an array and the the driver
doesn't allow it to be negative or otherwise invalid. It should be
unsigned but wasn't in all places.
Fix some structs and functions to have the norm be unsigned. Get rid of
useless checks for "< 0". Most of the driver code can't handle a norm
value that's out of range, so change some ">= BTTV_TVNORMS" checks to
BUG_ON(). There's no point in silently ignoring invalid driver state just
to crash because of it later.
Reported-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It's a quad Bt878 PCI-e x1 capture board that's basically the same as the
IVC-200 (quad Bt878 PCI) capture board that's currently supported in
the V4L2 bttv driver.
Manufacturer's web page for IVCE-8784 with photo and info:
http://www.iei.com.tw/en/product_IPC.asp?model=IVCE-8784
Signed-off-by: Douglas Kosovic <douglask@itee.uq.edu.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The radio_release function of the BTTV driver is missing a call to
v4l2_prio_close. As a result, after the radio device has been opened at
least once (e.g., by HAL during bootup), v4l2_priority will never drop below
V4L2_PRIORITY_INTERACTIVE again. With the following patch against 2.6.28,
applications that run with V4L2_PRIORITY_BACKGROUND are able to open devices
again. Previous Linux versions are affected as well.
Signed-off-by: Udo Steinberg <udo@hypervisor.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Since the i2c driver ID will be removed in the near future we have to
modify the v4l2 debugging API to use the driver name instead of driver ID.
Note that this API is not used in applications other than v4l2-dbg.cpp
as it is for debugging and testing only.
Should anyone use the old VIDIOC_G_CHIP_IDENT, then this will be logged
with a warning that it is deprecated and will be removed in 2.6.30.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Introduce a struct v4l2_file_operations for v4l2 drivers.
Remove the unnecessary inode argument.
Move compat32 handling (and llseek) into the v4l2-dev core: this is now
handled in the v4l2 core and no longer in the drivers themselves.
Note that this changeset reverts an earlier patch that changed the return
type of__video_ioctl2 from int to long. This change will be reinstated
later in a much improved version.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bt832 i2c driver was never used or even compiled and is no longer
maintained. It is now removed completely.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This Patch does modify the bttv-cards.c and bttc.h so that the driver
supports VD-011, VD-012, VD-012-X1 and VD-012-X2 Framegrabber from
Phytec Messtechnik GmbH.
Signed-off-by: Dirk Heer <d.heer@phytec.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The BT8XX device driver currently only supports 16 such devices in a
system. This is too small for many surveillance applications. This
patch increases the number to 32.
Signed-off-by: Alan McIvor <alan.mcivor@reveal.co.nz>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".
To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.
We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.
We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.
Thanks,
Kay
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The kernel number of a v4l2 node (e.g. videoX, radioX or vbiX) is now
independent of the minor number. So instead of using the minor field
of the video_device struct one has to use the num field: this always
contains the kernel number of the device node.
I forgot about this when I did the v4l2 core change, so this patch
converts all drivers that use it in one go. Luckily the change is
trivial.
Cc: michael@mihu.de
Cc: mchehab@infradead.org
Cc: corbet@lwn.net
Cc: luca.risolia@studio.unibo.it
Cc: isely@pobox.com
Cc: pe1rxq@amsat.org
Cc: royale@zerezo.com
Cc: mkrufky@linuxtv.org
Cc: stoth@linuxtv.org
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove the vidioc_enum_fmt_vbi_cap ops: it was scheduled for removal in
2.6.28 since the v4l2 specification says that V4L2_BUF_TYPE_VBI_CAPTURE should
not support VIDIOC_ENUM_FMT. It's also pretty pointless.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With video_nr, vbi_nr and radio_nr being simple integers, it is not
possible to use these parameters on a system with multiple bttv
adapters (which happens to be my case.) video_register_device() will
always fail on the second and later adapters. Turn these parameters
into arrays, as many other V4L drivers are already doing, so that they
can be used on such systems.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When the input is set to tuner and no antenna is connected, the BT848
can flood VPRES interrupts. So we don't want to enable this type of
interrupts when the input it set to tuner.
As we don't do anything when receiving such an interrupt anyway, the
easiest fix is to simply not unmask this specific interrupt.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks to Sistema Fenix (http://www.sistemafenix.com.br/) and CDI Brasil
(www.cdibrasil.com.br/) for sponsoring this development.
Signed-off-by: Gilberto <gilberto@sistemafenix.com.br>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The BKL is now moved from the video_open function in v4l2-dev.c to the
various drivers. It seems about a third of the drivers already has a
lock of some sort protecting the open(), another third uses
video_exclusive_open (yuck!) and the last third required adding the
BKL in their open function.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix the following crash in the bttv driver:
BUG: unable to handle kernel NULL pointer dereference at 000000000000036c
IP: [<ffffffffa037860a>] radio_open+0x3a/0x170 [bttv]
This happens because radio_open assumes that all present bttv devices
have a radio function. If a bttv device without radio and one with
radio are installed on the same system, and the one without radio is
registered first, then radio_open checks for the radio device number
of a bttv device that has no radio function, and this breaks. All we
have to do to fix it is to skip bttv devices without a radio function.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
b2c2-flexcop, dvb/bt8xx and video/bt8xx fails to build on ARM with:
__bad_udelay is specifically designed on ARM to fail when udelay is
called in a bad way. arch/arm/include/asm/delay.h has this to say
about __bad_udelay:
/*
* This function intentionally does not exist; if you see references to
* it, it means that you're calling udelay() with an out of range value.
*
* With currently imposed limits, this means that we support a max delay
* of 2000us. Further limits: HZ<=1000 and bogomips<=3355
*/
extern void __bad_udelay(void);
Solution is to replace udelay by a mdelay and udelay with value less than 2000
Signed-off-by: Thierry MERLE <thierry.merle@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixed a lot of sparse warnings: mostly warnings about shadowed variables
and signed/unsigned mismatches.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After commit d9b19199e4
(always enable FW_LOADER unless EMBEDDED=y) we can remove
the FW_LOADER select's and corresponding dependencies
on HOTPLUG.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The type and type2 fields were unused and so could be removed.
Instead add a vfl_type field that contains the type of the video
device.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
All ioctl callbacks are now stored in a new v4l2_ioctl_ops struct. Drivers fill in
a const struct v4l2_ioctl_ops and video_device just contains a const pointer to it.
This ensures a clean separation between the const ops struct and the non-const
video_device struct.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The functions in a header should not belong to another module. The prio functions
belong to v4l2-common.c, so move them to v4l2-common.h.
The ioctl functions belong to v4l2-ioctl.c, so create a new v4l2-ioctl.h header
and move those functions to it.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The class_dev field is a normal device, not a class device. This is very
confusing and now that the old 'dev' field has been renamed to 'parent'
we can rename 'class_dev' to just 'dev'.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The field 'dev' is not the video device, but the parent of the video device.
Rename accordingly.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Also remove some blank lines that were used to split compat code at -devel
tree.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Clean up the use of structure templates in bttv-i2c. For one thing, a
real template is supposed to be read-only. And in some cases it's more
efficient to initialize the few fields we need individually.
This clean-up shrinks bttv-i2c.o by 29% (x86_64).
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The naming for the callbacks that handle the VIDIOC_ENUM_FMT and
VIDIOC_S/G/TRY_FMT ioctls was very confusing. Renamed it to match
the v4l2_buf_type name.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
vidiocgmbuf() does this:
mutex_lock(&fh->cap.vb_lock);
retval = videobuf_mmap_setup(&fh->cap, gbuffers, gbufsize,
V4L2_MEMORY_MMAP);
and videobuf_mmap_setup() then just does
mutex_lock(&q->vb_lock);
ret = __videobuf_mmap_setup(q, bcount, bsize, memory);
mutex_unlock(&q->vb_lock);
which is an obvious double-take deadlock.
This patch fixes this by having vidiocgmbuf() just call the
__videobuf_mmap_setup function instead.
Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Reported-by: Koos Vriezen <koos.vriezen@gmail.com>
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Since:
1) FW_LOADER is defined as:
config FW_LOADER
tristate "Userspace firmware loading support"
depends on HOTPLUG
2) several V4L/DVB driver just selects it;
3) select is not smart enough to auto-select HOTPLUG, if select FW_LOADER.
So, All drivers that select FW_LOADER should also depend on HOTPLUG.
An easier solution (for the end-user perspective) would be to "select HOTPLUG".
However, live is not simple. This would cause recursive dependency issues like
this one:
drivers/usb/Kconfig:62:error: found recursive dependency: USB -> USB_OHCI_HCD
-> I2C -> MEDIA_TUNER -> MEDIA_TUNER_XC2028 -> HOTPLUG -> PCCARD -> PCMCIA ->
USB_ARCH_HAS_HCD -> MOUSE_APPLETOUCH -> USB
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
VIDEO_TUNER is responsible for compilation of tuners.ko module. This were the
previous behaviour before the creation of MEDIA_TUNER.
Before this patch, tuner.ko were created even for drivers that don't need a
tuner (like webcam drivers).
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Also, change the variable names used in the min/max macros to avoid shadowed
variable warnings when min/max min_t/max_t are nested.
Small formatting changes to make all the macros have a similar form.
[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix v4l build]
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Tejun Heo <htejun@gmail.com>
Cc: Michael Buesch <mb@bu3sch.de>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There were several issues in the past, caused by the hybrid tuner design, since
now, the same tuner can be used by drivers/media/dvb and drivers/media/video.
Kconfig items were rearranged, to split V4L/DVB core from their drivers.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Fix the leak of the bttv_fh structure allocated in radio_open which
was introduced by commit 5cd3955cb8.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Convert dvb-bt8xx to use tuner-simple instead of dvb-pll for Philips FCV1236D
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
TUNER_PHILIPS_ATSC is an ambiguous name for a tuner. Rename it to
TUNER_PHILIPS_FCV1236D to be more descriptive.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
I have what looks like a Geovision GV-600 (or 650) card. It has a large
chip in the middle labeled
CONEXANT
FUSION 878A
25878-13
E345881.1
0312 TAIWAN
It has an audio connector coming out from a chip labeled
ATMEL
0242
AT89C2051-24PI
It is identified as follows on my Debian GNU/Linux Etch (kernel 2.6.18)
...
01:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
01:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
...
01:0a.0 0400: 109e:036e (rev 11)
Subsystem: 008a:763c
Flags: bus master, medium devsel, latency 64, IRQ 58
Memory at dfffe000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
01:0a.1 0480: 109e:0878 (rev 11)
Subsystem: 008a:763c
Flags: bus master, medium devsel, latency 64, IRQ 58
Memory at dffff000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
It was being detected as a GENERIC UNKNOWN CARD both by the 2.6.18
kernel and the latest v4l-dvb drivers, but it did not work at all. The
card has sixteen (16) BNC video inputs, four of them on the board itself
and twelve on three daughter-cards. It has a single bt878 chip, no tuner
and what looks like and audio input. After doing some research I managed
to get only eight channels working by forcing card=125 and those DID NOT
match channels 0-7 on the card, and no audio.
Based on what was working for card=125, I added the card definition
block, added a specific muxsel routine and got the card working fully
with xawtv, where the sixteen channels show up as Composite0 to
Composite15, matching the channel labels in the card and daughter-cards.
I have made no efforts yet to get audio working, but would appreciate
any pointers.
Signed-off-by: Ernesto Hernández-Novich <emhn@usb.ve>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The PixelView PlayTV card definition structure was missing initialization of
the tuner_addr and radio_addr fields. As a result it was impossible to have the
tuner initialized using parameters specified while loading the bttv.ko module.
This regression became visible after the v4l rearrangements introduced
somewhere around 2.6.15 kernel version.
The root cause for the tuner initialization failure is located in the
attach_inform function in the bttv-i2c.c file.
There at the very beginning the addr variable holding the tuner device address
is initialized with the value taken from the bttv_tvcards array.
For the PixelView PlayTV card the tuner address field (and the radio address as
well) was uninitialized, and thus equal 0. Later in that function execution of
the TUNER_SET_TYPE_ADDR tuner command is guarded with check for the tuner
address either equal ADDR_UNSET, or client->addr.
Since both are non-zero (the latter in case of the card owned by me at the
runtime is equal 0x61) the TUNER_SET_TYPE_ADDR command is not executed, and
consequently in the tuner_attach function in the tuner-core.c file call to
i2c_attach_client does not result in assigning the tuner type variable with the
requested value.
Providing initialization of the tuner_addr and radio_addr with ADDR_UNSET
values as it is already done for other tv cards defined in bttv-cards.c ensures
that the tuner initialization is done correctly, just as it used to be in the
2.6.14 kernel.
Signed-off-by: Wojciech Migda <wojtek.golf@interia.pl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
videobuf-dma-sg does not need to depend on PCI. Switch it to using generic
DMA API, convert all affected drivers, relax Kconfig restriction, improve
compile-time type checking, fix some Coding Style violations while at it.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
- Static memory is always initialized with 0.
- Replaced in some cases C99 comments for /* */
Signed-off-by: Douglas Schilling Landgraf <dougsland@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
