As protocol decoders are specific to InfraRed, keep their names as-is.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

cx88 only depends on VIDEO_IR because it needs ir_extract_bits().
Move that function to ir-core.h and make it inline.

Lots of drivers had dependencies on VIDEO_IR when they really
wanted IR_CORE.

The only remaining drivers to depend on VIDEO_IR are bt8xx and
saa7134 (ir_rc5_timer_end is the only function exported by
ir-functions).

Rename VIDEO_IR -> IR_LEGACY to give a hint to anyone writing or
converting drivers to IR_CORE that they do not want a dependency
on IR_LEGACY.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch removes the remaining usages of the ir_input_nokey() and
ir_input_keydown() functions provided by drivers/media/IR/ir-functions.c
by using the corresponding functionality in ir-core instead.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch converts the cx88 driver (for sampling hw) to use the
decoders provided by ir-core instead of the separate ones provided
by ir-functions (and gets rid of those).

The value for MO_DDS_IO had a comment saying it corresponded to
a 4kHz samplerate. That comment was unfortunately misleading. The
actual samplerate was something like 3250Hz.

The current value has been derived by analyzing the elapsed time
between interrupts for different values (knowing that each interrupt
corresponds to 32 samples).

Thanks to Mariusz Bialonczyk <manio@skyboo.net> for testing my patches
(about one a day for two weeks!) on actual hardware.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Convert the driver to use regulator framework instead of set_power callback.
This with gpio_reset platform data provide cleaner way to manage chip VIO,
VDD and reset signal inside the driver.
Signed-off-by: NJarkko Nikula <jhnikula@gmail.com>
Cc: Eduardo Valentin <eduardo.valentin@nokia.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Because some clients (e.g. tvtime) will just open the filehandle and call
read() instead of explicitly calling streamon first, we need to make sure the
VBI timeout routine gets enabled in this case.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The first pass of fixes to cause the driver to continue streaming even when
there is no video arriving over the ITU656 bus were not adequate.  Continue
the work from the previous patch.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We need the au0828 to continue delivering frames even when the device is not
delivering video, or else applications such as tvtime will block indefinitely.

Unfortunately, the au8522 doesn't have any sort of free-running mode or "blue
screen on no video" like some other decoders.

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

Tweak the comb filter config when in s-video mode to match the Hauppauge
Windows driver values (based on register dumps).

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

Straighten out the clamp control configurations for the various video modes,
based off of register diffs done against the Hauppauge Windows driver.

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

Cleanup the routine which disables the audio decoder.  In particular, the i2s
output was being shut off but the audio processor itself was not, resulting
in more power being consumed than needed.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix the alignment of fields being delivered by the driver, which was
resulting in jerky video when there was horizontal motion (since the bottom
field of the frame was being sent with the top field of the previous frame)

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

We had the max packets per URB set to an incredibly low "10" as opposed to
the Windows driver which has it as 128.  Set the value to match the
Windows driver, which will reduce interrupts considerably.

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

The chip's default value for the brightness didn't match what we were sending
back in the queryctrl ioctl(), so if the application actually set the
brightness to the "default", it would actually end up being way too bright.

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

Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The bad value prevented the autogain to work correctly
and some images were truncated.
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Generate a release button event when the button is still pressed when the
stream stops.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

gspca_xirlink_cit: Add support camera button
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

At least on the ibm netcam pro frames have a 4 byte footer, take this
into account when calculating sizeimage.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The following usb bandwidth allocation changes were made to the ibm netcam
pro code:
- Don't restart negotiation at max packet size on stop0, as that gets called
  by gspca_main during negotiation. Move this to sd_isoc_init.
- Don't ask for full bandwidth when running at 160x120, that does not need
  full bandwidth
- Make minimum acceptable bandwidth depend upon resolution

[mchehab@redhat.com: Fix CodingStyle problems at switch statements]
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently alloc_and_submit_int_urb() is setting gspca->int_urb
as soon as the allocation has succeeded, but if the subsequent
submit fails, the urb gets destroyed. And then later will
get destroyed again in gspca_input_destroy_urb() because
gspca->int_urb is set, leading to a double free.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently gspca supported usb-1.1 webcams for which we support the input
button through an interrupt endpoint won't stream (not enough bandwidth
error) when used through an USB-2.0 hub.

After much debugging I've found out that the cause for this is that the
ehci-sched.c schedeling code does not like it when there are already urb's
scheduled when (large) isoc urbs are queued. By moving the submission
of the interrupt urbs to after submitting the isoc urbs the camera
starts working again through usb-2.0 hubs.

Note that this does not fix isoc. streaming through a usb-hub while another
1.1 usb device (like the microphone of the same cam) is also active
at the same time :(

I've spend a long time analyzing the linux kernel ehci scheduler code,
resulting in this (long) mail:
http://www.spinics.net/lists/linux-usb/msg37982.html

The conclusion of the following mail thread is that yes there are several
issues when using usb-1.1 devices through a usb-2.0 hub, but these are not
easily fixable in the current code. Fixing this in ehci-sched.c requires
an almost full rewrite, which is not bound to happen anytime soon.

So with this patch gspca driven usb-1.1 webcams will atleast work when
connected through an usb-2.0 hub when the microphone is not used.

As an added bonus this patch avoids extra destroy/create input urb cycles
when we end up falling back to a lower speed alt setting because of bandwidth
limitations.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

DM04/QQBOX USB Timing change.

Improved timing to avoid USB corruptions on some systems.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Improved frontend handling.

Frontend now remains open at all times, with signal lock, snr & signal level
polled from Interupt.

Updated driver for DM04/QQBOX USB DVB-S BOXES to version 1.70.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If you suspend and resume during video capture, the video colours
are corrupted on resume. This is because the sensor is being unconditionally
powered off during the resume path.

Only power down during resume if the camera is not in use, and correctly
reconfigure the sensor during resume.
Fixes http://dev.laptop.org/ticket/10190Signed-off-by: NDaniel Drake <dsd@laptop.org>
Acked-by: NJonathan Corbet <corbet@lwn.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Converted if (debug >= 2) printk(KERN_DEBUG... to if debug >= 2) dprintk(...)
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

Although cx231xx has a very good IR support, already supported by
mceusb driver, some designs decided to add a separate I2C
microcontroller chip in order to handle IR.

Due to that, add a glue to ir-kbd-i2c is needed, in order to support
those devices.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

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

By comparing the traffic between Pixelview (cx23102-based and Kworld
(saa7134-based), the only difference is at register 0xd5. After some
tests, It seems that it is used to change mode between serial and parallel.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

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

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

This adds the trivial bits to mb86a20s. As the driver won't touch
at the channel/layer parameters, this may not be enough for
receiving all channels, especially ISDB-Tsb, but the driver worked
properly for receiving video channels on my tests.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This device uses an em2874B + Sharp 921 One Seg frontend.
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>