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

[Sakari Ailus <sakari.ailus@linux.intel.com>]

Hi Felipe,

On Sat, Sep 05, 2026 at 12:07:32AM -0300, 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.

Please don't use a hard-coded value here. Instead, calculate the pixel
rate.

Registers 0x0304 and 0x0315 (both 16-bit) control the PLL multipliers for
OP and VT PLLs, respectively. You could also change the multipliers to
arrive in a frequency close to the previous configuration. The values would
be 0x28a and 0x1b1, respectively. I don't have the sensor so I can't test
this. The pixel rate would be a bit off, 400,307929 MHz, assuming the
previous value was exactly 400 MHz. This would also require adding the
frequency to the IPU bridge.

Either the pixel rate or the link frequency exported by the driver is
probably wrong.

-- 
Regards,

Sakari Ailus