From: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
To: Dave Stevenson <dave.stevenson@raspberrypi.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
Wenmeng Liu <quic_wenmliu@quicinc.com>
Subject: Re: [PATCH] media: i2c: imx412: Extend the power-on waiting time
Date: Mon, 22 Dec 2025 20:20:14 +0800 [thread overview]
Message-ID: <ffa7b849-51da-42f7-be1d-c3c7e1903e6e@oss.qualcomm.com> (raw)
In-Reply-To: <CAPY8ntD9GO_Y13K=Ko5kxz-o1edaocJP=Ns50rUheJP0iJ9fNg@mail.gmail.com>
On 12/22/2025 8:11 PM, Dave Stevenson wrote:
> Hi Wenmeng & Sakari
>
> On Mon, 22 Dec 2025 at 09:35, Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> wrote:
>>
>>
>>
>>
>>>>
>>>> The Arducam IMX577 module requires a longer reset time than the 1000µs
>>>> configured in the current driver. Increase the wait time after power-on
>>>> to ensure proper initialization.
>>>
>>> Is this somehow specific to the Arducam module? If so, what's there in the
>>> module that requires this?
>>>
>>
>>
>> Yes, This issue occurred on the Arducam 22-pin IMX577 module.
>> I have tried changing the sequence of regulator, reset, and clock, and
>> found that this module must wait a sufficient amount of time after reset
>> before registers can be written (10 ms is a safe duration). This issue
>> did not occur when using other IMX577 modules.
>
> Is it the probe that fails, or starting streaming?
>
> Google has found me a datasheet for IMX577 at [1]. I'm hoping you have
> an official datasheet, so do correct the following if that has any
> updates.
> Section 7-2-2 on page 30 for the startup sequence.
>
> The sequence is meant to be regulators, INCK, and then XCLR. The
> driver does XCLR before clock, so that would appear to be wrong.
>
> It also states that T6 as the time from XCLR to being able to read the
> version register is min 0.6ms, but T7 as the time before you can send
> "Streaming Commmand" is min 8ms "To complete reading all parameters
> from NVM".
> That would be a difference between probe and start_streaming, although
> admittedly sending the mode and control setup I2C commands will take
> up some of that time.
>
> Plausibly the other set of modules don't have the NVM programmed and
> hence they are ready sooner. Either way I'd say that does mean the
> driver currently isn't following the defined power up sequence, and
> the patch looks reasonable for IMX577.
> However as this is a shared driver does IMX412 have this restriction
> too? I can't find a datasheet for that one to check. For the sake of
> ~9ms it's not going to make a huge difference though.
>
> Dave
>
> [1] https://en.sunnywale.com/uploadfile/2021/1222/IMX577-AACK-C(Awin).pdf
>
Hi Dave,
this issue appears in the write register when streamon
imx412_write_regs. poweron->streamon.
static int imx412_start_streaming(struct imx412 *imx412)
{
const struct imx412_reg_list *reg_list;
int ret;
/* Write sensor mode registers */
reg_list = &imx412->cur_mode->reg_list;
ret = imx412_write_regs(imx412, reg_list->regs,
reg_list->num_of_regs);
if (ret) {
dev_err(imx412->dev, "fail to write initial registers\n");
return ret;
}
/* Setup handler will write actual exposure and gain */
ret = __v4l2_ctrl_handler_setup(imx412->sd.ctrl_handler);
if (ret) {
dev_err(imx412->dev, "fail to setup handler\n");
return ret;
}
/* Delay is required before streaming*/
usleep_range(7400, 8000);
/* Start streaming */
ret = imx412_write_reg(imx412, IMX412_REG_MODE_SELECT,
1, IMX412_MODE_STREAMING);
if (ret) {
dev_err(imx412->dev, "fail to start streaming\n");
return ret;
}
return 0;
}
> but T7 as the time before you can send "Streaming Commmand" is min 8ms "
I think the usleep_range(7400, 8000) represents the 8ms duration
required by T7.
Thanks,
Wenmeng
next prev parent reply other threads:[~2025-12-22 12:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-22 9:04 [PATCH] media: i2c: imx412: Extend the power-on waiting time Wenmeng Liu
2025-12-22 9:11 ` Sakari Ailus
2025-12-22 9:14 ` Wenmeng Liu
2025-12-22 9:35 ` Wenmeng Liu
2025-12-22 12:11 ` Dave Stevenson
2025-12-22 12:20 ` Wenmeng Liu [this message]
2025-12-22 14:16 ` Dave Stevenson
2025-12-23 6:19 ` Wenmeng Liu
2025-12-30 11:33 ` Sakari Ailus
2026-01-05 8:14 ` Wenmeng Liu
2026-01-07 13:36 ` 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=ffa7b849-51da-42f7-be1d-c3c7e1903e6e@oss.qualcomm.com \
--to=wenmeng.liu@oss.qualcomm.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=quic_wenmliu@quicinc.com \
--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;
as well as URLs for NNTP newsgroup(s).