From: Bryan O'Donoghue <bod@kernel.org>
To: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: mchehab@kernel.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] media: i2c: imx412: wait for NVM read (T7) before programming mode registers
Date: Mon, 12 Jan 2026 10:21:18 +0000 [thread overview]
Message-ID: <ca5e24d7-94ea-47f0-9e02-cb6ecb3b9b24@kernel.org> (raw)
In-Reply-To: <468ce093-7704-4497-a538-c54baacbd8ae@oss.qualcomm.com>
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.
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.
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.
---
bod
next prev parent reply other threads:[~2026-01-12 10:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <tjF2Z2nt6dR-T_d-5cSpzZqItgoMsUzNmUBQ-jucG9SMQ9Q4y9cCrW4aya-hRJR0dQG-q63OBmZajTWMbxfeUA==@protonmail.internalid>
2026-01-09 4:49 ` Wenmeng Liu
2026-01-09 12:32 ` Bryan O'Donoghue
2026-01-12 3:07 ` Wenmeng Liu
2026-01-12 9:06 ` Sakari Ailus
2026-01-12 10:09 ` Wenmeng Liu
2026-01-12 10:21 ` Bryan O'Donoghue [this message]
2026-01-12 11:50 ` Wenmeng Liu
2026-01-12 11:59 ` Bryan O'Donoghue
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=ca5e24d7-94ea-47f0-9e02-cb6ecb3b9b24@kernel.org \
--to=bod@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=wenmeng.liu@oss.qualcomm.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®