diff options
author | Robert Jarzmik <robert.jarzmik@free.fr> | 2009-03-31 02:44:21 -0400 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@redhat.com> | 2009-04-06 20:43:45 -0400 |
commit | 256b02332a0ba1d7382d736d776e605be63ded17 (patch) | |
tree | 10f661d4bd82e23272379ecdd6acd5ed4a23ef98 /Documentation/video4linux | |
parent | 37f5aefd537d5f98b3fa9726362effeccf1d2161 (diff) |
V4L/DVB (11321): pxa_camera: Redesign DMA handling
The DMA transfers in pxa_camera showed some weaknesses in
multiple queued buffers context :
- poll/select problem
The bug shows up with capture_example tool from v4l2 hg
tree. The process just "stalls" on a "select timeout".
- multiple buffers DMA starting
When multiple buffers were queued, the DMA channels were
always started right away. This is not optimal, as a
special case appears when the first EOF was not yet
reached, and the DMA channels were prematurely started.
- Maintainability
DMA code was a bit obfuscated. Rationalize the code to be
easily maintainable by anyone.
- DMA hot chaining
DMA is not stopped anymore to queue a buffer, the buffer
is queued with DMA running. As a tribute, a corner case
exists where chaining happens while DMA finishes the
chain, and the capture is restarted to deal with the
missed link buffer.
This patch attemps to address these issues / improvements.
create mode 100644 Documentation/video4linux/pxa_camera.txt
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'Documentation/video4linux')
-rw-r--r-- | Documentation/video4linux/pxa_camera.txt | 125 |
1 files changed, 125 insertions, 0 deletions
diff --git a/Documentation/video4linux/pxa_camera.txt b/Documentation/video4linux/pxa_camera.txt new file mode 100644 index 00000000000..b1137f9a53e --- /dev/null +++ b/Documentation/video4linux/pxa_camera.txt | |||
@@ -0,0 +1,125 @@ | |||
1 | PXA-Camera Host Driver | ||
2 | ====================== | ||
3 | |||
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 | |||
11 | |||
12 | Global video workflow | ||
13 | --------------------- | ||
14 | a) QCI stopped | ||
15 | Initialy, the QCI interface is stopped. | ||
16 | When a buffer is queued (pxa_videobuf_ops->buf_queue), the QCI starts. | ||
17 | |||
18 | b) QCI started | ||
19 | More buffers can be queued while the QCI is started without halting the | ||
20 | capture. The new buffers are "appended" at the tail of the DMA chain, and | ||
21 | smoothly captured one frame after the other. | ||
22 | |||
23 | Once a buffer is filled in the QCI interface, it is marked as "DONE" and | ||
24 | removed from the active buffers list. It can be then requeud or dequeued by | ||
25 | userland application. | ||
26 | |||
27 | Once the last buffer is filled in, the QCI interface stops. | ||
28 | |||
29 | |||
30 | DMA usage | ||
31 | --------- | ||
32 | a) DMA flow | ||
33 | - first buffer queued for capture | ||
34 | Once a first buffer is queued for capture, the QCI is started, but data | ||
35 | transfer is not started. On "End Of Frame" interrupt, the irq handler | ||
36 | starts the DMA chain. | ||
37 | - capture of one videobuffer | ||
38 | The DMA chain starts transfering data into videobuffer RAM pages. | ||
39 | When all pages are transfered, the DMA irq is raised on "ENDINTR" status | ||
40 | - finishing one videobuffer | ||
41 | The DMA irq handler marks the videobuffer as "done", and removes it from | ||
42 | the active running queue | ||
43 | Meanwhile, the next videobuffer (if there is one), is transfered by DMA | ||
44 | - finishing the last videobuffer | ||
45 | On the DMA irq of the last videobuffer, the QCI is stopped. | ||
46 | |||
47 | b) DMA prepared buffer will have this structure | ||
48 | |||
49 | +------------+-----+---------------+-----------------+ | ||
50 | | desc-sg[0] | ... | desc-sg[last] | finisher/linker | | ||
51 | +------------+-----+---------------+-----------------+ | ||
52 | |||
53 | This structure is pointed by dma->sg_cpu. | ||
54 | The descriptors are used as follows : | ||
55 | - desc-sg[i]: i-th descriptor, transfering the i-th sg | ||
56 | element to the video buffer scatter gather | ||
57 | - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN | ||
58 | - linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0 | ||
59 | |||
60 | For the next schema, let's assume d0=desc-sg[0] .. dN=desc-sg[N], | ||
61 | "f" stands for finisher and "l" for linker. | ||
62 | A typical running chain is : | ||
63 | |||
64 | Videobuffer 1 Videobuffer 2 | ||
65 | +---------+----+---+ +----+----+----+---+ | ||
66 | | d0 | .. | dN | l | | d0 | .. | dN | f | | ||
67 | +---------+----+-|-+ ^----+----+----+---+ | ||
68 | | | | ||
69 | +----+ | ||
70 | |||
71 | After the chaining is finished, the chain looks like : | ||
72 | |||
73 | Videobuffer 1 Videobuffer 2 Videobuffer 3 | ||
74 | +---------+----+---+ +----+----+----+---+ +----+----+----+---+ | ||
75 | | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f | | ||
76 | +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+ | ||
77 | | | | | | ||
78 | +----+ +----+ | ||
79 | new_link | ||
80 | |||
81 | c) DMA hot chaining timeslice issue | ||
82 | |||
83 | As DMA chaining is done while DMA _is_ running, the linking may be done | ||
84 | while the DMA jumps from one Videobuffer to another. On the schema, that | ||
85 | would be a problem if the following sequence is encountered : | ||
86 | |||
87 | - DMA chain is Videobuffer1 + Videobuffer2 | ||
88 | - pxa_videobuf_queue() is called to queue Videobuffer3 | ||
89 | - DMA controller finishes Videobuffer2, and DMA stops | ||
90 | => | ||
91 | Videobuffer 1 Videobuffer 2 | ||
92 | +---------+----+---+ +----+----+----+---+ | ||
93 | | d0 | .. | dN | l | | d0 | .. | dN | f | | ||
94 | +---------+----+-|-+ ^----+----+----+-^-+ | ||
95 | | | | | ||
96 | +----+ +-- DMA DDADR loads DDADR_STOP | ||
97 | |||
98 | - pxa_dma_add_tail_buf() is called, the Videobuffer2 "finisher" is | ||
99 | replaced by a "linker" to Videobuffer3 (creation of new_link) | ||
100 | - pxa_videobuf_queue() finishes | ||
101 | - the DMA irq handler is called, which terminates Videobuffer2 | ||
102 | - Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!) | ||
103 | |||
104 | Videobuffer 1 Videobuffer 2 Videobuffer 3 | ||
105 | +---------+----+---+ +----+----+----+---+ +----+----+----+---+ | ||
106 | | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f | | ||
107 | +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+ | ||
108 | | | | | | ||
109 | +----+ +----+ | ||
110 | new_link | ||
111 | DMA DDADR still is DDADR_STOP | ||
112 | |||
113 | - pxa_camera_check_link_miss() is called | ||
114 | This checks if the DMA is finished and a buffer is still on the | ||
115 | pcdev->capture list. If that's the case, the capture will be restarted, | ||
116 | and Videobuffer3 is scheduled on DMA chain. | ||
117 | - the DMA irq handler finishes | ||
118 | |||
119 | Note: if DMA stops just after pxa_camera_check_link_miss() reads DDADR() | ||
120 | value, we have the guarantee that the DMA irq handler will be called back | ||
121 | when the DMA will finish the buffer, and pxa_camera_check_link_miss() will | ||
122 | be called again, to reschedule Videobuffer3. | ||
123 | |||
124 | -- | ||
125 | Author: Robert Jarzmik <robert.jarzmik@free.fr> | ||