Re: [PATCH v2] media: i2c: imx412: wait for NVM read (T7) before programming mode registers
From: Wenmeng Liu
Date: Mon Jan 12 2026 - 06:50:45 EST
On 1/12/2026 6:21 PM, Bryan O'Donoghue wrote:
On 12/01/2026 10:09, Wenmeng Liu wrote:
Hi Sakari,I would have thought that, too, but I understand there's an issue with anThis delay should go at the end of the operation that requires the delay
not at the start of the streaming operation.
Arducam module. It's also not exactly clear to me if all other registers
are writable at the sensor identification time or is the required delay
only concerning starting streaming (I'd hope so).
I tried adding a read ID at the end of power_on func and found that it
could only read the ID during probe; subsequent attempts during stream
on would fail to read every power on read.
[ 11.298460] imx412 2-001a: read reg chip id: 577
[ 11.310703] imx412 2-001a: read reg chip id: 577
[ 35.392396] imx412 2-001a: read reg failed ret = -5
[ 39.583990] imx412 2-001a: read reg failed ret = -5
This "smell wrong" points to the power_on() sequence not being correct.
You should be able to read the identity register at the end of power_on() every single time, if not, power_on - isn't working.
You should be able to put exactly the same delay into power_on() and have the same result as having no delay in power_on() instead having it in start_streaming().
Are you sure something else isn't happening - a reset line, pm_runtime .. ?
I think either power_off() is happening without you knowing it or more likely the reset line logic in the power_on() sequence isn't correct, which is why detecting the chip then fails.
-- if disable gpiod_set_value_cansleep(imx412->reset_gpio, 1); form imx412_power_off, the issue will not happen.
Through this analysis, the issue was ultimately identified as the Arducam IMX577 sensor module requiring a relatively long wait time after the reset pin is pulled high.
The reason why the ID can be read successfully the first time is that the GPIO’s default state is not output low. Therefore, to fix this problem, it is necessary to increase the delay time in the power_on sequence.
> In fact, looking at the power_on() sequence, I'd say we should have put
> reset 1, switched on power, and clock and then taken the part out of reset.
I tried this, but it didn't work at all.
Thanks,
Wenmeng