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: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The 6.5 MHz carrier was interpreted as SECAM-L even if SECAM-D/K was
selected.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Fsc 3.58 refers to Combination PAL-N (aka PAL-Nc), not to plain PAL-N (that
uses Fsc 4.43).
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The q_io queue was never taken into account by the poll function. Thanks to
Andy Walls for finding this bug.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NGuennadi Liakhovetski <g.liakhovetski@pengutronix.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Please run checkpatch prior to sending patches
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This saves an initialization and a comparison.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NSascha Sommer <saschasommer@freenet.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Fix a cut-and-paste error
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Call pvr2_hdw_cmd_powerdown to power down the device
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

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: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>