pxa_camera.rst 8.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193
  1. PXA-Camera Host Driver
  2. ======================
  3. Author: Robert Jarzmik <robert.jarzmik@free.fr>
  4. Constraints
  5. -----------
  6. a) Image size for YUV422P format
  7. All YUV422P images are enforced to have width x height % 16 = 0.
  8. This is due to DMA constraints, which transfers only planes of 8 byte
  9. multiples.
  10. Global video workflow
  11. ---------------------
  12. a) QCI stopped
  13. Initialy, the QCI interface is stopped.
  14. When a buffer is queued (pxa_videobuf_ops->buf_queue), the QCI starts.
  15. b) QCI started
  16. More buffers can be queued while the QCI is started without halting the
  17. capture. The new buffers are "appended" at the tail of the DMA chain, and
  18. smoothly captured one frame after the other.
  19. Once a buffer is filled in the QCI interface, it is marked as "DONE" and
  20. removed from the active buffers list. It can be then requeud or dequeued by
  21. userland application.
  22. Once the last buffer is filled in, the QCI interface stops.
  23. c) Capture global finite state machine schema
  24. .. code-block:: none
  25. +----+ +---+ +----+
  26. | DQ | | Q | | DQ |
  27. | v | v | v
  28. +-----------+ +------------------------+
  29. | STOP | | Wait for capture start |
  30. +-----------+ Q +------------------------+
  31. +-> | QCI: stop | ------------------> | QCI: run | <------------+
  32. | | DMA: stop | | DMA: stop | |
  33. | +-----------+ +-----> +------------------------+ |
  34. | / | |
  35. | / +---+ +----+ | |
  36. |capture list empty / | Q | | DQ | | QCI Irq EOF |
  37. | / | v | v v |
  38. | +--------------------+ +----------------------+ |
  39. | | DMA hotlink missed | | Capture running | |
  40. | +--------------------+ +----------------------+ |
  41. | | QCI: run | +-----> | QCI: run | <-+ |
  42. | | DMA: stop | / | DMA: run | | |
  43. | +--------------------+ / +----------------------+ | Other |
  44. | ^ /DMA still | | channels |
  45. | | capture list / running | DMA Irq End | not |
  46. | | not empty / | | finished |
  47. | | / v | yet |
  48. | +----------------------+ +----------------------+ | |
  49. | | Videobuf released | | Channel completed | | |
  50. | +----------------------+ +----------------------+ | |
  51. +-- | QCI: run | | QCI: run | --+ |
  52. | DMA: run | | DMA: run | |
  53. +----------------------+ +----------------------+ |
  54. ^ / | |
  55. | no overrun / | overrun |
  56. | / v |
  57. +--------------------+ / +----------------------+ |
  58. | Frame completed | / | Frame overran | |
  59. +--------------------+ <-----+ +----------------------+ restart frame |
  60. | QCI: run | | QCI: stop | --------------+
  61. | DMA: run | | DMA: stop |
  62. +--------------------+ +----------------------+
  63. Legend: - each box is a FSM state
  64. - each arrow is the condition to transition to another state
  65. - an arrow with a comment is a mandatory transition (no condition)
  66. - arrow "Q" means : a buffer was enqueued
  67. - arrow "DQ" means : a buffer was dequeued
  68. - "QCI: stop" means the QCI interface is not enabled
  69. - "DMA: stop" means all 3 DMA channels are stopped
  70. - "DMA: run" means at least 1 DMA channel is still running
  71. DMA usage
  72. ---------
  73. a) DMA flow
  74. - first buffer queued for capture
  75. Once a first buffer is queued for capture, the QCI is started, but data
  76. transfer is not started. On "End Of Frame" interrupt, the irq handler
  77. starts the DMA chain.
  78. - capture of one videobuffer
  79. The DMA chain starts transferring data into videobuffer RAM pages.
  80. When all pages are transferred, the DMA irq is raised on "ENDINTR" status
  81. - finishing one videobuffer
  82. The DMA irq handler marks the videobuffer as "done", and removes it from
  83. the active running queue
  84. Meanwhile, the next videobuffer (if there is one), is transferred by DMA
  85. - finishing the last videobuffer
  86. On the DMA irq of the last videobuffer, the QCI is stopped.
  87. b) DMA prepared buffer will have this structure
  88. .. code-block:: none
  89. +------------+-----+---------------+-----------------+
  90. | desc-sg[0] | ... | desc-sg[last] | finisher/linker |
  91. +------------+-----+---------------+-----------------+
  92. This structure is pointed by dma->sg_cpu.
  93. The descriptors are used as follows:
  94. - desc-sg[i]: i-th descriptor, transferring the i-th sg
  95. element to the video buffer scatter gather
  96. - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
  97. - linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0
  98. For the next schema, let's assume d0=desc-sg[0] .. dN=desc-sg[N],
  99. "f" stands for finisher and "l" for linker.
  100. A typical running chain is :
  101. .. code-block:: none
  102. Videobuffer 1 Videobuffer 2
  103. +---------+----+---+ +----+----+----+---+
  104. | d0 | .. | dN | l | | d0 | .. | dN | f |
  105. +---------+----+-|-+ ^----+----+----+---+
  106. | |
  107. +----+
  108. After the chaining is finished, the chain looks like :
  109. .. code-block:: none
  110. Videobuffer 1 Videobuffer 2 Videobuffer 3
  111. +---------+----+---+ +----+----+----+---+ +----+----+----+---+
  112. | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
  113. +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
  114. | | | |
  115. +----+ +----+
  116. new_link
  117. c) DMA hot chaining timeslice issue
  118. As DMA chaining is done while DMA _is_ running, the linking may be done
  119. while the DMA jumps from one Videobuffer to another. On the schema, that
  120. would be a problem if the following sequence is encountered :
  121. - DMA chain is Videobuffer1 + Videobuffer2
  122. - pxa_videobuf_queue() is called to queue Videobuffer3
  123. - DMA controller finishes Videobuffer2, and DMA stops
  124. .. code-block:: none
  125. =>
  126. Videobuffer 1 Videobuffer 2
  127. +---------+----+---+ +----+----+----+---+
  128. | d0 | .. | dN | l | | d0 | .. | dN | f |
  129. +---------+----+-|-+ ^----+----+----+-^-+
  130. | | |
  131. +----+ +-- DMA DDADR loads DDADR_STOP
  132. - pxa_dma_add_tail_buf() is called, the Videobuffer2 "finisher" is
  133. replaced by a "linker" to Videobuffer3 (creation of new_link)
  134. - pxa_videobuf_queue() finishes
  135. - the DMA irq handler is called, which terminates Videobuffer2
  136. - Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!)
  137. .. code-block:: none
  138. Videobuffer 1 Videobuffer 2 Videobuffer 3
  139. +---------+----+---+ +----+----+----+---+ +----+----+----+---+
  140. | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
  141. +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
  142. | | | |
  143. +----+ +----+
  144. new_link
  145. DMA DDADR still is DDADR_STOP
  146. - pxa_camera_check_link_miss() is called
  147. This checks if the DMA is finished and a buffer is still on the
  148. pcdev->capture list. If that's the case, the capture will be restarted,
  149. and Videobuffer3 is scheduled on DMA chain.
  150. - the DMA irq handler finishes
  151. .. note::
  152. If DMA stops just after pxa_camera_check_link_miss() reads DDADR()
  153. value, we have the guarantee that the DMA irq handler will be called back
  154. when the DMA will finish the buffer, and pxa_camera_check_link_miss() will
  155. be called again, to reschedule Videobuffer3.