The raw Sony IR decoder decodes 15bit messages slightly incorrectly.
To decode the function number, it shifts the bits right by 7 so that the
function is in bits 7:1, masks with 0xFD (0b11111101), and does an 8 bit
reverse so it ends up in bits 6:0. The mask should be 0xFE to correspond
with bits 7:1 (0b11111110).

The old mask had the effect of dropping the MSB of the function number
from bit 6, and leaving the LSB of the device number in bit 7.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Adds GPIO based IR Receiver driver. It decodes signals using decoders
available in rc framework.
Signed-off-by: NRavi Kumar V <kumarrav@codeaurora.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Correct spelling "thresold" to "threshold" in
drivers/media/video/davinci/dm355_ccdc.c
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Reverse cx18-driver part of commit
90ab5ee9 and change
module_param_array() type from bool to int to fix
compiler warning:

In function ‘__check_radio’:
113:1: warning: return from incompatible pointer type [enabled by default]
At top level:
113:1: warning: initialization from incompatible pointer type [enabled by default]
113:1: warning: (near initialization for ‘__param_arr_radio.num’) [enabled by default]

v2: corrected version, don't change to module_param_named(), change
    all to int/uint
Signed-off-by: NDanny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In driver ivtv, there is a mismatch between the type of the radio module
parameter and the storage variable, which leads to the following
warning:

  CC [M]  drivers/media/video/ivtv/ivtv-driver.o
drivers/media/video/ivtv/ivtv-driver.c: In function ‘__check_radio’:
drivers/media/video/ivtv/ivtv-driver.c:142: warning: return from incompatible pointer type
drivers/media/video/ivtv/ivtv-driver.c: At top level:
drivers/media/video/ivtv/ivtv-driver.c:142: warning: initialization from incompatible pointer type
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The code was unnecessarily complex, introducing a hdl_out handler that was
not needed. Instead just add the controls to the cxhdl.hdl handler directly.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently v4l2_ctrl_add_handler adds only the controls that are owned
by the handler. This is wrong. Instead all controls, whether owned or
not, should be added.

This is also implied by the v4l2-controls.txt documentation and it is
clearly the right thing to do. The only reason this was never noticed
before is because we never did this. Only recent changes in ivtv made
this error visible because there a third handler layer was added (handler
A inherits from handler B which inherits from C, D and E). Without this
change handler A only sees the controls owned by handler B and the controls
from C, D and E are missing.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

[mchehab@redhat.com: CodingStyle fixes]
Signed-off-by: NKyle Strickland <kyle@kyle.strickland.name>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Without this we have got the warnings like following if build with "make W=1
O=/var/tmp":
  cc1: warning: drivers/media/dvb/dvb-core: No such file or directory [enabled by default]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Without this we have got the warnings like following if build with "make W=1
O=/var/tmp":
  cc1: warning: drivers/media/dvb/dvb-core: No such file or directory [enabled by default]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Without this we have got the warnings like following if build with "make W=1
O=/var/tmp":
  cc1: warning: drivers/media/dvb/dvb-core: No such file or directory [enabled by default]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Without this we have got the warnings like following if build with "make W=1
O=/var/tmp":
  cc1: warning: drivers/media/dvb/dvb-core: No such file or directory [enabled by default]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Without this we have got the warnings like following if build with "make W=1
O=/var/tmp":
  cc1: warning: drivers/media/dvb/dvb-core: No such file or directory [enabled by default]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Without this we have got the warnings like following if build with "make W=1
O=/var/tmp":
  cc1: warning: drivers/media/dvb/dvb-core: No such file or directory [enabled by default]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Without this we have got the warnings like following if build with "make W=1
O=/var/tmp":
   CHECK   drivers/media/video/videobuf-vmalloc.c
   CC [M]  drivers/media/video/videobuf-vmalloc.o
 +cc1: warning: drivers/media/dvb/dvb-core: No such file or directory [enabled by default]
 +cc1: warning: drivers/media/dvb/frontends: No such file or directory [enabled by default]
 +cc1: warning: drivers/media/dvb/dvb-core: No such file or directory [enabled by default]
 +cc1: warning: drivers/media/dvb/frontends: No such file or directory [enabled by default]
   LD      drivers/media/built-in.o

Some details could be found in [1] as well.

[1] http://comments.gmane.org/gmane.linux.kbuild.devel/7733Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

I don't have this hardware and I don't know the subsystem very well.  So
please review this patch carefully.  The original code definitely looks
buggy though.

Sparse complains about some endian bugs where little endian bugs are
treated as cpu endian.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDean Anderson <linux-dev@sensoray.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

"f" wasn't checked consistently, so static checkers complain.  This
function is always called with a valid "f" pointer, so I have removed
the check.

Also the indenting was messed up.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDean Anderson <linux-dev@sensoray.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

drivers/media/video/mt9p031.c included 'media/v4l2-subdev.h' twice,
remove the duplicate.
Signed-off-by: NDanny Kukawka <danny.kukawka@bisect.de>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

drivers/media/video/adp1653.c included 'linux/module.h' twice,
remove the duplicate.
Signed-off-by: NDanny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Raw IR events are passed to the raw event thread through a kfifo. The
size of the event struct is 12 bytes, and space for 512 events is
reserved in the kfifo (6144 bytes), however this is rounded down to 4096
bytes (the next power of 2) by __kfifo_alloc().

4096 bytes is not divisible by 12 therefore if the fifo fills up a third
of a record will be written in the end of the kfifo by
ir_raw_event_store() because the recsize of the fifo is 0 (it doesn't
have records). When this is read by ir_raw_event_thread() a corrupted or
partial record will be read, and in the case of a partial record the
BUG_ON(retval != sizeof(ev)) gets hit too.

According to samples/kfifo/record-example.c struct kfifo_rec_ptr_1 can
handle records of a length between 0 and 255 bytes, so change struct
ir_raw_event_ctrl to use that instead of struct kfifo.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If the attached video sensor cannot provide the
requested image size, try to use resizing engine
included in the eMMa-PrP IP.

This patch supports both averaging and bilinear
algorithms.
Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

csi clock frequency is already shown by:

dev_info(&pdev->dev, "MX2 Camera (CSI) driver probed, clock frequency: %ld\n",
		clk_get_rate(pcdev->clk_csi));

,so no need to have the dev_dbg call to present the same information.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Provide error message if clk_get fails.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some elements of 'mx2_buffer' are grouped together in another
auxiliary structure. This way we don't need to have unused
'vb2_buffer' structures for both discard buffers.
Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If active_bufs() list is empty and no IRQ status bit is set
we are probably dealing with a share IRQ. Return IRQ_NONE in
this case.
Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We don't need to use spin_lock_irqsave() since there are not
any other IRQs that can race with this ISR.
Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com>
[g.liakhovetski@gmx.de: fix one list_first_entry() instance]
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The way discard buffer was previously handled lead
to possible races that made a buffer that was not
yet ready to be overwritten by new video data. This
is easily detected at 25fps just adding "#define DEBUG"
to enable the "memset" check and seeing how the image
is corrupted.

A new "discard" queue and two discard buffers have
been added to make them flow trough the pipeline
of queues and thus provide suitable event ordering.
Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add "start_stream" and "stop_stream" callback in order to enable
and disable the eMMa-PrP properly and save CPU usage avoiding
IRQs when the device is not streaming. This also makes the driver
return 0 as the sequence number of the first frame.
Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com>
[g.liakhovetski@gmx.de: remove the mx27_camera_emma() macro]
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The i.MX27 DMA support was introduced with the initial commit of this
driver and originally created by me. However, I never got this stable
due to the racy DMA engine and used the EMMA engine instead. As the DMA
support is most probably unused and broken in its current state, remove
it. EMMA becomes the only supported mode on i.MX27.

This also helps us get rid of another user of the legacy i.MX DMA
support and remove the dependency on ARCH_MX* macros as these are
scheduled for removal.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
[g.liakhovetski@gmx.de: remove unused goto]
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The error handling in lgdt3303_read_status() and lgdt330x_read_ucblocks()
doesn't work, because i2c_read_demod_bytes() returns a u8 and (err < 0)
is always false.

        err = i2c_read_demod_bytes(state, 0x58, buf, 1);
        if (err < 0)
                return err;

Change the return type of i2c_read_demod_bytes() to int.  Also change
the return value on error to -EIO to make (err < 0) work.
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Correct spelling "contrls" to "controls" in
drivers/media/radio/radio-sf16fmr2.c
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

On a set-top-box based on the Broadcom 7405 SoC (MIPS), the Abilis as102 driver
causes a kernel oops while trying to map the URB stream buffers DMA addresses:

CPU 0 Unable to handle kernel paging request at virtual address 007b9900,
epc == 80010cc4, ra == 8039d108

Call Trace:
[<80010cc4>] mips_dma_map_page+0x14/0x108
[<8039d108>] usb_hcd_map_urb_for_dma+0x338/0x4a8
[<8039d540>] usb_hcd_submit_urb+0x2c8/0x8cc
[<e13655d8>] as102_submit_urb_stream+0x64/0xc8 [dvb_as102]
[<e1365680>] as102_usb_start_stream+0x44/0x80 [dvb_as102]
[<e1363628>] as102_dvb_dmx_start_feed+0xb4/0x17c [dvb_as102]
[<803e20f4>] dmx_ts_feed_start_filtering+0x5c/0x134
[<803de454>] dvb_dmxdev_start_feed+0xd4/0x158
[<803dff28>] dvb_dmxdev_filter_start+0x2b8/0x448
[<803e07ac>] dvb_demux_do_ioctl+0x2a0/0x654
[<803ddc8c>] dvb_usercopy+0x124/0x204
[<800d5284>] do_vfs_ioctl+0xa0/0x6c0
[<800d58e8>] sys_ioctl+0x44/0xa8
[<8000ecfc>] stack_done+0x20/0x40

On other boxes based on older SoCs (7401) this doesn't happen, so it looks like
a bug in the kernel specific to MIPS SMP. This issue has been reproduced on
several kernel versions from 2.6.18 to 3.1.0.

Since the base DMA address and the offsets are known, it is possible to map
the DMA addresses of the URB buffers directly in the driver. This workaround
fixes the problem and has been tested on both MIPS and x86 CPUs with success.

By the way, with this fix the driver works perfectly fine on the set-top-box:
both UHF and VHF frequencies are tuned without problems, and zapping is quite
fast. SNR and signal strength reports seems to work fine, too.

The only remaining problem (on both the PC and the set-top-box) is that after
a soft reboot the device is not recognized again by the kernel. It requires
a power cycle (or a manual unplug/replug) to be recognized again. So probably
the device state is not reset properly at shut-down.
Signed-off-by: NGianluca Gennari <gennarone@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

On MIPS/ARM set-top-boxes, as well as old x86 PCs, memory allocation failures
in the em28xx driver are common, due to memory fragmentation over time, that
makes impossible to allocate large chunks of coherent memory.
A typical system with 256/512 MB of RAM fails after just 1 day of uptime (see
the old thread for detailed reports and crashlogs).

In fact, the em28xx driver allocates memory for USB isoc transfers at runtime,
as opposite to the dvb-usb drivers that allocates the USB buffers when the
device is initialized, and frees them when the device is disconnected.

Moreover, in digital mode the USB isoc transfer buffers are freed, allocated
and cleared every time the user selects a new channel, wasting time and
resources.

This patch solves both problems by allocating DVB isoc transfer buffers in
em28xx_usb_probe(), and freeing them in em28xx_usb_disconnect().
In fact, the buffers size and number depend only on the max USB packet size
that is parsed from the USB descriptors in em28xx_usb_probe(), so it can
never change for a given device.

This approach makes no sense in analog mode (as the buffer size depends on
the alternate mode selected at runtime), the patch creates two separate sets
of buffers for digital and analog modes.

For digital-only devices, USB buffers are created when the device is probed
and freed when the device is disconnected.
For analog-only devices, nothing changes: isoc buffers are created at runtime.
For hybrid devices, two sets of buffers are maintained: the digital-mode
buffers are created when the device is probed, and freed when the device is
disconnected; analog-mode buffers are created/destroyed at runtime as before.
So, in analog mode, digital and analog buffers coexists at the same time: this
can be justified by the fact that digital mode is by far more commonly used
nowadays, so it makes sense to optimize the driver for this use case scenario.

The patch has been tested in the last few days on a x86 PC and a MIPS
set-top-box, with the PCTV 290e (digital only) and the Terratec Hybrid XS
(hybrid device). With the latter, I switched several times between analog and
digital mode (Kaffeine/TvTime) with no issue at all.
I unplugged/plugged the devices several times with no problem.
Also, after over 3 days of normal usage in the MPIS set-top-box, the PCTV 290e
was still up and running.
Signed-off-by: NGianluca Gennari <gennarone@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If go7007_usb_vendor_request() fails in write_reg_fp()
or in read_reg_fp(), the usb->i2c_lock mutex left locked.

The patch moves mutex_unlock(&usb->i2c_lock) before check
for go7007_usb_vendor_request() returned value.

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>

The signal strength value returned is not quite correct, it decreases
when I increase the gain of my antenna, and vice versa. It also
doesn't span over the whole 0x0000-0xffff range. Compute a value which
at least increases when signal strength increases, and spans the whole
allowed range.

In practice I get 67% with my antenna fully amplified and 51% with
no amplification. This is close enough to what I get on my other
DVB-T adapter with the same antenna.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Steven Toth <stoth@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>