[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <828597fc-ec02-488c-99e9-418a7ff266d3@oss.qualcomm.com>
Date: Mon, 12 Jan 2026 19:50:38 +0800
From: Wenmeng Liu <wenmeng.liu@....qualcomm.com>
To: Bryan O'Donoghue <bod@...nel.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: mchehab@...nel.org, linux-media@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] media: i2c: imx412: wait for NVM read (T7) before
programming mode registers
On 1/12/2026 6:21 PM, Bryan O'Donoghue wrote:
> On 12/01/2026 10:09, Wenmeng Liu wrote:
>>>>> This delay should go at the end of the operation that requires the
>>>>> delay
>>>>> not at the start of the streaming operation.
>>> I would have thought that, too, but I understand there's an issue
>>> with an
>>> 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).
>>>
>> Hi Sakari,
>>
>> 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
Powered by blists - more mailing lists