Fixes error:
[next:master 7435/8702] ERROR: "usb_alloc_urb
[drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined!

rtl2832_sdr driver implements own USB streaming for SDR data.
Logically that functionality belongs to USB interface driver, but
currently it is implemented here.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

[next:master 7472/8702] warning: (USB_MSI2500) selects
MEDIA_TUNER_MSI001 which has unmet direct dependencies
((MEDIA_ANALOG_TV_SUPPORT || ..) && ..)

[next:master 7698/8702] warning: (MEDIA_TUNER && ..) selects
MEDIA_TUNER_XC5000 which has unmet direct dependencies
((MEDIA_ANALOG_TV_SUPPORT || ..) && ..)
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Once upon a time the radio-miropcm20 driver had RDS support. However, after
some internal kernel changes that support was removed. Now that we have a
nice RDS API I have been working on adding back this support. It has been
tested with the si4713 RDS transmitter and it is working quite nicely.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Document the new RDS receiver controls. This will be used by the radio-miropcm20
driver.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The radio-miropcm20 driver has firmware that decodes the RDS signals. So in that
case the RDS data becomes available in the form of controls.

Add support for these controls to the control framework, allowing the miro driver
to use them.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Not all the RDS features of the si4713 were supported. Add
the missing bits to fully support the hardware capabilities.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Document the new RDS features that will be supported by the si4713 driver.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The si4713 supports several RDS features not yet implemented in the driver.

This patch adds the missing RDS functionality to the list of RDS controls.

The ALT_FREQS control is a compound control containing an array of up
to 25 (the maximum according to the RDS standard) frequencies. To support
that the V4L2_CTRL_TYPE_U32 was added.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

vb2_poll should always return POLLOUT | POLLWRNORM as long as there
are fewer buffers queued than there are buffers available. Poll for
an output stream should only wait if all buffers are queued and nobody
is dequeuing them.
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

A lot of work was done in vb2 to regulate how drivers and the vb2 core handle
buffer ownership, but inexplicably the videobuf2-core.h comments were never
updated. Do so now. The same was true for the replacement of the -ENOBUFS
mechanism by the min_buffers_needed field.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Rather than always having to use a v4l2_ext_control struct to set
a control value from within a driver, switch to just setting the
new value. This is faster and it makes it possible to set more
complex types such as a string control as is added by this
patch.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This patch explicitly documents the relationship between bytesused and data_offset.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Now that the protocol is part of the scancode, it is pretty easy to merge
the rc5 and streamzap decoders. An additional advantage is that the decoder
is now stricter as it waits for the trailing silence before determining that
a command is a valid rc5/streamzap command (which avoids collisions that I've
seen with e.g. Sony protocols).
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

We already have dev->scancode_filter and dev->scancode_wakeup_filter
so rename dev->scanmask to dev->scancode_mask for consistency.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The basic API of rc-core used to be:

	dev = rc_allocate_device();
	dev->x = a;
	dev->y = b;
	dev->z = c;
	rc_register_device();

which is a pretty common pattern in the kernel, after the introduction of
protocol arrays the API looks something like:

	dev = rc_allocate_device();
	dev->x = a;
	rc_set_allowed_protocols(dev, RC_BIT_X);
	dev->z = c;
	rc_register_device();

There's no real need for the protocols to be an array, so change it
back to be consistent (and in preparation for the following patches).

[m.chehab@samsung.com: added missing changes at some files]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Simplify and cleanup the sysfs code a bit.

[m.chehab@samsung.com: rebased and fixed a CodingStyle issue]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This driver codes the two address bytes in reverse order when compared to the
other drivers, so make it consistent (and update the keymap, note that the
result is a prefix change from 0x6b86 -> 0x866b, and the latter is pretty
common among the NECX keymaps. While not conclusive, it's still a strong hint
that the change is correct).
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Right now the protocol information is not preserved, rc-core gets handed a
scancode but has no idea which protocol it corresponds to.

This patch (which required reading through the source/keymap for all drivers,
not fun) makes the protocol information explicit which is important
documentation and makes it easier to e.g. support multiple protocols with one
decoder (think rc5 and rc-streamzap). The information isn't used yet so there
should be no functional changes.

[m.chehab@samsung.com: rebased, added cxusb and removed bad whitespacing]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

the RC RX packet is defined as:

        struct dib0700_rc_response {
		...
                                u8 not_system;
                                u8 system;
		...
                u8 data;
                u8 not_data;

The NEC protocol transmits in the order:
        system
        not_system
        data
        not_data

Note that the code defines the NEC extended scancode as:

        scancode = be16_to_cpu(poll_reply->system16) << 8 | poll_reply->data;

i.e.

        scancode = poll_reply->not_system << 16 |
                   poll_reply->system     << 8  |
                   poll_reply->data;

Which, if the order *is* reversed, would mean that the scancode that
gets defined is in reality:

        scancode = poll_reply->system     << 16 |
                   poll_reply->not_system << 8  |
                   poll_reply->data;

Which is the same as the order used in drivers/media/rc/ir-nec-decoder.c.

This patch changes the code to match my assumption (the generated scancode
should, however, not change).

[m.chehab@samsung.com: rebased and fixed the decoding error message]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
CC: Patrick Boettcher <pboettcher@kernellabs.com>
Tested-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The arguments used for ir-kbd-i2c's get_key() functions are not
really suited for rc-core and the ir_raw/ir_key distinction is
just confusing.

Convert all of them to return a protocol/scancode/toggle triple instead.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The bt8xx driver does RC5 decoding for Nebula digi hardware, but includes
some pointless limitations (both start bits must be one, the
device/address/system must be 0x00). Remove those limitations and update
the keymap to use the full RC5 scancode (fortunately the 0x00 address
means that this is perfectly backwards compatible).
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

"ir" is already checked before calling unregister_from_lirc().
Signed-off-by: NDaeseok Youn <daeseok.youn@gmail.com>
Reviewed-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

As reported by Vincent:
	[   16.332247] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id 0000000000000000.
	[   16.344378] cxusb: i2c wr: len=64 is too big!

64 bytes is too short for firmware load on this device. So, increase it
to 80 bytes.
Reported-by: NVincent McIntyre <vincent.mcintyre@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The DocBook documentation is incorrect: on ISDB-T, interleaving
time is always a power of 2. Fix it and provides a table showing
the actual interleaving length for each mode.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The programmed frequency on xc4000 is not the middle
frequency, but the initial frequency on the bandwidth range.
However, the DVB API works with the middle frequency.

This works fine on set_frontend, as the device calculates
the needed offset. However, at get_frequency(), the returned
value is the initial frequency. That's generally not a big
problem on most drivers, however, starting with changeset
6fe1099c, the frequency drift is taken into account at
dib7000p driver.

This broke support for PCTV 340e, with uses dib7000p demod and
xc4000 tuner.

Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The programmed frequency on xc5000 is not the middle
frequency, but the initial frequency on the bandwidth range.
However, the DVB API works with the middle frequency.

Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This meta-tag is used by some distros to help them package
the firmware and generate proper initrd images.

So, add the firmware names there.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The firmware name at:
   http://www.kernellabs.com/firmware/xc4000/

Is different from the one at the Kernel. Update it
try first the new name, falling back to the previous one
if the new name can't be found.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This patch removes the null test on ch. ch is initialized at the
beginning of the function to &demod->dtv_property_cache. Since demod
is dereferenced prior to the null test, demod must be a valid pointer,
and &demod->dtv_property_cache cannot be null.

The following Coccinelle script is used for detecting the change:

@r@
expression e,f;
identifier g,y;
statement S1,S2;
@@

*e = &f->g
<+...
 f->y
 ...+>
*if (e != NULL || ...)
 S1 else S2
Signed-off-by: NHimangi Saraogi <himangi774@gmail.com>
Acked-by: NJulia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Instead of looking at the guard interval field, it was using
the interval length, with is wrong. Fix it.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Interleaving code was wrong at mb86a20s: instead, it was looking
at the Guard Interval. Fix it.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The driver was reporting an incorrect mode, when mode 2
is selected.

While testing it, noticed that neither mode 1 or guard
interval 1/32 is supported by this device. Document it,
and ensure that it will report _AUTO when it doesn't lock,
in order to not report a wrong detection to userspace.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Implement read_ber for BER estimate.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

There was 32-bit calculation overflow. Use div_u64.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Cc: Antti Palosaari <crope@iki.fi>
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Cc: Antti Palosaari <crope@iki.fi>
Cc: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This cleans up some line over 80 character violations.
Signed-off-by: NEmil Goode <emilgoode@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>