[PATCH] media: i2c: imx412: Extend the power-on waiting time

[PATCH] media: i2c: imx412: Extend the power-on waiting time

[Wenmeng Liu]

From: Wenmeng Liu <quic_wenmliu@quicinc.com>

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.

Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
---
Signed-off-by: Wenmeng <wenmeng.liu@oss.qualcomm.com>
---
 drivers/media/i2c/imx412.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/imx412.c b/drivers/media/i2c/imx412.c
index b3826f80354703b17b416dc233854da3f5736e38..e444c48c11b171b421c535beb23211bf0b600d3a 100644
--- a/drivers/media/i2c/imx412.c
+++ b/drivers/media/i2c/imx412.c
@@ -1037,7 +1037,7 @@ static int imx412_power_on(struct device *dev)
 		goto error_reset;
 	}
 
-	usleep_range(1000, 1200);
+	usleep_range(10000, 12000);
 
 	return 0;
 

---
base-commit: cc3aa43b44bdb43dfbac0fcb51c56594a11338a8
change-id: 20251222-imx412-1b02ec8bd2b5

Best regards,
-- 
Wenmeng <wenmeng.liu@oss.qualcomm.com>

Re: [PATCH] media: i2c: imx412: Extend the power-on waiting time

[Sakari Ailus]

Hi Wenmeng,

Thanks for the patch.

On Mon, Dec 22, 2025 at 05:04:07PM +0800, Wenmeng Liu wrote:
> From: Wenmeng Liu <quic_wenmliu@quicinc.com>
> 
> 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?

> 
> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
> ---
> Signed-off-by: Wenmeng <wenmeng.liu@oss.qualcomm.com>
> ---

Which one is the right one?

>  drivers/media/i2c/imx412.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/imx412.c b/drivers/media/i2c/imx412.c
> index b3826f80354703b17b416dc233854da3f5736e38..e444c48c11b171b421c535beb23211bf0b600d3a 100644
> --- a/drivers/media/i2c/imx412.c
> +++ b/drivers/media/i2c/imx412.c
> @@ -1037,7 +1037,7 @@ static int imx412_power_on(struct device *dev)
>  		goto error_reset;
>  	}
>  
> -	usleep_range(1000, 1200);
> +	usleep_range(10000, 12000);
>  
>  	return 0;
>  
> 

-- 
Kind regards,

Sakari Ailus

Re: [PATCH] media: i2c: imx412: Extend the power-on waiting time

[Wenmeng Liu]

On 12/22/2025 5:11 PM, Sakari Ailus wrote:
> Hi Wenmeng,
> 
> Thanks for the patch.
> 
> On Mon, Dec 22, 2025 at 05:04:07PM +0800, Wenmeng Liu wrote:
>> From: Wenmeng Liu <quic_wenmliu@quicinc.com>
>>
>> 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?
> 
>>
>> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
>> ---
>> Signed-off-by: Wenmeng <wenmeng.liu@oss.qualcomm.com>
>> ---
> 
> Which one is the right one?

Hi Sakari,

Sorry that there was an issue with the signature of this patch. Here is 
the correct one:
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>

Thanks,
Wenmeng

Re: [PATCH] media: i2c: imx412: Extend the power-on waiting time

[Wenmeng Liu]

>>
>> 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.

Thanks,
Wenmeng

Re: [PATCH] media: i2c: imx412: Extend the power-on waiting time

[Dave Stevenson]

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

> Thanks,
> Wenmeng
>

Re: [PATCH] media: i2c: imx412: Extend the power-on waiting time

[Wenmeng Liu]

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

Re: [PATCH] media: i2c: imx412: Extend the power-on waiting time

[Dave Stevenson]

Hi Wenmeng

On Mon, 22 Dec 2025 at 12:20, Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> wrote:
>
>
>
> 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.

I'd missed that one.
If you've delayed for 10-12ms between coming out of reset and sending
the first command, then does the Arducam module still require another
8ms here, or can that be removed as you've already complied with T7?

Have you asked Arducam as to why their module takes longer? I can't
find an IMX577 module listed on their product pages so presumably it's
discontinued. There are a few links for a Luxonis Oak DepthAI board
[1] which is made by Arducam and is using IMX577, so is it that one?
Generally I've not encountered an issue with Arducam adding any weird
delay circuits on their sensor boards.

  Dave

[1] https://shop.luxonis.com/products/oak-ffc-imx577-m12

> Thanks,
> Wenmeng
>
>

Re: [PATCH] media: i2c: imx412: Extend the power-on waiting time

[Wenmeng Liu]

On 12/22/2025 10:16 PM, Dave Stevenson wrote:
> Hi Wenmeng
> 
> On Mon, 22 Dec 2025 at 12:20, Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> wrote:
>>
>>
>>
>> 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.
> 
> I'd missed that one.
> If you've delayed for 10-12ms between coming out of reset and sending
> the first command, then does the Arducam module still require another
> 8ms here, or can that be removed as you've already complied with T7?
> 
> Have you asked Arducam as to why their module takes longer? I can't
> find an IMX577 module listed on their product pages so presumably it's
> discontinued. There are a few links for a Luxonis Oak DepthAI board
> [1] which is made by Arducam and is using IMX577, so is it that one?
> Generally I've not encountered an issue with Arducam adding any weird
> delay circuits on their sensor boards.
> 
>    Dave
> 
> [1] https://shop.luxonis.com/products/oak-ffc-imx577-m12
> 
>> Thanks,
>> Wenmeng
>>
>>

Hi Dave,

Based on my testing, moving usleep_range(7400, 8000); to the beginning 
of the imx412_start_streaming function allows the Arducam IMX577 module 
to work properly. In contrast, other IMX577 sensors do not require this 
delay. I believe this corresponds to the T7 timing requirement. I have 
not yet confirmed this with Arducam, and I plan to compare once I 
receive another type Arducam IMX577 sensor.

Thanks,
Wenmeng

Re: [PATCH] media: i2c: imx412: Extend the power-on waiting time

[Sakari Ailus]

Hi Wenmeng,

On Tue, Dec 23, 2025 at 02:19:18PM +0800, Wenmeng Liu wrote:
> 
> 
> On 12/22/2025 10:16 PM, Dave Stevenson wrote:
> > Hi Wenmeng
> > 
> > On Mon, 22 Dec 2025 at 12:20, Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> wrote:
> > > 
> > > 
> > > 
> > > 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.
> > 
> > I'd missed that one.
> > If you've delayed for 10-12ms between coming out of reset and sending
> > the first command, then does the Arducam module still require another
> > 8ms here, or can that be removed as you've already complied with T7?
> > 
> > Have you asked Arducam as to why their module takes longer? I can't
> > find an IMX577 module listed on their product pages so presumably it's
> > discontinued. There are a few links for a Luxonis Oak DepthAI board
> > [1] which is made by Arducam and is using IMX577, so is it that one?
> > Generally I've not encountered an issue with Arducam adding any weird
> > delay circuits on their sensor boards.
> > 
> >    Dave
> > 
> > [1] https://shop.luxonis.com/products/oak-ffc-imx577-m12
> > 
> > > Thanks,
> > > Wenmeng
> > > 
> > > 
> 
> Hi Dave,
> 
> Based on my testing, moving usleep_range(7400, 8000); to the beginning of
> the imx412_start_streaming function allows the Arducam IMX577 module to work
> properly. In contrast, other IMX577 sensors do not require this delay. I
> believe this corresponds to the T7 timing requirement. I have not yet
> confirmed this with Arducam, and I plan to compare once I receive another
> type Arducam IMX577 sensor.

Thanks for investigating this.

Have you checked how long it actually takes elsewhere (where the sensor
works) before the mode related registers are written (and when they start
being written) on systems where it actually works? As I²C writes require
sleeping and depend on a process getting scheduled a large number of times,
this might play a role here.

These patches might be useful in sensor drivers at large (but won't address
this problem)
<URL:https://git.retiisi.eu/?p=~sailus/linux.git;a=shortlog;h=refs/heads/pm-resume-delay>.

-- 
Kind regards,

Sakari Ailus

Re: [PATCH] media: i2c: imx412: Extend the power-on waiting time

[Wenmeng Liu]

On 12/30/2025 7:33 PM, Sakari Ailus wrote:
> Hi Wenmeng,
> 
> On Tue, Dec 23, 2025 at 02:19:18PM +0800, Wenmeng Liu wrote:
>>
>>
>> On 12/22/2025 10:16 PM, Dave Stevenson wrote:
>>> Hi Wenmeng
>>>
>>> On Mon, 22 Dec 2025 at 12:20, Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> wrote:
>>>>
>>>>
>>>>
>>>> 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.
>>>
>>> I'd missed that one.
>>> If you've delayed for 10-12ms between coming out of reset and sending
>>> the first command, then does the Arducam module still require another
>>> 8ms here, or can that be removed as you've already complied with T7?
>>>
>>> Have you asked Arducam as to why their module takes longer? I can't
>>> find an IMX577 module listed on their product pages so presumably it's
>>> discontinued. There are a few links for a Luxonis Oak DepthAI board
>>> [1] which is made by Arducam and is using IMX577, so is it that one?
>>> Generally I've not encountered an issue with Arducam adding any weird
>>> delay circuits on their sensor boards.
>>>
>>>     Dave
>>>
>>> [1] https://shop.luxonis.com/products/oak-ffc-imx577-m12
>>>
>>>> Thanks,
>>>> Wenmeng
>>>>
>>>>
>>
>> Hi Dave,
>>
>> Based on my testing, moving usleep_range(7400, 8000); to the beginning of
>> the imx412_start_streaming function allows the Arducam IMX577 module to work
>> properly. In contrast, other IMX577 sensors do not require this delay. I
>> believe this corresponds to the T7 timing requirement. I have not yet
>> confirmed this with Arducam, and I plan to compare once I receive another
>> type Arducam IMX577 sensor.
> 
> Thanks for investigating this.
> 
> Have you checked how long it actually takes elsewhere (where the sensor
> works) before the mode related registers are written (and when they start
> being written) on systems where it actually works? As I²C writes require
> sleeping and depend on a process getting scheduled a large number of times,
> this might play a role here.
> 
> These patches might be useful in sensor drivers at large (but won't address
> this problem)
> <URL:https://git.retiisi.eu/?p=~sailus/linux.git;a=shortlog;h=refs/heads/pm-resume-delay>.
> 

Hi Sakari,

Based on my testing, it takes about 6.5ms before the registers become 
writable. I believe this is not a CCI issue, because I have tested 
multiple platforms and only the Arducam 22-pin IMX577 shows this 
problem. This delay seems to correspond to the time required for T7. I 
made the following changes and ran multiple tests, and this approach 
works fine:

diff --git a/drivers/media/i2c/imx412.c b/drivers/media/i2c/imx412.c
index 459cca36493e..5be698863653 100644
--- a/drivers/media/i2c/imx412.c
+++ b/drivers/media/i2c/imx412.c
@@ -798,6 +798,9 @@ static int imx412_start_streaming(struct imx412 *imx412)
         const struct imx412_reg_list *reg_list;
         int ret;

+       /* Delay is required before streaming*/
+       usleep_range(7400, 8000);
+
         /* Write sensor mode registers */
         reg_list = &imx412->cur_mode->reg_list;
         ret = imx412_write_regs(imx412, reg_list->regs,
@@ -814,9 +817,6 @@ static int imx412_start_streaming(struct imx412 *imx412)
                 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);


 From the perspective of the spec timing, I believe the above 
modification to the delay position is an acceptable change. What do you 
think?

sensor link:
https://www.arducam.com/arducam-imx577-mini-camera-module-for-qualcomm-rb3g2.html
https://www.arducam.com/arducam-imx477-camera-module-for-depthai-oak-b0369.html

Thanks,
Wenmeng

Re: [PATCH] media: i2c: imx412: Extend the power-on waiting time

[Sakari Ailus]

Hi Wenmeng,

On Mon, Jan 05, 2026 at 04:14:21PM +0800, Wenmeng Liu wrote:
> 
> 
> On 12/30/2025 7:33 PM, Sakari Ailus wrote:
> > Hi Wenmeng,
> > 
> > On Tue, Dec 23, 2025 at 02:19:18PM +0800, Wenmeng Liu wrote:
> > > 
> > > 
> > > On 12/22/2025 10:16 PM, Dave Stevenson wrote:
> > > > Hi Wenmeng
> > > > 
> > > > On Mon, 22 Dec 2025 at 12:20, Wenmeng Liu <wenmeng.liu@oss.qualcomm.com> wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > 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.
> > > > 
> > > > I'd missed that one.
> > > > If you've delayed for 10-12ms between coming out of reset and sending
> > > > the first command, then does the Arducam module still require another
> > > > 8ms here, or can that be removed as you've already complied with T7?
> > > > 
> > > > Have you asked Arducam as to why their module takes longer? I can't
> > > > find an IMX577 module listed on their product pages so presumably it's
> > > > discontinued. There are a few links for a Luxonis Oak DepthAI board
> > > > [1] which is made by Arducam and is using IMX577, so is it that one?
> > > > Generally I've not encountered an issue with Arducam adding any weird
> > > > delay circuits on their sensor boards.
> > > > 
> > > >     Dave
> > > > 
> > > > [1] https://shop.luxonis.com/products/oak-ffc-imx577-m12
> > > > 
> > > > > Thanks,
> > > > > Wenmeng
> > > > > 
> > > > > 
> > > 
> > > Hi Dave,
> > > 
> > > Based on my testing, moving usleep_range(7400, 8000); to the beginning of
> > > the imx412_start_streaming function allows the Arducam IMX577 module to work
> > > properly. In contrast, other IMX577 sensors do not require this delay. I
> > > believe this corresponds to the T7 timing requirement. I have not yet
> > > confirmed this with Arducam, and I plan to compare once I receive another
> > > type Arducam IMX577 sensor.
> > 
> > Thanks for investigating this.
> > 
> > Have you checked how long it actually takes elsewhere (where the sensor
> > works) before the mode related registers are written (and when they start
> > being written) on systems where it actually works? As I²C writes require
> > sleeping and depend on a process getting scheduled a large number of times,
> > this might play a role here.
> > 
> > These patches might be useful in sensor drivers at large (but won't address
> > this problem)
> > <URL:https://git.retiisi.eu/?p=~sailus/linux.git;a=shortlog;h=refs/heads/pm-resume-delay>.
> > 
> 
> Hi Sakari,
> 
> Based on my testing, it takes about 6.5ms before the registers become
> writable. I believe this is not a CCI issue, because I have tested multiple
> platforms and only the Arducam 22-pin IMX577 shows this problem. This delay
> seems to correspond to the time required for T7. I made the following
> changes and ran multiple tests, and this approach works fine:
> 
> diff --git a/drivers/media/i2c/imx412.c b/drivers/media/i2c/imx412.c
> index 459cca36493e..5be698863653 100644
> --- a/drivers/media/i2c/imx412.c
> +++ b/drivers/media/i2c/imx412.c
> @@ -798,6 +798,9 @@ static int imx412_start_streaming(struct imx412 *imx412)
>         const struct imx412_reg_list *reg_list;
>         int ret;
> 
> +       /* Delay is required before streaming*/
> +       usleep_range(7400, 8000);
> +
>         /* Write sensor mode registers */
>         reg_list = &imx412->cur_mode->reg_list;
>         ret = imx412_write_regs(imx412, reg_list->regs,
> @@ -814,9 +817,6 @@ static int imx412_start_streaming(struct imx412 *imx412)
>                 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);
> 
> 
> From the perspective of the spec timing, I believe the above modification to
> the delay position is an acceptable change. What do you think?

Could you also add a comment explaining the issue? Otherwise there are good
chances someone will (at least try to) "fix" this later on.

-- 
Kind regards,

Sakari Ailus