- 24 Apr, 2008 40 commits
-
-
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 <hverkuil@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org>
-
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:
Andrew Morton <akpm@linux-foundation.org> 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:
Michael Krufky <mkrufky@linuxtv.org> 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:
-
Mike Isely authored
The pvrusb2 tear-down logic was clearing two timers before stopping its internal work queue. That left a tiny window open where the work queue might run after the timers are stopped, possibly starting them again. This could lead to dangling pointers and an oops. Solution: Kill the work queue first, then delete the timers. Signed-off-by:
-
Mike Isely authored
There is a callback that is issued to into pvr2_context from pvr2_hdw after initialization is done. There was a probability that this callback could get missed. Fixed. Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
Buffer size for printing pvrusb2 video standard strings was too small before. This is cosmetic; the printing logic is not able to overrun a too-short buffer. Signed-off-by:
-
Mike Isely authored
The pvrusb2 driver dynamically generates an enumeration of support video standard combinations based on which video standard bits are set. ATSC modes don't fall into this since they are by nature not analog. The pvrusb2 driver has been warning about an inability to classify ATSC standards. This change causes the classification algorithm to ignore any ATSC standards (such things are better handled elsewhere anyway). Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
The pvrusb2 driver has used hardcoded logic to control the LED on the device. However this is really Hauppauge-specific behavior. This change defines a new device attribute for LED control and sets things up appropriately for Hauppauge devices. Signed-off-by:
-
Mike Isely authored
Most of this originates from Michael Krufky <mkrufky@linuxtv.org>; these changes move LED control into separate functions. This is the first step in new work to make LED control a device-specific attribute. Signed-off-by:
-
Mike Isely authored
The encoder is not a part of the pipeline when in digital mode, so streaming is OK in this case even when the encoder's firmware is not loaded. Modify the driver core handling of this scenario to permit streaming. Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
This is a major pvrusb2 change. The driver core has an algorithm that is used to cleanly sequence the changes needed to enable / disable video streaming. The algorithm had originally been written for analog streaming, but when in digital mode the pipeline is considerably Signed-off-by: -
Mike Isely authored
Unlike analog control, control of the digital side is not nearly as uniform among different devices. So we have to specify the correct digital control scheme as a new device attribute. Signed-off-by:
-
Mike Isely authored
This code is actually part of a larger set from Mike Krufky <mkrufky@linuxtv.org>, to support ATSC streaming from within the pvrusb2 driver. More to come... Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Michael Krufky authored
Call pvr2_hdw_cmd_powerdown to power down the device Signed-off-by:
-
Mike Isely authored
Previously the pvrusb2 driver just started with the default input to be "television". But if the device doesn't support an analog tuner then this default must be different. New logic here selects a reasonable default based on the actual valid set of available inputs. Signed-off-by:
-
Mike Isely authored
When an enumeration control is changed, the pvrusb2 driver assumed that the enumeration values were continuous. That is no longer true; this change allows for properly input validation even when not all enumeration values are legal (which can happen with input selection based on what the hardware supports). Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
Now that the pvrusb2 driver can dynamically choose which inputs to make available depending on the hardware, the enumeration of input choices is no longer a contiguous range of integers. Unfortunately this causes a problem in the v4l2 implementation since the input enumeration requires continuity in the API. This change implements a mapping in order to preserve the v4l2 interface requirement. Signed-off-by:
-
Mike Isely authored
Signed-off-by:
-
Mike Isely authored
The v4l2 implementation in pvru2b2 must produce a sane answer when asked, when the input choice is set to dtv. Signed-off-by:
-
Mike Isely authored
This follows from defining the available inputs as device attributes. This change causes the driver to adjust its list of inputs based on those attributes. Now, for example, the FM radio will appear as a choice only if the hardware supports an FM radio. Signed-off-by:
-
