[media] media/usb/gspca: Add support for Scopium astro webcam (0547:7303)

This patch does not modify existing drivers. It adds subdriver
to gspca for DTCS033 (Scopium) webcam for astrophotography.
The patch adds dtcs033.c and modifies Kconfig and Makefile.

Signed-off-by: Robert Butora <robert.butora.fi@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] gspca_gl860: Clean up idxdata structs

Signed-off-by: Ismael Luceno <ismael.luceno@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] v4l2-subdev.h: fix sparse error with v4l2_subdev_notify

The notify function is a void function, yet the v4l2_subdev_notify
define uses it in a ? : construction, which causes sparse warnings.

Replace the define by a static inline function and move it to
v4l2-device.h, which is where it belongs since it needs to know the
v4l2_device struct. This wasn't a problem when it was a define, but
as a static inline function this no longer compiles in v4l2-subdev.h.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] videobuf2-core: fix sparse errors

Sparse generated a bunch of errors like this:

drivers/media/v4l2-core/videobuf2-core.c:2045:25: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:136:17: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:151:17: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:168:25: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:183:17: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:185:9: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:385:25: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1115:17: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1268:33: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1270:25: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1315:17: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1324:25: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1396:25: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1457:17: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1482:17: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1484:9: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1523:17: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1525:17: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1815:17: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1828:17: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1914:25: error: incompatible types in conditional expression (different base types)
drivers/media/v4l2-core/videobuf2-core.c:1944:9: error: incompatible types in conditional expression (different base types)

These are caused by the call*op defines which do something like this:

        (ops->op) ? ops->op(args) : 0

which is OK as long as op is not a void function, because in that case one part
of the conditional expression returns void, the other an integer. Hence the sparse
errors.

I've replaced this by introducing three variants of the call_ macros:
call_*op for int returns, call_void_*op for void returns and call_ptr_*op for
pointer returns.

That's the bad news. The good news is that the fail_*op macros could be removed
since the call_*op macros now have enough information to determine if the op
succeeded or not and can increment the op counter only on success. This at least
makes it more robust w.r.t. future changes.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] v4l2-common.h: remove __user annotation in struct v4l2_edid

The edid array is copied to kernelspace by the v4l2 core, so drivers
shouldn't see the __user annotation. This conforms to other structs like
v4l2_ext_controls where the data pointed to is copied to from user to
kernelspace.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] v4l2-ioctl.c: fix sparse __user-related warnings

Fix the use of __user in the check_array_args() prototype: instead of
using 'void * __user *' you should use 'void __user **' for sparse to
understand this correctly.

This also required the use of __force in the '*kernel_ptr = user_ptr'
assignment.

Also replace a wrong cast (void *) with the correct one (void **)
in check_array_args().

This fixes these sparse warnings:

drivers/media/v4l2-core/v4l2-ioctl.c:2284:35: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-ioctl.c:2301:35: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-ioctl.c:2319:35: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/v4l2-ioctl.c:2386:57: warning: incorrect type in argument 4 (different address spaces)
drivers/media/v4l2-core/v4l2-ioctl.c:2420:29: warning: incorrect type in assignment (different address spaces)

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] staging: omap24xx: fix coding style

Fix missing parentheses in macros
Errors found by checkpatch.pl

Signed-off-by: Ioana Ileana <ileana@enst.fr>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] adv7842: update RGB quantization range on HDMI/DVI-D mode irq

This was the reason for enabling the HDMI/DVI-D mode irq in the first place.

Signed-off-by: Martin Bugge <marbugge@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] adv7842: Disable access to EDID DDC lines before chip power up

In core_init make sure access to EDID DDC lines are disabled
before chip is powered up. Also DISABLE_AUTO_EDID before power up.
The correct setting is applied later when setting the EDID.
Some sources (MAC) kept on reading EDID even when Hotplug was low
and in the short period in core_init before the DDC lines was enabled
read a corrupt EDID.

Signed-off-by: Martin Bugge <marbugge@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] bttv: Add support for PCI-8604PW

This patch adds support for the PCI-8604PW card equipped with four 878A.
It is unknown who the manufacturer of this card is and no drivers were
available during development of the patch. According to images found
online, the card is originally sold with Linux DVR software.

A CPLD on the card prevents the 878A from requesting access to the
bus until an initialization sequence has been issued via GPIOs. The
implemented sequence uses the minimum number of GPIOs needed to
successfully unlock bus access. As there are many more GPIOs connected
to the CPLD, it is very likely that some of the others have an influence
on the bus arbitration scheduling. This should be investigated further
in case of performance issues.

The tested card contains an EEPROM on one of the 878A, but it is
completely empty (i.e. contains only 0xff), so it is not possible
to detect the card.

Signed-off-by: Daniel Glöckner <daniel-gl@gmx.net>
Tested-by: Robert Longbottom <rongblor@googlemail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] media: davinci: vpbe: use v4l2_fh for priority handling

This patch migrates the vpbe driver to use v4l2_fh for
priority handling. This also fixes v4l2-compliance test.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] media: davinci: vpfe: use v4l2_fh for priority handling

This patch migrates the vpfe driver to use v4l2_fh for
priority handling.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] sn9c102_hv7131r: fix style warnings flagged by checkpatch.pl

Signed-off-by: Mike Sampson <mike@sambodata.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] staging: media: davinci: vpfe: use v4l2_fh for priority handling

Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] staging: media: davinci: vpfe: release buffers in case start_streaming call back fails

this patch releases the buffer by calling vb2_buffer_done(),
with state marked as VB2_BUF_STATE_QUEUED if start_streaming()
call back fails.

Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] v4l2-dv-timings.h: add CEA-861-F 4K timings

Add the CEA-861-F timings for 3840x2160p24/25/30/50/60 and
4096x2160p24/25/30/50/60.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] v4l2-dv-timings.c: add the new 4K timings to the list

Add the new CEA-861-F and DMT 4K timings to the list of predefined
timings.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] vb2: fix handling of data_offset and v4l2_plane.reserved[]

The videobuf2-core did not zero the 'planes' array in __qbuf_userptr()
and __qbuf_dmabuf(). That's now memset to 0. Without this the reserved
array in struct v4l2_plane would be non-zero, causing v4l2-compliance
errors.

More serious is the fact that data_offset was not handled correctly:

- for capture devices it was never zeroed, which meant that it was
  uninitialized. Unless the driver sets it it was a completely random
  number. With the memset above this is now fixed.

- __qbuf_dmabuf had a completely incorrect length check that included
  data_offset.

- in __fill_vb2_buffer in the DMABUF case the data_offset field was
  unconditionally copied from v4l2_buffer to v4l2_plane when this
  should only happen in the output case.

- in the single-planar case data_offset was never correctly set to 0.
  The single-planar API doesn't support data_offset, so setting it
  to 0 is the right thing to do. This too is now solved by the memset.

All these issues were found with v4l2-compliance.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] vb2: if bytesused is 0, then fill with output buffer length

The application should really always fill in bytesused for output
buffers, unfortunately the vb2 framework never checked for that.

So for single planar formats replace a bytesused of 0 by the length
of the buffer, and for multiplanar format do the same if bytesused is
0 for ALL planes.

This seems to be what the user really intended if v4l2_buffer was
just memset to 0.

I'm afraid that just checking for this and returning an error would
break too many applications. Quite a few drivers never check for bytesused
at all and just use the buffer length instead.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] vb2: use correct prefix

Many dprintk's in vb2 use a hardcoded prefix with the function name. In
many cases that is now outdated. To keep things consistent the dprintk
macro has been changed to print the function name in addition to the "vb2:"
prefix. Superfluous prefixes elsewhere in the code have been removed.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>