Re: [PATCH 2/2] media: i2c: ov08x40: Do not expose the broken 1928x1088 binned mode

["Edvinas Šulcas" <edvinas.sulcas@gmail.com>]

Hi,

I can confirm this on a second CVS machine, and I think the data
supports what Jimmy wrote about CVS and Sakari's suggestion to deal
with it on the CVS side.

Machine: Dell XPS 14 DA14260 (Panther Lake), OV08X40 (OVTI08F4) behind
the CVS chip (ACPI INTC10E1, USB 06cb:0701), 2 data lanes. Ubuntu
7.0.0-38-generic with the in-tree intel_ipu7 and ov08x40 (the latter
built out of tree from v7.0 for the tests), intel_cvs from
intel/vision-drivers at 845d6f8.

- 1928x1088 (2 lanes, 749 MHz link frequency): the kernel logs "error
  group 3 code 18 details [0 0]" about twice per frame, which is
  INSYS_MSG_ERR_CAPTURE_HW_ERR_BAD_FRAME_DIM as Pierre found. A raw
  dump with libcamera's raw stream (stride 3904 bytes) has data only in
  line 0 (samples 42-90); the other 1087 lines are entirely 0xffff.
  Pierre saw the first and the last line; my buffer has 1088 lines, so
  a 1089th line would not fit. In the 3856x2176 mode all 2176 lines
  carry data and there are no errors.

- It does not depend on the extra registers of the binned list. That
  list writes about 110 registers the 3856x2176 list never touches
  (0x3a1a-0x3b06, 0x4911-0x497f, 0x49e0-0x49f1) and differs in 0x4501,
  0x4542, 0x3894 and 0x5000/0x5001. With a debug parameter that drops
  each group alone, all of them, and with 0x4501/0x4542 forced to the
  full-mode values, 20 captured frames at 1280x720 gave the same number
  of errors (43 or 44) in every case. That fits Jimmy's description
  that CVS only handles 1928x1088 as sHDR while the driver programs it
  as linear: changing details of the linear programming does not help.

- It is not CPU frequency either (all CPUs at 4.3 GHz instead of
  400 MHz while capturing, the idea from libcamera issue #328): same
  errors.

- Pierre's patches 1/2 and 2/2 applied to ov08x40.c from v7.0 (2/2 with
  fuzz 1) work here: 640x480, 1280x720, 1920x1080 and 3840x2160 all run
  at 28.6 fps with zero ISYS errors, and libcamera no longer complains
  about the missing crop rectangles. I have been using it in video
  calls. For patch 2/2 as posted:

  Tested-by: Edvinas Šulcas <edvinas.sulcas@gmail.com>

Oleg's report that the mode streams fine on a Yoga Slim 7x without a
vision chip in between points the same way: the mode itself works, it
is the combination with CVS that does not. Hiding it unconditionally
would take a working mode away from boards without CVS. So I think the
better place is on the CVS side, as Sakari suggested: either only make
the mode unavailable when the sensor is behind CVS (for example the
CVS driver restricting the sizes a sensor may use), or program the
sHDR variant of 1928x1088 for that case, which I cannot do without
documentation of the sensor's sHDR setup. Until one of these exists,
2/2 is a fine workaround for the affected machines.

I can test patches or run experiments on this machine, for example
logging the ISYS CSI-2 frame/line counts with dyndbg, or trying a
larger minimum size from the CVS driver. I can also send the lsusb
output if useful.

Regards,
Edvinas Šulcas