Signed-off-by: NDouglas Schilling Landgraf <dougsland@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The analog entries are wrong. Fix it.
Signed-off-by: NMauro 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: NAidan Thornton <makosoft@googlemail.com>
Signed-off-by: NMauro 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: NAidan Thornton <makosoft@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Adds the correct GPIOs and demod attach code for the HVR-900
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This will make tuner-xc2028 to change to analog, if needed.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Thanks to Devin Heitmueller <devin.heitmueller@gmail.com> for pointing
this issue.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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)
Signed-off-by: NDevin Heitmueller <devin.heitmueller@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Thanks to Devin Heitmueller <devin.heitmueller@gmail.com> and Aidan
Thornton" <makosoft@googlemail.com> for pointing some errors with the
previous scenario.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This patch adds DVB support for Hauppauge HVR950.

Thanks to Michael Krufky <mkrufky@linuxtv.org> for getting those values.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

em28xx based devices with xc3028 may require some specific gpio values.
This patch adds a generic handling for such values.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Some devices have msp3400 audio decoder chip. Selects it, if em28xx.
Signed-off-by: NMauro 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: NMauro 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: NMauro 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: NAidan Thornton <makosoft@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro 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: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro 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: NAidan Thornton <makosoft@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

It seems that we don't need a timeout for em28xx.
Signed-off-by: NMauro 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: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

- Remove dead code;
- Fix a few CodingStyle issues;
- Prints frame number, if debug is enabled.
Signed-off-by: NMauro 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: NAidan Thornton <makosoft@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro 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: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Also removes the dead restart_video_queue() function
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro 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: NAidan Thornton <makosoft@googlemail.com>
Signed-off-by: NMauro 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: NMauro Carvalho Chehab <mchehab@infradead.org>

__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro 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: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NSascha Sommer <saschasommer@freenet.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

- Static memory is always initialized with 0.
- Replaced in some cases C99 comments for /* */
Signed-off-by: NDouglas Schilling Landgraf <dougsland@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

be less silly while we're there.
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

In commit e6bafba5, a bug was fixed that
involved converting !x & y to !(x & y).  The code below shows the same
pattern, and thus should perhaps be fixed in the same way.

This is not tested and clearly changes the semantics, so it is only
something to consider.

The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@@ expression E1,E2; @@
(
  !E1 & !E2
|
- !E1 & E2
+ !(E1 & E2)
)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Thanks to Alan Stern <stern@rowland.harvard.edu> for pointing this issue.
Signed-off-by: NMauro 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: NMauro Carvalho Chehab <mchehab@infradead.org>