Some devices use a separate interface for the vendor audio class.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Export ac97 volume controls via mixer.

Pulseaudio will probably handle it very badly, as it has
no idea about how volumes are wired, and how are they
associated with each TV input. Those wirings are
card model dependent, and we don't have the wiring mappings
for each supported device.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fixes most cases of initializing a var but not using it.

There are still 3 cases at em28xx-alsa, were those vars should
probably be used.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NSteve Kerrison <steve@stevekerrison.com>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

EM28174 is very similar as already supported EM2874.
I am not sure what are differences, but it could be analog support.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The "dev" variable is used as a list cursor in a list_for_each_entry()
loop and can never be null here so I removed the check.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

For more clearance what the functions actually do,

  usb_buffer_alloc() is renamed to usb_alloc_coherent()
  usb_buffer_free()  is renamed to usb_free_coherent()

They should only be used in code which really needs DMA coherency.

All call sites have been changed accordingly, except for staging
drivers.
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Pedro Ribeiro <pedrib@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Serialize DVB initialization, to avoid it to happen while analog
initialization is still happening.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It turns up we can reduce the starting line for the active area, which results
in more data being captured when under PAL (while the full VBI capture window
still stays properly encoded).

This work was sponsored by EyeMagnet Limited.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

Make the VBI support work for PAL standards in addition to NTSC.

This work was sponsored by EyeMagnet Limited.

Thanks go out to Andy Walls for providing a CD containing test PAL/VBI captures
and to Steven Toth for providing a PVR-350 to do signal generation with.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix all device drivers to use the video_drvdata function instead of
maintaining a local list of minor to private data mappings. Call
video_set_drvdata to register the driver private pointer when not
already done.

Where applicable, the local list of mappings is completely removed when
it becomes unused.

[mchehab.redhat.com: removed tm6000 changes as tm6000 is not ready yet for submission even on staging]
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

With em2800 hardware, AC97 hardware can be detected even when it doesn't
exist. If, after probing for AC97, the driver won't find a companion
chip, simply prevents the load of the audio modules.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It seems that some patch broke alt modprobe parameter. Fix it to allow
changing alternate interfaces during module load and at runtime.

If changed during runtime, you'll need to stop a and restart stream for
the parameter to be used.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Do not create the VBI device in cases where VBI is not supported on the target
em28xx chip.

This work was sponsored by EyeMagnet Limited.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add support for raw VBI capture for the em28xx bridge, currently only for
NTSC.  Support for PAL capture to follow shortly (including the removal of
numerous hard-coded NTSC-specific sizes for capture buffers, etc).

Note that the code currently changes the default current norm from PAL to
NTSC (so that zvbi-ntsc-cc works properly).  The default norm really should
be moved into a board-level parameter.

This work was sponsored by EyeMagnet Limited.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add code enabling the VBI registers for variants of the em28xx chip that
support VBI, and make sure the isoc streaming code continues to work for
the video component of the stream (note the video and vbi data arrive
intermixed on the same isoc pipe).

Note that this version just drops the actual VBI data onto the floor as
opposed to processing it.  The "#ifdef 0" tags are for the videobuf code that
appears in the next patch in this series.

We created a separate version of the isoc_copy version for parsing the version
of the stream that includes VBI data.  In theory, they might be able to be
merged at some point in the future, but the initial goal is to ensure that we
do not cause any regressions with devices that do not have VBI support.

This work was sponsored by EyeMagnet Limited.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Register 0x13 seems to be a sort of image control, maybe gamma, white
level or black level. Lower values produce better images, while higher
values increases the contrast and shifts colors to green. 0xff produces
a black image. This register is not Silvercrest-specific, so its code
should be moved to a better place.

If this register is left alone, a random value can be found at the
register, producing weird results.

While here, let's remove register 0x0d, as it had no noticed effect at
the image.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Due to historical reasons, em28xx driver gets two consecutive frames and
fold them into an unique framing, doing interlacing. While this works
fine for TV images, this produces two bad effects with webcams:

1) webcam images are progressive. Merging two consecutive images produce
interlacing artifacts on the image;

2) since the driver needs to get two frames, it reduces the maximum
frame rate by two.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Depending on the video input format, vinmode/vinctl needs adjustments.
For TV, this is not relevant, since the supported decoders output data
at the same format. However, webcam sensors may have different formats,
so, this needs to be adjusted based on the device.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

While trying to fix an mt9v001 webcam, I noticed that HSCALE/VSCALE do
work with em28xx + webcam. The issue is that the scaling setup depends
on the number of visible rows/cols of the input image.

With mt9v011 (Silvercrest), the resolution is 640x480. So, the scaling
is different from a normal TV image (720x480 on NTSC). This were causing
a wrong scaling and a previous patch disabled scaling.

As each sensor have their different resolution setting, the xres/yres
should be adjusted accordingly with the input sensor.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Just renames the flag, to use a clearer name. Later patches will use
this flag to properly set some drivers behaviors for webcams.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Discovered the bug that were limiting the output format to just RGB565.
Now, it is possible to output image at Bayer format (the original one,
as generated by Silvercrest sensor, and two others), and also on YUY.

Adds Bayer formats also to the driver.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This webcam uses a em2710 chipset, that identifies itself as em2820,
plus a mt9v011 sensor, and a DY-301P lens.

It needs a few different initializations than a normal em28xx device.

Thanks to Hans de Goede <hdegoede@redhat.com> and Douglas Landgraf
<dougsland@redhat.com> for providing the acces for the webcam during
this weekend, I could make a patch for it while returning back from
FISL/Fudcom LATAM 2009.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In cases where the device does not actually provide a USB audio class *or*
vendor audio, do not load the driver that provides vendor audio support (such
as the KWorld 2800d).  Otherwise, the /dev/audio1 device file gets created and
users get confused.

Also, reworks the logic a bit so that we don't try to inspect the register
content if the register read failed entirely.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The em28xx actually has a register that tells the driver what the maximum
packet size is (based on a value programmed into the eeprom).  Make use of
that register instead of assuming a hardcoded value of 564 (since 564 is not
correct for devices that do QAM such as the KWorld 340u).

Note that for now the em2874 code isn't there, falling back to the 564 value,
however this is not a problem since there are not any em2874 based devices in
the current v4l-dvb tree).

Thanks to Jarod Wilson for detecting the initial problem and figuring out that
the isoc configuration was wrong for his device.

Cc: Jarod Wilson <jarod@wilsonet.com>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix typo usbtransfer->usb transfer on em28xx_errdev message.
Signed-off-by: NFilipe Rosset <rosset.filipe@gmail.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It is no longer needed to use a struct pointer as argument, since v4l2_subdev
doesn't require that ioctl-like approach anymore. Instead just pass the input,
output and config (new!) arguments directly.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Converted em28xx driver to v4l2_subdev.
Thanks to Hans Verkuil <hverkuil@xs4all.nl> for helping this conversion.
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add missing URB_NO_TRANSFER_DMA_MAP flag, since	the use	of consistent memory
is not permitted for DMA on the ARM platform.

Thanks to Paul Thomas <pthomas8589@gmail.com> for providing sample ARM
hardware that was experiencing the oops (tested on the at91rm9200 based
LinuxStamp).

Thanks to David Brownell <david-b@pacbell.net> for providing insight into the
ARM memory architecture.
Signed-off-by: NDevin Heitmueller <dheitmueller@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Compro VideoMate uses an external audio DSP chip, controlled via tvaudio
module (tda9874a). This patch improves em28xx infrastructure to support
an external audio processor and fixes the Compro VideoMate entry to work
with it.
Signed-off-by: NVitaly Wool <vital@embeddedalley.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Lots of coding style fixes and a typo correction for em28xx.

[dougsland@redhat.com: fixed a reject due to a change on em28xx-audio.c]
Signed-off-by: NNicola Soranzo <nsoranzo@tiscali.it>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix for em28xx memory leak and function rename
Signed-off-by: NRobert Krakora <rob.krakora@messagenetsystems.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Clock (XCLK) Cleanup
Signed-off-by: NRobert Krakora <rob.krakora@messagenetsystems.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Trace:  (Provided by Douglas)

BUG: sleeping function called from invalid context at drivers/usb/core/urb.c:558
in_atomic():0, irqs_disabled():1
Pid: 4918, comm: sox Not tainted 2.6.27.5 #1
 [<c04246d8>] __might_sleep+0xc6/0xcb
 [<c058c8b0>] usb_kill_urb+0x1a/0xd8
 [<c0488e68>] ? __kmalloc+0x9b/0xfc
 [<c0488e85>] ? __kmalloc+0xb8/0xfc
 [<c058cd5a>] ? usb_alloc_urb+0xf/0x31
 [<f8dd638c>] em28xx_isoc_audio_deinit+0x2f/0x6c [em28xx_alsa]
 [<f8dd6573>] em28xx_cmd+0x1aa/0x1c5 [em28xx_alsa]
 [<f8dd65e1>] snd_em28xx_capture_trigger+0x53/0x68 [em28xx_alsa]
 [<f8aa8674>] snd_pcm_do_start+0x1c/0x23 [snd_pcm]
 [<f8aa85d7>] snd_pcm_action_single+0x25/0x4b [snd_pcm]
 [<f8aa9833>] snd_pcm_action+0x6a/0x76 [snd_pcm]
 [<f8aa98f5>] snd_pcm_start+0x14/0x16 [snd_pcm]
 [<f8aae10e>] snd_pcm_lib_read1+0x66/0x273 [snd_pcm]
 [<f8aac5a3>] ? snd_pcm_kernel_ioctl+0x46/0x5f [snd_pcm]
 [<f8aae4a7>] snd_pcm_lib_read+0xbf/0xcd [snd_pcm]
 [<f8aad774>] ? snd_pcm_lib_read_transfer+0x0/0xaf [snd_pcm]
 [<f89feeb6>] snd_pcm_oss_read3+0x99/0xdc [snd_pcm_oss]
 [<f89fef9c>] snd_pcm_oss_read2+0xa3/0xbf [snd_pcm_oss]
 [<c064169d>] ? _cond_resched+0x8/0x32
 [<f89ff0be>] snd_pcm_oss_read+0x106/0x150 [snd_pcm_oss]
 [<f89fefb8>] ? snd_pcm_oss_read+0x0/0x150 [snd_pcm_oss]
 [<c048c6e2>] vfs_read+0x81/0xdc
 [<c048c7d6>] sys_read+0x3b/0x60
 [<c04039bf>] sysenter_do_call+0x12/0x34
 =======================

The culprit in the trace is snd_pcm_action() which invokes a spin lock
which disables pre-emption which disables an IRQ which causes the
__might_sleep() function to fail the irqs_disabled() test.  Since
pre-emption is enabled then it is safe to de-allocate the memory if
you first unlink each URB.  In this instance you are safe since
pre-emption is disabled.  If pre-emption and irqs are not disabled then
call usb_kill_urb(), else call usb_unlink_urb().

Thanks to Douglas for tracking down this bug originally!!!

[dougsland@redhat.com: Fixed codyingstyle]
Signed-off-by: NRobert Krakora <rob.krakora@messagenetsystems.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix for KWorld 330U AC97

Many thanks to Devin and Mauro again!!!
Signed-off-by: NRobert Krakora <rob.krakora@messagenetsystems.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some em28xx devices use the PCM IN AC 97 PIN for digital audio. However,
currently, the PCM IN selection is not set by the driver. This patch allows
specifying the PCM IN expected output, via board description table.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

/home/v4l/master/v4l/em28xx-core.c:396:25: warning: symbol 'outputs' was not declared. Should it be static?
/home/v4l/master/v4l/em28xx-input.c:324:6: warning: symbol 'em28xx_ir_start' was not declared. Should it be static?
/home/v4l/master/v4l/em28xx-cards.c:1925:5: warning: symbol 'em28xx_init_dev' was not declared. Should it be static?
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>