Re: [PATCH 3/3] media: ov02c10: Accept a 26 MHz external clock

From: Bryan O'Donoghue

Date: Tue Sep 08 2026 - 06:11:24 EST


On 05/09/2026 04:07, Felipe Calliari wrote:
Several Meteor Lake / Lunar Lake designs (e.g. the Samsung Galaxy Book3/4
series) wire the OV02C10 to a 26 MHz external clock instead of the
19.2 MHz assumed so far. The IPU6 ipu-bridge forwards the rate from the
ACPI SSDB verbatim as the "clock-frequency" property, so probe() just
rejects it today:

ov02c10 i2c-OVTI02C1:00: external clock 26000000 is not supported

Rename OV02C10_MCLK to OV02C10_MCLK_19_2MHZ, add OV02C10_MCLK_26MHZ and
accept both.

The PLL register tables are the 19.2 MHz ones; OmniVision's 26 MHz PLL
programming is not publicly available. With a 26 MHz input the same
dividers make every internal clock, and therefore the MIPI link, run
26/19.2 = 1.3542x faster: a ~541.7 MHz link and ~40 fps instead of the
nominal 400 MHz / 30 fps. Rather than leave link-frequency and
pixel-rate describing the 19.2 MHz case, add a second
V4L2_CID_LINK_FREQ menu entry (400 MHz * 26 / 19.2) and select it when
the external clock is 26 MHz. pixel-rate is derived from the link
frequency and scales with it, so the frame rate and exposure times
reported to userspace match the hardware, and the IPU6 CSI-2 receiver
programs its D-PHY high-speed frequency range and bandwidth budget for
the rate the sensor actually transmits.

The ipu-bridge fwnode only lists the nominal 400 MHz link frequency
(keyed by ACPI HID, not by clock rate), so v4l2_link_freq_to_bitmap()
still matches on the 400 MHz entry and the 541.7 MHz index is selected
explicitly for the 26 MHz case.

On a Meteor Lake test machine a single CSI-2 "frame sync error" may
still be logged by the IPU6 receiver at stream start, after which
capture runs cleanly; this looks like a sensor PLL settling transient
and is not addressed here.

While touching the clock check, terminate its error string with a
newline.

Signed-off-by: Felipe Calliari<calliarifelipe@xxxxxxxxx>
I don't see how this gets handled with Intel's downstream work

https://github.com/intel/ipu6-drivers/blob/master/drivers/media/i2c/ov02c10.c

So perhaps it just isn't handled. Seems a bit odd that several ODMs would use the 26MHz clock but there is no update to the ipu sensors drivers to match.

Absent the real init sequences for a 26 MHz xvclk, this solution is better than nothing.

Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>