Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb

   - ves1x93		: Alps BSRV2 (ves1893 demodulator) and dbox2 (ves1993)

   - cx24110		: Conexant HM1221/HM1811 (cx24110 or cx24106 demod, cx24108 PLL)

   - grundig_29504-491	: Grundig 29504-491 (Philips TDA8083 demodulator), tsa5522 PLL

   - mt312		: Zarlink mt312 or Mitel vp310 demodulator, sl1935 or tsa5059 PLL

   - mt312		: Zarlink mt312 or Mitel vp310 demodulator, sl1935 or tsa5059 PLLi, Technisat Sky2Pc with bios Rev. 2.3

   - stv0299		: Alps BSRU6 (tsa5059 PLL), LG TDQB-S00x (tsa5059 PLL),

			  LG TDQF-S001F (sl1935 PLL), Philips SU1278 (tua6100 PLL),

			  Philips SU1278SH (tsa5059 PLL), Samsung TBMU24112IMB

			  Philips SU1278SH (tsa5059 PLL), Samsung TBMU24112IMB, Technisat Sky2Pc with bios Rev. 2.6

  DVB-C:

   - ves1820		: various (ves1820 demodulator, sp5659c or spXXXX PLL)

   - at76c651		: Atmel AT76c651(B) with DAT7021 PLL

 42 -> digitalnow DNTV Live! DVB-T Pro                     [1822:0025,1822:0019]

 43 -> KWorld/VStream XPert DVB-T with cx22702             [17de:08a1,12ab:2300]

 44 -> DViCO FusionHDTV DVB-T Dual Digital                 [18ac:db50,18ac:db54]

 45 -> KWorld HardwareMpegTV XPert                         [17de:0840]

 45 -> KWorld HardwareMpegTV XPert                         [17de:0840,1421:0305]

 46 -> DViCO FusionHDTV DVB-T Hybrid                       [18ac:db40,18ac:db44]

 47 -> pcHDTV HD5500 HDTV                                  [7063:5500]

 48 -> Kworld MCE 200 Deluxe                               [17de:0841]

 75 -> AVerMedia AVerTVHD MCE A180              [1461:1044]

 76 -> SKNet MonsterTV Mobile                   [1131:4ee9]

 77 -> Pinnacle PCTV 40i/50i/110i (saa7133)     [11bd:002e]

 78 -> ASUSTeK P7131 Dual                       [1043:4862]

 78 -> ASUSTeK P7131 Dual                       [1043:4862,1043:4876]

 79 -> Sedna/MuchTV PC TV Cardbus TV/Radio (ITO25 Rev:2B)

 80 -> ASUS Digimatrix TV                       [1043:0210]

 81 -> Philips Tiger reference design           [1131:2018]

 98 -> Proteus Pro 2309                         [0919:2003]

 99 -> AVerMedia TV Hybrid A16AR                [1461:2c00]

100 -> Asus Europa2 OEM                         [1043:4860]

101 -> Pinnacle PCTV 310i                       [11bd:002f]

102 -> Avermedia AVerTV Studio 507              [1461:9715]

103 -> Compro Videomate DVB-T200A

104 -> Hauppauge WinTV-HVR1110 DVB-T/Hybrid     [0070:6701]

105 -> Terratec Cinergy HT PCMCIA               [153b:1172]

"cafe_ccic" is a driver for the Marvell 88ALP01 "cafe" CMOS camera

controller.  This is the controller found in first-generation OLPC systems,

and this driver was written with support from the OLPC project.

Current status: the core driver works.  It can generate data in YUV422,

RGB565, and RGB444 formats.  (Anybody looking at the code will see RGB32 as

well, but that is a debugging aid which will be removed shortly).  VGA and

QVGA modes work; CIF is there but the colors remain funky.  Only the OV7670

sensor is known to work with this controller at this time.

To try it out: either of these commands will work:

     mplayer tv:// -tv driver=v4l2:width=640:height=480 -nosound

     mplayer tv:// -tv driver=v4l2:width=640:height=480:outfmt=bgr16 -nosound

The "xawtv" utility also works; gqcam does not, for unknown reasons.

There are a few load-time options, most of which can be changed after

loading via sysfs as well:

 - alloc_bufs_at_load:  Normally, the driver will not allocate any DMA

   buffers until the time comes to transfer data.  If this option is set,

   then worst-case-sized buffers will be allocated at module load time.

   This option nails down the memory for the life of the module, but

   perhaps decreases the chances of an allocation failure later on.

 - dma_buf_size: The size of DMA buffers to allocate.  Note that this

   option is only consulted for load-time allocation; when buffers are

   allocated at run time, they will be sized appropriately for the current

   camera settings.

 - n_dma_bufs: The controller can cycle through either two or three DMA

   buffers.  Normally, the driver tries to use three buffers; on faster

   systems, however, it will work well with only two.

 - min_buffers: The minimum number of streaming I/O buffers that the driver

   will consent to work with.  Default is one, but, on slower systems,

   better behavior with mplayer can be achieved by setting to a higher

   value (like six).

 - max_buffers: The maximum number of streaming I/O buffers; default is

   ten.  That number was carefully picked out of a hat and should not be

   assumed to actually mean much of anything.

 - flip: If this boolean parameter is set, the sensor will be instructed to

   invert the video image.  Whether it makes sense is determined by how

   your particular camera is mounted.

Work is ongoing with this driver, stay tuned.

jon

Jonathan Corbet

corbet@lwn.net

Driver for Trust Computer Products Framegrabber, version 0.6.1

------ --- ----- -------- -------- ------------  ------- - - -

- ZORAN ------------------------------------------------------

 Author: Pauline Middelink <middelin@polyware.nl>

   Date: 18 September 1999

Version: 0.6.1

- Description ------------------------------------------------

Video4Linux compatible driver for an unknown brand framegrabber

(Sold in the Netherlands by TRUST Computer Products) and various

other zoran zr36120 based framegrabbers.

The card contains a ZR36120 Multimedia PCI Interface and a Philips

SAA7110 Onechip Frontend videodecoder. There is also an DSP of

which I have forgotten the number, since i will never get that thing

to work without specs from the vendor itself.

The SAA711x are capable of processing 6 different video inputs,

CVBS1..6 and Y1+C1, Y2+C2, Y3+C3. All in 50/60Hz, NTSC, PAL or

SECAM and delivering a YUV datastream.  On my card the input

'CVBS-0' corresponds to channel CVBS2 and 'S-Video' to Y2+C2.

I have some reports of other cards working with the mentioned

chip sets. For a list of other working cards please have a look

at the cards named in the tvcards struct in the beginning of

zr36120.c

After some testing, I discovered that the carddesigner messed up

on the I2C interface. The Zoran chip includes 2 lines SDA and SCL

which (s)he connected reversely. So we have to clock on the SDA

and r/w data on the SCL pin. Life is fun... Each cardtype now has

a bit which signifies if you have a card with the same deficiency.

Oh, for the completeness of this story I must mention that my

card delivers the VSYNC pulse of the SAA chip to GIRQ1, not

GIRQ0 as some other cards have. This is also incorporated in

the driver be clearing/setting the 'useirq1' bit in the tvcard

description.

Another problems of continuous capturing data with a Zoran chip

is something nasty inside the chip. It effectively halves the

fps we ought to get... Here is the scenario: capturing frames

to memory is done in the so-called snapshot mode. In this mode

the Zoran stops after capturing a frame worth of data and wait

till the application set GRAB bit to indicate readiness for the

next frame. After detecting a set bit, the chip neatly waits

till the start of a frame, captures it and it goes back to off.

Smart ppl will notice the problem here. Its the waiting on the

_next_ frame each time we set the GRAB bit... Oh well, 12,5 fps

is still plenty fast for me.

-- update 28/7/1999 --

Don't believe a word I just said... Proof is the output

of `streamer -t 300 -r 25 -f avi15 -o /dev/null`

	++--+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25

	+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25

	+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25

	+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25

	+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25

	+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25

	+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25

	+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25

	+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25

	+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25

	+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25

	+-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+-

	syncer: done

	writer: done

(note the /dev/null is prudent here, my system is not able to

 grab /and/ write 25 fps to a file... gifts welcome :) )

The technical reasoning follows: The zoran completed the last

frame, the VSYNC goes low, and GRAB is cleared. The interrupt

routine starts to work since its VSYNC driven, and again

activates the GRAB bit. A few ms later the VSYNC (re-)rises and

the zoran starts to work on a new and freshly broadcasted frame....

For pointers I used the specs of both chips. Below are the URLs:

  http://www.zoran.com/ftp/download/devices/pci/ZR36120/36120data.pdf

  http://www-us.semiconductor.philips.com/acrobat/datasheets/SAA_7110_A_1.pdf

Some alternatives for the Philips SAA 7110 datasheet are:

  http://www.datasheetcatalog.com/datasheets_pdf/S/A/A/7/SAA7110.shtml

  http://www.datasheetarchive.com/search.php?search=SAA7110&sType=part

The documentation has very little on absolute numbers or timings

needed for the various modes/resolutions, but there are other

programs you can borrow those from.

------ Install --------------------------------------------

Read the file called TODO.  Note its long list of limitations.

Build a kernel with VIDEO4LINUX enabled. Activate the

BT848 driver; we need this because we have need for the

other modules (i2c and videodev) it enables.

To install this software, extract it into a suitable directory.

Examine the makefile and change anything you don't like.  Type "make".

After making the modules check if you have the much needed

/dev/video devices. If not, execute the following 4 lines:

	mknod /dev/video c 81 0

	mknod /dev/video1 c 81 1

	mknod /dev/video2 c 81 2

	mknod /dev/video3 c 81 3

	mknod /dev/video4 c 81 4

After making/checking the devices do:

	modprobe i2c

	modprobe videodev

	modprobe saa7110	(optional)

	modprobe saa7111	(optional)

	modprobe tuner		(optional)

	insmod zoran cardtype=<n>

<n> is the cardtype of the card you have. The cardnumber can

be found in the source of zr36120. Look for tvcards. If your

card is not there, please try if any other card gives some

response, and mail me if you got a working tvcard addition.

PS. <TVCard editors behold!)

    Don't forget to set video_input to the number of inputs

    you defined in the video_mux part of the tvcard definition.

    It's a common error to add a channel but not incrementing

    video_input and getting angry with me/v4l/linux/linus :(

You are now ready to test the framegrabber with your favorite

video4linux compatible tool

------ Application ----------------------------------------

This device works with all Video4Linux compatible applications,

given the limitations in the TODO file.

------ API ------------------------------------------------

This uses the V4L interface as of kernel release 2.1.116, and in

fact has not been tested on any lower version.  There are a couple

of minor differences due to the fact that the amount of data returned

with each frame varies, and no doubt there are discrepancies due to my

misunderstanding of the API.  I intend to convert this driver to the

new V4L2 API when it has stabilized more.

------ Current state --------------------------------------

The driver is capable of overlaying a video image in screen, and

even capable of grabbing frames. It uses the BIGPHYSAREA patch

to allocate lots of large memory blocks when tis patch is

found in the kernel, but it doesn't need it.

The consequence is that, when loading the driver as a module,

the module may tell you it's out of memory, but 'free' says

otherwise. The reason is simple; the modules wants its memory

contiguous, not fragmented, and after a long uptime there

probably isn't a fragment of memory large enough...

The driver uses a double buffering scheme, which should really

be an n-way buffer, depending on the size of allocated framebuffer

and the requested grab-size/format.

This current version also fixes a dead-lock situation during irq

time, which really, really froze my system... :)

Good luck.

  Pauline