linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@bootlin.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	linux-media@vger.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Mylene Josserand <mylene.josserand@bootlin.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Hugues Fruchet <hugues.fruchet@st.com>,
	Loic Poulain <loic.poulain@linaro.org>,
	Samuel Bobrowicz <sam@elite-embedded.com>,
	Steve Longerbeam <slongerbeam@gmail.com>,
	Daniel Mack <daniel@zonque.org>,
	Maxime Ripard <maxime.ripard@bootlin.com>
Subject: [PATCH v3 06/12] media: ov5640: Compute the clock rate at runtime
Date: Thu, 17 May 2018 10:53:59 +0200	[thread overview]
Message-ID: <20180517085405.10104-7-maxime.ripard@bootlin.com> (raw)
In-Reply-To: <20180517085405.10104-1-maxime.ripard@bootlin.com>

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: Maxime Ripard <maxime.ripard@bootlin.com>
---
 drivers/media/i2c/ov5640.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 77864a1a5eb0..e9bd0aa55409 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -1886,7 +1886,8 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
 	 * which is 8 bits per pixel.
 	 */
 	bpp = sensor->fmt.code == MEDIA_BUS_FMT_JPEG_1X8 ? 8 : 16;
-	rate = mode->pixel_clock * bpp;
+	rate = mode->vtot * mode->htot * bpp;
+	rate *= ov5640_framerates[sensor->current_fr];
 	if (sensor->ep.bus_type == V4L2_MBUS_CSI2) {
 		rate = rate / sensor->ep.bus.mipi_csi2.num_data_lanes;
 		ret = ov5640_set_mipi_pclk(sensor, rate);
-- 
2.17.0

  parent reply	other threads:[~2018-05-17  8:54 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17  8:53 [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements Maxime Ripard
2018-05-17  8:53 ` [PATCH v3 01/12] media: ov5640: Fix timings setup code Maxime Ripard
2018-05-18  8:32   ` Daniel Mack
2018-05-21  7:27     ` Maxime Ripard
2018-05-17  8:53 ` [PATCH v3 02/12] media: ov5640: Adjust the clock based on the expected rate Maxime Ripard
2018-05-17  8:53 ` [PATCH v3 03/12] media: ov5640: Remove the clocks registers initialization Maxime Ripard
2018-05-18 10:35   ` Daniel Mack
2018-05-19  2:42     ` Sam Bobrowicz
2018-05-19  5:52       ` Daniel Mack
2018-05-21  7:39       ` Maxime Ripard
2018-05-22 19:54         ` Maxime Ripard
2018-05-23  9:31           ` Daniel Mack
2018-05-24 14:59             ` Maxime Ripard
2018-06-01 23:05         ` Sam Bobrowicz
2018-06-04 16:22           ` Maxime Ripard
2018-06-29 13:51           ` jacopo mondi
2018-05-17  8:53 ` [PATCH v3 04/12] media: ov5640: Remove redundant defines Maxime Ripard
2018-05-17  8:53 ` [PATCH v3 05/12] media: ov5640: Remove redundant register setup Maxime Ripard
2018-05-17  8:53 ` Maxime Ripard [this message]
2018-05-17  8:54 ` [PATCH v3 07/12] media: ov5640: Remove pixel clock rates Maxime Ripard
2018-05-17  8:54 ` [PATCH v3 08/12] media: ov5640: Enhance FPS handling Maxime Ripard
2018-05-17  8:54 ` [PATCH v3 09/12] media: ov5640: Make the return rate type more explicit Maxime Ripard
2018-05-17  8:54 ` [PATCH v3 10/12] media: ov5640: Make the FPS clamping / rounding more extendable Maxime Ripard
2018-05-17  8:54 ` [PATCH v3 11/12] media: ov5640: Add 60 fps support Maxime Ripard
2018-05-17  8:54 ` [PATCH v3 12/12] media: ov5640: Remove duplicate auto-exposure setup Maxime Ripard
2018-05-17  9:24 ` [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements Daniel Mack
2018-05-17 11:22   ` Maxime Ripard
2018-05-17 11:30     ` Sakari Ailus
2018-09-27 15:59 ` Hugues FRUCHET
2018-09-28 16:05   ` Maxime Ripard
2018-10-01 14:12     ` Hugues FRUCHET
2018-10-04 15:04       ` Maxime Ripard
2018-10-04 15:17         ` Hugues FRUCHET

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180517085405.10104-7-maxime.ripard@bootlin.com \
    --to=maxime.ripard@bootlin.com \
    --cc=daniel@zonque.org \
    --cc=hans.verkuil@cisco.com \
    --cc=hugues.fruchet@st.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=mchehab@kernel.org \
    --cc=mylene.josserand@bootlin.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sam@elite-embedded.com \
    --cc=slongerbeam@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).