All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@iki.fi>
To: Robert Foss <robert.foss@linaro.org>
Cc: Dongchun Zhu <dongchun.zhu@mediatek.com>,
	Fabio Estevam <festevam@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Tomasz Figa <tfiga@chromium.org>,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [v2 3/3] media: ov8856: Implement sensor module revision identification
Date: Fri, 13 Mar 2020 14:43:54 +0200	[thread overview]
Message-ID: <20200313124354.GE5730@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <20200313110350.10864-4-robert.foss@linaro.org>

Hi Robert,

On Fri, Mar 13, 2020 at 12:03:50PM +0100, Robert Foss wrote:
> Query the sensor for its module revision, and compare it
> to known revisions.
> Currently only the '1B' revision has been added.
> 
> Signed-off-by: Robert Foss <robert.foss@linaro.org>
> ---
>  drivers/media/i2c/ov8856.c | 54 +++++++++++++++++++++++++++++++++-----
>  1 file changed, 48 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov8856.c b/drivers/media/i2c/ov8856.c
> index db61eed223e8..39662d3d86dd 100644
> --- a/drivers/media/i2c/ov8856.c
> +++ b/drivers/media/i2c/ov8856.c
> @@ -34,6 +34,18 @@
>  #define OV8856_MODE_STANDBY		0x00
>  #define OV8856_MODE_STREAMING		0x01
>  
> +/* define 1B module revision */
> +#define OV8856_1B_MODULE		0x02
> +
> +/* the OTP read-out buffer is at 0x7000 and 0xf is the offset
> + * of the byte in the OTP that means the module revision
> + */
> +#define OV8856_MODULE_REVISION		0x700f
> +#define OV8856_OTP_MODE_CTRL		0x3d84
> +#define OV8856_OTP_LOAD_CTRL		0x3d81
> +#define OV8856_OTP_MODE_AUTO		0x00
> +#define OV8856_OTP_LOAD_CTRL_ENABLE	BIT(0)
> +
>  /* vertical-timings from sensor */
>  #define OV8856_REG_VTS			0x380e
>  #define OV8856_VTS_MAX			0x7fff
> @@ -711,6 +723,25 @@ static int ov8856_test_pattern(struct ov8856 *ov8856, u32 pattern)
>  				OV8856_REG_VALUE_08BIT, pattern);
>  }
>  
> +static int ov8856_check_revision(struct ov8856 *ov8856)

There are no version checks being done here, nor apparently the version is
read by this function. 

> +{
> +	int ret;
> +
> +	ret = ov8856_write_reg(ov8856, OV8856_REG_MODE_SELECT,
> +			       OV8856_REG_VALUE_08BIT, OV8856_MODE_STREAMING);
> +	if (ret)
> +		return ret;
> +
> +	ret = ov8856_write_reg(ov8856, OV8856_OTP_MODE_CTRL,
> +			       OV8856_REG_VALUE_08BIT, OV8856_OTP_MODE_AUTO);
> +	if (ret)
> +		return ret;
> +
> +	return ov8856_write_reg(ov8856, OV8856_OTP_LOAD_CTRL,
> +				OV8856_REG_VALUE_08BIT,
> +				OV8856_OTP_LOAD_CTRL_ENABLE);

If streaming is started to read the EEPROM, shouldn't it be stopped after
reading it as well?

> +}
> +
>  static int ov8856_set_ctrl(struct v4l2_ctrl *ctrl)
>  {
>  	struct ov8856 *ov8856 = container_of(ctrl->handler,
> @@ -1144,6 +1175,23 @@ static int ov8856_identify_module(struct ov8856 *ov8856)
>  		return -ENXIO;
>  	}
>  
> +	/* check sensor hardware revision */
> +	ret = ov8856_check_revision(ov8856);
> +	if (ret) {
> +		dev_err(&client->dev, "failed to check sensor revision");
> +		return ret;
> +	}
> +
> +	ret = ov8856_read_reg(ov8856, OV8856_MODULE_REVISION,
> +			      OV8856_REG_VALUE_08BIT, &val);
> +	if (ret)
> +		return ret;

How about moving this inside the check_revision function above? It looks as
if it's dependent on that.

> +
> +	dev_info(&client->dev, "OV8856 revision %x (%s) at address 0x%02x\n",
> +		val,
> +		val == OV8856_1B_MODULE ? "1B" : "unknown revision",
> +		client->addr);
> +
>  	return 0;
>  }
>  
> @@ -1254,12 +1302,6 @@ static int ov8856_probe(struct i2c_client *client)
>  		return PTR_ERR(ov8856->xvclk);
>  	}
>  
> -	ret = clk_set_rate(ov8856->xvclk, OV8856_XVCLK_24);

This seems like an unrelated change.

> -	if (ret < 0) {
> -		dev_err(&client->dev, "failed to set xvclk rate (24MHz)\n");
> -		return ret;
> -	}
> -
>  	ov8856->reset_gpio = devm_gpiod_get(&client->dev, "reset",
>  					       GPIOD_OUT_HIGH);
>  	if (IS_ERR(ov8856->reset_gpio)) {

-- 
Regards,

Sakari Ailus

WARNING: multiple messages have this Message-ID (diff)
From: Sakari Ailus <sakari.ailus@iki.fi>
To: Robert Foss <robert.foss@linaro.org>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Tomasz Figa <tfiga@chromium.org>,
	Dongchun Zhu <dongchun.zhu@mediatek.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Fabio Estevam <festevam@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [v2 3/3] media: ov8856: Implement sensor module revision identification
Date: Fri, 13 Mar 2020 14:43:54 +0200	[thread overview]
Message-ID: <20200313124354.GE5730@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <20200313110350.10864-4-robert.foss@linaro.org>

Hi Robert,

On Fri, Mar 13, 2020 at 12:03:50PM +0100, Robert Foss wrote:
> Query the sensor for its module revision, and compare it
> to known revisions.
> Currently only the '1B' revision has been added.
> 
> Signed-off-by: Robert Foss <robert.foss@linaro.org>
> ---
>  drivers/media/i2c/ov8856.c | 54 +++++++++++++++++++++++++++++++++-----
>  1 file changed, 48 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov8856.c b/drivers/media/i2c/ov8856.c
> index db61eed223e8..39662d3d86dd 100644
> --- a/drivers/media/i2c/ov8856.c
> +++ b/drivers/media/i2c/ov8856.c
> @@ -34,6 +34,18 @@
>  #define OV8856_MODE_STANDBY		0x00
>  #define OV8856_MODE_STREAMING		0x01
>  
> +/* define 1B module revision */
> +#define OV8856_1B_MODULE		0x02
> +
> +/* the OTP read-out buffer is at 0x7000 and 0xf is the offset
> + * of the byte in the OTP that means the module revision
> + */
> +#define OV8856_MODULE_REVISION		0x700f
> +#define OV8856_OTP_MODE_CTRL		0x3d84
> +#define OV8856_OTP_LOAD_CTRL		0x3d81
> +#define OV8856_OTP_MODE_AUTO		0x00
> +#define OV8856_OTP_LOAD_CTRL_ENABLE	BIT(0)
> +
>  /* vertical-timings from sensor */
>  #define OV8856_REG_VTS			0x380e
>  #define OV8856_VTS_MAX			0x7fff
> @@ -711,6 +723,25 @@ static int ov8856_test_pattern(struct ov8856 *ov8856, u32 pattern)
>  				OV8856_REG_VALUE_08BIT, pattern);
>  }
>  
> +static int ov8856_check_revision(struct ov8856 *ov8856)

There are no version checks being done here, nor apparently the version is
read by this function. 

> +{
> +	int ret;
> +
> +	ret = ov8856_write_reg(ov8856, OV8856_REG_MODE_SELECT,
> +			       OV8856_REG_VALUE_08BIT, OV8856_MODE_STREAMING);
> +	if (ret)
> +		return ret;
> +
> +	ret = ov8856_write_reg(ov8856, OV8856_OTP_MODE_CTRL,
> +			       OV8856_REG_VALUE_08BIT, OV8856_OTP_MODE_AUTO);
> +	if (ret)
> +		return ret;
> +
> +	return ov8856_write_reg(ov8856, OV8856_OTP_LOAD_CTRL,
> +				OV8856_REG_VALUE_08BIT,
> +				OV8856_OTP_LOAD_CTRL_ENABLE);

If streaming is started to read the EEPROM, shouldn't it be stopped after
reading it as well?

> +}
> +
>  static int ov8856_set_ctrl(struct v4l2_ctrl *ctrl)
>  {
>  	struct ov8856 *ov8856 = container_of(ctrl->handler,
> @@ -1144,6 +1175,23 @@ static int ov8856_identify_module(struct ov8856 *ov8856)
>  		return -ENXIO;
>  	}
>  
> +	/* check sensor hardware revision */
> +	ret = ov8856_check_revision(ov8856);
> +	if (ret) {
> +		dev_err(&client->dev, "failed to check sensor revision");
> +		return ret;
> +	}
> +
> +	ret = ov8856_read_reg(ov8856, OV8856_MODULE_REVISION,
> +			      OV8856_REG_VALUE_08BIT, &val);
> +	if (ret)
> +		return ret;

How about moving this inside the check_revision function above? It looks as
if it's dependent on that.

> +
> +	dev_info(&client->dev, "OV8856 revision %x (%s) at address 0x%02x\n",
> +		val,
> +		val == OV8856_1B_MODULE ? "1B" : "unknown revision",
> +		client->addr);
> +
>  	return 0;
>  }
>  
> @@ -1254,12 +1302,6 @@ static int ov8856_probe(struct i2c_client *client)
>  		return PTR_ERR(ov8856->xvclk);
>  	}
>  
> -	ret = clk_set_rate(ov8856->xvclk, OV8856_XVCLK_24);

This seems like an unrelated change.

> -	if (ret < 0) {
> -		dev_err(&client->dev, "failed to set xvclk rate (24MHz)\n");
> -		return ret;
> -	}
> -
>  	ov8856->reset_gpio = devm_gpiod_get(&client->dev, "reset",
>  					       GPIOD_OUT_HIGH);
>  	if (IS_ERR(ov8856->reset_gpio)) {

-- 
Regards,

Sakari Ailus

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-03-13 12:44 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-13 11:03 [v2 0/3] media: ov8856: Add devicetree support Robert Foss
2020-03-13 11:03 ` Robert Foss
2020-03-13 11:03 ` [v2 1/3] media: dt-bindings: ov8856: Document YAML bindings Robert Foss
2020-03-13 11:03   ` Robert Foss
2020-03-13 12:19   ` Sakari Ailus
2020-03-13 12:19     ` Sakari Ailus
2020-03-13 22:00   ` Rob Herring
2020-03-13 22:00     ` Rob Herring
2020-03-13 11:03 ` [v2 2/3] media: ov8856: Add devicetree support Robert Foss
2020-03-13 11:03   ` Robert Foss
2020-03-13 12:17   ` Sakari Ailus
2020-03-13 12:17     ` Sakari Ailus
2020-03-26 11:56     ` Robert Foss
2020-03-26 11:56       ` Robert Foss
2020-03-26 14:47       ` Sakari Ailus
2020-03-26 14:47         ` Sakari Ailus
2020-03-27 10:32         ` Robert Foss
2020-03-27 10:32           ` Robert Foss
2020-03-27 13:37           ` Sakari Ailus
2020-03-27 13:37             ` Sakari Ailus
2020-03-13 12:28   ` Andy Shevchenko
2020-03-13 12:28     ` Andy Shevchenko
2020-03-13 13:15   ` Fabio Estevam
2020-03-13 13:15     ` Fabio Estevam
2020-03-31 13:37     ` Robert Foss
2020-03-31 13:37       ` Robert Foss
2020-03-31 13:42       ` Fabio Estevam
2020-03-31 13:42         ` Fabio Estevam
2020-03-31 13:53         ` Andy Shevchenko
2020-03-31 13:53           ` Andy Shevchenko
2020-03-13 11:03 ` [v2 3/3] media: ov8856: Implement sensor module revision identification Robert Foss
2020-03-13 11:03   ` Robert Foss
2020-03-13 12:43   ` Sakari Ailus [this message]
2020-03-13 12:43     ` Sakari Ailus

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=20200313124354.GE5730@valkosipuli.retiisi.org.uk \
    --to=sakari.ailus@iki.fi \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dongchun.zhu@mediatek.com \
    --cc=festevam@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=robert.foss@linaro.org \
    --cc=tfiga@chromium.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.