Re: [PATCH RFC 2/2] media: i2c: imx681: Add C-PHY support

[George Neacsu]

Hi Bryan,

The values come from two places on this machine: the Windows sensor
file, and a kernel debugger attached to Windows while it streamed. They
were then checked against the CCS definitions and on Linux. In detail:

1. The Windows sensor file. The Windows install on this Surface Pro 11
   has a Qualcomm sensor module file for the IMX681 (SONY0681). A script
   here parses its register tables: an init table of 364 writes and six
   per-mode tables of 68 writes. Nothing from the file is
   redistributed; only register values are used.

2. Windows observed live. With a second machine as kernel debugger, I
   set a breakpoint in the Windows front sensor driver just before it
   applies the mode table, started the stock Windows Camera app, and
   dumped the 68 writes it sent. They match the file's 3840x2160 30 fps
   mode exactly. That live table includes

     0x0114 = 0x00 (CSI_LANE_MODE),
     0x0306/0x0307 = 225, 0x030d = 3, 0x030e/0x030f = 375,
     line length 6752, frame length 3554.

   In separate debugger sessions I read the CSIPHY2 registers while
   Windows streamed. The receiver was in C-PHY mode, and its settings
   match Qualcomm's GPL 2.5 Gsps C-PHY table (121 registers, compared
   from two snapshots).

   CSI_SIGNALING_MODE = 0x03 is in the init table. I have it from the
   file, but I did not catch Windows writing it live.

3. Why 0x03 means C-PHY. 0x0111 is CSI_SIGNALING_MODE and 0x0114
   CSI_LANE_MODE in the MIPI CCS register map, as in
   drivers/media/i2c/ccs/ccs-regs.h: 2 is CSI-2 D-PHY, 3 is CSI-2 C-PHY
   (0 and 1 are the old CCP2 modes), and the lane mode is the lane or
   trio count minus one. This agrees with the hardware: Sergey reads
   back 0x02 and 0x01 on the Intel model while streaming two D-PHY
   lanes; the Windows receiver here runs C-PHY on one trio; and under
   Linux, with 0x03 and 0x00, the sensor streams into the PHY in C-PHY
   mode.

4. The 2.4 Gsym/s is calculated, not measured: 19.2 MHz / 3 * 375 from
   the OP PLL values Windows writes. The receiver does not report the
   rate, and it locks over a wide range of settle counts, so a working
   capture does not prove the exact value. It does fall in the 2.5 Gsps
   bin that Windows programs into the receiver. Likewise,
   6752 * 3554 * 30 = 719.9 MHz matches v8's pixel rate, and the pixel
   PLL (225) is the one v8 already writes.

In the next version the commit message will say which values come from
the live Windows capture, which come only from the sensor file, which
are calculated, and what was checked on Linux. The extraction and
capture process will also be written up in the project repository and
linked. I will also read the CCS capability register 0x1602 (bit 3 =
C-PHY) here, and Sergey may be able to read it on the Intel model.

Thanks,
George