diff options
author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /Documentation/video4linux/zr36120.txt |
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Diffstat (limited to 'Documentation/video4linux/zr36120.txt')
-rw-r--r-- | Documentation/video4linux/zr36120.txt | 159 |
1 files changed, 159 insertions, 0 deletions
diff --git a/Documentation/video4linux/zr36120.txt b/Documentation/video4linux/zr36120.txt new file mode 100644 index 000000000000..4af6c52595eb --- /dev/null +++ b/Documentation/video4linux/zr36120.txt | |||
@@ -0,0 +1,159 @@ | |||
1 | Driver for Trust Computer Products Framegrabber, version 0.6.1 | ||
2 | ------ --- ----- -------- -------- ------------ ------- - - - | ||
3 | |||
4 | - ZORAN ------------------------------------------------------ | ||
5 | Author: Pauline Middelink <middelin@polyware.nl> | ||
6 | Date: 18 September 1999 | ||
7 | Version: 0.6.1 | ||
8 | |||
9 | - Description ------------------------------------------------ | ||
10 | |||
11 | Video4Linux compatible driver for an unknown brand framegrabber | ||
12 | (Sold in the Netherlands by TRUST Computer Products) and various | ||
13 | other zoran zr36120 based framegrabbers. | ||
14 | |||
15 | The card contains a ZR36120 Multimedia PCI Interface and a Philips | ||
16 | SAA7110 Onechip Frontend videodecoder. There is also an DSP of | ||
17 | which I have forgotten the number, since i will never get that thing | ||
18 | to work without specs from the vendor itself. | ||
19 | |||
20 | The SAA711x are capable of processing 6 different video inputs, | ||
21 | CVBS1..6 and Y1+C1, Y2+C2, Y3+C3. All in 50/60Hz, NTSC, PAL or | ||
22 | SECAM and delivering a YUV datastream. On my card the input | ||
23 | 'CVBS-0' corresponds to channel CVBS2 and 'S-Video' to Y2+C2. | ||
24 | |||
25 | I have some reports of other cards working with the mentioned | ||
26 | chip sets. For a list of other working cards please have a look | ||
27 | at the cards named in the tvcards struct in the beginning of | ||
28 | zr36120.c | ||
29 | |||
30 | After some testing, I discovered that the carddesigner messed up | ||
31 | on the I2C interface. The Zoran chip includes 2 lines SDA and SCL | ||
32 | which (s)he connected reversely. So we have to clock on the SDA | ||
33 | and r/w data on the SCL pin. Life is fun... Each cardtype now has | ||
34 | a bit which signifies if you have a card with the same deficiency. | ||
35 | |||
36 | Oh, for the completeness of this story I must mention that my | ||
37 | card delivers the VSYNC pulse of the SAA chip to GIRQ1, not | ||
38 | GIRQ0 as some other cards have. This is also incorporated in | ||
39 | the driver be clearing/setting the 'useirq1' bit in the tvcard | ||
40 | description. | ||
41 | |||
42 | Another problems of continuous capturing data with a Zoran chip | ||
43 | is something nasty inside the chip. It effectively halves the | ||
44 | fps we ought to get... Here is the scenario: capturing frames | ||
45 | to memory is done in the so-called snapshot mode. In this mode | ||
46 | the Zoran stops after capturing a frame worth of data and wait | ||
47 | till the application set GRAB bit to indicate readiness for the | ||
48 | next frame. After detecting a set bit, the chip neatly waits | ||
49 | till the start of a frame, captures it and it goes back to off. | ||
50 | Smart ppl will notice the problem here. Its the waiting on the | ||
51 | _next_ frame each time we set the GRAB bit... Oh well, 12,5 fps | ||
52 | is still plenty fast for me. | ||
53 | -- update 28/7/1999 -- | ||
54 | Don't believe a word I just said... Proof is the output | ||
55 | of `streamer -t 300 -r 25 -f avi15 -o /dev/null` | ||
56 | ++--+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
57 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
58 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
59 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
60 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
61 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
62 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
63 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
64 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
65 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
66 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25 | ||
67 | +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- | ||
68 | syncer: done | ||
69 | writer: done | ||
70 | (note the /dev/null is prudent here, my system is not able to | ||
71 | grab /and/ write 25 fps to a file... gifts welcome :) ) | ||
72 | The technical reasoning follows: The zoran completed the last | ||
73 | frame, the VSYNC goes low, and GRAB is cleared. The interrupt | ||
74 | routine starts to work since its VSYNC driven, and again | ||
75 | activates the GRAB bit. A few ms later the VSYNC (re-)rises and | ||
76 | the zoran starts to work on a new and freshly broadcasted frame.... | ||
77 | |||
78 | For pointers I used the specs of both chips. Below are the URLs: | ||
79 | http://www.zoran.com/ftp/download/devices/pci/ZR36120/36120data.pdf | ||
80 | http://www-us.semiconductor.philips.com/acrobat/datasheets/SAA_7110_A_1.pdf | ||
81 | |||
82 | The documentation has very little on absolute numbers or timings | ||
83 | needed for the various modes/resolutions, but there are other | ||
84 | programs you can borrow those from. | ||
85 | |||
86 | ------ Install -------------------------------------------- | ||
87 | Read the file called TODO. Note its long list of limitations. | ||
88 | |||
89 | Build a kernel with VIDEO4LINUX enabled. Activate the | ||
90 | BT848 driver; we need this because we have need for the | ||
91 | other modules (i2c and videodev) it enables. | ||
92 | |||
93 | To install this software, extract it into a suitable directory. | ||
94 | Examine the makefile and change anything you don't like. Type "make". | ||
95 | |||
96 | After making the modules check if you have the much needed | ||
97 | /dev/video devices. If not, execute the following 4 lines: | ||
98 | mknod /dev/video c 81 0 | ||
99 | mknod /dev/video1 c 81 1 | ||
100 | mknod /dev/video2 c 81 2 | ||
101 | mknod /dev/video3 c 81 3 | ||
102 | mknod /dev/video4 c 81 4 | ||
103 | |||
104 | After making/checking the devices do: | ||
105 | modprobe i2c | ||
106 | modprobe videodev | ||
107 | modprobe saa7110 (optional) | ||
108 | modprobe saa7111 (optional) | ||
109 | modprobe tuner (optional) | ||
110 | insmod zoran cardtype=<n> | ||
111 | |||
112 | <n> is the cardtype of the card you have. The cardnumber can | ||
113 | be found in the source of zr36120. Look for tvcards. If your | ||
114 | card is not there, please try if any other card gives some | ||
115 | response, and mail me if you got a working tvcard addition. | ||
116 | |||
117 | PS. <TVCard editors behold!) | ||
118 | Dont forget to set video_input to the number of inputs | ||
119 | you defined in the video_mux part of the tvcard definition. | ||
120 | Its a common error to add a channel but not incrementing | ||
121 | video_input and getting angry with me/v4l/linux/linus :( | ||
122 | |||
123 | You are now ready to test the framegrabber with your favorite | ||
124 | video4linux compatible tool | ||
125 | |||
126 | ------ Application ---------------------------------------- | ||
127 | |||
128 | This device works with all Video4Linux compatible applications, | ||
129 | given the limitations in the TODO file. | ||
130 | |||
131 | ------ API ------------------------------------------------ | ||
132 | |||
133 | This uses the V4L interface as of kernel release 2.1.116, and in | ||
134 | fact has not been tested on any lower version. There are a couple | ||
135 | of minor differences due to the fact that the amount of data returned | ||
136 | with each frame varies, and no doubt there are discrepancies due to my | ||
137 | misunderstanding of the API. I intend to convert this driver to the | ||
138 | new V4L2 API when it has stabilized more. | ||
139 | |||
140 | ------ Current state -------------------------------------- | ||
141 | |||
142 | The driver is capable of overlaying a video image in screen, and | ||
143 | even capable of grabbing frames. It uses the BIGPHYSAREA patch | ||
144 | to allocate lots of large memory blocks when tis patch is | ||
145 | found in the kernel, but it doesn't need it. | ||
146 | The consequence is that, when loading the driver as a module, | ||
147 | the module may tell you it's out of memory, but 'free' says | ||
148 | otherwise. The reason is simple; the modules wants its memory | ||
149 | contiguous, not fragmented, and after a long uptime there | ||
150 | probably isn't a fragment of memory large enough... | ||
151 | |||
152 | The driver uses a double buffering scheme, which should really | ||
153 | be an n-way buffer, depending on the size of allocated framebuffer | ||
154 | and the requested grab-size/format. | ||
155 | This current version also fixes a dead-lock situation during irq | ||
156 | time, which really, really froze my system... :) | ||
157 | |||
158 | Good luck. | ||
159 | Pauline | ||