- 24 Apr, 2008 40 commits
-
-
Mauro Carvalho Chehab authored
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>
-
Brandon Philips authored
A spinlock is necessary for queue_cancel to work with every driver in the tree. Otherwise a race exists between IRQ handlers removing buffers from the queue and queue_cancel invalidating the queue. Signed-off-by:
Brandon Philips <bphilips@suse.de> Signed-off-by:
-
Mauro Carvalho Chehab authored
Before the patch, there were a risk of freeing and unmapping userspace memory, while there were pending requests. Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Aidan Thornton authored
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 authored
It seems that we don't need a timeout for em28xx. Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
There were a small bug on videobuf-vmalloc that were preventing STREAMOFF to work. The issue is that vmalloc'ed mmaped memory should only be freed after being sure that there aren't any mmap usage. Otherwise, the memory remap will stop working, and the userspace won't receive any frames. This bug were affecting some userspace applications, like tvtime. After this patch, tvtime started to work again with the drivers that use videobuf-vmalloc. Signed-off-by: -
Mauro Carvalho Chehab authored
There were some bugs on videobuf-vmalloc. Basically, remap were called with a wrong parameter. Due to that, a later remap were needed, generating the need of some hacks on videobuf-vmalloc and videobuf-core. This patch fixes the remap and removes the hacks. TODO: - V4L2_MEMORY_USERPTR is not implemented yet. This method should be properly implemented, in order to work with a few userspace applications. - The driver also doesn't implement V4L2_MEMORY_OVERLAY. This method is used only by a few applications, and are becaming obsolete, due to the increment of cpu performance. So, most apps prefer to retrieve data to an internal buffer, doing some processing like de-interlacing. Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Brandon Philips authored
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:
-
Mauro Carvalho Chehab authored
- Remove dead code; - Fix a few CodingStyle issues; - Prints frame number, if debug is enabled. Signed-off-by: -
Aidan Thornton authored
- 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:
-
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
The last videobuf changes introduced several CodingStyle errors. Fixes all those errors, as reported by checkpatch.pl Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Also removes the dead restart_video_queue() function Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Aidan Thornton authored
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:
-
Mauro Carvalho Chehab authored
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: -
Janne Grunau authored
The adapter_nr module options can be used to allocate static adapter numbers on a driver level. It avoids problems with changing DVB apapter numbers after warm/cold boot or device unplugging and repluging. Each driver holds DVB_MAX_ADAPTER long array of the preferred order of adapter numbers. options dvb-usb-dib0700 adapter_nr=7,6,5,4,3,2,1,0 would result in a reversed allocation of adapter numbers. With adapter_nr=2,5 it tries first to get adapter number 2 and 5. If both are already in use it will allocate the lowest free adapter number. Signed-off-by:
Janne Grunau <janne-dvb@grunau.be> Acked-by:
Hermann Pitton <hermann.pitton@arcor.de> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
If frontend is not attached, both cx88-dvb and saa7134-dvb don't register DVB. However, dvb unregister were inconditionally called. Due to that, an OOPS is generated. Signed-off-by: -
Hans Verkuil authored
Added the last remaining out-of-tree kernel driver from the ivtv project. The saa717x is used in several Japanese cards and a Russian card. The driver is not complete in that only NTSC is supported and no PAL/SECAM. Hopefully this will be added in the future. Signed-off-by:
Takahiro Adachi <tadachi@tadachi-net.com> Signed-off-by:
Kyuma Ohta <whatisthis@jcom.home.ne.jp> Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Oliver Endriss authored
Implement support for Fujitsu Siemens DVB-T Activy Budget, sub-system id 0x1131:0x5f61. Signed-off-by:
Oliver Endriss <o.endriss@gmx.de> Signed-off-by:
-
Christoph Pfister authored
Quoting the commit introducing reinitialise_demod (3984 / by adq): "These cards [KNC1 DVBT and DVBC] need special handling for CI - reinitialising the frontend device when the CI module is reset." Apparently my 1894:0010 also needs that fix, because once you initialise CI/CAM you lose lock. Signed-off-by:
Christoph Pfister <pfister@linuxtv.org> Signed-off-by:
-
Christoph Pfister authored
The current ci implementation doesn't accept 0xff when reading data bytes (address == 0), thus breaks cams which report a buffer size of 0x--ff like my orion one. Remove the 0xff check altogether, because validation is really the job of a higher layer. Signed-off-by:
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
-
