[media] doc-rst: add pxa_camera documentation

Convert pxa_camera to ReST format and add it to the
media/v4l-drivers book.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

Documentation/media/v4l-drivers/index.rst

@@ -31,4 +31,5 @@ License".
 	omap3isp
 	omap4_camera
 	pvrusb2
+	pxa_camera
 	zr364xx

Documentation/media/v4l-drivers/pxa_camera.rst

@@ -1,8 +1,11 @@
 PXA-Camera Host Driver
 ======================
 
+Author: Robert Jarzmik <robert.jarzmik@free.fr>
+
 Constraints
 -----------
+
 a) Image size for YUV422P format
    All YUV422P images are enforced to have width x height % 16 = 0.
    This is due to DMA constraints, which transfers only planes of 8 byte
@@ -11,6 +14,7 @@ Constraints
 
 Global video workflow
 ---------------------
+
 a) QCI stopped
    Initialy, the QCI interface is stopped.
    When a buffer is queued (pxa_videobuf_ops->buf_queue), the QCI starts.
@@ -28,6 +32,8 @@ Global video workflow
 
 c) Capture global finite state machine schema
 
+.. code-block:: none
+
 	+----+                             +---+  +----+
 	| DQ |                             | Q |  | DQ |
 	|    v                             |   v  |    v
@@ -78,6 +84,7 @@ Global video workflow
 
 DMA usage
 ---------
+
 a) DMA flow
      - first buffer queued for capture
        Once a first buffer is queued for capture, the QCI is started, but data
@@ -95,12 +102,15 @@ DMA usage
 
 b) DMA prepared buffer will have this structure
 
+.. code-block:: none
+
      +------------+-----+---------------+-----------------+
      | desc-sg[0] | ... | desc-sg[last] | finisher/linker |
      +------------+-----+---------------+-----------------+
 
 This structure is pointed by dma->sg_cpu.
 The descriptors are used as follows:
+
 - desc-sg[i]: i-th descriptor, transferring the i-th sg
   element to the video buffer scatter gather
 - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
@@ -110,6 +120,8 @@ DMA usage
 "f" stands for finisher and "l" for linker.
 A typical running chain is :
 
+.. code-block:: none
+
          Videobuffer 1         Videobuffer 2
      +---------+----+---+  +----+----+----+---+
      | d0 | .. | dN | l |  | d0 | .. | dN | f |
@@ -119,6 +131,8 @@ DMA usage
 
 After the chaining is finished, the chain looks like :
 
+.. code-block:: none
+
          Videobuffer 1         Videobuffer 2         Videobuffer 3
      +---------+----+---+  +----+----+----+---+  +----+----+----+---+
      | d0 | .. | dN | l |  | d0 | .. | dN | l |  | d0 | .. | dN | f |
@@ -136,6 +150,9 @@ DMA usage
 - DMA chain is Videobuffer1 + Videobuffer2
 - pxa_videobuf_queue() is called to queue Videobuffer3
 - DMA controller finishes Videobuffer2, and DMA stops
+
+.. code-block:: none
+
       =>
          Videobuffer 1         Videobuffer 2
      +---------+----+---+  +----+----+----+---+
@@ -150,6 +167,8 @@ DMA usage
 - the DMA irq handler is called, which terminates Videobuffer2
 - Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!)
 
+.. code-block:: none
+
          Videobuffer 1         Videobuffer 2         Videobuffer 3
      +---------+----+---+  +----+----+----+---+  +----+----+----+---+
      | d0 | .. | dN | l |  | d0 | .. | dN | l |  | d0 | .. | dN | f |
@@ -165,10 +184,9 @@ DMA usage
   and Videobuffer3 is scheduled on DMA chain.
 - the DMA irq handler finishes
 
-     Note: if DMA stops just after pxa_camera_check_link_miss() reads DDADR()
+.. note::
+
+     If DMA stops just after pxa_camera_check_link_miss() reads DDADR()
      value, we have the guarantee that the DMA irq handler will be called back
      when the DMA will finish the buffer, and pxa_camera_check_link_miss() will
      be called again, to reschedule Videobuffer3.
-
---
-Author: Robert Jarzmik <robert.jarzmik@free.fr>