- 24 Apr, 2008 40 commits
-
-
Andrew Morton authored
Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> CC: Guennadi Liakhovetski <kernel@pengutronix.de> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org>
-
Mauro Lacy authored
Signed-off-by:
Mauro Lacy <mauro@lacy.com.ar> Signed-off-by:
-
Ernesto Hernández-Novich authored
I have what looks like a Geovision GV-600 (or 650) card. It has a large chip in the middle labeled CONEXANT FUSION 878A 25878-13 E345881.1 0312 TAIWAN It has an audio connector coming out from a chip labeled ATMEL 0242 AT89C2051-24PI It is identified as follows on my Debian GNU/Linux Etch (kernel 2.6.18) ... 01:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 01:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) ... 01:0a.0 0400: 109e:036e (rev 11) Subsystem: 008a:763c Flags: bus master, medium devsel, latency 64, IRQ 58 Memory at dfffe000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 01:0a.1 0480: 109e:0878 (rev 11) Subsystem: 008a:763c Flags: bus master, medium devsel, latency 64, IRQ 58 Memory at dffff000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 It was being detected as a GENERIC UNKNOWN CARD both by the 2.6.18 kernel and the latest v4l-dvb drivers, but it did not work at all. The card has sixteen (16) BNC video inputs, four of them on the board itself and twelve on three daughter-cards. It has a single bt878 chip, no tuner and what looks like and audio input. After doing some research I managed to get only eight channels working by forcing card=125 and those DID NOT match channels 0-7 on the card, and no audio. Based on what was working for card=125, I added the card definition block, added a specific muxsel routine and got the card working fully with xawtv, where the sixteen channels show up as Composite0 to Composite15, matching the channel labels in the card and daughter-cards. I have made no efforts yet to get audio working, but would appreciate any pointers. Signed-off-by:Ernesto Hernández-Novich <emhn@usb.ve> Signed-off-by:
-
Marcin Slusarz authored
poll_one allocated on stack struct poll_wqueues which is pretty big structure (>500 bytes on x86_64). v4l1_compat_sync invokes poll_one in a loop, so allocate struct poll_wqueues in v4l1_compat_sync (with kmalloc) and pass it to poll_one. Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by:
-
Marcin Slusarz authored
v4l_compat_translate_ioctl used 1376 bytes of stack (x86_64), so split this 800 lines long function into ~20 small noinline functions; the biggest function takes now 712 bytes (v4l1_compat_sync) fix VIDIOCSWIN handler which printked wrong errors Signed-off-by:
-
Marcin Slusarz authored
fix most coding style violations found by checkpatch Signed-off-by:
-
Michael Krufky authored
simple_dvb_configure returns the actual tuned frequency to its caller, so it must be declared as a u32 rather than an int. As a result, we will return 0 to indicate a failure. Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Michael Krufky authored
Enable digital tuning support within tuner-simple. This will allow for a single tuner module to manage the hardware, without having dvb-pll loaded. Signed-off-by:
-
Michael Krufky authored
Enable digital tuning support within tuner-simple. This will allow for a single tuner module to manage the hardware, without having dvb-pll loaded. Signed-off-by:
-
Michael Krufky authored
Enable digital tuning support within tuner-simple. This will allow for a single tuner module to manage the hardware, without having dvb-pll loaded. Signed-off-by:
-
Michael Krufky authored
Enable digital tuning support within tuner-simple. This will allow for a single tuner module to manage the hardware, without having dvb-pll loaded. Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Enable digital tuning support within tuner-simple. This will allow for a single tuner module to manage the hardware, without having dvb-pll loaded. Signed-off-by:
-
Michael Krufky authored
Enable digital tuning support within tuner-simple. This will allow for a single tuner module to manage the hardware, without having dvb-pll loaded. Signed-off-by:
-
Michael Krufky authored
Enable digital tuning support within tuner-simple. This will allow for a single tuner module to manage the hardware, without having dvb-pll loaded. Signed-off-by:
-
Michael Krufky authored
taken from dvb-pll Signed-off-by:
-
Michael Krufky authored
Enable digital tuning support within tuner-simple. This will allow for a single tuner module to manage the hardware, without having dvb-pll loaded. Signed-off-by:
-
Michael Krufky authored
Enable digital tuning support within tuner-simple. This will allow for a single tuner module to manage the hardware, without having dvb-pll loaded. Signed-off-by:
-
Michael Krufky authored
if (priv->i2c_props.adap == NULL) then exit any function that would send commands over the i2c bus. We allow drivers to attach without an i2c adapter for cases where the dvb demod accesses the tuner directly via calc_regs. Signed-off-by:
-
Michael Krufky authored
Add entry points used for digital tuning via the dvb_frontend. Share state data between multiple instances of the driver for hybrid tuners. Signed-off-by:
-
Michael Krufky authored
Convert tda9887 to use the new hybrid_tuner_request_state and hybrid_tuner_release_state macros to manage state sharing between hybrid tuner instances. Some ATSC/DVB cards need to put the analog demodulator into standby before tuning digital. This patch allows us to attach the tda9887 driver to the digital side of the bridge driver and be able to put it into standby without jeopardizing the analog demod driver's state. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Hans Verkuil authored
The 6.5 MHz carrier was interpreted as SECAM-L even if SECAM-D/K was selected. Signed-off-by:
-
Hans Verkuil authored
Fsc 3.58 refers to Combination PAL-N (aka PAL-Nc), not to plain PAL-N (that uses Fsc 4.43). Signed-off-by:
-
Hans Verkuil authored
There are two tuner types: those for M/N standards and those for all others. However, M/N standards are not always 60 Hz (PAL-N/Nc are 50 Hz), so rename the module option accordingly. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
Allow options like pal=bgh, improve description of those options. Add tunerhz option: 50=card has 50Hz tuner, 60=card has 60Hz tuner. Signed-off-by:
-
Hans Verkuil authored
The q_io queue was never taken into account by the poll function. Thanks to Andy Walls for finding this bug. Signed-off-by:
-
Guennadi Liakhovetski authored
Improve hardware parameter negotiation between the camera host driver and camera drivers. Parameters like horizontal and vertical synchronisation, pixel clock polarity shall be set depending on capabilities of the parties. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@pengutronix.de> Signed-off-by:
-
Andrew Morton authored
Please run checkpatch prior to sending patches Signed-off-by:
-
Jean Delvare authored
This saves an initialization and a comparison. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Sascha Sommer authored
Signed-off-by:
Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Andreas Oberritter authored
Previously, the macro DVR_FEED, which is used to recognize and filter out duplicate packets going to the DVR device, used the TS_PAYLOAD_ONLY flag to identify a packet's destination. This kind of filtering was introduced by the following two changesets: Now, that it is possible to record TS PIDs using the demux device by setting the output type to DMX_OUT_TSDEMUX_TAP, checking TS_PAYLOAD_ONLY is not sufficient anymore. Therefore another flag, TS_DEMUX, is added to specify the output type of a feed. This allows multiple clients to filter the same TS PID on a demux device simultaneously. Signed-off-by:
Andreas Oberritter <obi@linuxtv.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
Fix a cut-and-paste error Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
If dvb_attach fails, dev->dvb.frontend is NULL. This will produce an OOPS, as reported. Thanks to Vanessa Ezekowitz <vanessaezekowitz@gmail.com> Signed-off-by: -
Michael Krufky authored
The pvrusb2 driver normally picks up the default video standard from the eeprom on Hauppauge devices, but the OnAir HDTV and OnAir Creator are not Hauppauge devices, and do not store this information in any eeprom. These devices support NTSC/ATSC, so we should use NTSC by default when in analog mode. Signed-off-by:
-
Tobias Klauser authored
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
Mike Isely <isely@pobox.com> Signed-off-by:
-
Mike Isely authored
This change significantly rearranges pvr2_context level initialization and operation: 1. A new kernel thread is set up for management of the context. 2. Destruction of the pvr2_context instance is moved into the kernel thread. No other context is able to remove the instance; doing this simplifies lock handling. 3. The callback into pvrusb2-main, which is used to trigger initialization of each interface, is now issued from this kernel thread. Previously it had been indirectly issued out of the work queue thread in pvr2_hdw, which led to deadlock issues if the interface needed to change a control setting (which in turn requires dispatch of another work queue entry). 4. Callbacks into the interfaces (via the pvr2_channel structure) are now issued strictly from this thread. The net result of this is that such callback functions can now also safely operate driver controls without deadlocking the work queue. (At the moment this is not actually a problem, but I'm anticipating issues with this in the future). 5. There is no longer any need for anyone to enter / exit the pvr2_context structure. Implementation of the kernel thread here allows this all to be internal now, simplifying other logic. 6. A very very longstanding issue involving a mutex deadlock between the pvrusb2 driver and v4l should now be solved. The deadlock involved the pvr2_context mutex and a globals-protecting mutex in v4l. During initialization the driver would take the pvr2_context mutex first then the v4l2 interface would register with v4l and implicitly take the v4l mutex. Later when v4l would call back into the driver, the two mutexes could possibly be taken in the opposite order, a situation that can lead to deadlock. In practice this really wasn't an issue unless a v4l app tried to start VERY early after the driver appeared. However it still needed to be solved, and with the use of the kernel thread relieving need for pvr2_context mutex, the problem should be finally solved. Signed-off-by:
-
