wiki: tidyup GMSL_xxx page

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

2 files changed, 23 insertions, 17 deletions

diff --git a/wiki/GMSL_Cameras_Open_Issues_and_testing.wiki b/wiki/GMSL_Cameras_Open_Issues_and_testing.wiki
index d884072..ad17ec7 100644
--- a/wiki/GMSL_Cameras_Open_Issues_and_testing.wiki
+++ b/wiki/GMSL_Cameras_Open_Issues_and_testing.wiki
@@ -23,7 +23,8 @@ 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*
+h3. patch
+
 http://jmondi.org/owncloud/index.php/s/RG0rq870YEHOtAy
 
 3)
@@ -33,7 +34,8 @@ 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*
+h3. patch
+
 http://jmondi.org/owncloud/index.php/s/Fj56fNUWsFPlhBi
 
 h2. Horizontal and vertical sync configuration
@@ -96,7 +98,7 @@ Register used to monitor MAX9286 operations
 | 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*
+h3. Testing
 
 Printout of values while waiting for FSYNC locking.
 Configuration:
@@ -120,7 +122,8 @@ Configuration:
 [   48.861158] master vsync per - 2d 07 50
 </pre>
 
-*Patch*
+h3. Patch
+
 http://jmondi.org/owncloud/index.php/s/OLz8Ah7ZZH6X1t0
 
 h2. Frame combination isn't fully understood
diff --git a/wiki/GMSL_Configuration.wiki b/wiki/GMSL_Configuration.wiki
index f9f3426..d0f2b4b 100644
--- a/wiki/GMSL_Configuration.wiki
+++ b/wiki/GMSL_Configuration.wiki
@@ -6,7 +6,7 @@ Their configurations and operating modes are below summarized, along with some p
 
 h2. OV10635
 
-*Relevant Pins and Configuration Parameters*
+h3. Relevant Pins and Configuration Parameters
 
 |_. PIN |_. Function|
 |FSIN | frame sync input|
@@ -15,7 +15,7 @@ h2. OV10635
 |D [9:0]| data pins|
 |SIOD-SIOC | SCCB interface|
 
-*VSYNC/HREF Polarities*
+h3. VSYNC/HREF Polarities
 
 Register 0x4708 = 0x00
 
@@ -28,12 +28,12 @@ _The sensor datasheet does not report what bit value corresponds to what; Applic
 As default value of 0x4708 register is 0x01, we may assume what is reported in timing diagrams in the sensor manual is respected with inverted pixel clock edge (rising instead of default falling).
 As the serializer is configured to latch data on the falling PCLK edge, this seems correct, as timing diagram of serializer operations show data are latched on the edge opposite to the one where pixel are emitted by the sensor)
 
-*Format configuration*
+h3. Format configuration
 
 0x4300 = 0x3a = UYVY components ordering
 0x4605 = 0x08 = 8-bit YUV422 mode
 
-*Timing diagram*
+h3. Timing diagram
 
 !GMSL_Configuration/ov10635_timings.png!
 
@@ -44,7 +44,7 @@ VSYNC pulses at beginning of a new sensor scanout and stays low during the whole
 
 h2. MAX9271 Serializer
 
-*Relevant Pin and Configuration Parameters*
+h3. Relevant Pin and Configuration Parameters
 
 _LCCEN_: Enable/disable local control channel pins
          When LCCEN pin is high the serializer operating parameters are configured through register 0x07. Alternatively if LCCEN is    low, pin 14/15/22 and 23 values are used to configure the serializer
@@ -65,7 +65,8 @@ _EDC_: Error correction enable/disable
 
 _ES_: Specifies if data are latched on rising/falling PCLK edge. 1 = falling edge; 0 = rising edge
 
-*RDACM20 Configuration*
+h3. RDACM20 Configuration
+
 |_. Parameter |_. Value|
 |DBL | 1|
 |BWS | 0|
@@ -85,7 +86,7 @@ The 24 bit encoded on the GMSL serial link are:
 
 *Note* see Table 2 (input map) because it reports HS and VS signals in DIN-A and DIN-B but they're not part of the data sent on serial link.
 
-*Serial link data output*
+h3. Serial link data output
 !GMSL_Configuration/IMG_20170822_214808.jpg!
 
 From the serializer manual, same image
@@ -133,7 +134,7 @@ The above quote from the serializer manual may be interpreted simply as the conf
 
 It is legit to assume the encoded HS/VS signals are sent recording transactions of falling and rising edges
 
-*Synchronism signal timings*
+h3. Synchronism signal timings
 To be verified in image sensor configuration if the following constraints are respected
 
 With DBL=1:
@@ -143,15 +144,16 @@ With DBL=1:
 
 h2. MAX9286 De-Serializer
 
-*De-serializer Configuration Parameters*
+h3. De-serializer Configuration Parameters
+
+h3. general configuration
 
-*general configuration*
 Register 0x12
 |DBL | 1|
 |EDC | 0|
 |BWS |0 (pull down to ground)|
 
-*FSYNC and VSYNC signal configuration*
+h3. FSYNC and VSYNC signal configuration
 
 The de-serializer run by default with inverted VSYNC
 Register 0x0c
@@ -185,7 +187,7 @@ The previously values determinate how frame synchronization is performed
 !GMSL_Configuration/fsync.png!
 
 
-*HS/VS location*/
+h3. HS/VS location
 
 HVSRC parameter description in register 0x0c (page 66) reports that the de-serializer expects HS/VS in bit 14:15
 
@@ -201,7 +203,8 @@ The following image describing the input map expected by deserializer for yuv8 f
 This seems pretty different from what the serializer sends on the serial link, as bit 0:21 are reserved for two 11bit pixel data word, and there is no mention of HS/VS encoding in bits 14:15 (or 16:17).
 So, HS/VS are either encoded in special packets with no pixel data (something like CSI-2 short packets) or their bits part of the data sent on the serial link along with pixel data (but in that case, it seems all the 24 bits used by the serializer are actually used by two pixel data word)
 
-*VSYNC inversion*
+h3. VSYNC inversion
+
 The deserializer is configured to run with inverted VSYNC output on CSI bus.
 See below what it can possibly mean (inversion of short packet vertical synchronization codes?)