mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: George Neacsu <geocausa@gmail.com>
To: Sergey Lebedev <lsa.uz@pm.me>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
	Benjamin Mugnier <benjamin.mugnier@foss.st.com>,
	Sylvain Petinot <sylvain.petinot@foss.st.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Dan Scally <dan.scally@ideasonboard.com>,
	Hans de Goede <hansg@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Peter Marshall <pm@petermarshall.ca>, Hao Yao <hao.yao@intel.com>,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] media: i2c: Add ST VD55G0 global shutter sensor driver
Date: Tue, 20 Oct 2026 07:44:54 +0100	[thread overview]
Message-ID: <179247822513.25202.7960395606350309657@gmail.com> (raw)
In-Reply-To: <20261019193402.52923-1-lsa.uz@pm.me>

On Mon, Oct 19, 2026 at 07:34:10PM +0000, Sergey Lebedev wrote:
> From 19.2 MHz, 403.2 MHz (806.4 Mbps, 42 times the clock) and
> 384 MHz (768 Mbps, 40 times) are exact, so the change is one value in
> your board's DT, in the sensor endpoint:
>
> 	link-frequencies = /bits/ 64 <403200000>;
>
> If it still stops after one frame, I would be glad to compare what the
> two drivers write at stream start.

That took the clock mismatch out of the experiment. With 403.2 MHz in
the DT and your v1 otherwise as posted, the sensor probes cleanly and
reports link_frequency=403200000 and pixel_rate=134400000, but capture
still delivers exactly one 644x604 Y10 frame and then times out waiting
for frame 2.

I then went back to the earlier VD55G0 A/B tests on this same Snapdragon
machine. One result was particularly useful: the 1200-pixel line length
alone still stalled, and omitting the 0x0329 write with the old line
length still stalled, but 1200 plus leaving 0x0329 untouched streamed
continuously. Your driver already has the 1200-pixel line length, but it
also has:

	vd55g0_write(sensor, VD55G0_REG_ISL_ENABLE, 0, &ret);

I rebuilt v1 with only that single write omitted, keeping the 403.2 MHz
DT setting and everything else unchanged. That fixes continuous capture
here:

- 5/5 frames in the initial Y10 644x604 capture
- 120/120 frames in a continuous run at about 60.2 fps
- immediate stream restart: 10/10 frames
- v4l2-compliance on the sensor subdev: 46/46, 0 failures, 0 warnings

There were no new CAMSS/CSID/VFE errors during the runs.

So the link-frequency correction is needed, but the one-frame stall is a
separate issue caused here by clearing VD55G0_REG_ISL_ENABLE (0x0329).
I have not tried to infer yet why clearing it prevents subsequent frames
on this sensor, but the A/B is repeatable and agrees with the older
VD55G0 results on this machine.

Would you be comfortable dropping that write in the next revision? I can
retest the revision on the Snapdragon model and add a Tested-by once it
is clean.

Best regards,
George

  reply	other threads:[~2026-10-20  6:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 16:27 [PATCH 0/4] media: Add the ST VD55G0 global shutter sensor Sergey Lebedev
2026-10-19 16:27 ` [PATCH 1/4] dt-bindings: media: i2c: Add ST VD55G0 camera sensor Sergey Lebedev
2026-10-20  8:27   ` Krzysztof Kozlowski
2026-10-20  9:08     ` Sergey Lebedev
2026-10-19 16:27 ` [PATCH 2/4] media: i2c: Add ST VD55G0 global shutter sensor driver Sergey Lebedev
2026-10-19 18:24   ` George Neacsu
2026-10-19 19:34     ` Sergey Lebedev
2026-10-20  6:44       ` George Neacsu [this message]
2026-10-20  8:52         ` Sergey Lebedev
2026-10-19 16:28 ` [PATCH 3/4] media: ipu-bridge: Add ST VD55G0 Sergey Lebedev
2026-10-19 16:28 ` [PATCH 4/4] media: ipu-bridge: Add the Surface Pro 11 infrared illuminator Sergey Lebedev

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=179247822513.25202.7960395606350309657@gmail.com \
    --to=geocausa@gmail.com \
    --cc=benjamin.mugnier@foss.st.com \
    --cc=conor+dt@kernel.org \
    --cc=dan.scally@ideasonboard.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hansg@kernel.org \
    --cc=hao.yao@intel.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lsa.uz@pm.me \
    --cc=mchehab@kernel.org \
    --cc=pm@petermarshall.ca \
    --cc=robh@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sylvain.petinot@foss.st.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®