From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Maurizio Casciano <mauriziocasciano7@gmail.com>
Cc: mchehab@kernel.org, linux-media@vger.kernel.org,
bingbu.cao@amd.com, jacopo.mondi@ideasonboard.com,
nicholas@rothemail.net, andy@kernel.org,
andriy.shevchenko@intel.com, hansg@kernel.org,
gregkh@linuxfoundation.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 02/16] media: ov8858: support 19.2 MHz clock and CHT gain setup
Date: Thu, 1 Oct 2026 23:00:35 +0300 [thread overview]
Message-ID: <ar674__4-cNOGMMy@kekkonen.localdomain> (raw)
In-Reply-To: <628adb1cabec866554ca26a2da5af860b04d6cb1.1788360629.git.mauriziocasciano7@gmail.com>
Hi Maurizio,
On Wed, Sep 02, 2026 at 04:53:31PM +0200, Maurizio Casciano wrote:
> The Yoga Book drives its OV8858 from a 19.2 MHz platform clock, while
> the existing mode tables program the sensor PLL for 24 MHz. Reusing
> those settings produces incorrect internal and CSI-2 clocks.
>
> Accept both input rates and use the actual rate for the reset delay.
> Move the 24 MHz PLL and global timing registers out of the common mode
> tables, provide revision- and lane-specific arrays, and select the
> matching clock programming explicitly when starting the stream.
>
> Keep the existing long digital-gain control independent of the input
> clock. Expose the per-channel manual white-balance registers as separate
> red and blue balance controls, keep green at unity, and accumulate write
> errors while programming the three channels.
>
> The manual white-balance register definitions and programming follow
> Intel's GPL-2.0 OV5670 driver, so retain its 2017 Intel copyright
> notice in this file. No proprietary source or tuning binary is included.
>
> Tested on the Lenovo Yoga Book YB1-X91L OV8858 with three complete
> 10-bit raw Bayer frames, independent red, blue and digital gain updates
> during active streaming, and front and rear camera capture in Cheese.
Please describe what the patch does here, the rest can go to the cover
letter.
>
> Link: https://lore.kernel.org/linux-media/apf7cJOoXrl_wZfr@kekkonen.localdomain/
> Signed-off-by: Maurizio Casciano <mauriziocasciano7@gmail.com>
> Assisted-by: LLM [Codex] [Sparse]
> ---
> drivers/media/i2c/ov8858.c | 182 +++++++++++++++++++++++++++++--------
> 1 file changed, 146 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/media/i2c/ov8858.c b/drivers/media/i2c/ov8858.c
> index d95f034de752..e040c1fa0a94 100644
> --- a/drivers/media/i2c/ov8858.c
> +++ b/drivers/media/i2c/ov8858.c
> @@ -3,10 +3,9 @@
> * Copyright (C) 2023 Jacopo Mondi <jacopo.mondi@ideasonboard.com>
> * Copyright (C) 2022 Nicholas Roth <nicholas@rothemail.net>
> * Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd.
> + * Copyright (c) 2017 Intel Corporation.
> */
>
> -#include <linux/unaligned.h>
> -
> #include <linux/clk.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> @@ -18,6 +17,8 @@
> #include <linux/property.h>
> #include <linux/regulator/consumer.h>
> #include <linux/slab.h>
> +#include <linux/unaligned.h>
> +#include <linux/units.h>
>
> #include <media/media-entity.h>
> #include <media/v4l2-async.h>
> @@ -28,8 +29,9 @@
> #include <media/v4l2-mediabus.h>
> #include <media/v4l2-subdev.h>
>
> -#define OV8858_LINK_FREQ 360000000U
> -#define OV8858_XVCLK_FREQ 24000000
> +#define OV8858_LINK_FREQ (360 * HZ_PER_MHZ)
> +#define OV8858_XVCLK_FREQ_24MHZ 24000000
> +#define OV8858_XVCLK_FREQ_19_2MHZ 19200000
Why to use HZ_PER_MHZ for LINK_FREQ but not the rest?
>
> #define OV8858_REG_SIZE_SHIFT 16
> #define OV8858_REG_ADDR_MASK 0xffff
> @@ -59,6 +61,14 @@
> #define OV8858_LONG_GAIN_STEP 1
> #define OV8858_LONG_GAIN_DEFAULT 0x80
>
> +#define OV8858_REG_MWB_RED_GAIN OV8858_REG_16BIT(0x5032)
> +#define OV8858_REG_MWB_GREEN_GAIN OV8858_REG_16BIT(0x5034)
> +#define OV8858_REG_MWB_BLUE_GAIN OV8858_REG_16BIT(0x5036)
> +#define OV8858_MWB_GAIN_MIN 0x400
> +#define OV8858_MWB_GAIN_MAX 0xfff
> +#define OV8858_MWB_GAIN_STEP 1
> +#define OV8858_MWB_GAIN_DEFAULT 0x400
> +
> #define OV8858_REG_LONG_DIGIGAIN OV8858_REG_16BIT(0x350a)
> #define OV8858_LONG_DIGIGAIN_H_MASK 0x3fc0
> #define OV8858_LONG_DIGIGAIN_L_MASK 0x3f
> @@ -104,6 +114,7 @@ struct ov8858_mode {
>
> struct ov8858 {
> struct clk *xvclk;
> + unsigned long xvclk_rate;
> struct gpio_desc *reset_gpio;
> struct gpio_desc *pwdn_gpio;
> struct regulator_bulk_data supplies[ARRAY_SIZE(ov8858_supply_names)];
> @@ -115,12 +126,87 @@ struct ov8858 {
> struct v4l2_ctrl *exposure;
> struct v4l2_ctrl *hblank;
> struct v4l2_ctrl *vblank;
> + struct v4l2_ctrl *red_balance;
> + struct v4l2_ctrl *blue_balance;
>
> const struct regval *global_regs;
> + const struct regval *xvclk_regs;
>
> unsigned int num_lanes;
> };
>
> +/* Keep input-clock programming separate from the common sensor setup. */
> +static const struct regval ov8858_24mhz_r1a_2lane[] = {
> + {0x0302, 0x1e},
> + {0x0303, 0x00},
> + {0x0304, 0x03},
> + {0x030e, 0x00},
> + {0x030f, 0x09},
> + {0x0312, 0x01},
> + {0x031e, 0x0c},
> + {0x4837, 0x16},
> + {REG_NULL, 0x00},
> +};
> +
> +static const struct regval ov8858_24mhz_r2a_2lane[] = {
> + {0x0302, 0x1e},
> + {0x0303, 0x00},
> + {0x0304, 0x03},
> + {0x030e, 0x02},
> + {0x030f, 0x04},
> + {0x0312, 0x03},
> + {0x031e, 0x0c},
> + {0x4837, 0x16},
> + {REG_NULL, 0x00},
> +};
> +
> +static const struct regval ov8858_24mhz_r2a_4lane[] = {
> + {0x0302, 0x1e},
> + {0x0303, 0x00},
> + {0x0304, 0x03},
> + {0x030e, 0x00},
> + {0x030f, 0x04},
> + {0x0312, 0x01},
> + {0x031e, 0x0c},
> + {0x4837, 0x16},
> + {REG_NULL, 0x00},
> +};
> +
> +/*
> + * Cherry Trail MRD production settings for a 19.2 MHz input and 360 MHz
> + * CSI-2 link.
Cherry Trail isn't relevant in a sensor driver.
> + *
> + * Besides the corrected sensor/MIPI PLL divisors, keep the final common
> + * black-level settings here. The per-mode tables retain their resolution
> + * dependent black-column anchors and window sizes.
> + */
> +static const struct regval ov8858_cht_mrd_19_2mhz[] = {
I'd include the frequencies in the name perhaps, but not cht_mrd.
> + {0x0300, 0x00},
> + {0x0302, 0x27},
> + {0x0303, 0x00},
> + {0x0304, 0x03},
> + {0x030b, 0x00},
> + {0x030d, 0x27},
> + {0x030e, 0x00},
> + {0x030f, 0x04},
> + {0x0312, 0x01},
> + {0x031e, 0x0c},
> + {0x3f08, 0x08},
> + {0x400a, 0x01},
> + {0x400d, 0x10},
> + {0x4011, 0x20},
> + {0x403e, 0x08},
> + {0x4040, 0x07},
> + {0x4041, 0xc6},
> + {0x4202, 0x00},
> + {0x4500, 0x58},
> + {0x470b, 0x28},
> + {0x4837, 0x15},
> + {0x58f4, 0x32},
> + {0x58f8, 0x3d},
> + {REG_NULL, 0x00},
> +};
> +
> static inline struct ov8858 *sd_to_ov8858(struct v4l2_subdev *sd)
> {
> return container_of(sd, struct ov8858, subdev);
> @@ -131,13 +217,6 @@ static const struct regval ov8858_global_regs_r1a[] = {
> {0x0100, 0x00},
> {0x0100, 0x00},
> {0x0100, 0x00},
> - {0x0302, 0x1e},
> - {0x0303, 0x00},
> - {0x0304, 0x03},
> - {0x030e, 0x00},
> - {0x030f, 0x09},
> - {0x0312, 0x01},
> - {0x031e, 0x0c},
> {0x3600, 0x00},
> {0x3601, 0x00},
> {0x3602, 0x00},
> @@ -370,7 +449,6 @@ static const struct regval ov8858_global_regs_r1a[] = {
> {0x4600, 0x00},
> {0x4601, 0xcb},
> {0x481f, 0x32},
> - {0x4837, 0x16},
> {0x4850, 0x10},
> {0x4851, 0x32},
> {0x4b00, 0x2a},
> @@ -405,13 +483,6 @@ static const struct regval ov8858_global_regs_r2a_2lane[] = {
> */
> {0x0103, 0x01}, /* software reset */
> {0x0100, 0x00}, /* software standby */
> - {0x0302, 0x1e}, /* pll1_multi */
> - {0x0303, 0x00}, /* pll1_divm */
> - {0x0304, 0x03}, /* pll1_div_mipi */
> - {0x030e, 0x02}, /* pll2_rdiv */
> - {0x030f, 0x04}, /* pll2_divsp */
> - {0x0312, 0x03}, /* pll2_pre_div0, pll2_r_divdac */
> - {0x031e, 0x0c}, /* pll1_no_lat */
> {0x3600, 0x00},
> {0x3601, 0x00},
> {0x3602, 0x00},
> @@ -648,7 +719,6 @@ static const struct regval ov8858_global_regs_r2a_2lane[] = {
> {0x4600, 0x00},
> {0x4601, 0xcb},
> {0x481f, 0x32}, /* clk prepare min */
> - {0x4837, 0x16}, /* global timing */
> {0x4850, 0x10}, /* lane 1 = 1, lane 0 = 0 */
> {0x4851, 0x32}, /* lane 3 = 3, lane 2 = 2 */
> {0x4b00, 0x2a},
> @@ -810,13 +880,6 @@ static const struct regval ov8858_global_regs_r2a_4lane[] = {
> {0x0103, 0x01}, /* software reset for OVTATool only */
> {0x0103, 0x01}, /* software reset */
> {0x0100, 0x00}, /* software standby */
> - {0x0302, 0x1e}, /* pll1_multi */
> - {0x0303, 0x00}, /* pll1_divm */
> - {0x0304, 0x03}, /* pll1_div_mipi */
> - {0x030e, 0x00}, /* pll2_rdiv */
> - {0x030f, 0x04}, /* pll2_divsp */
> - {0x0312, 0x01}, /* pll2_pre_div0, pll2_r_divdac */
> - {0x031e, 0x0c}, /* pll1_no_lat */
> {0x3600, 0x00},
> {0x3601, 0x00},
> {0x3602, 0x00},
> @@ -1053,7 +1116,6 @@ static const struct regval ov8858_global_regs_r2a_4lane[] = {
> {0x4600, 0x00},
> {0x4601, 0xcb},
> {0x481f, 0x32}, /* clk prepare min */
> - {0x4837, 0x16}, /* global timing */
> {0x4850, 0x10}, /* lane 1 = 1, lane 0 = 0 */
> {0x4851, 0x32}, /* lane 3 = 3, lane 2 = 2 */
> {0x4b00, 0x2a},
> @@ -1345,6 +1407,10 @@ static int ov8858_start_stream(struct ov8858 *ov8858,
> if (ret)
> return ret;
>
> + ret = ov8858_write_array(ov8858, ov8858->xvclk_regs);
> + if (ret)
> + return ret;
> +
> /* 200 usec max to let PLL stabilize. */
> fsleep(200);
>
> @@ -1540,6 +1606,21 @@ static int ov8858_set_long_digital_gain(struct ov8858 *ov8858, u32 gain)
> return ov8858_write(ov8858, OV8858_REG_LONG_DIGIGAIN, long_gain, NULL);
> }
>
> +static int ov8858_set_mwb_gains(struct ov8858 *ov8858)
> +{
> + int ret = 0;
> +
> + ov8858_write(ov8858, OV8858_REG_MWB_RED_GAIN,
> + ov8858->red_balance->val, &ret);
> + /* Green is the unity reference for the red and blue balance controls. */
> + ov8858_write(ov8858, OV8858_REG_MWB_GREEN_GAIN,
> + OV8858_MWB_GAIN_DEFAULT, &ret);
Any reasoning why the green gain wouldn't be exposed on UAPI?
> + ov8858_write(ov8858, OV8858_REG_MWB_BLUE_GAIN,
> + ov8858->blue_balance->val, &ret);
> +
> + return ret;
> +}
> +
> static int ov8858_set_ctrl(struct v4l2_ctrl *ctrl)
> {
> struct ov8858 *ov8858 = container_of(ctrl->handler,
> @@ -1588,6 +1669,10 @@ static int ov8858_set_ctrl(struct v4l2_ctrl *ctrl)
> case V4L2_CID_DIGITAL_GAIN:
> ret = ov8858_set_long_digital_gain(ov8858, ctrl->val);
> break;
> + case V4L2_CID_RED_BALANCE:
> + case V4L2_CID_BLUE_BALANCE:
> + ret = ov8858_set_mwb_gains(ov8858);
> + break;
> case V4L2_CID_VBLANK:
> ret = ov8858_write(ov8858, OV8858_REG_VTS,
> ctrl->val + format->height, NULL);
> @@ -1622,9 +1707,6 @@ static int ov8858_power_on(struct ov8858 *ov8858)
> unsigned long delay_us;
> int ret;
>
> - if (clk_get_rate(ov8858->xvclk) != OV8858_XVCLK_FREQ)
> - dev_warn(dev, "xvclk mismatched, modes are based on 24MHz\n");
> -
> ret = clk_prepare_enable(ov8858->xvclk);
> if (ret < 0) {
> dev_err(dev, "Failed to enable xvclk\n");
> @@ -1643,7 +1725,7 @@ static int ov8858_power_on(struct ov8858 *ov8858)
> * transaction, but a double sleep between the release of gpios
> * helps with sporadic failures observed at probe time.
> */
> - delay_us = DIV_ROUND_UP(8192, OV8858_XVCLK_FREQ / 1000 / 1000);
> + delay_us = DIV_ROUND_UP(8192, ov8858->xvclk_rate / HZ_PER_MHZ);
>
> gpiod_set_value_cansleep(ov8858->reset_gpio, 0);
> fsleep(delay_us);
> @@ -1709,7 +1791,7 @@ static int ov8858_init_ctrls(struct ov8858 *ov8858)
> u32 h_blank;
> int ret;
>
> - ret = v4l2_ctrl_handler_init(handler, 10);
> + ret = v4l2_ctrl_handler_init(handler, 12);
> if (ret)
> return ret;
>
> @@ -1751,6 +1833,19 @@ static int ov8858_init_ctrls(struct ov8858 *ov8858)
> OV8858_LONG_DIGIGAIN_STEP,
> OV8858_LONG_DIGIGAIN_DEFAULT);
>
> + ov8858->red_balance =
> + v4l2_ctrl_new_std(handler, &ov8858_ctrl_ops,
> + V4L2_CID_RED_BALANCE,
> + OV8858_MWB_GAIN_MIN, OV8858_MWB_GAIN_MAX,
> + OV8858_MWB_GAIN_STEP,
> + OV8858_MWB_GAIN_DEFAULT);
> + ov8858->blue_balance =
> + v4l2_ctrl_new_std(handler, &ov8858_ctrl_ops,
> + V4L2_CID_BLUE_BALANCE,
> + OV8858_MWB_GAIN_MIN, OV8858_MWB_GAIN_MAX,
> + OV8858_MWB_GAIN_STEP,
> + OV8858_MWB_GAIN_DEFAULT);
> +
> v4l2_ctrl_new_std_menu_items(handler, &ov8858_ctrl_ops,
> V4L2_CID_TEST_PATTERN,
> ARRAY_SIZE(ov8858_test_pattern_menu) - 1,
> @@ -1804,15 +1899,20 @@ static int ov8858_check_sensor_id(struct ov8858 *ov8858)
>
> if (id == OV8858_R2A) {
> /* R2A supports 2 and 4 lanes modes. */
> - ov8858->global_regs = ov8858->num_lanes == 4
> - ? ov8858_global_regs_r2a_4lane
> - : ov8858_global_regs_r2a_2lane;
> + if (ov8858->num_lanes == 4) {
> + ov8858->global_regs = ov8858_global_regs_r2a_4lane;
> + ov8858->xvclk_regs = ov8858_24mhz_r2a_4lane;
> + } else {
> + ov8858->global_regs = ov8858_global_regs_r2a_2lane;
> + ov8858->xvclk_regs = ov8858_24mhz_r2a_2lane;
> + }
> } else if (ov8858->num_lanes == 2) {
> /*
> * R1A only supports 2 lanes mode and it's only partially
> * supported.
> */
> ov8858->global_regs = ov8858_global_regs_r1a;
> + ov8858->xvclk_regs = ov8858_24mhz_r1a_2lane;
> dev_warn(&client->dev, "R1A may not work well!\n");
> } else {
> dev_err(&client->dev,
> @@ -1820,6 +1920,9 @@ static int ov8858_check_sensor_id(struct ov8858 *ov8858)
> return -EINVAL;
> }
>
> + if (ov8858->xvclk_rate == OV8858_XVCLK_FREQ_19_2MHZ)
> + ov8858->xvclk_regs = ov8858_cht_mrd_19_2mhz;
> +
> return 0;
> }
>
> @@ -1887,6 +1990,13 @@ static int ov8858_probe(struct i2c_client *client)
> return dev_err_probe(dev, PTR_ERR(ov8858->xvclk),
> "Failed to get xvclk\n");
>
> + ov8858->xvclk_rate = clk_get_rate(ov8858->xvclk);
> + if (ov8858->xvclk_rate != OV8858_XVCLK_FREQ_19_2MHZ &&
> + ov8858->xvclk_rate != OV8858_XVCLK_FREQ_24MHZ)
> + return dev_err_probe(dev, -EINVAL,
> + "Unsupported xvclk rate %lu Hz\n",
> + ov8858->xvclk_rate);
> +
> ov8858->reset_gpio = devm_gpiod_get_optional(dev, "reset",
> GPIOD_OUT_HIGH);
> if (IS_ERR(ov8858->reset_gpio))
--
Regards,
Sakari Ailus
next prev parent reply other threads:[~2026-10-01 20:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 14:53 [PATCH v7 00/16] media: Add Yoga Book camera support Maurizio Casciano
2026-09-02 14:53 ` [PATCH v7 01/16] media: ov8858: Extract digital gain programming Maurizio Casciano
2026-09-02 14:53 ` [PATCH v7 02/16] media: ov8858: support 19.2 MHz clock and CHT gain setup Maurizio Casciano
2026-09-03 4:42 ` Andy Shevchenko
2026-10-01 20:00 ` Sakari Ailus [this message]
2026-09-02 14:53 ` [PATCH v7 03/16] media: ov2740: Use C99 initializers for ACPI IDs Maurizio Casciano
2026-09-02 14:53 ` [PATCH v7 04/16] media: ov2740: Add OVTI2740 ACPI ID Maurizio Casciano
2026-09-03 5:35 ` Andy Shevchenko
2026-09-02 14:53 ` [PATCH v7 05/16] media: ov8858: Add INT3477 " Maurizio Casciano
2026-09-02 14:53 ` [PATCH v7 06/16] media: intel: ipu-bridge: Add Yoga Book camera sensors Maurizio Casciano
2026-09-02 14:53 ` [PATCH v7 07/16] media: atomisp: Add Yoga Book camera configuration Maurizio Casciano
2026-09-02 14:53 ` [PATCH v7 08/16] media: ov2740: support 288 MHz link frequency Maurizio Casciano
2026-09-02 14:53 ` [PATCH v7 09/16] media: intel: ipu-bridge: allow sensor-specific link frequencies Maurizio Casciano
2026-09-03 7:01 ` Andy Shevchenko
2026-10-01 20:03 ` Sakari Ailus
2026-09-02 14:53 ` [PATCH v7 10/16] media: atomisp: derive CSI-2 timing from sensor link frequency Maurizio Casciano
2026-09-02 14:53 ` [PATCH v7 11/16] media: atomisp: provide Yoga Book OV2740 " Maurizio Casciano
2026-09-02 14:53 ` [PATCH v7 12/16] media: ov2740: release group hold after gain write errors Maurizio Casciano
2026-10-01 20:06 ` Sakari Ailus
2026-09-02 14:53 ` [PATCH v7 13/16] media: ov2740: add manual white balance controls Maurizio Casciano
2026-09-02 14:53 ` [PATCH v7 14/16] media: atomisp: Use struct v4l2_area for padding Maurizio Casciano
2026-09-03 7:04 ` Andy Shevchenko
2026-09-02 14:53 ` [PATCH v7 15/16] media: atomisp: allow raw Bayer capture Maurizio Casciano
2026-09-03 7:12 ` Andy Shevchenko
2026-09-02 14:53 ` [PATCH v7 16/16] media: i2c: Add WV517S lens actuator driver Maurizio Casciano
2026-09-03 4:44 ` [PATCH v7 00/16] media: Add Yoga Book camera support Andy Shevchenko
2026-09-03 5:37 ` Andy Shevchenko
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=ar674__4-cNOGMMy@kekkonen.localdomain \
--to=sakari.ailus@linux.intel.com \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=bingbu.cao@amd.com \
--cc=gregkh@linuxfoundation.org \
--cc=hansg@kernel.org \
--cc=jacopo.mondi@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=mauriziocasciano7@gmail.com \
--cc=mchehab@kernel.org \
--cc=nicholas@rothemail.net \
/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
all inboxes | Powered by JetHome®