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: 5a3ad937 ("media: ov5640: Make the return rate type more explicit")
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Acked-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro 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: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro 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: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro 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: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro 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: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro 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: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro 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: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

OV5640 sensor supports raw image output (bayer).
Configure ISP mux/format registers accordingly.
Signed-off-by: NLoic Poulain <loic.poulain@linaro.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The autoexposure setup in the 1080p init array is redundant with the
default value of the sensor.

Remove it.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx6dq
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Now that we have everything in place to compute the clock rate at runtime,
we can enable the 60fps framerate for the mode we tested it with.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx6dq
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The current code uses an algorithm to clamp the FPS values and round them
to the closest supported one that isn't really allows to be extended to
more than two values.

Rework it a bit to make it much easier to extend the amount of FPS options
we support.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx6dq
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

In the ov5640_try_frame_interval function, the ret variable actually holds
the frame rate index to use, which is represented by the enum
ov5640_frame_rate in the driver.

Make it more obvious.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx6dq
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Now that we have moved the clock generation logic out of the bytes array,
these arrays are identical between the 15fps and 30fps variants.

Remove the duplicate entries, and convert the code accordingly.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx6dq
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The pixel clock rates were introduced to report the initially static clock
rate.

Since this is now handled dynamically, we can remove them entirely.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx6dq
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The clock rate, while hardcoded until now, is actually a function of the
resolution, framerate and bytes per pixel. Now that we have an algorithm to
adjust our clock rate, we can select it dynamically when we change the
mode.

This changes a bit the clock rate being used, with the following effect:

+------+------+------+------+-----+-----------------+----------------+-----------+
| Hact | Vact | Htot | Vtot | FPS | Hardcoded clock | Computed clock | Deviation |
+------+------+------+------+-----+-----------------+----------------+-----------+
|  640 |  480 | 1896 | 1080 |  15 |        56000000 |       61430400 | 8.84 %    |
|  640 |  480 | 1896 | 1080 |  30 |       112000000 |      122860800 | 8.84 %    |
| 1024 |  768 | 1896 | 1080 |  15 |        56000000 |       61430400 | 8.84 %    |
| 1024 |  768 | 1896 | 1080 |  30 |       112000000 |      122860800 | 8.84 %    |
|  320 |  240 | 1896 |  984 |  15 |        56000000 |       55969920 | 0.05 %    |
|  320 |  240 | 1896 |  984 |  30 |       112000000 |      111939840 | 0.05 %    |
|  176 |  144 | 1896 |  984 |  15 |        56000000 |       55969920 | 0.05 %    |
|  176 |  144 | 1896 |  984 |  30 |       112000000 |      111939840 | 0.05 %    |
|  720 |  480 | 1896 |  984 |  15 |        56000000 |       55969920 | 0.05 %    |
|  720 |  480 | 1896 |  984 |  30 |       112000000 |      111939840 | 0.05 %    |
|  720 |  576 | 1896 |  984 |  15 |        56000000 |       55969920 | 0.05 %    |
|  720 |  576 | 1896 |  984 |  30 |       112000000 |      111939840 | 0.05 %    |
| 1280 |  720 | 1892 |  740 |  15 |        42000000 |       42002400 | 0.01 %    |
| 1280 |  720 | 1892 |  740 |  30 |        84000000 |       84004800 | 0.01 %    |
| 1920 | 1080 | 2500 | 1120 |  15 |        84000000 |       84000000 | 0.00 %    |
| 1920 | 1080 | 2500 | 1120 |  30 |       168000000 |      168000000 | 0.00 %    |
| 2592 | 1944 | 2844 | 1944 |  15 |        84000000 |      165862080 | 49.36 %   |
+------+------+------+------+-----+-----------------+----------------+-----------+

Only the 640x480, 1024x768 and 2592x1944 modes are significantly affected
by the new formula.

In this case, 640x480 and 1024x768 are actually fixed by this change.
Indeed, the sensor was sending data at, for example, 27.33fps instead of
30fps. This is -9%, which is roughly what we're seeing in the array.
Testing these modes with the new clock setup actually fix that error, and
data are now sent at around 30fps.

2592x1944, on the other hand, is probably due to the fact that this mode
can only be used using MIPI-CSI2, in a two lane mode, and never really
tested with a DVP bus.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx6dq
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The MIPI divider is also cleared as part of the clock setup sequence, so we
can remove that code.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx6dq
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT and OV5640_SCLK_ROOT_DIVIDER_DEFAULT
defines represent exactly the same setup, and are at the same value, than
the more consistent with the rest of the driver OV5640_SCLK2X_ROOT_DIV and
OV5640_SCLK_ROOT_DIV.

Remove them.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx6dq
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Part of the hardcoded initialization sequence is to set up the proper clock
dividers. However, this is now done dynamically through proper code and as
such, the static one is now redundant.

Let's remove it.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx6dq
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The clock structure for the PCLK is quite obscure in the documentation, and
was hardcoded through the bytes array of each and every mode.

This is troublesome, since we cannot adjust it at runtime based on other
parameters (such as the number of bytes per pixel), and we can't support
either framerates that have not been used by the various vendors, since we
don't have the needed initialization sequence.

We can however understand how the clock tree works, and then implement some
functions to derive the various parameters from a given rate. And now that
those parameters are calculated at runtime, we can remove them from the
initialization sequence.

The modes also gained a new parameter which is the clock that they are
running at, from the register writes they were doing, so for now the switch
to the new algorithm should be transparent.
Co-Developed-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Tested-by: Adam Ford <aford173@gmail.com> #imx6dq
Signed-off-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The set_fmt operations updates the sensor format only when the image format
is changed. When only the image sizes gets changed, the format do not get
updated causing the sensor to always report the one that was previously in
use.

Without this patch, updating frame size only fails:
  [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ...]

With this patch applied:
  [fmt:UYVY8_2X8/1024x768@1/30 field:none colorspace:srgb xfer:srgb ...]

Fixes: 6949d864 ("media: ov5640: do not change mode if format or frame interval is unchanged")
Signed-off-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Adam Ford <aford173@gmail.com> #imx6 w/ CSI2 interface on 4.19.6 and 4.20-RC5
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

This adds log_status ioctl and event interface for ov5640's v4l2 controls.

Cc: Steve Longerbeam <slongerbeam@gmail.com>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Changing framerate right before streamon had no effect,
the new framerate value was taken into account only at
next streamon, fix this.
Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The CSI-2 bus may use either D-PHY or C-PHY. Make this visible in media
bus enum.
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Tested-by: NSteve Longerbeam <steve_longerbeam@mentor.com>
Tested-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Change 720p JPEG mode to mode 3 as per other resolutions.
Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Mode setting depends on last mode set, in particular
because of exposure calculation when downscale mode
change between subsampling and scaling.
At stream on the last mode was wrongly set to current mode,
so no change was detected and exposure calculation
was not made, fix this.
Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
Reviewed-by: NJacopo Mondi <jacopo@jmondi.org>
Tested-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

When switching from auto to manual mode, V4L2 core is calling
g_volatile_ctrl() in manual mode in order to get the manual initial value.
Remove the manual mode check/return to not break this behaviour.
Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
Tested-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

ov5640_set_mode_exposure_calc() is checking binning value but
binning value read is buggy, fix this.
Rename ov5640_binning_on() to ov5640_get_binning() as per other
similar functions.
Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Ensure that auto gain and auto exposure are well restored
when changing mode.
Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
Reviewed-by: NJacopo Mondi <jacopo@jmondi.org>
Tested-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Symptom was black image when capturing HD or 5Mp picture
due to manual exposure set to 1 while it was intended to
set autoexposure to "manual", fix this.

Fixes: bf4a4b51 ("media: ov5640: Don't force the auto exposure state at start time").
Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

As of: commit 476dec01 ("media: ov5640: Add horizontal and vertical
totals") the timings parameters gets programmed separately from the
static register values array.

When changing capture mode, the vertical and horizontal totals gets
inspected by the set_mode_exposure_calc() functions, and only later
programmed with the new values. This means exposure, light banding
filter and shutter gain are calculated using the previous timings, and
are thus not correct.

Fix this by programming timings right after the static register value
table has been sent to the sensor in the ov5640_load_regs() function.

Fixes: 476dec01 ("media: ov5640: Add horizontal and vertical totals")

Tested-by: Steve Longerbeam <slongerbeam@gmail.com> # i.MX6q SabreSD, CSI-2
Tested-by: Loic Poulain <loic.poulain@linaro.org> # Dragonboard-410c, CSI-2
Signed-off-by: NSamuel Bobrowicz <sam@elite-embedded.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Rework the MIPI interface startup sequence with the following changes:

- Remove MIPI bus initialization from the initial settings blob
- At set_power(1) time power up MIPI Tx/Rx and set data and clock lanes in
  LP11 during 'sleep' and 'idle' with MIPI clock in non-continuous mode.
- At s_stream time enable/disable the MIPI interface output.
- Restore default settings at set_power(0) time.

Before this commit the sensor MIPI interface was initialized with settings
that require a start/stop sequence at power-up time in order to force lanes
into LP11 state, as they were initialized in LP00 when in 'sleep mode',
which is assumed to be the sensor manual definition for the D-PHY defined
stop mode.

The stream start/stop was performed by enabling disabling clock gating,
and had the side effect to change the lanes sleep mode configuration when
stream was stopped.

Clock gating/ungating:
-       ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
-                            on ? 0 : BIT(5));
-       if (ret)

Set lanes in LP11 when in 'sleep mode':
-       ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
-                              on ? 0x00 : 0x70);

This commit fixes an issue reported by Jagan Teki on i.MX6 platforms that
prevents the host interface from powering up correctly:
https://lkml.org/lkml/2018/6/1/38

It also improves MIPI capture operations stability on my testing platform
where MIPI capture often failed and returned all-purple frames.

Fixes: f22996db ("media: ov5640: add support of DVP parallel interface")

Tested-by: Steve Longerbeam <slongerbeam@gmail.com> (i.MX6q SabreSD, CSI-2)
Tested-by: Loic Poulain <loic.poulain@linaro.org> (Dragonboard-410c, CSI-2)
Reported-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

fixes: 6949d864 ("media: ov5640: do not change mode if format or frame interval is unchanged").

Symptom was fuzzy image because of JPEG default format
not being changed according to new format selected, fix this.
Init sequence initialises format to YUV422 UYVY but
sensor->fmt initial value was set to JPEG, fix this.
Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Save load of mode registers array when V4L2 client sets a format or a
frame interval which selects the same mode than the current one.
Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Driver must reject frame interval enumeration of unsupported resolution.
This was detected by v4l2-compliance format ioctl test:
v4l2-compliance Format ioctls:
    info: found 2 frameintervals for pixel format 4745504a and size 176x144
  fail: v4l2-test-formats.cpp(123):
                           found frame intervals for invalid size 177x144
    test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL
Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

According to ov5640 datasheet xvclk is allowed to be between 6 and 54 MHz.
I run a successful test with 27 MHz.
Signed-off-by: NPhilipp Puschmann <pp@emlix.com>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Add support of module being physically mounted upside down.
In this case, mirror and flip are enabled to fix captured images
orientation.

[Sakari Ailus: Use dev_fwnode() instead of accessing device's of_node]
Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

Add HFLIP/VFLIP controls support by setting registers REG21/REG20.
Useless values in hardcoded mode sequences are removed and
remaining binning values are now set after mode sequence being set.
Note that due to BSI (Back Side Illuminated) technology, image capture
is physically mirrored, mirror logic is so inversed in REG21 register
to cancel this effect.
Signed-off-by: NHugues Fruchet <hugues.fruchet@st.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The active frame size is set in the initialization arrays, but the value
itself is also available in the struct ov5640_mode_info.

Let's move these values out of the big bytes arrays, and program it with
the value of the mode that we are given.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

All the initialization arrays are changing the horizontal and vertical
totals for some value.

In order to clean up the driver, and since we're going to need that value
later on, let's introduce in the ov5640_mode_info structure the horizontal
and vertical total sizes, and move these out of the bytes array.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>

The current width and height parameters in the struct ov5640_mode_info are
actually the active horizontal and vertical resolutions.

Since we're going to add a few other parameters, let's pick a better, more
precise name for these values.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>