From: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Bryan O'Donoghue <bod@kernel.org>,
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 18:09:15 +0800 [thread overview]
Message-ID: <468ce093-7704-4497-a538-c54baacbd8ae@oss.qualcomm.com> (raw)
In-Reply-To: <aWS5qIA1Hfrr-3Yb@kekkonen.localdomain>
On 1/12/2026 5:06 PM, Sakari Ailus wrote:
> Hi Wenmeng, Bryan,
>
> On Mon, Jan 12, 2026 at 11:07:39AM +0800, Wenmeng Liu wrote:
>>
>>
>> On 1/9/2026 8:32 PM, Bryan O'Donoghue 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
> Also see
> <URL:https://git.retiisi.eu/?p=~sailus/linux.git;a=shortlog;h=refs/heads/pm-resume-delay>.
> I haven't posted these yet, but I think it'd be useful to avoid extra
> delays here and elsewhere.
compile failed in my side...
+void pm_runtime_resume_fsleep(struct device *dev, u64 sleep_us)
+{
+ u64 ns_diff = ktime_get_mono_fast_ns() -
READ_ONCE(dev->power.last_busy);
+
+ if (ns_diff < NSEC_PER_USEC * sleep_us)
+ fsleep(sleep_us - (ns_diff >> 10)); /* avoid div_u64 */
+}
use this func in imx412.c for all usleep_range, have no effect.
>
>>>
>>> The delay after the stream write, should be related to the stream write
>>> command, not the antecedent - the command that came before
>>> start_streaming.
>>>
>>> Basically I think you need to put your delay into the CCI_ID read NVM
>>> parameter load routine so that it guarantees its own completion.
>>>
>>> Because for argument's sake if start_streaming() were not to be the
>>> thing to happen after CCI_ID/NVM loading, the logic would no longer
>>> work.
>>>
>>> And you need a Fixes: tag for this patch too.
>>
>> Reading the sensor ID only occurs during the sensor probe process. After the
>> probe is completed, the IMX577 will power down. When stream on occurs, the
>> driver will power on again and then start streaming, but the sensor ID is
>> not read during the stream on process.I have tested this change on imx577
>> modules of different models.
>>
>> So this change can only happen during power on or stream on.
>>
>> Hi Bryan, Sakari,
>> May I ask if you have any suggestions regarding this?
>
> Could you add a comment this delay is there for the Arducam module (and
> which one), that doesn't work without it?
>
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
I have tested on these two IMX577 sensor module form Arducam,all have
this issue.Did not encounter this problem when using one non-arducam
IMX577.
Thanks,
Wenmeng
next prev parent reply other threads:[~2026-01-12 10:09 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 [this message]
2026-01-12 10:21 ` Bryan O'Donoghue
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=468ce093-7704-4497-a538-c54baacbd8ae@oss.qualcomm.com \
--to=wenmeng.liu@oss.qualcomm.com \
--cc=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 \
/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®