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

It survives now on reset_resume.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Changing cached frequency during init is something no-no.
Make it behave a little bit better. After that device could
survive from suspend/resume when streaming is ongoing.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The uvcvideo driver now supports USERPTR, and isn't limited to YUYV and
MJPEG anymore.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NRichard Zhao <richard.zhao@freescale.com>
Acked-by: NJavier Martin <javier.martin@vista-silicon.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

ite_dev::rdev is currently initialised in ite_probe() after
rc_register_device() returns.  If a newly registered device is opened
quickly enough, we may enable interrupts and try to use ite_dev::rdev
before it has been initialised.  Move it up to the earliest point we
can, right after calling rc_allocate_device().
Reported-and-tested-by: NYunQiang Su <wzssyqa@gmail.com>
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The result of one call to a function is tested, and then at the second call
to the same function, the previous result, and not the current result, is
tested again.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression ret;
identifier f;
statement S1,S2;
@@

*ret = f(...);
if (\(ret != 0\|ret < 0\|ret == NULL\)) S1
... when any
*f(...);
if (\(ret != 0\|ret < 0\|ret == NULL\)) S2
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The result of one call to a function is tested, and then at the second call
to the same function, the previous result, and not the current result, is
tested again.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression ret;
identifier f;
statement S1,S2;
@@

*ret = f(...);
if (\(ret != 0\|ret < 0\|ret == NULL\)) S1
... when any
*f(...);
if (\(ret != 0\|ret < 0\|ret == NULL\)) S2
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

[media] gspca_pac7302: avoid duplicate calls of the image quality adjustment functions on capturing start

There is no need to call the image quality adjustment functions in sd_start.
The gspca main driver calls v4l2_ctrl_handler_setup in gspca_init_transfer,
which already applies all image control values.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The current white balance temperature default value is 4, which is much too small (possible values are 0-255).
Improve the picture quality by increasing the default value to 55, which is the default value used by the Windows driver.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The Windows driver uses page 0 register 0xb6 for sharpness adjustment.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix a regression from kernel 3.4 which has been introduced with the conversion of the gspca driver to the v4l2 control framework.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Cc: stable@kernel.org
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Cc: stable@kernel.org
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

1) We always re-create the input-urb on resume, so we must also always
   destroy it on suspend to avoid leaking it
2) If we're going to do an init_transfer, then that will destroy the urb
   before starting the stream (nop if there is none), and (re-)create it
   once the stream is started. So there is little use in creating it, if
   we're going to do an init_transfer immediately afterward
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

gspca_main: init_transfer does not do anything between calling sd_start
(which starts the workqueue) and releasing the usb_lock, so this
synchronization is a nop, remove it.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In commit a3d6e8cc gspca_dev->dev is set
to NULL on disconnect, before calling stop0. The plan was to get rid of
gspca_dev->present and instead simply check for gspca_dev->dev everywhere
where we were checking for present. This should be race free since all users
of gspca_dev->dev hold the usb_lock, or so I thought.

But I was wrong, drivers which use a work-queue + synchronous bulk transfers
to get the video data don't hold the usb_lock while doing so, their stop0
callbacks stop the workqueue, so they won't be using gspca_dev->dev anymore
after the stop0 call, but they might be dereferincing it before, so we should
not set gspca_dev->dev to NULL on disconnect before calling stop0.

This also means that the workqueue functions in these drivers cannot
use gspca_dev->dev to check if they need to stop because of disconnection,
so we will need to keep gspca_dev->present around, and set that to 0 on
disconnect, before calling stop0. Unfortunately as part of the plan to remove
gspca_dev->present, these workqueues where already moved over to checking
for gspca_dev->dev instead of gspca_dev->present as part of commit
254902b0, so this patch also reverts those
parts of that commit.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}

// </smpl>
Signed-off-by: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch changes some signed integers to unsigned because
they are not intended for negative values and sparse
is making noise about it.

Sparse gives eight of these errors:
drivers/media/usb/gspca/ov519.c:144:29: error: dubious one-bit signed bitfield
Signed-off-by: NEmil Goode <emilgoode@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

struct vb2_queue is allocated through kzalloc as part of a larger struct,
there's no need to clear it.

Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This lock was being taken using two different names
(pointers) in the same function.
Both names refer to the same lock,
so this wasn't an error; but it looked very strange.

Cc: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

drivers/media/radio/shark2.o: In function `_GLOBAL__sub_I_65535_0_usb_shark_suspend':
drivers/media/radio/radio-shark2.c:344: multiple definition of `usb_shark_suspend'
drivers/media/radio/radio-shark.o:/home/v4l/v4l/patchwork/drivers/media/radio/radio-shark.c:379: first defined here
drivers/media/radio/shark2.o: In function `usb_shark_resume':
drivers/media/radio/radio-shark2.c:349: multiple definition of `usb_shark_resume'
drivers/media/radio/radio-shark.o:/home/v4l/v4l/patchwork/drivers/media/radio/radio-shark.c:384: first defined here
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This completes my work on the Griffin radioSHARK2 driver, let me use this
opportunity to thank Hisaaki Shibata for his generous donation of a
Griffin radioSHARK2 to me, which has made this driver possible.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

freq fits easily into 32 bits until it gets shifted, so make it 32 bits,
and cast it to 64 bits before shifting.

[mchehab@redhat.com: also remove asm/div64.h header, as this is not
 needed anymore]
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add support for tuning AM (on devices with the necessary additional
hardware components), and advertise the available bands using the new
VIDIOC_ENUM_FREQ_BANDS ioctl.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
CC: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Am 14.08.2012 14:05, schrieb Manu Abraham:
>> My other device, a STB0899, always reports the set frequency. So it seems
>> driver dependent whether it reports the actually locked frequency found by
>> the zig-zag-algorithm or just the set frequency to tune to.
>
> The STV0299 blindly sets the value based on a software zigzag (due to simpler
> hardware), but this might not be accurate enough. On the other hand, the
> STB0899 internally does zig-zag in hardware for DVB-S2, and partly in
> software for DVB-S.
>
> In any event, the get_frontend callback should return the value that is read
> from the demodulator registers, rather than the cached original value that
> which was requested to be tuned.
>
> The stb0899 returns only the cached value IIRC. Maybe I will fix this soon,
> or maybe you can send a patch.
This is what I get after the patch:

Sat.    Pol.    Band    Freq (MHz) Set    Freq (MHz) Get    Delta (MHz)
S19,2E    H     L       10744             10748,474         4,474
S19,2E    H     L       10773             10777,944         4,944
S19,2E    H     L       10832             10836,953         4,953
S19,2E    H     L       10861             10868,774         7,774
...
Signed-off-by: NReinhard Nißl <rnissl@gmx.de>
Cc: Manu Abraham <abraham.manu@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

changeset 1248c7cb broke html compilation:

Documentation/DocBook/v4l2.xml:584: parser error : Entity 'sub-subdev-g-edid' not defined
Documentation/DocBook/v4l2.xml:626: parser error : chunk is not well balanced
Documentation/DocBook/media_api.xml:74: parser error : Failure to process entity sub-v4l2
Documentation/DocBook/media_api.xml:74: parser error : Entity 'sub-v4l2' not defined

I suspect that one file was simply missed at the patch. Yet, keeping
it broken is a very bad idea, so we should either remove the broken
patch or to remove just the invalid include. Let's take the latter
approach.

Due to that, a warning is now produced:

Error: no ID for constraint linkend: v4l2-subdev-edid.

Cc: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Compute the horizontal blanking value according to the datasheet. The
value written to the hblank and vblank registers must be equal to the
number of blank columns and rows minus one.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Provide pixel rate control calculated from external clock and horizontal
binning factor.
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

These helper functions get and set a 64-bit control's value from within
a driver. They are similar to v4l2_ctrl_[gs]_ctrl() but operate on
64-bit integer controls instead of 32-bit controls.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Initial version of this driver.

The full datasheets are available from the Analog Devices website:

  http://ez.analog.com/docs/DOC-1741

Not all features of the receiver are supported by this driver for various
reasons. Most notably:

- No CEC support (the CEC API needs a lot more discussion)
- No HDCP repeater support (we don't use that either)

I'm sure that there are more things missing, but this driver does work
well for our hardware.

Note that I am using the register addresses instead of register names: the
datasheet containing the register descriptions is organized by register
address. Using names would make the datasheet lookup very hard. An attempt
was made to try and document what is being done when registers are used
instead.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Initial version of this driver.

The full datasheets are available from the Analog Devices website:

  http://ez.analog.com/docs/DOC-1545

Not all features of the receiver are supported by this driver for various
reasons. Most notably:

- No CEC support (the CEC API needs a lot more discussion)
- Only port A of the four HDMI input ports is implemented (our hardware only
  uses that port)
- No HDCP repeater support (we don't use that either)

And since there are some 600-odd pages of datasheet for this single device,
I'm sure that there are many more things missing, but this driver does work
well for our hardware.

Note that I am using the register addresses instead of register names: the
datasheet containing the register descriptions is organized by register
address. Using names would make the datasheet lookup very hard. An attempt
was made to try and document what is being done when registers are used
instead.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

These two helper functions detect whether the analog video timings detected
by the video receiver match the VESA CVT or GTF standards.

They basically do the inverse of the CVT and GTF modeline calculations.

This patch also adds a helper function that will determine the aspect ratio
based on the provided EDID values. This aspect ratio can be given to the GTF
helper function.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add the v4l_match_dv_timings function that can be used to compare two
v4l2_dv_timings structs.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>