[PATCH v3 0/5] media: ov02c10: get_selection and 26 MHz clock support

[Felipe Calliari <calliarifelipe@gmail.com>]

Some Raptor Lake laptops, e.g. the Samsung Galaxy Book3 series, feed the
OV02C10 a 26 MHz external clock, which the driver rejects at probe
today. This series adds support for it, together with two small changes
found along the way.

Patches 1 and 2 are unchanged from v2, apart from a corrected commit
message in patch 2. Patch 3 splits the PLL registers off the mode
tables, with no functional change. Patch 4 adds the 26 MHz link
frequency to the ipu-bridge. Patch 5 adds a 26 MHz PLL table and picks
the PLL table and the link frequency from the external clock rate.

With the other PLL registers left as for 19.2 MHz, the link frequency is
mclk * M / 19.2 MHz, M being the OP and VT PLL multipliers, which are
set to the same value. The 19.2 MHz tables use M = 400. At 26 MHz an
exact 400 MHz would need M = 295.38, so patch 5 uses M = 295 (0x0127):
399.479167 MHz, advertised as such, with a pixel rate of 159.791666 MHz
on two lanes. M = 296 would give 400.833333 MHz. Getting exactly 400 MHz
from 26 MHz needs a divider with a factor of 13. I have no PLL
documentation for this sensor. Sweeping 0x0301, 0x0303, 0x0313 and
0x031c around their table values only gave coarse steps, no output or no
change, so I don't think such a divider is available.

Tested on a Samsung Galaxy Book3 Ultra (Raptor Lake, two CSI-2 lanes,
26 MHz clock):

 - link_frequency reads 399479167 and pixel_rate 159791666.
 - I rewrote VTS over i2c while streaming and fitted the frame period,
   from buffer timestamps, against four VTS values from 2360 to 4600
   lines. That gives a line time of 14268.73 ns for an HTS of 2280,
   i.e. a pixel rate of 159.7899 MHz, 11 ppm below the advertised
   value. The intercept is -0.02 lines.
 - At the default VTS, a 60 s capture runs at 30.014 fps. No frames are
   dropped, apart from sequence number 1, which is skipped at every
   stream start with or without this series. 30.014 fps is below the
   30.105 fps that hblank, vblank and pixel_rate describe. The cause is
   not the PLL: with the exposure at its maximum (VTS - 8) the sensor
   stretches the frame to exposure + 15 lines. That is a separate issue,
   which I'll look at on its own.
 - A single CSI-2 "Frame sync error" is logged at stream start, as it is
   with the unmodified tables.

The 19.2 MHz path is untested, as I have no such hardware. It ends up
with the same register values. Only the write order changes, and two
writes that the per-lane tables used to override are gone.

Changes in v3:
- Patch 2, commit message only: the crop is centred in the output size
  (0x3808-0x380b), not taken from the readout window.
- New patch 3, splitting the PLL registers off the mode tables (Sakari).
- Advertise the 26 MHz link frequency, 399.479167 MHz, as a second menu
  entry and derive the pixel rate from it (Sakari). New ipu-bridge
  patch 4 lists it in the fwnode.
- Patch 5: short commit message, dev_dbg() dropped, no 0x0315 write.

v2: https://lore.kernel.org/linux-media/20260923144257.119076-1-calliarifelipe@gmail.com/
v1: https://lore.kernel.org/linux-media/20260905030732.39196-1-calliarifelipe@gmail.com/

Felipe Calliari (5):
  media: ov02c10: Drop duplicate register write
  media: ov02c10: Implement get_selection
  media: ov02c10: Split the PLL registers off the mode tables
  media: ipu-bridge: Add the OV02C10 26 MHz link frequency
  media: ov02c10: Add support for a 26 MHz external clock

 drivers/media/i2c/ov02c10.c          | 134 +++++++++++++++++++++++----
 drivers/media/pci/intel/ipu-bridge.c |   2 +-
 2 files changed, 116 insertions(+), 20 deletions(-)


base-commit: 2dcdfb625c3b8fe87454e19dfbc54b3e3f0ad70e
-- 
2.55.0