Fix a NULL pointer dereference that would occur if the video decoder tied to
the em28xx supports the VIDIOC_INT_RESET call (for example: the cx25840 driver)
Signed-off-by: Devin Heitmueller <dheitmueller@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Newer versions of hald tries to open it to call QUERYCAP.
Due to the lack of a proper locking, it is possible to open the device
before it finishes initialization.
This patch adds a lock to avoid this risk, and to protect the list of
em28xx devices.
While here, remove the uneeded BKL lock.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that we have a polling task for IR, there's a race condition, since
IR can be polling while other operations are being doing. Also, we are
now sharing the same urb_buf for both read and write control urb
operations. So, we need a mutex.
Thanks to Davin Heitmueller <devin.heitmueller@gmail.com> for warning me.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
em28xx_init_dev() has some error conditions that are not properly
de-allocating dev var, nor freeing the device number for a future usage.
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>
The v4l core creates four different video devices (video, vbi, radio, vtx)
and each has its own range of minor numbers. However, modern devices keep
increasing the number of devices that they need so a maximum of 64 video
devices will not be enough in the future. In addition this scheme makes
it very hard to add new device types.
This patch disconnects the kernel number allocation (e.g. video0, video1,
etc.) from the actual minor number (just pick the first free minor).
This allows for much more flexibility in the future. However, it does
require the use of udev. For those who cannot use udev a new CONFIG option
was created that changes the allocation scheme back to the old behavior.
Thanks to Greg KH for suggesting this approach during the 2008 LPC.
In addition, several bugs were fixed in the ivtv and cx18 drivers: these
drivers try to allocate specific kernel numbers but that scheme contained
a bug which caused what should have been e.g. video17 to appear as e.g.
video2.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixed and Added some validations
Signed-off-by: Douglas Schilling Landgraf <dougsland@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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>
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 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>
em28xx-cards.c
em28xx-input.c
em28xx-video.c
em28xx.h
- Add support for the PointNix Intra-Oral Camera, which required addition of
a construct for reading the "snapshot" button (provided on the em2860 and
em2880 chips, but this is the first case where I have seen it actually used
in a product). The button is wired to pin 56 on the em2880.
http://www.pointnix.com/ENG/dental/product_02.asp
Thanks to Roberto Mantovani <rmantovani@libero.it> for testing the changes
Signed-off-by: Devin Heitmueller <devin.heitmueller@gmail.com>
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>
em28xx-video.c
- Properly handle loading of the module when multiple devices are already
connected (such as at bootup). Before we were only calling dvb_init()
against the last device in the list, so while we were handling subsequent
adds properly, if there were multiple devices present on driver load,
everybody except the last device would not get initialized.
Signed-off-by: Devin Heitmueller <devin.heitmueller@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Before this patch, HVR900/HVR950 were incorreclty going back to analog. The
result is that only digital were working.
This patch provides the proper setup for analog/digital and tuner callback.
It also properly resets analog into a sane state at open().
Thanks to Steven Toth <stoth@linuxtv.org> and Michael Krufky <mkrufky@linuxtv.org>
for helping to set the proper parameters to GPO/GPIO em2883 ports.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Now, all registers will follow the same convension:
EM28XX_R<reg_number>_<reg_name>
This allows to associate a register with its value, and also with a canonical
name. Also, registers that are specific to a given chip were renamed accordingly,
as EM2800_foo (for 2800 only registers) or EM2880_foo (for registers that started
to appear on em2880).
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This is more conservative than just removing the msleep() from
em28xx_write_regs_req(), since some old hardware may still need it.
So, it will remove the sleep time only for those chips where this
removal were tested.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Modifies em28xx-dvb not to use videobuf-dvb, but instead to include the code
for registering dvb devices locally and use the URB management code in the
em28xx driver directly. DVB data streaming should now work.
Signed-off-by: Aidan Thornton <makosoft@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Move the URB setup and management code to em28xx-core.c and generalise
it slighlty so that the DVB code can use it.
Signed-off-by: Aidan Thornton <makosoft@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This patch adds em28xx-dvb. This driver is highly based on cx88-dvb and
saa7134-dvb.
This code currently loads and unloads successfully. However, some
changes are needed to properly support the mpeg streams and to setup
em28xx to work on DVB mode.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Removes some fields from data structs.
There are some fields that are just caching some calculus for buffer
size. The calculus were moved to the places it were needed and the now
unused fields were removed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This patch fixes three related issues and a fourth trivial one:
- Use buffers even if no-one's currently waiting for them (fixes
underrun issues);
- Don't return incomplete/mangled frames at the start of streaming and
in the case of buffer underruns;
- Fix an issue which could cause the driver to write to a buffer that's
been freed after videobuf_queue_cancel is called (exposed by the
previous two fixes - for some reason, ignoring buffers that weren't
being waited on worked around the issue);
- Fix a bug which could cause only one field to be filled in the first
buffer (or first few buffers) after streaming is started.
Signed-off-by: Aidan Thornton <makosoft@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
There are some cases where nobody is waiting for a buffer. Due to the
lack of check, if you try to abort the userspace app, machine were
hanging, since IRQ were trying to use a buffer that were disallocated.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Currently, vidioc_s_fmt_cap is allowed even if streaming is running on some
other fh. This is likely to cause issues.
Block use of vidioc_s_fmt_cap if someone else has claimed access to the device.
Signed-off-by: Aidan Thornton <makosoft@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
I did notice a possible memory leak since iolock is could possibly be
called before a buffer has been freed.
This ensure s_fmt isn't called while the queue is busy thereby avoiding
iolock on already allocated buffers.
Signed-off-by: Brandon Philips <bphilips@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
- Remove dead code;
- Fix a few CodingStyle issues;
- Prints frame number, if debug is enabled.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
- Aborting buffer_filled if no-one's waiting on the waitqueue probably isn't
what we want, since just because no-one's waiting for it now doesn't mean they
wouldn't dequeue it in time. (vivi gets away with this, possibly because it
can fill each buffer much faster.)
- The first BUG_ON(lencopy <= 0); really isn't worth causing a kernel panic
over, especially since there are some reasons why it could trigger in normal use.
- The top and botom frames are actually the wrong way around.
Signed-off-by: Aidan Thornton <makosoft@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The last videobuf changes introduced several CodingStyle errors. Fixes all those
errors, as reported by checkpatch.pl
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
It fixes a couple of minor bugs, comments out a bogus BUG_ON, sets fh->type
correctly, uses dev->width and dev->height for now, and adds a missing spinlock
init (nasty - caused a system lockup). It also adds some debug code which
probably isn't all that useful. I haven't tested this version of the patch yet,
though, so I'm not sure what you can expect if you try it.
Signed-off-by: Aidan Thornton <makosoft@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The usage of videobuf-vmalloc allows to cleanup em28xx logic.
Also, it reduced its size by about 5.42% on i386 arch (and about 7.5% on x86_64):
39113 4876 40 44029 abfd old/em28xx.ko
36731 4868 40 41639 a2a7 /home/v4l/master/v4l/em28xx.ko
Also, the preliminary tests, made on a single core 1.5 MHz Centrino showed
that CPU usage reduced from 42%-75% to 28%-33% (reports from "top") command.
A test with time command presented an even better result:
This is the performance tests I did, running code_example to get 1,000 frames
@29.995 Hz (about 35 seconds of stream), tested on a i386 machine, running at
1,5GHz:
The old driver:
$ time -f "%E: %Us User time, %Ss Kernel time, %P CPU used" ./capture_example
0:34.21: 8.22s User time, 25.16s Kernel time, 97% CPU used
The videobuf-based driver:
$ time -f "%E: %Us User time, %Ss Kernel time, %P CPU used" ./capture_example
0:35.36: 0.01s User time, 0.05s Kernel time, 0% CPU used
Conclusion:
The time consumption to receive the stream where reduced from about 33.38
seconds to 0.05 seconds.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
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>
em28xx driver is capable of handling more than one usb device. However, isoc
transfers require a large amount of data to be transfered.
Before this patch, just one em28xx board were enough to allocate more than 50%
URBs:
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 8
B: Alloc=480/800 us (60%), #Int= 0, #Iso= 2
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
So, only one board could use an USB host at the same time. After the patch, it
is possible to use more than one em28xx at the same time, on the same usb host,
if the image size is slower or equal to 345600, since those images will
require about 30% of the URBs:
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 8
B: Alloc=232/800 us (29%), #Int= 0, #Iso= 2
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
So, in thesis, after the patch, it would be possible to use up to 3 boards by
each usb host, if the devices are generating small images.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Improves audio configurations on em28xx:
- mutes audio before changing amux;
- adds a delay after setting audio src;
- waits up to 50ms for ac97 busy.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
