Steven Toth [Sat, 19 Apr 2008 00:34:00 +0000 (21:34 -0300)]
V4L/DVB (7621): Add support for Hauppauge HVR950Q/HVR850/FusioHDTV7-USB
Including support for the AU0828 USB Bridge.
Including support for the AU8522 ATSC/QAM Demodulator.
Including support for the AU8522 ATSC/QAM Demodulator.
Signed-off-by: Steven Toth <stoth@hauppauge.com> 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).
V4L/DVB (7610): em28xx: Select reg wait time based on chip ID
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.
V4L/DVB (7603): em28xx-dvb: don't use videobuf-dvb
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.
V4L/DVB (7598): em28xx: several fixes on gpio programming
em28xx-cards.c:
- Fix reversed val/rst values in both analog_gpio and digital_gpio
vectors
- Fix crash that would was occurring during every analog startup
while looping over gpio_ctl
- Remove what appears to be a redundant setting of gpio_ctl->val
- Don't use OREN538 demodulation for the HVR-950 (prevents ATSC
scanning from working)
em28xx-dvb.c:
- Tuner should be in digital mode when issuing the reset
- Add copyright
- Change struct definition (corresponds to fix in em28xx-cards.c for
gpio_ctl looping)
V4L/DVB (7597): em28xx: share the same xc3028 setup for analog and digital modes
Thanks to Devin Heitmueller <devin.heitmueller@gmail.com> and Aidan
Thornton" <makosoft@googlemail.com> for pointing some errors with the
previous scenario.
V4L/DVB (7593): em28xx: add a module to handle dvb
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.
David Hilvert [Wed, 16 Apr 2008 07:27:09 +0000 (04:27 -0300)]
V4L/DVB (7589): ibmcam: improve support for the IBM PC Camera Pro
This patch modifies Dmitri's original ibmcam driver for Linux to improve
support for the IBM PC Camera Pro. It may also offer improved support for
other models classified by the driver as 'Model 3', such as the IBM PC Camera
Pro Max.
See http://auricle.dyndns.org/xvp610/
Signed-off-by: David Hilvert <dhilvert@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
V4L/DVB (7580): Fix concurrent read from /proc/videocodecs
Observation one: ->write_proc and ->data assignments aren't needed. Removed.
Observation two: codecs lists are unprotected. Patch doesn't fix this.
Observation three:
/proc/videocodecs printout is done to temporary _global_ buffer which
is freed in between. Consequently, two users hitting this file can
screwup each other.
Steps to reproduce:
modprobe videocodec
while true; do cat /proc/videocodecs &>/dev/null; done &
while true; do cat /proc/videocodecs &>/dev/null; done &
The fix is switching to seq_files, this removes code, especially some
line-length "logic".
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Acked-by: Jan Kara <jack@suse.cz> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Due to the patch order change, pvrusb2 were broken. So, changeset 4c3b01f71181a52ab7735a7c52b1aa2232826075 were applied at mainstream to fix.
After the pvrusb2 changes, this patch is no longer required and should be
reverted.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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.
V4L/DVB (7566): videobuf-dvb: allow its usage with videobuf-vmalloc
videobuf-dvb were still using a function that were videobuf-dma-sg
dependent. This patch creates a generic handler for this function. This
way, videobuf-dvb can now work with all videobuf implementations.
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.
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.
Brandon Philips [Fri, 28 Mar 2008 17:18:33 +0000 (10:18 -0700)]
V4L/DVB (7562): videobuf: Require spinlocks for all videobuf users
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.
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.
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.
V4L/DVB (7548): Various fixes for the em28xx videobuf code
- 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.
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.
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.
Janne Grunau [Wed, 9 Apr 2008 22:13:13 +0000 (19:13 -0300)]
V4L/DVB (7538): Adds selectable adapter numbers as per module option
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 <mchehab@infradead.org>
Hans Verkuil [Wed, 9 Apr 2008 09:26:17 +0000 (06:26 -0300)]
V4L/DVB (7535): saa717x: add new audio/video decoder i2c driver
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.
V4L/DVB (7531): budget-av: Fix CI interface on (some) KNC1 DVBS cards
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: Oliver Endriss <o.endriss@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
V4L/DVB (7530): budget-av: Fix support for certain cams
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: Christoph Pfister <pfister@linuxtv.org> Signed-off-by: Oliver Endriss <o.endriss@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
projects / karo-tx-linux.git / log