Add camera implementations from gtab kernel
Thanks to dpw13
adam board: Changes for camera
Changes in board files according to dpw13 changes for gTab
Add config for camera
V4L: add media bus configuration subdev operations

Add media bus configuration types and two subdev operations to get
supported mediabus configurations and to set a specific configuration.
Subdevs can support several configurations, e.g., they can send video data
on 1 or several lanes, can be configured to use a specific CSI-2 channel,
in such cases subdevice drivers return bitmasks with all respective bits
set. When a set-configuration operation is called, it has to specify a
non-ambiguous configuration.

Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Document missing CSI registers and some values. Abstract clock enabling for future CSI use.

Conflicts:
	arch/arm/mach-tegra/include/mach/csi.h
CHROMIUM: videobuf: Initial revision of videobuf-dma-nvmap

This is a videobuf driver that's heavily based on the existing
videobuf-dma-contig, but uses nvmap to allocate video buffers.

Change-Id: I3956ce22721b16e1396a7556020f963dbe41008e

BUG=none
TEST=Builds cleanly.  Tested to work with Tegra's V4L2 stuff.
Signed-off-by: Andrew Chew <achew@nvidia.com>
Signed-off-by: Olof Johansson <olofj@chromium.org>

Review URL: http://codereview.chromium.org/6551018
v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control

V4L2_CID_POWER_LINE_FREQUENCY control allows applications to instruct
a driver what is the power line frequency so an appropriate filter
can be used by the device to cancel flicker by compensating the light
intensity ripple. Currently in the menu we have entries for 50 Hz and
60 Hz and for entirely disabling the anti-flicker filter.
However some devices are capable of automatically detecting the
frequency, so add V4L2_CID_POWER_LINE_FREQUENCY_AUTO entry for them.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v4l2-ctrls: introduce call_op define

Add the call_op define to safely call the control ops. This also allows
for controls without any ops such as the 'control class' controls.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v4l2-ctrls: fix and improve volatile control handling

If you have a cluster of controls that is a mix of volatile and non-volatile
controls, then requesting the value of the volatile control would fail if the
master control of that cluster was non-volatile. The code assumed that the
volatile state of the master control was the same for all other controls in
the cluster.

This is now fixed.

In addition, it was clear from bugs in some drivers that it was confusing that
the ctrl->cur union had to be used in g_volatile_ctrl. Several drivers used the
'new' values instead. The framework was changed so that drivers now set the new
value instead of the current value.

This has an additional benefit as well: the volatile values are now only stored
in the 'new' value, leaving the current value alone. This is useful for
autofoo/foo control clusters where you want to have a 'foo' control act like a
volatile control if 'autofoo' is on, but as a normal control when it is off.

Since with this change the cur value is no longer overwritten when g_volatile_ctrl
is called, you can use it to remember the original 'foo' value. For example:

autofoo = 0, foo = 10 and foo is non-volatile.

Now autofoo is set to 1 and foo is marked volatile. Retrieving the foo value
will get the volatile value. Set autofoo back to 0, which marks foo as non-
volatile again, and retrieving foo will get the old current value of 10.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v4l2-ctrls: simplify error_idx handling

The lower-level prepare functions just set error_idx for each control that
might have an error. The high-level functions will override this with
cs->count in the get and set cases. Only try will keep the error_idx.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v4l2-ctrls: drivers should be able to ignore the READ_ONLY flag

When applications try to set READ_ONLY controls an error should
be returned. However, when drivers do that it should be accepted.

Those controls could reflect some driver status which the application
can't change but the driver obviously has to be able to change it.

This is needed among others for future HDMI status controls.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v4l2-ctrls: add v4l2_ctrl_auto_cluster to simplify autogain/gain scenarios

It is a bit tricky to handle autogain/gain type scenerios correctly. Such
controls need to be clustered and the V4L2_CTRL_FLAG_UPDATE should be set on
the autofoo controls. In addition, the manual controls should be marked
inactive when the automatic mode is on, and active when the manual mode is on.
This also requires specialized volatile handling.

The chances of drivers doing all these things correctly are pretty remote.
So a new v4l2_ctrl_auto_cluster function was added that takes care of these
issues.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Pull V4L2 tegra camera support from chromiumos
See http://codereview.chromium.org/6627032
Return standard -1 on error at open
v4l: soc-camera: Add support for enum_frameintervals ioctl

Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
Build fixes for soc_camera frame interval
Fix build
board adam: Power camera
More camera changes in board files
More camera chagnes