- Set a default timeout (matching mceusb.c) and use
  ir_raw_event_store_with_filter, which leads to better behavior when
  using lirc userspace decoding with this hardware
- Fill in rx_resolution with the value we're using here (50us)
- Wire up input phys and device parent pointer
- Use device_init_wakeup() instead of device_set_wakeup_*()
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Using ir_raw_event_store_with_filter() saves about 20 lines of code.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If an IR command is sent (using the LIRC userspace) to rc-loopback
which doesn't include a trailing space, the result is that the message
won't be completely decoded. In addition, "leftovers" from a previous
transmission can be left until the next one. Fix this by faking a long
silence after the end of TX data.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch adds preliminary IR TX capabilities to the
winbond-cir driver.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Using bool instead of an int helps readability a bit.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Per hardware provided to me, the Formosa Industrial Computing eHome
Infrared Receiver, 0x147a:0xe017, has no tx capability, it is rx only.

Thanks go to Paul Rae for the hardware.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Thanks to some excellent investigative work by Douglas Clowes, it was
uncovered that the older w83667hg Nuvoton chip functions with this
driver after actually enabling the CIR function via its multi-function
chip config register. The CIR and CIR wide-band sensor enable bits are
just in a different place on this hardware, so we only poke register
0x27 on 677 hardware now, and we poke register 0x2c on the 667 now.
Reported-by: NDouglas Clowes <dclowes1@optusnet.com.au>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There are additional chip IDs that report a PNP ID of NTN0530, which we
were refusing to load on. Instead, lets just warn if we encounter an
unknown chip, as there's a chance it will work just fine.

Also, expand the list of known hardware to include both an earlier and a
later generation chip that this driver should function with. Douglas has
an older w83667hg variant, that with a touch more work, will be
supported by this driver, and Lutz has a newer w83677hg variant that
works without any further modifications to the driver.
Reported-by: NDouglas Clowes <dclowes1@optusnet.com.au>
Reported-by: NLutz Sammer <johns98@gmx.net>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Use the newly introduced KEY_IMAGES where appropriate, and standardize
on KEY_MEDIA for media center/application launcher button (such as the
Windows logo key on the Windows Media Center Ed. remotes).
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

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

The following is a patch to avoid a kernel oops when running rmmod
saa7134 on kernel 2.6.27.1. The change is as suggested by mchehab on
irc.freenode.org
Signed-off-by: NHussam Al-Tayeb <ht990332@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The imon_ir_change_protocol function gets called two different ways, one
way is from rc_register_device, for initial protocol selection/setup,
and the other is via a userspace-initiated protocol change request,
either by direct sysfs prodding or by something like ir-keytable.

In the rc_register_device case, the imon context lock is already held,
but when initiated from userspace, it is not, so we must acquire it,
prior to calling send_packet, which requires that the lock is held.

Without this change, there's an easily reproduceable deadlock when
another function calls send_packet (such as either of the display write
fops) after a userspace-initiated change_protocol.

With a lock-debugging-enabled kernel, I was getting this:

[   15.014153] =====================================
[   15.015048] [ BUG: bad unlock balance detected! ]
[   15.015048] -------------------------------------
[   15.015048] ir-keytable/773 is trying to release lock (&ictx->lock) at:
[   15.015048] [<ffffffff814c6297>] mutex_unlock+0xe/0x10
[   15.015048] but there are no more locks to release!
[   15.015048]
[   15.015048] other info that might help us debug this:
[   15.015048] 2 locks held by ir-keytable/773:
[   15.015048]  #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff8119d400>] sysfs_write_file+0x3c/0x144
[   15.015048]  #1:  (s_active#87){.+.+.+}, at: [<ffffffff8119d4ab>] sysfs_write_file+0xe7/0x144
[   15.015048]
[   15.015048] stack backtrace:
[   15.015048] Pid: 773, comm: ir-keytable Not tainted 2.6.38.4-20.fc15.x86_64.debug #1
[   15.015048] Call Trace:
[   15.015048]  [<ffffffff81089715>] ? print_unlock_inbalance_bug+0xca/0xd5
[   15.015048]  [<ffffffff8108b35c>] ? lock_release_non_nested+0xc1/0x263
[   15.015048]  [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[   15.015048]  [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[   15.015048]  [<ffffffff8108b67b>] ? lock_release+0x17d/0x1a4
[   15.015048]  [<ffffffff814c6229>] ? __mutex_unlock_slowpath+0xc5/0x125
[   15.015048]  [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[   15.015048]  [<ffffffffa02964b6>] ? send_packet+0x1c9/0x264 [imon]
[   15.015048]  [<ffffffff8108b376>] ? lock_release_non_nested+0xdb/0x263
[   15.015048]  [<ffffffffa0296731>] ? imon_ir_change_protocol+0x126/0x15e [imon]
[   15.015048]  [<ffffffffa024a334>] ? store_protocols+0x1c3/0x286 [rc_core]
[   15.015048]  [<ffffffff81326e4e>] ? dev_attr_store+0x20/0x22
[   15.015048]  [<ffffffff8119d4cc>] ? sysfs_write_file+0x108/0x144
...

The original report that led to the investigation was the following:

[ 1679.457305] INFO: task LCDd:8460 blocked for more than 120 seconds.
[ 1679.457307] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1679.457309] LCDd            D ffff88010fcd89c8     0  8460      1 0x00000000
[ 1679.457312]  ffff8800d5a03b48 0000000000000082 0000000000000000 ffff8800d5a03fd8
[ 1679.457314]  00000000012dcd30 fffffffffffffffd ffff8800d5a03fd8 ffff88010fcd86f0
[ 1679.457316]  ffff8800d5a03fd8 ffff8800d5a03fd8 ffff88010fcd89d0 ffff8800d5a03fd8
[ 1679.457319] Call Trace:
[ 1679.457324]  [<ffffffff810ff1a5>] ? zone_statistics+0x75/0x90
[ 1679.457327]  [<ffffffff810ea907>] ? get_page_from_freelist+0x3c7/0x820
[ 1679.457330]  [<ffffffff813b0a49>] __mutex_lock_slowpath+0x139/0x320
[ 1679.457335]  [<ffffffff813b0c41>] mutex_lock+0x11/0x30
[ 1679.457338]  [<ffffffffa0d54216>] display_open+0x66/0x130 [imon]
[ 1679.457345]  [<ffffffffa01d06c0>] usb_open+0x180/0x310 [usbcore]
[ 1679.457349]  [<ffffffff81143b3b>] chrdev_open+0x1bb/0x2d0
[ 1679.457350]  [<ffffffff8113d93d>] __dentry_open+0x10d/0x370
[ 1679.457352]  [<ffffffff81143980>] ? chrdev_open+0x0/0x2d0
...

Bump the driver version here so its easier to tell if people have this
locking fix or not, and also make locking during probe easier to follow.

CC: stable@kernel.org
Reported-by: NBenjamin Hodgetts <ben@xnode.org>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

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

Add device ID for a Dell-branded, Philips device ID transceiver reported
by an OpenELEC user on their forums.

http://openelec.tv/forum/27-hardware-support/5622-adding-support-for-an-ir-receiver--dell-branded--#5622Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

Stop including <linux/delay.h> in x86 header files which don't
need it. This will let the compiler complain when this header is
not included by source files when it should, so that
contributors can fix the problem before building on other
architectures starts to fail.

Credits go to Geert for the idea.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: James E.J. Bottomley <James.Bottomley@suse.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
LKML-Reference: <20110325152014.297890ec@endymion.delvare>
[ this also fixes an upstream build bug in drivers/media/rc/ite-cir.c ]
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Fix the following compile failure:

  drivers/media/rc/ite-cir.c: In function 'ite_decode_bytes':
  drivers/media/rc/ite-cir.c:190: error: implicit declaration of function 'generic_find_next_le_bit'
  drivers/media/rc/ite-cir.c:199: error: implicit declaration of function 'generic_find_next_zero_le_bit'

Caused by commit 620a32bb ("[media] rc: New rc-based ite-cir driver
for several ITE CIRs") interacting with commit c4945b9e
("asm-generic: rename generic little-endian bitops functions").
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The Apple and TiVo remotes I've got use an NEC-ish protocol, but rather
than a command/not_command pair, they have what appear to be vendor ID
bytes. This change makes the NEC decoder warn if the command/not_command
checksum fails, but then passes along a full 32-bit scancode for keymap
lookup. This change should make no difference for existing keymaps,
since they simply won't have 32-bit scancodes, but allows for a 32-bit
keymap. At the moment, that'll have to be uploaded by the user, but I've
got Apple and TiVo remote keymaps forthcoming.

In the long run (2.6.40, hopefully), we should probably just always use
all 32 bits for all NEC keymaps, but this should get us by for 2.6.39.

(Note that a few of the TiVo keys actuallly *do* pass the command
checksum, so for now, the keymap for this remote will have to be a mix
of 24-bit and 32-bit scancodes, but so be it).
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

This keymap were used for the Hauppauge Black remote controller
only. It also contains some keycodes not found there. As the
Hauppauge Black is now part of the hauppauge keymap, just remove
it.

Also, remove the modprobe hacks to select between the Gray
and the Black versions of the remote controller as:
 - Both are supported by default by the keymap;
 - If the user just wants one keyboard supported,
   it is just a matter of changing the keymap via
   the userspace tool (ir-keytable), removing
   the keys that he doesn't desire. As ir-keytable
   auto-loads the keys via udev, this is better than
   obscure modprobe parameters.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>

The rc-hauppauge-new map is a messy thing, as it bundles 3

different remote controllers as if they were just one,
discarding the address byte. Also, some key maps are wrong.

With the conversion to the new rc-core, it is likely that
most of the devices won't be working properly, as the i2c
driver and the raw decoders are now providing 16 bits for
the remote, instead of just 8.

 delete mode 100644 drivers/media/rc/keymaps/rc-hauppauge-new.c
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>

There are two "hauppauge-new" keymaps, one with protocol
unknown, and the other with the protocol marked accordingly.
However, both tables are miss-named.

Also, the old rc-hauppauge-new is broken, as it mixes
three different controllers as if they were just one.

This patch solves half of the problem by renaming the
correct keycode table as just rc-hauppauge. This table
contains the codes for the four different types of
remote controllers found on Hauppauge cards, properly
mapped with their different addresses.

 create mode 100644 drivers/media/rc/keymaps/rc-hauppauge.c
 delete mode 100644 drivers/media/rc/keymaps/rc-rc5-hauppauge-new.c
[Jarod: fix up RC_MAP_HAUPPAUGE defines]
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>

The keys for the old black were messed with the ones for the
hauppauge grey. Fix it.

Also, fixes some keycodes and order the keys according with
the way they appear inside the remote controller.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>

Hans borrowed me an old Black Hauppauge RC. Thanks to that, we
can fix the RC5 table for Hauppauge.

Thanks-to: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>

Adds the old grey remote controller to Hauppauge table.

Hans borrowed me an old gray Hauppauge RC. Thanks to that, we
can fix the RC5 table for Hauppauge.

Thanks-to: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>

One of the remotes has a picture available at:
	http://lirc.sourceforge.net/remotes/leadtek/Y04G0004.jpg

As there's one variant with a set direction keys plus vol/chann
keys, and the same table is used for both models, change it to
represent all keys, avoiding the usage of weird function keys.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>

Using xev and testing the "Windows" key on a normal keyboard, it
is mapped as KEY_LEFTMETA. So, as this is the standard code for
it, use it, instead of a generic, meaningless KEY_PROG1.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>

Those KEY_PROG[n] keys were used on places where the developer
didn't know for sure what key should be used. On several cases,
using KEY_RED, KEY_GREEN, KEY_YELLOW would be enough. On others,
there are specific keys for that already.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>

Each keyboard map were using a different definition for
the Source/Video Source key.
Behold Columbus were the only one using KEY_PROPS.

As we want to standardize those keys at X11 and at
userspace applications, we need to use just one code
for it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>

On a few places, KEY_MHP were used for snapshots. However, KEY_CAMERA
is used for it on all the other keyboards that have a snapshot/Picture
button.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>

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

Cc: Juan J. Garcia de Soria <skandalfo@gmail.com>
Cc: Stephan Raue <stephan@openelec.tv>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is a second version of an rc-core based driver for the ITE Tech IT8712F
CIR and now for a pair of other variants of the IT8512 CIR too.

This driver should replace the lirc_it87 and lirc_ite8709 currently living in
the LIRC staging directory.

The driver should support the ITE8704, ITE8713, ITE8708 and ITE8709 (this last
one yet untested) PNP ID's.

The code doesn'te reuse code from the pre-existing LIRC drivers, but has been
written from scratch using the nuvoton.cir driver as a skeleton.

This new driver shouldn't exhibit timing problems when running under load (or
with interrupts disabled for relatively long times). It works OOTB with the
RC6 MCE remote bundled with the ASUS EEEBox. TX support is implemented, but
I'm unable to test it since my hardware lacks TX capability.
Signed-off-by: NJuan J. Garcia de Soria <skandalfo@gmail.com>
Tested-by: NStephan Raue <stephan@openelec.tv>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

These bubble button remote controls appear to be generic from China.

These are the three variants known to be supplied with DM04/QQBOX DVB-S

They could well be supplied with other devices from the region.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Remote used for TerraTec Cinergy T Stick RC.
Keytable from Martin Groszhauser <mgroszhauser@gmail.com>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Cc: Martin Groszhauser <mgroszhauser@gmail.com>
Cc: TerraTux <TerraTux@terratec.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch is adding support for Technisat's new USB2.0 DVB-S/S2 receiver
device. The development was sponsored by Technisat.

The Green led is toggle depending on the frontend-state. The Red LED is turned
on all the time.

The MAC address reading from the EEPROM along with the
LRC-method to check whether its valid.

Support for the IR-receiver of the Technisat USB2 box. The keys of
small, black remote-control are built-in, repeated key behaviour are
simulated.

The i2c-mutex of the dvb-usb-structure is used as a general mutex for
USB requests, as there are 3 threads racing for atomic requests
consisting of multiple usb-requests.

A module option is there which disables the toggling of LEDs by the
driver on certain triggers. Useful when being used in a "dark"
environment.

[mchehab@redhat.com: Fix merge conflicts with RC renaming patches]
Signed-off-by: NMartin Wilks <m.wilks@technisat.com>
Signed-off-by: NPatrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There's a Realtek combo card reader and IR receiver device with multiple
usb interfaces on it. The mceusb driver is incorrectly grabbing all of
them. This change should make it bind to only interface 2 (patch based
on lsusb output on the linux-media list from Lucian Muresan).

Tested regression-free with the six mceusb devices I have myself.
Reported-by: NPatrick Boettcher <pboettcher@kernellabs.com>
Reported-by: NLucian Muresan <lucianm@users.sourceforge.net>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>