Some macros were changed/removed at the material for v4.5. We need
to sync with those changes here, in order to avoid troubles.

* v4l_for_linus:
  [media] media.h: get rid of MEDIA_ENT_F_CONN_TEST
  [media] [for,v4.5] media.h: increase the spacing between function ranges
  [media] media: i2c/adp1653: probe: fix erroneous return value
  [media] media: davinci_vpfe: fix missing unlock on error in vpfe_prepare_pipeline()

Defining it as a connector was a bad idea. Remove it while it is
not too late.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Defining it as a connector was a bad idea. Remove it while it is
not too late.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Each function range is quite narrow and especially for connectors this
will pose a problem. Increase the function ranges while we still can and
move the connector range to the end so that range is practically limitless.

[mchehab@osg.samsung.com: Rebased to apply at Linus tree]
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

MEDIA_ENT_F_CONN_TEST is not really a connector, it is actually
a signal generator. Also, as other drivers use the
V4L2_CID_TEST_PATTERN control for signal generators, let's change
the driver accordingly.

Tested with Terratec Grabster AV350.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This macro is not used inside the driver. get rid of it.
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This is not used on the driver. remove it.
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This fixes this warning:

	v4l2-mc.c: In function 'v4l2_mc_create_media_graph':
	v4l2-mc.c:60:69: warning: variable 'sensor' set but not used [-Wunused-but-set-variable]

We could solve it the other way: don't do the second loop for
webcams. However, that would fail if a chip would have two sensors
plugged. This is not the current case, but it doesn't hurt to be
future-safe here, specially since this code runs only once during
device probe. So, performance is not an issue here.
Reported-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

We need to add connectors to the cx231xx graph.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

As si2157 doesn't use the subdev, but has instead a binding
logic that doesn't have any core framework, we need to manually
pass the media_device struct via platform data on every place
it is called.

This fixes support for HVR-955Q when MC is enabled.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

As this tuner doesn't use the usual subdev interface, we need
to register it manually.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Instead of having its own routine, use the one defined at the
core, as it is generic enough to handle the cx231xx usecases.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

When in analog mode, the RF connector will be created by
em28xx-video. However, when the device is in digital mode only,
the RF connector is not shown. In this case, let the DVB
core to create it for us.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Except for the usbuvc driver (with has an embedded media_device
struct on it), the other drivers have a pointer to media_device.

On those drivers, replace their own implementation for the core
one. That warrants that those subdev drivers will fill the
media_device info the same way.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

On USB drivers, the dev struct is usually filled with the USB
device. That would mean that the name of the driver specified
by media_device.dev.driver.name would be "usb", instead of the
name of the actual driver that created the media entity.

Add an optional field at the internal struct to allow drivers
to override the driver name.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The mutex lock at rc_register_device() was added by commit 08aeb7c9
("[media] rc: add locking to fix register/show race").

It is meant to avoid race issues when trying to open a sysfs file while
the RC register didn't complete.

Adding a lock there causes troubles, as detected by the Kernel lock
debug instrumentation at the Kernel:

    ======================================================
    [ INFO: possible circular locking dependency detected ]
    4.5.0-rc3+ #46 Not tainted
    -------------------------------------------------------
    systemd-udevd/2681 is trying to acquire lock:
     (s_active#171){++++.+}, at: [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0

    but task is already holding lock:
     (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core]

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (&dev->lock){+.+.+.}:
           [<ffffffff8124817d>] lock_acquire+0x13d/0x320
           [<ffffffff822de966>] mutex_lock_nested+0xb6/0x860
           [<ffffffffa0721f2b>] show_protocols+0x3b/0x3f0 [rc_core]
           [<ffffffff81cdaba5>] dev_attr_show+0x45/0xc0
           [<ffffffff8171f1b3>] sysfs_kf_seq_show+0x203/0x3c0
           [<ffffffff8171a6a1>] kernfs_seq_show+0x121/0x1b0
           [<ffffffff81617c71>] seq_read+0x2f1/0x1160
           [<ffffffff8171c911>] kernfs_fop_read+0x321/0x460
           [<ffffffff815abc20>] __vfs_read+0xe0/0x3d0
           [<ffffffff815ae90e>] vfs_read+0xde/0x2d0
           [<ffffffff815b1d01>] SyS_read+0x111/0x230
           [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76

    -> #0 (s_active#171){++++.+}:
           [<ffffffff81244f24>] __lock_acquire+0x4304/0x5990
           [<ffffffff8124817d>] lock_acquire+0x13d/0x320
           [<ffffffff81717d3a>] __kernfs_remove+0x58a/0x810
           [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0
           [<ffffffff81721592>] remove_files.isra.0+0x72/0x190
           [<ffffffff8172174b>] sysfs_remove_group+0x9b/0x150
           [<ffffffff81721854>] sysfs_remove_groups+0x54/0xa0
           [<ffffffff81cd97d0>] device_remove_attrs+0xb0/0x140
           [<ffffffff81cdb27c>] device_del+0x38c/0x6b0
           [<ffffffffa0724b8b>] rc_register_device+0x8cb/0x1450 [rc_core]
           [<ffffffffa1326a7b>] dvb_usb_remote_init+0x66b/0x14d0 [dvb_usb]
           [<ffffffffa1321c81>] dvb_usb_device_init+0xf21/0x1860 [dvb_usb]
           [<ffffffffa13517dc>] dib0700_probe+0x14c/0x410 [dvb_usb_dib0700]
           [<ffffffff81dbb1dd>] usb_probe_interface+0x45d/0x940
           [<ffffffff81ce7e7a>] driver_probe_device+0x21a/0xc30
           [<ffffffff81ce89b1>] __driver_attach+0x121/0x160
           [<ffffffff81ce21bf>] bus_for_each_dev+0x11f/0x1a0
           [<ffffffff81ce6cdd>] driver_attach+0x3d/0x50
           [<ffffffff81ce5df9>] bus_add_driver+0x4c9/0x770
           [<ffffffff81cea39c>] driver_register+0x18c/0x3b0
           [<ffffffff81db6e98>] usb_register_driver+0x1f8/0x440
           [<ffffffffa074001e>] dib0700_driver_init+0x1e/0x1000 [dvb_usb_dib0700]
           [<ffffffff810021b1>] do_one_initcall+0x141/0x300
           [<ffffffff8144d8eb>] do_init_module+0x1d0/0x5ad
           [<ffffffff812f27b6>] load_module+0x6666/0x9ba0
           [<ffffffff812f5fe8>] SyS_finit_module+0x108/0x130
           [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76

    other info that might help us debug this:

     Possible unsafe locking scenario:

           CPU0                    CPU1
           ----                    ----
      lock(&dev->lock);
                                   lock(s_active#171);
                                   lock(&dev->lock);
      lock(s_active#171);

     *** DEADLOCK ***

    3 locks held by systemd-udevd/2681:
     #0:  (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160
     #1:  (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160
     #2:  (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core]

In this specific case, some error happened during device init,
causing IR to be disabled.

Let's fix it by adding a var that will tell when the device is
initialized. Any calls before that will return a -EINVAL.

That should prevent the race issues.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Instead of copying exactly the same code on all USB devices,
add an ancillary routine that will create and fill the
struct media_device with the values imported from the USB
device.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Don't let it be included twice, to avoid compiler issues.
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The tvp5150 decoder has different input connectors. The actual list of
HW inputs depends on the device version but all have at least these 3:

1) Composite0
2) Composite1
3) S-Video

and some variants have a 4th possible input connector:

4) Signal generator

The driver currently uses the .s_routing callback to switch the input
connector but since these are separate HW blocks, it's better to use
media entities to represent the input connectors and their source pads
linked with the decoder's sink pad.

This allows user-space to use the MEDIA_IOC_SETUP_LINK ioctl to choose
the input connector. For example using the media-ctl user-space tool:

$ media-ctl -r -l '"Composite0":0->"tvp5150 1-005c":0[1]'
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The tvp5150 decoder has different input connectors so extend the device
tree binding to allow device tree source files to define the connectors
that are available on a given board.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Add a header file for the tvp5150 input connectors constants that
can be shared between the driver and Device Tree source files.

[mchehab@osg.samsung.com: rename tvp5150.h also at em28xx-cards.c]
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Some tvp5150 variants, have an internal generator that can generate a
black screen output. Since this is a HW block, it should be in the HW
inputs list.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Not all tvp5150 variants support the same, for example some have an
internal signal generator that can output a black screen.

So the device id and rom version have to be stored in the driver's
state to know what variant is a given device.

While being there, remove some redundant comments about the device
version since there is already calls to v4l2_info() with that info.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

If the parallel mbus configuration is not correct, the endpoint
device node isn't currently put again in the error path. Fix it.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

V4L2 sub-devices might need to do initialization that depends on being
registered with a V4L2 device. As an example, sub-devices with Media
Controller support may need to register entities and create pad links.

Execute the registered_async callback after the sub-device has been
registered with the V4L2 device so the driver can do any needed init.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

V4L2 sub-devices that are registered asynchronously have no way to know
when they have been registration with a V4L2 device but they might need
to take some action after this.

So let's add a callback that can be executed by the V4L2 async core to
allow sub-devices drivers to do any needed initialization that depends
on the registration.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The module is used only as a library for now. Remove module init and exit
routines to show this.

While here, remove FSF snail address and attach EXPORT_SYMBOL() macros to
corresponding functions.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

v4l2_ctrl_add_ctrl() interface has no users since its introduction in
commit 0996517c ("V4L/DVB: v4l2: Add new control handling framework")
and its functionality is covered by v4l2_ctrl_new() and derivative
interfaces, so it is safe to remove the interface from the kernel.
Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This transmitter now supports configuring the IT content type of the incoming
video.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This receiver now supports reading the IT content type of the incoming
video.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This receiver now supports reading the IT content type of the incoming
video.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Document these new controls.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

HDMI and DisplayPort both support IT Content Type information that
tells the receiver what type of material the video is, graphics such
as from a PC desktop, Photo, Cinema or Game (low-latency).

This patch adds controls for receivers and transmitters to get/set
this information.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Use the helper to enumerate and set DV timings instead of a custom code.
This will ease debugging too, as it is consistent with other drivers.
Signed-off-by: NJean-Michel Hautbois <jean-michel.hautbois@veo-labs.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Remove an unnecassary cast in the argument to kfree.

Found using Coccinelle. The semantic patch used to find this is as follows:

//<smpl>
@@
type T;
expression *f;
@@

- kfree((T *)(f));
+ kfree(f);
//</smpl>
Signed-off-by: NAmitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Auto-gain and auto-exposure clusters in the ov9650 driver have both a
size of 2, not 3 controls. Fix this.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The adp1653_probe() function may return positive value EINVAL
which is obviously wrong.
Signed-off-by: NAnton Protopopov <a.s.protopopov@gmail.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Add the missing unlock before return from function
vpfe_prepare_pipeline() in the error handling case.

video->lock is lock/unlock in function vpfe_open(),
and no need to unlock it here, so remove unlock
video->lock.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Instead of having lots of #ifdefs inside au0828-core due to
V4L2, move the dependencies to au0828-video.c. That allows
removing all those ifdefs, as au0828-video is only compiled if
CONFIG_VIDEO_AU0828_V4L2.

This fixes the following warnings reported by Kbuild test
with a random config with au0828 enabled, but V4L2 is disabled.

All warnings (new ones prefixed by >>):

   drivers/media/usb/au0828/au0828-core.c: In function 'au0828_usb_probe':
>> drivers/media/usb/au0828/au0828-core.c:463:1: warning: label 'done' defined but not used [-Wunused-label]
    done:
    ^
   drivers/media/usb/au0828/au0828-core.c: At top level:
   drivers/media/usb/au0828/au0828-core.c:250:12: warning: 'au0828_create_media_graph' defined but not used [-Wunused-function]
    static int au0828_create_media_graph(struct au0828_dev *dev)
               ^

Tested with a WinTV HVR 950Q (USB ID: 2040:7200)
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

It doesn't make sense to try to create the analog TV graph,
if the device fails to register at V4L2, or if it doesn't have
V4L2 support.

Thanks to Shuah for pointing this issue.
Reported-by: NShuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>