A number of recent bug reports involve usb_submit_urb() failing which was
only reported with debug parameter on. In addition, remove custom debug
function.

[m.chehab@samsung.com: patch rebased, as one of the patches on this
 series need changes]
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Add usb id of Hauppauge WinTV-HVR-930C HD to mceusb RC driver.
This device has no IR transmitter (according to eeprom content decoded
by tveeprom).
Set the rc mapping to Hauppauge, every key of the deliviered remote
control works correctly.

[m.chehab@samsung.com: fix merge conflicts and unmangled whitespace]
Signed-off-by: NMatthias Schwarzott <zzam@gentoo.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Fix mceusb_cmdsize() which returns incorrect datasize=0 for
sub-commands MCE_RSP_GETPORTSTATUS, MCE_RSP_GETWAKESOURCE,
MCE_RSP_EQDEVDETAILS, MCE_RSP_EQEMVER, and MCE_RSP_EQIRNUMPORTS.

While here, change mceusb_cmdsize() name to reflect that it returns
data size not cmd size.
Signed-off-by: NWilliam Steidtmann <billstei@hbci.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Smatch complains that "cmdbuf[cmdcount - length]" might go past the end
of the array.  It's an easy warning to silence by moving the limit
check earlier.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This transceiver expects the set IR TX ports and IR data as seperate
packets, like the Windows driver does. Remove unnecessary kzalloc.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The GET_REVISION command puts the device in an unresponsive state,
although it continues to report any IR activity. Note that GET_REVISION
command is not documented, nor is any possible response to it parsed.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The RC_TYPE_* defines are currently used both where a single protocol is
expected and where a bitmap of protocols is expected.

Functions like rc_keydown() and functions which add/remove entries to the
keytable want a single protocol. Future userspace APIs would also
benefit from numeric protocols (rather than bitmap ones). Keytables are
smaller if they can use a small(ish) integer rather than a bitmap.

Other functions or struct members (e.g. allowed_protos,
enabled_protocols, etc) accept multiple protocols and need a bitmap.

Using different types reduces the risk of programmer error. Using a
protocol enum whereever possible also makes for a more future-proof
user-space API as we don't need to worry about a sufficient number of
bits being available (e.g. in structs used for ioctl() calls).

The use of both a number and a corresponding bit is dalso one in e.g.
the input subsystem as well (see all the references to set/clear bit when
changing keytables for example).

This patch separate the different usages in preparation for
upcoming patches.

Where a single protocol is expected, enum rc_type is used; where one or more
protocol(s) are expected, something like u64 is used.

The patch has been rewritten so that the format of the sysfs "protocols"
file is no longer altered (at the loss of some detail). The file itself
should probably be deprecated in the future though.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Cc: Andy Walls <awalls@md.metrocast.net>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Antti Palosaari <crope@iki.fi>
Cc: Mike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
dealing with unsigned dividends.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Tested-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The lirc TX functionality expects the process which writes (TX) data to
the lirc dev to sleep until the actual data has been transmitted by the
hardware.

Since the same timeout calculation is duplicated in more than one driver
(and would have to be duplicated in even more drivers as they gain TX
support), it makes sense to move this timeout calculation to the lirc
layer instead.

At the same time, centralize some of the sanity checks.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Cc: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The TechnoTrend USB IR Receiver sends 125 ISO URBs per second, even when
there is no IR activity. Reduce the number of wake ups from the other
drivers too.

This saves about 0.25ms/s on a 2.4GHz Core 2 according to powertop.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NSean Young <sean@mess.org>
Cc: Jarod Wilson <jarod@wilsonet.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add USB identifiers for MCE compatible I/R transceivers from Twisted Melon.
Signed-off-by: NMark Lord <mlord@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Drivers that refer to a __devexit function in an operations
structure need to annotate that pointer with __devexit_p so
replace it with a NULL pointer when the section gets discarded.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

media_build/v4l/drxk_hard.c: In function 'DownloadMicrocode':
media_build/v4l/drxk_hard.c:1388:6: warning: variable 'BlockCRC' set but not used [-Wunused-but-set-variable]
media_build/v4l/drxk_hard.c:1384:6: warning: variable 'Drain' set but not used [-Wunused-but-set-variable]
media_build/v4l/drxk_hard.c:1383:6: warning: variable 'Flags' set but not used [-Wunused-but-set-variable]
media_build/v4l/lmedm04.c: In function 'lme2510_probe':
media_build/v4l/lmedm04.c:1208:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
media_build/v4l/hopper_cards.c: In function 'hopper_irq_handler':
media_build/v4l/hopper_cards.c:68:26: warning: variable 'lstat' set but not used [-Wunused-but-set-variable]
media_build/v4l/mantis_cards.c: In function 'mantis_irq_handler':
media_build/v4l/mantis_cards.c:76:26: warning: variable 'lstat' set but not used [-Wunused-but-set-variable]
media_build/v4l/mantis_dma.c: In function 'mantis_dma_stop':
media_build/v4l/mantis_dma.c:202:16: warning: variable 'mask' set but not used [-Wunused-but-set-variable]
media_build/v4l/mantis_dma.c:202:6: warning: variable 'stat' set but not used [-Wunused-but-set-variable]
media_build/v4l/mantis_evm.c: In function 'mantis_hifevm_work':
media_build/v4l/mantis_evm.c:44:17: warning: variable 'gpif_mask' set but not used [-Wunused-but-set-variable]
media_build/v4l/stb0899_drv.c: In function 'stb0899_init_calc':
media_build/v4l/stb0899_drv.c:640:5: warning: variable 'agc1cn' set but not used [-Wunused-but-set-variable]
media_build/v4l/stb0899_drv.c: In function 'stb0899_diseqc_init':
media_build/v4l/stb0899_drv.c:830:13: warning: variable 'f22_rx' set but not used [-Wunused-but-set-variable]
media_build/v4l/stb0899_drv.c:826:31: warning: variable 'tx_data' set but not used [-Wunused-but-set-variable]
media_build/v4l/stv0900_sw.c: In function 'stv0900_track_optimization':
media_build/v4l/stv0900_sw.c:838:26: warning: variable 'rolloff' set but not used [-Wunused-but-set-variable]
media_build/v4l/ir-sanyo-decoder.c: In function 'ir_sanyo_decode':
media_build/v4l/ir-sanyo-decoder.c:59:14: warning: variable 'not_address' set but not used [-Wunused-but-set-variable]
media_build/v4l/mceusb.c: In function 'mceusb_dev_printdata':
media_build/v4l/mceusb.c:523:46: warning: variable 'data5' set but not used [-Wunused-but-set-variable]
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Yet another device ID that has started showing up in the wild.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

module_param(bool) used to counter-intuitively take an int.  In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option.  For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This converts the drivers in drivers/media/* to use the
module_usb_driver() macro which makes the code smaller and a bit
simpler.

Added bonus is that it removes some unneeded kernel log messages about
drivers loading and/or unloading.

Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Luca Risolia <luca.risolia@studio.unibo.it>
Cc: Jean-Francois Moine <moinejf@free.fr>
Cc: Frank Zago <frank@zago.net>
Cc: Olivier Lorin <o.lorin@laposte.net>
Cc: Erik Andren <erik.andren@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Brian Johnson <brijohn@gmail.com>
Cc: Leandro Costantino <lcostantino@gmail.com>
Cc: Antoine Jacquet <royale@zerezo.com>
Cc: Jarod Wilson <jarod@redhat.com>
Cc: Florian Mickler <florian@mickler.org>
Cc: Antti Palosaari <crope@iki.fi>
Cc: Michael Krufky <mkrufky@kernellabs.com>
Cc: "David Härdeman" <david@hardeman.nu>
Cc: Florent Audebert <florent.audebert@anevia.com>
Cc: Sam Doshi <sam@metal-fish.co.uk>
Cc: Manu Abraham <manu@linuxtv.org>
Cc: Olivier Grenie <olivier.grenie@dibcom.fr>
Cc: Patrick Boettcher <patrick.boettcher@dibcom.fr>
Cc: "Igor M. Liplianin" <liplianin@me.by>
Cc: Derek Kelly <user.vdr@gmail.com>
Cc: Malcolm Priestley <tvboxspy@gmail.com>
Cc: Steven Toth <stoth@kernellabs.com>
Cc: "André Weidemann" <Andre.Weidemann@web.de>
Cc: Martin Wilks <m.wilks@technisat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Jose Alberto Reguero <jareguero@telefonica.net>
Cc: David Henningsson <david.henningsson@canonical.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Joe Perches <joe@perches.com>
Cc: Jesper Juhl <jj@chaosbits.net>
Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
Cc: Anssi Hannula <anssi.hannula@iki.fi>
Cc: Rafi Rubin <rafi@seas.upenn.edu>
Cc: Dan Carpenter <error27@gmail.com>
Cc: Paul Bender <pebender@gmail.com>
Cc: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: "Márcio A Alves" <froooozen@gmail.com>
Cc: Julia Lawall <julia@diku.dk>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Chris Rankin <rankincj@yahoo.com>
Cc: Lee Jones <lee.jones@canonical.com>
Cc: Andy Walls <awalls@md.metrocast.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Dean Anderson <linux-dev@sensoray.com>
Cc: Pete Eberlein <pete@sensoray.com>
Cc: Arvydas Sidorenko <asido4@gmail.com>
Cc: Andrea Anacleto <andreaanacleto@libero.it>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add note about recent updates coming from Microsoft's publicly available
specs on Windows Media Center remotes and receivers/transmitters.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Rather than dumping out hex values, lets print the actual calculated
frequency and period the hardware has been configured for. After this

[ 2643.276215] mceusb 3-1:1.0: tx data: 9f 07 (length=2)
[ 2643.276218] mceusb 3-1:1.0: Get carrier mode and freq
[ 2643.277206] mceusb 3-1:1.0: rx data: 9f 06 01 42 (length=4)
[ 2643.277209] mceusb 3-1:1.0: Got carrier of 37037 Hz (period 27us)

Matches up perfectly with the table in Microsoft's docs.

Of course, I've noticed on one of my devices that the MS-recommended
default value of 1 for carrier pre-scaler and 66 for carrier period was
butchered, and instead of converting 66 to hex (0x42 like above), they
put in 0x66, so the hardware reports a default carrier of 24390Hz.
Fortunately, I guess, this particular device is rx-only, but I wouldn't
put it past other hw to screw up here too.
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>

According to the specs, you can read the number of tx ports, number of
rx sensors, which tx ports have cables plugged into them, and which rx
sensors are active. In practice, most of my devices do seem to report
sane values for tx ports and rx sensors (but not all -- one without any
tx ports reports having them), and most report the active sensor
correctly, but only one of eight reports cabled tx ports correctly. So
for the most part, this is just for informational purposes.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Supposedly, there are essentially three different classes of devices
that are compatible with Microsoft's specs. First are the "legacy"
devices, which are built using Microsoft-provided hardware specs and
firmware. Second are "emulator" devices, which are built using custom
hardware and firmware, written to emulate Microsoft's firmware. Third
are "port" devices, which have their own device driver and firmware,
which provides compatible data to higher levels of the stack.

>From what I can tell, things like nuvoton-cir and fintek-cir are
essentially "port" devices -- their raw IR buffer format is very similar
to that of the mceusb devices. Now, within the mceusb driver, we have
three different "generations", which at first, seemed like maybe they
mapped to emulator versions. Unfortuantely, every single device I have
responds "illegal command" to the query to get firmware emulator version
from the hardware, which means they're either all emulator version 1, or
they're legacy devices, and our different "generations" aren't at all
related here. Though in theory, its possible the gen1 devices are
"legacy" devices and the rest are emulator v1. There are some useful
features of the v2 interface I was hoping to play with, but alas...
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

According to MS docs, the device firmware may halt after receiving an
unknown instruction, but that it should be possible to tell the firmware
to continue running by simply sending a device resume command. So lets
do that.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Its not uncommon for folks to force these bits enabled, because people
do want to wake their htpc kit via their remote. Lets just set the bits
for 'em.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Sometimes the init routine is blasting commands out to the hardware
faster than it can reply. Throw a brief delay in there to give the
hardware a chance to reply before we send the next command.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

I was recently pointed to the document titled
Windows-Media-Center-RC-IR-Collection-Green-Button-Specification-03-08-2011-V2.pdf
which as of this writing, is publicly available from
download.microsoft.com. It covers a LOT of the gaps in the mceusb
driver, which to this point, was written almost entirely by
reverse-engineering. First up, I'm updating the defines for all the MCE
commands and responses to match their names in the spec. More to come...
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Durations can never be negative, so it makes sense to consistently use
unsigned int for LIRC transmission. Contrary to the initial impression,
this shouldn't actually change the userspace API.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This matches the typical timeout advertised by hardware, once we're
actually interpreting it correctly.
Signed-off-by: NRafi Rubin <rafi@seas.upenn.edu>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Unit missmatch in mceusb_handle_command.  It should be converting to us,
not 1/10th of ms.

mceusb_dev_printdata 100us/ms -> 1000us/ms

Alter format of fix slightly and update comment to match proper reality.
Signed-off-by: NRafi Rubin <rafi@seas.upenn.edu>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Hans Petter Selasky pointed out to me that we're leaking urbs when
mce_async_out is called. Its used both for configuring the hardware and
for transmitting IR data. In the tx case, mce_request_packet actually
allocates both a urb and the transfer buffer, neither of which was being
torn down. Do that in the tx callback.

CC: Hans Petter Selasky <hselasky@c2i.net>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Aside from the initial "hey, lets make sure we've flushed any
pre-existing data on the device" call to mce_sync_in, every other one of
the calls was entirely superfluous. Ergo, remove them all, and rename
the one and only (questionably) useful one to reflect what it really
does. Verified on both gen2 and gen3 hardware to make zero difference.
Well, except that you no longer get a bunch of urb submit failures from
the unneeded mce_sync_in calls. Oh. And move that flush to a point
*after* we've wired up the inbound urb, or it won't do squat. I have
half a mind to just remove it entirely, but someone thought it was
necessary at some point, and it doesn't seem to hurt, so lets leave it
for the time being.

This excercise took place due to insightful questions asked by Hans
Petter Selasky, about the possible reuse of the inbound urb before it
was actually availble by mce_sync_in, so thanks to him for motivating
this cleanup.
Reported-by: NHans Petter Selasky <hselasky@c2i.net>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There's an SMK-device-id remote kit from I-O Data avaiable primarily in
Japan, which appears to have no tx hardware, but has rx functionality
that works with the mceusb driver by simply adding its device ID.
Reported-by: NJeremy Kwok <jeremykwok@desu.ca>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Using dev_dbg is more complexity than many users are able to deal with.
Make it easier to get debug spew feedback from them by adding an mce_dbg
printk macro that spews using dev_info when debug=1 is set for the
mceusb module.
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>

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>

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>

Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@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>