Provide a frontend setup routine for the PCTV 340e which takes into account
the specific GPIO setup of the board.

Note that this patch does *not* take into account the xc4000 reset pin, which
is attached to the dib7000.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add the board profile for the PCTV 340eSE, since that's what I have here
for development.

[mchehab@redhat.com: rebased on the top of the current tree]
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is initial code written by Davide Ferri for the PCTV 340e, including
a new xc4000 driver.  I am checking in all the code unmodified, and making
no assertions about its quality (other than confirming it compiles).

[mchehab@redhat.com: rebased on the top of the current tree]
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NDavide Ferri <davidef1986@gmail.com>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The function "rc5_scan" in "dvb_usb.h" is returning invalid value.
The value should be returned "u16" but is returning "u8".

See example below in "drivers/media/dvb/dvb-usb/opera1.c":

        send_key = (send_key & 0xffff) | 0x0100;

        for (i = 0; i < ARRAY_SIZE(rc_map_opera1_table); i++) {
            if (rc5_scan(&rc_map_opera1_table[i]) == (send_key & 0xffff)) {
                *state = REMOTE_KEY_PRESSED;
                *event = rc_map_opera1_table[i].keycode;
                opst->last_key_pressed =
                    rc_map_opera1_table[i].keycode;
                break;
            }
            opst->last_key_pressed = 0;
        }
Signed-off-by: NManoel Pinheiro <pinusdtv@hotmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Change some info, comments, variables. No functionality changes.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Basically it is just same device as Anysee E7 S2 but made for
internal PCI(e) slot and motherboard USB connector.

Cc: info@anysee.com
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Basically it is just same device as Anysee E7 TC but made for
internal PCI(e) slot and motherboard USB connector.

Cc: info@anysee.com
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Check I2C messages and return error properly.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

driver to use dvb-usb-remote.
The remote(s) generates 24 bit NEC codes, lme2510 keymaps redefined.

Other minor fixes
fix le warning.
make sure frontend is detached on firmware change.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

[mchehab@redhat.com: The same patch were sent by Alf and by Randoslaw.
I've applied the oldest version, just fixing the entry index]

Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Tested-by: NJames Huk <huk256@gmail.com>
Tested-by: NAlf Fahland <alf-f@gmx.de>
Signed-off-by: NRadoslaw Warowny <radoslaww@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It is DVB-S/S2 USB box.

* DNBU10512IST NIM
 * STV0903 demod
 * STV6110 tuner

* Intersil ISL6423 LNB controller
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Cc: info@anysee.com
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It is USB DVB-S/S2 box.

Conexant cx24116/cx24118 demod tuner combo
Intersil ISL6423 LNB controller
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Cc: info@anysee.com
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Bits 4 and 5 on register 02 should always be set to 1.

Opera1/Bsru6/z0194a/mantis_vp1033
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Acked-by: NOliver Endriss <o.endriss@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Improve PID filtering and program register 20 correctly.
 Make sure stream_on message is sent if streaming is off, otherwise
 PIDs are not registered.
 Move mutex outside lme2510_enable_pid.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

usb_buffer not inside mutex lock, waiting caller can alter buffer.
 Static added to lme2510_exit and lme2510_exit_int.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Return device errors to demuxer from on/off streamming and
 pid filtering.

Please test this patch with all dvb-usb devices.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There are a couple of places where mutex_unlock() is called even
if mutex_lock_interruptible() failed. The patch fixes the issue.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A greatly simplified version of the PID Filter now added
back to the Driver.

The driver allows for the PID filter to be turned off.

applied after patch 683781.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

 stv0288 Register 42 bits 6 & 7 should be set to 0.
 This is causing intermittent lock, the dvb-usb-lmedm04 driver uses
 register 50 (auto fine mode) to correct for this, this register is
 now returned to its default setting.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Seems like 'adap->fe' test for NULL was meant to be before we dereference
that pointer.
Signed-off-by: NMariusz Kozlowski <mk@lab.zgora.pl>
Acked-by: NPatrick Boettcher <patrick.boettcher@dibcom.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.

In lib/dma_debug.c the function check_for_stack even warns about it:
	WARNING: at lib/dma-debug.c:866 check_for_stack
Tested-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.

In lib/dma_debug.c the function check_for_stack even warns about it:
	WARNING: at lib/dma-debug.c:866 check_for_stack
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Acked-by: NAntti Palosaari <crope@iki.fi>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Tested-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.

In lib/dma_debug.c the function check_for_stack even warns about it:
	WARNING: at lib/dma-debug.c:866 check_for_stack
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Acked-by: NAntti Palosaari <crope@iki.fi>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Tested-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.

In lib/dma_debug.c the function check_for_stack even warns about it:
	WARNING: at lib/dma-debug.c:866 check_for_stack
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Acked-by: NAntti Palosaari <crope@iki.fi>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Tested-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Note: This change is tested to compile only as I don't have the
hardware.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If we need a bigger buffer, we reallocte a new buffer and free the old
one.

Note: This change is tested to compile only as I don't have the
hardware.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Note: This change is tested to compile only as I don't have the
hardware.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Otherwise it is not obvious that vp702x_usb_in_op or vp702x_usb_out_op
will not interfere with any vp702x_usb_inout_op.

Note: This change is tested to compile only, as I don't have the
hardware.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.

In lib/dma_debug.c the function check_for_stack even warns about it:
	WARNING: at lib/dma-debug.c:866 check_for_stack

Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

struct vp702x_device_state.power_state is nowhere referenced.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This sets up a buffer and a mutex protecting that buffer in
the struct vp702x_device_state.

The definition of struct vp702x_device_state is moved into the header
in order to use the buffer also in the frontend.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We need a state struct for the dvb_usb_device.
In order to reduce confusion we rename the vp702x_state struct.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some whitespace, one linebreak and one unneded variable
initialization...
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Cc: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.

In lib/dma_debug.c the function check_for_stack even warns about it:
	WARNING: at lib/dma-debug.c:866 check_for_stack

Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.

In lib/dma_debug.c the function check_for_stack even warns about it:
	WARNING: at lib/dma-debug.c:866 check_for_stack

Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Cc: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.

In lib/dma_debug.c the function check_for_stack even warns about it:
	WARNING: at lib/dma-debug.c:866 check_for_stack

Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Cc: Igor M. Liplianin <liplianin@tut.by>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.

In lib/dma_debug.c the function check_for_stack even warns about it:
	WARNING: at lib/dma-debug.c:866 check_for_stack

Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Cc: Akihiro Tsukada <tskd2@yahoo.co.jp>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.

In lib/dma_debug.c the function check_for_stack even warns about it:
	WARNING: at lib/dma-debug.c:866 check_for_stack

Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>