From: Kieran Bingham <kieran.bingham@ideasonboard.com>
To: Alexandru Ardelean <aardelean@baylibre.com>,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org
Cc: laurent.pinchart@ideasonboard.com,
manivannan.sadhasivam@linaro.org, sakari.ailus@linux.intel.com,
mchehab@kernel.org, Alexandru Ardelean <alex@shruggie.ro>,
Alexandru Ardelean <aardelean@baylibre.com>
Subject: Re: [PATCH] media: i2c: imx296: Implement simple retry for model identification
Date: Fri, 15 Nov 2024 14:57:12 +0000 [thread overview]
Message-ID: <173168263299.4187655.2771344063896221513@ping.linuxembedded.co.uk> (raw)
In-Reply-To: <20241115142021.574402-1-aardelean@baylibre.com>
Quoting Alexandru Ardelean (2024-11-15 14:20:21)
> From: Alexandru Ardelean <alex@shruggie.ro>
>
> On a cold boot of the device (and sensor), and when using the 'sony,imx296'
> compatible string, it often seems that I get 'invalid device model 0x0000'.
> After doing a soft reboot, it seems to work fine.
>
> After applying this change (to do several retries), the sensor is
> identified on the first cold boot. The assumption here would be that the
> wake-up from standby takes too long. But even trying a 'udelay(100)' after
> writing register IMX296_CTRL00 doesn't seem to help (100 microseconds
> should be a reasonable fixed time).
I believe Raspberry Pi have an IMX296 and have some out of tree patches.
https://github.com/raspberrypi/linux/commits/rpi-6.6.y/drivers/media/i2c/imx296.c
It looks like they do similar fixes for bootup, for instance:
https://github.com/raspberrypi/linux/commit/7713ce38e6a26425ace3a57b3d03ba0125c16f89
which introduces a 2-5ms delay before reading the IMX296_SENSOR_INFO
register.
As this delay is significantly longer tahn the 100microseconds you've
tried it might be worth testing Naushir's patch, which states:
"""
Add a 2-5ms delay when coming out of standby and before reading the
sensor info register durning probe, as instructed by the datasheet. This
standby delay is already present when the sensor starts streaming.
"""
Regards
--
Kieran
>
> However, after implementing the retry loop (as this patch does it), seems
> to resolve the issue on the cold boot, and the device is identified.
>
> When using the 'sony,imx296ll' and 'sony,imx296lq' compatible strings, the
> device identification process isn't happening, and the sensor works fine.
>
> Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com>
> ---
> drivers/media/i2c/imx296.c | 44 ++++++++++++++++++++++----------------
> 1 file changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/i2c/imx296.c b/drivers/media/i2c/imx296.c
> index 83149fa729c4..9c3641c005a4 100644
> --- a/drivers/media/i2c/imx296.c
> +++ b/drivers/media/i2c/imx296.c
> @@ -931,7 +931,7 @@ static int imx296_read_temperature(struct imx296 *sensor, int *temp)
> static int imx296_identify_model(struct imx296 *sensor)
> {
> unsigned int model;
> - int temp = 0;
> + int temp = 0, retries;
> int ret;
>
> model = (uintptr_t)of_device_get_match_data(sensor->dev);
> @@ -943,25 +943,33 @@ static int imx296_identify_model(struct imx296 *sensor)
> return 0;
> }
>
> - /*
> - * While most registers can be read when the sensor is in standby, this
> - * is not the case of the sensor info register :-(
> - */
> - ret = imx296_write(sensor, IMX296_CTRL00, 0, NULL);
> - if (ret < 0) {
> - dev_err(sensor->dev,
> - "failed to get sensor out of standby (%d)\n", ret);
> - return ret;
> - }
> + retries = 0;
> + do {
> + /*
> + * While most registers can be read when the sensor is in
> + * standby, this is not the case of the sensor info register :-(
> + */
> + ret = imx296_write(sensor, IMX296_CTRL00, 0, NULL);
> + if (ret < 0) {
> + dev_err(sensor->dev,
> + "failed to get sensor out of standby (%d)\n",
> + ret);
> + return ret;
> + }
>
> - ret = imx296_read(sensor, IMX296_SENSOR_INFO);
> - if (ret < 0) {
> - dev_err(sensor->dev, "failed to read sensor information (%d)\n",
> - ret);
> - goto done;
> - }
> + udelay(10);
> +
> + ret = imx296_read(sensor, IMX296_SENSOR_INFO);
> + if (ret < 0) {
> + dev_err(sensor->dev,
> + "failed to read sensor information (%d)\n",
> + ret);
> + goto done;
> + }
> +
> + model = (ret >> 6) & 0x1ff;
> + } while (model == 0 && retries++ < 3);
>
> - model = (ret >> 6) & 0x1ff;
>
> switch (model) {
> case 296:
> --
> 2.46.1
>
next prev parent reply other threads:[~2024-11-15 14:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-15 14:20 Alexandru Ardelean
2024-11-15 14:57 ` Kieran Bingham [this message]
2024-11-15 17:11 ` Alexandru Ardelean
2024-11-15 18:07 ` [PATCH v2] drivers: media: imx296: Add standby delay during probe Alexandru Ardelean
2024-11-16 16:47 ` Laurent Pinchart
2024-11-18 10:08 ` Kieran Bingham
2024-12-10 13:35 ` 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=173168263299.4187655.2771344063896221513@ping.linuxembedded.co.uk \
--to=kieran.bingham@ideasonboard.com \
--cc=aardelean@baylibre.com \
--cc=alex@shruggie.ro \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.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
all inboxes | Powered by JetHome®