According to the ov5640 specification (2.7 power up sequence), host can
access the sensor's registers 20ms after reset. Trying to access them
before leads to undefined behavior and result in sporadic initialization
errors.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The ov5640_try_frame_interval operation updates the FPS as per user
input based on default ov5640_frame_rate, OV5640_30_FPS which is failed
to update when user trigger 15fps.
So, initialize the default ov5640_frame_rate to OV5640_15_FPS so-that
it can satisfy to update all fps.
Fixes: 5a3ad937bc ("media: ov5640: Make the return rate type more explicit")
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The register value lists for all the supported resolution settings all
include a register address/value pair for setting the JPEG compression
mode. With the exception of 1080p (which sets mode 2), all resolutions
use mode 3.
The only difference between mode 2 and mode 3 is that mode 2 may have
padding data on the last line, while mode 3 does not add padding data.
As these register values were from dumps of running systems, and the
difference between the modes is quite small, using mode 3 for all
configurations should be OK.
[Sakari Ailus: Align OV5640_REG_JPG_MODE_SELECT register naming.]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
When compression is turned on, the on-bus data is framed according to
the compression mode, and the height and width set in VFIFO_VSIZE and
VFIFO_HSIZE. If these are not updated correctly, the sensor will send
data framed in a manner unexpected by the capture interface, such as
having more bytes per line than expected, and having the extra data
dropped. This ultimately results in corrupted data.
Set the two values when the media bus is configured for JPEG data,
meaning the sensor would be in JPEG mode.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The OV5640 driver currently supports a static color bar pattern with a
small vertical gamma gradient. The hardware also supports a color square
pattern, as well as having a rolling bar for dynamic sequences.
Add three more test patterns:
- color bars with a rolling bar (but without the gamma gradient)
- static color squares
- color squares with a rolling bar
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The transparent feature for test patterns blends the test pattern with
an actual captured image. This makes the result non-static, subject to
changes in the sensor's field of view.
Test patterns should be predictable and deterministic, even if they are
dynamic patterns. Disable the transparent feature of the test pattern.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The OV5640 can generate many types of test patterns, some with
additional modifiers, such as a rolling bar, or gamma gradients.
Add the bit definitions for all bits in the test pattern register,
and use them to compose the values to be written to the register.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The OV5640 has many options for generating test patterns. Unfortunately
there is only one V4L2 control for it. Thus the driver would need to
list some or all combinations.
Move the test_pattern_menu list before the ov5640_set_ctrl_test_pattern
function that programs the hardware. This would allow us to add a
matching list of values to program into the hardware, while keeping the
two lists together for ease of maintenance.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The ADV748x is currently reset by writting a small table of registers to
the device.
The table lacks documentation and contains magic values to perform the
actions, including using a fake register address to introduce a delay
loop.
Remove the table, and convert to code, documenting the purpose of the
specific writes along the way.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Both the AFE and HDMI s_stream routines (adv748x_afe_s_stream() and
adv748x_hdmi_s_stream()) have to enable the CSI-2 TX they are streaming video
data to.
With the introduction of dynamic routing between HDMI and AFE entities to
TXA, the video stream sink needs to be set at run time, and not statically
selected as the s_stream functions are currently doing.
To fix this, store a reference to the active CSI-2 TX sink for both HDMI and
AFE sources, and operate on it when starting/stopping the stream.
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The power_up_tx() procedure needs to set a few registers conditionally to
the selected video source, but it currently checks for the provided tx to
be either TXA or TXB.
With the introduction of dynamic routing between HDMI and AFE entities to
TXA, checking which TX the function is operating on is not meaningful anymore.
To fix this, store the subdevice of the source providing video data to the
CSI-2 TX in the 'struct adv748x_csi2' representing the TX and check on it.
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Set initial try format with default configuration instead of current one.
Fixes: 8d3b307a15 ("media: ov2640: make VIDIOC_SUBDEV_G_FMT ioctl work with V4L2_SUBDEV_FORMAT_TRY")
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
This function prints an error message on success. I don't have the
hardware, I just noticed this while reading the code.
Fixes: 8b99312b72 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
We use put_unaligned_be16() to be simplified for setting register address
in ov8856_read_reg() and use sizeof() to be better suited for bytes
copying.
Signed-off-by: Ben Kao <ben.kao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
This provides more power saving when the sensor is off.
While at that, do the delay on power/clock enable even if the sensor driver
itself doesn't control the GPIOs. This is required for the OLPC XO-1
platform, that lacks the proper power/reset properties in its DT, but
needs the delay after the sensor is clocked up.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
The commit 71862f63f3 ("media: ov7670: Add the ov7670_s_power function")
added a power control routing. However, it was not good enough to use as
a s_power() callback: it merely flipped on the power GPIOs without
restoring the register settings.
Fix this now and register an actual power callback.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Instead of assigning the return value to ret and then checking and
returning it, just return the value to the caller directly. The success
value is always 0.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
This patch adds driver for Omnivision's ov8856 sensor,
the driver supports following features:
- manual exposure/gain(analog and digital) control support
- two link frequencies
- VBLANK/HBLANK support
- test pattern support
- media controller support
- runtime PM support
- enable Vsync signal output
- supported resolutions
+ 3280x2464 at 30FPS
+ 1640x1232 at 30FPS
Signed-off-by: Ben Kao <ben.kao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Add initial support for MLX90640 thermal cameras which output an 32x24
greyscale pixel image along with 2 rows of coefficent data.
Because of this the data outputed is really 32x26 and needs the two rows
removed after using the coefficent information to generate processed
images in userspace.
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
This driver got converted to not depend on soc_camera in commit
7b20f325a5 ("media: i2c: tw9910: Remove soc_camera dependencies").
There's no sense in keeping the old version there.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
This driver got converted to not depend on soc_camera in commit
762c28121d ("media: i2c: ov772x: Remove soc_camera dependencies").
There's no sense in keeping the old version there.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
This driver got converted to not depend on soc_camera in commit
6a26f141bf ("media: i2c: mt9t112: Remove soc_camera dependencies").
There's no sense in keeping the old version there.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
This driver got converted to not depend on soc_camera on commit
57b0ad9ebe ("media: soc_camera: ov9640: move ov9640 out of soc_camera").
There's no sense on keeping the old version there.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
