Fix a divide-by-zero error in ds3000's ds3000_read_snr(), when getting
a very low signal reading (dvbs2_signal_reading >= 1). This prevents
some nasty EIPs when running szap-s2 with a very low signal strength.
Signed-off-by: NNicolas Noirbent <nicolas.noirbent@smartjog.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

drivers/media/video/gspca/cpia1.c:1063: warning: ‘command_setlights’ defined but not used
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

drivers/media/IR/ir-raw-event.c:55: warning: ‘wq_load’ defined but not used
drivers/media/IR/ir-raw-event.c:222: warning: ‘init_decoders’ defined but not used
drivers/media/IR/rc-map.c: In function ‘get_rc_map’:
drivers/media/IR/rc-map.c:40: warning: unused variable ‘rc’
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Due to obvious copy and paste coding a number of video capture drivers
which implement a limit on the buffer memory decremented the user
supplied buffer count in a while loop until it reaches an acceptable
value.

This is a silly thing to do when the maximum value can be directly
computed.
Signed-off-by: NAndreas Bombe <aeb@debian.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This reverts commit bc52d6eb.

On newer kernels, a saa7134 board stopped to display TV video output
properly. After a bisect, I found it as the commit causing the issue.
Turns out that v4l_bound_align_image isn't doing the same bounding
calculation as manually done previously in saa7134_try_fmt_vid_cap.

What isn't equal is the calculation done in clamp align, while
previously it did "f->fmt.pix.width &= ~0x03", clamp_align function
does "Round to nearest aligned value" as stated in the comment, which
yields a different result. If I comment the round calculation in
clamp_align like this: "x = (x /*+ (1 << (align - 1))*/) & mask",
I get it fixed too, because this way the calculation is the same then.
Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In file included from drivers/media/dvb/dvb-usb/dib0700_devices.c:14:
  drivers/media/dvb/frontends/dib8000.h: In function 'dib8000_get_adc_power':
  drivers/media/dvb/frontends/dib8000.h:112: warning: no return statement in function returning non-void

Fixed by adding a return to the dummy function.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Remove unused #include <linux/version.h>('s) in
  drivers/media/dvb/ngene/ngene-core.c
Signed-off-by: NHuang Weiyi <weiyi.huang@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Now that video_ioctl2 no longer clobbers the argument for _IO() ioctls we
can move these into vidioc_default where they really belong.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Try to make a more sensible sequence of events in __video_do_ioctl: first
check for a valid ops pointer, then get the compat part done. The VIDIOCGMBUF
command is now part of the big switch.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

After unregister_device all fileops are blocked, except for ioctls.
So it is not just the open that is blocked, others are as well.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Note that I have not been able to find anyone with this hardware. I tried
contacting the author without success, searched on eBay and similar places
without luck either.

So this conversion is untested. That said, it was pretty straightforward
so it is time to have this driver join the V4L2 world at last.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The indentation of the sections had gone wrong, causing a mistake with
section nesting. Fixed.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The usbvision driver created vbi device nodes but the actual implementation
was just stubs and only returned errors to userspace.

In addition it used video_usercopy() and we want to remove that eventually.

So remove all the vbi code except for the vbi flag in the card definition
should someone ever be mad enough to work on a proper implementation for this
driver.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

You want to be able to reach the debug code at the end of this function,
so don't use return, use break.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If the ioctl was defined without direction (e.g. _IO('o', 25)), then
the arg as passed to vidioc_default was NULL instead of the original
argument.

Several ioctls in e.g. include/linux/dvb/video.h and audio.h use this type
of ioctl to pass simple numerical values to the driver.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

For some reason the definition of enum v4l2_ctrl_type is far from the
place where it is actually needed. This makes it hard to work with this
header.

Move it to just before struct v4l2_queryctrl, which is the one that
actually uses it.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The spec says that the control ID for these types of controls is the same
as that of the control class. But it should read: 'control class + 1'.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If the kmalloc() failed for "ccdc_cfg = kmalloc(...);" then we would exit
with the lock held.  I moved the mutex_lock() below the allocation
because it isn't protecting anything in that block and allocations are
allocations are sometimes slow.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

ir-core.h has the kABI to be used by the bridge drivers, when needing to register
IR protocols and pass IR events. However, the same file also contains IR subsystem
internal calls, meant to be used inside ir-core and between ir-core and the raw
decoders.

Better to move those functions to an internal header, for some reasons:

1) Header will be a little more cleaner;

2) It avoids the need of recompile everything (bridge/hardware drivers, etc),
   just because a new decoder were added, or some other internal change were needed;

3) Better organize the ir-core API, splitting the functions that are internal to
   IR core and the ancillary drivers (decoders, lirc_dev) from the features that
   should be exported to IR subsystem clients.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

drivers/media/IR/ir-raw-event.c is currently written with the assumption
that all "raw" hardware will generate events only on state change (i.e.
when a pulse or space starts).

However, some hardware (like mceusb, probably the most popular IR receiver
out there) only generates duration data (and that data is buffered so using
any kind of timing on the data is futile).

Furthermore, using signed int's to represent pulse/space durations is a
well-known approach when writing ir decoders.

With this patch:

- s64 int's are used to represent pulse/space durations in ns

- a workqueue is used to decode the ir protocols outside of interrupt context

- #defines are added to make decoders clearer

- decoder reset is implemented by passing a zero duration to the kfifo queue
  and decoders are updated accordingly
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

drivers/media/IR/ir-sysfs.c: In function ‘store_protocol’:
drivers/media/IR/ir-sysfs.c:93: warning: suggest parentheses around assignment used as truth value
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Hardware decoders have a more limited set of decoders than software ones.
In general, they support just one protocol at a given time, but allow
changing between a few options.

Rename the previous badly named "current_protocol" as just "protocol",
meaning the current protocol(s) accepted by the driver, and
add a "support_protocols" to represent the entire universe of supported
protocols by that specific hardware.

As commented on http://lwn.net/Articles/378884/, the "one file, one value"
rule doesn't fit nor does make much sense for bitmap or enum values. So, the
supported_protocols will enum all supported protocols, and the protocol
will present all active protocols.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some devices have in-hardware Remote Controller decoder, while others
need a software decoder to get the IR code. As each software decoder
can be enabled/disabled individually, allowing multiple protocol
decoding capability.

On the other hand, hardware decoders have a limited protocol
support, often being able of decoding just one protocol each time.
So, each type needs a different set of capabilities to control the
supported protocol(s).
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When the remote controller class is anyway being renamed from ir to rc
this would be a good time to also rename the devices from rcrcvX to rcX.

I know we haven't reached any agreement on whether transmission will
eventually be handled by the same device, but this change will at
least make the device name non-receive-specific which will make it
possible in the future (and if a different approach is finally
agreed upon, the device name still works).
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some spinlocks are not properly initialized on ir core:

[  471.714132] BUG: spinlock bad magic on CPU#0, modprobe/1899
[  471.719838]  lock: f92a08ac, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[  471.727301] Pid: 1899, comm: modprobe Not tainted 2.6.33 #36
[  471.733062] Call Trace:
[  471.735537]  [<c1498793>] ? printk+0x1d/0x22
[  471.739866]  [<c12694e3>] spin_bug+0xa3/0xf0
[  471.744224]  [<c126962d>] do_raw_spin_lock+0x7d/0x160
[  471.749364]  [<f92a01ff>] ? ir_rc5_register+0x6f/0xf0 [ir_rc5_decoder]

So, use static initialization for the static spinlocks, instead of the
dynamic ones (currently used), as proposed by David Härdeman on one
of his RFC patches.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The patch that adds the rc-map changes didn't take into account that an
a table with IR_TYPE_UNKNOWN would make change_protocol to return -EINVAL.

As this function is fundamental to initialize some data, including a
callback to the getkey function, this caused the driver to stop working,
hanging the machine most of the times.

The fix were simply to add a handler for the IR type, but, to avoid further
issues, explicitly call change_protocol and handle the error before
initializing the IR. Also, let input_dev to start/stop IR handling,
after the opening of the input device.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Reimplement the RC-5 decoder state machine. Code is now clear, and works
properly. It is also simpler than the previous implementations.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A previous cleanup patch removed more than needed. Re-add the logic that
disable the decoders.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A few hardware Remote Controller decoders, even using a standard protocol,
aren't able to provide the entire scancode. Due to that, the capability
of using other IR's are limited on those hardware.

Adds a way to indicate to ir-core what are the bits that the hardware
provides, from a scancode, allowing the addition of a complete IR table
to the kernel and allowing a limited support for changing the Remote
Controller on those devices.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The keymaps don't need to be recompiled every time a change at ir-core.h
happens, since it only depends on rc-map defines. By moving those
definitions to the proper header, the code became cleaner, and avoids
needing to recompile all the RC maps every time a non-related change
is introduced.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Now that the decoders are state machine, there's no need to create
an ancillary buffer while decoding the protocol. Just call the decoders
code directly, event by event.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

This decoder is also based on a state machine, just like the NEC protocol
decoder. It is pedantic in the sense that accepts only 14 bits. As there
are some variants that outputs less bits, it needs to be improved to also
handle those.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Remove dead code and properly name a few constants
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Thanks to Andy Walls <awalls@md.metrocast.net> for pointing me his
code, that gave me some ideas to better implement it.

After some work with saa7134 bits, I found a way to catch both IRQ
edge pulses. By enabling it, the NEC decoder can now take both
pulse and spaces into account, making it more precise.

Instead of the old strategy of handling the events all at once,
this code implements a state machine. Due to that, it handles
individual pulse or space events, validating them against the
protocol, producing a much more reliable decoding.

With the new implementation, the protocol trailer bits are properly
handled, making possible for the repeat key to work.

Also, the code is now capable of handling both NEC and NEC extended
IR devices. With NEC, it produces a 16 bits code, while with NEC
extended, a 24 bits code is returned.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Converts drivers/media/dvb/ttpci/budget-ci.c to use ir-core rather than
rolling its own keydown timeout handler and reporting keys via
drivers/media/IR/ir-functions.c.

[mchehab@redhat.com: Drop the call to ir_input_init() as it is no longer needed]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Rewrites the keyup/keydown logic in drivers/media/IR/ir-keytable.c.

All knowledge of keystates etc is now internal to ir-keytable.c
and not scattered around ir-raw-event.c and ir-nec-decoder.c (where
it doesn't belong).

In addition, I've changed the API slightly so that ir_input_dev is
passed as the first argument rather than input_dev. If we're ever
going to support multiple keytables we need to move towards making
ir_input_dev the main interface from a driver POV and obscure away
the input_dev as an implementational detail in ir-core.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

The attached patch rewrites much of the keytable code in
drivers/media/IR/ir-keytable.c.

The scancodes are now inserted into the array in sorted
order which allows for a binary search on lookup.

The code has also been shrunk by about 150 lines.

In addition it fixes the following bugs:

Any use of ir_seek_table() was racy.

ir_dev->driver_name is leaked between ir_input_register() and
ir_input_unregister().

ir_setkeycode() unconditionally does clear_bit() on dev->keybit
when removing a mapping, but there might be another mapping with
a different scancode and the same keycode.

This version has been updated to incorporate patch feedback from
Mauro Carvalho Chehab.

[mchehab@redhat.com: Fix a conflict with RC keytable breakup patches and input changes]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The code that enables IRQ for the Remote Controller on saa7134 is a little
messy: it is outside saa7134-input, it checks if RC is GPIO based, and
it mixes both serial raw decode with parallel reads from a hardware-based
IR decoder.

Also, currently, it doesn't allow to trigger both transition edges at GPIO16
and GPIO18 lines. A rework on the code is needed to provide a better way
to specify what saa7134-input needs, maybe even moving part of the code from
saa7134-core and saa7134-cards into saa7134-input.

Yet, as a large rework is happening at RC core, it is better to wait until
the core changes stablize, in order to rework saa7134 RC internals.While
this don't happen, let's just change the logic a little bit to allow
enabling IRQ to be generated on both edge transitions, in order to better
support pulse/space raw decoders.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>