h1. GMSL Cameras Open Issues and testing

h2. Frame synchronization isn't fully understood

The MAX9286 deserializer requires input frames to be synchronized. Cameras does operate in external trigger mode, where a frame sync signal broadcasted by the MAX9286 over all enabled GMSL links is output by the MAX9271 serializers on their GPO pin to the camera sensor. The MAX9286 can be configured to generate the frame sync signal internally, or based on an external sync signal received on its GPI pin. The current code uses internal sync unconditionally. Previous experiments used external sync when enabling a single camera. As the SoC GPIO connected to the MAX9286 GPI pin is never toggled this shouldn't have worked, but for an unknown reason we could still capture valid frames. This has to be investigated and understood.

Understand how frame sync is emitted and which conditions prevent it from locking.

h3. Test

1)
Use manual frame sync with a frame period of 1905x840 pixels ( = 1905x840x2 PCLK pulses in YUYV8 format)
No locking, but monitoring calculated master link VSYNC period returns the exact number of expected PCLK pulses

<pre>
     master vsync period - 0x30d590 = 3200400 = 1905*840*2
</pre>

This at least confirms that FSYNC is successfully fed to camera sensors

2)
Play around with KVAL, PVAL and DIFF periods
Anticipating that the manual does not provide any information on what time constraints have to be respected to have a successful KVAL + PVAL hit (Figure 46, above reported), play around with configuration parameters.
DIFF can be disabled (to confirm what does it mean)

*patch*
http://jmondi.org/owncloud/index.php/s/RG0rq870YEHOtAy

3)
Change AUTO_MODE to SEMI_AUTO_MODE
Try to have VSYNC follow the master link, not slowest one

4) Try to use i2c broadcast address
To start all cameras at the same time

*patch*
http://jmondi.org/owncloud/index.php/s/Fj56fNUWsFPlhBi

h2. Horizontal and vertical sync configuration

The MAX9286 is configured to invert vertical sync, while the MAX9271 isn't. Check whether this is caused by the sensor using a vertical sync polarity opposite of what the MAX9286 expects. Furthermore, sync signals can be encoded in different GMSL bits, make sure the serializer and deserializer agree.

Possible answer: the INVSYNC option on de-serializer side, is used to invert vsync signal on CSI output (pag. 14 of MAX9286 programming guide)

<pre>
    INVVS Invert Vsync in CSI output
</pre>
     
1) Theory 1:
De-serialize outputs <fs> on VSYNC rising edge, <fe> on VSYCN falling edge.
This would result in an invalid <fs><fe><fs> sequence on CSI-2 bus and that would explain why vertical synchronism are inverted on CSI-2 bus output.

Figure 32 in de-serialize manual is below reported
!GMSL_Cameras_Open_Issues/vsync-csi-output.png!

and seems to contradict the hypothesis since a single short packet is emitted on VSYNC falling edge 

<pre>
Hypothesis 1: CSI short packets for frame start/end are inverted
                  _                                  _                   _
VSYNC    ________| |________________________________| |_______... ______| |_______________
                     ____    ____            ____
HREF     ___________|    |__|    |__  ... __|    |__ ...  
GMSL DATA   <VS1><VS0><HS1><pixel data> ... <pixel data><HS0><HS1><pixel data> ... <pixel data><HS0><VS1><VS0>
CSI          <fs> <fe> <ls-0> <pixel data> ... <pixel data> <le-0> ... <ls-n> <pixel data> ... <pixel data> <le-n> <fs> <fe>
INVSYCN
CSI          <fe> <fs> <ls-0> <pixel data> ... <pixel data> <le-0> ... <ls-n> <pixel data> ... <pixel data> <le-n> <fe> <fs>
</pre>

2) Theory 2
The OV10635 sensor is sending inverted VSYNC.
Try to change this setting bit 2 of register 0x4708

h3. Testing

The deserializer is configured to invert VSYNC. Frame capture from one camera, with this configuration works fine.

1. Remove VSYNC inversion in max9286 -> green frames
2. Invert VSYNC polarity on OV10635 side ( 0x4708 = 0x02 ) and remove VSYNC inversion on max9286 -> good frames

This seems to confirm, OV10635 is configured to use active low VSYNC signal polarity

h2. Lock and synchronization monitoring

The MAX9286 provides status registers to monitor locking and synchronization. We need to make use of them for instrumentation purpose, in order to better understand the MAX9286 operation and detect error conditions. This includes the control link, serial link and video synchronization.

Register used to monitor MAX9286 operations

|_. Register Name |_. Register Address |_. Bits |_. Comment|
| Video Links Detected | 0x49 | D3:D0 | |
| Links Locked | 0x27 | D7 | All video links are locked |
| VSYNC Detected | 0x27 | D3:D0 | VSYNC detected on link 3:0 in the last 100ms (0ed when read) |
| Frame Diff | 0x31 0x30 | D5:D0  - D7:D0 | Difference in master PCLK cycles between fastest and slowest link |
| Master Link | 0x71 | D5:D4 | ID of link selected as master |
| FSYNC Error Counter | 0x5e | D7:D0 | Frame sync error counter (reset to zero when read)|
| Master VSYNC period | 0x5d 0x5c 0x5b | D7:D0 | Calculated VSYNC period of master link in PCLK cycles |
| FSYNC Locked | 0x31 | D6 | Frame sync locked |

*Testing*

Printout of values while waiting for FSYNC locking.
Configuration:
# Link 0 and 1 enabled
# AUTO FSYNC mode
# 

<pre>
[   48.760818] vsync detected 0x27[3:0] = b3
[   48.764843] fsync locked 0x31[6] = 00
[   48.768515] framediff 0x31[5:0] 0x30 = 3f fe
[   48.772791] master link 0x71[5:4] = 00
[   48.776547] fsync err 0x52[7:0]= 01
[   48.780042] master vsync per - 2d 07 50
[   48.783884] <-------- usleep_range(2000, 50000);
[   48.841958] vsync detected 0x27[3:0] = b3
[   48.845974] fsync locked 0x31[6] = 00
[   48.849634] framediff 0x31[5:0] 0x30 = 3f fe
[   48.853916] master link 0x71[5:4] = 00
[   48.857672] fsync err 0x52[7:0]= 06
[   48.861158] master vsync per - 2d 07 50
</pre>

*Patch*
http://jmondi.org/owncloud/index.php/s/OLz8Ah7ZZH6X1t0

h2. Frame combination isn't fully understood

According to page 26 of the MAX9286 datasheet, the deserializes combines all input video streams into a single (4 x W) x H or W x (4 x H) frame. How to select which combination mode to use isn't specified in the datasheet, neither is it explained how CSI-2 virtual channels are used. Previous experiments to capture a (4 x W) x H frame failed, with the VIN never signalling frame completion. More experiments are needed to understand how frame combination operates.

h2. Errors in the MAX9271 datasheet

The MAX9271 datasheet contradicts some of the tests we have performed, which could indicate errors in the datasheet.

* Register 0x15 - PCLKDET

 The bit seems to be inverted, we read PCLKDET = 1 when a pixel clock is present.