linux-toradex.git/drivers/media/rc, branch v3.0.47

media: rc: ite-cir: Initialise ite_dev::rdev earlier

2012-10-12T20:28:02+00:00

commit 4b961180ef275035b1538317ffd0e21e80e63e77 upstream.

ite_dev::rdev is currently initialised in ite_probe() after
rc_register_device() returns.  If a newly registered device is opened
quickly enough, we may enable interrupts and try to use ite_dev::rdev
before it has been initialised.  Move it up to the earliest point we
can, right after calling rc_allocate_device().

Reported-and-tested-by: YunQiang Su 

Signed-off-by: Ben Hutchings 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: Avoid sysfs oops when an rc_dev's raw device is absent

2012-10-02T16:47:52+00:00

commit 720bb6436ff30fccad05cf5bdf961ea5b1f5686d upstream.

For some reason, when the lirc daemon learns that a usb remote control
has been unplugged, it wants to read the sysfs attributes of the
disappearing device. This is useful for uncovering transient
inconsistencies, but less so for keeping the system running when such
inconsistencies exist.

Under some circumstances (like every time I unplug my dvb stick from
my laptop), lirc catches an rc_dev whose raw event handler has been
removed (presumably by ir_raw_event_unregister), and proceeds to
interrogate the raw protocols supported by the NULL pointer.

This patch avoids the NULL dereference, and ignores the issue of how
this state of affairs came about in the first place.

Version 2 incorporates changes recommended by Mauro Carvalho Chehab
(-ENODEV instead of -EINVAL, and a signed-off-by).

Signed-off-by: Douglas Bagnall 
Signed-off-by: Mauro Carvalho Chehab 
Cc: Herton Ronaldo Krzesinski 
Signed-off-by: Greg Kroah-Hartman

media: rc: Postpone ISR registration

2012-05-21T16:40:01+00:00

commit 9ef449c6b31bb6a8e6dedc24de475a3b8c79be20 upstream.

An early registration of an ISR was causing a crash to several users (for
example, with the ite-cir driver: http://bugs.launchpad.net/bugs/972723).
The reason was that IRQs were being triggered before a driver
initialisation was completed.

This patch fixes this by moving the invocation to request_irq() and to
request_region() to a later stage on the driver probe function.

Signed-off-by: Luis Henriques 
Acked-by: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: rc-core: set mode for winbond-cir

2012-04-27T16:51:06+00:00

commit d9b786955f80fb306471fdb9ea24c6d03af6ca36 upstream.

Setting the correct mode is required by rc-core or scancodes won't be
generated (which isn't very user-friendly).

This one-line fix should be suitable for 3.4-rc2.

Signed-off-by: David Härdeman 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

nuvoton-cir: simplify raw IR sample handling

2011-10-03T18:40:15+00:00

commit de4ed0c111ed078b8729a5cc49c23197740f5bad upstream.

The nuvoton-cir driver was storing up consecutive pulse-pulse and
space-space samples internally, for no good reason, since
ir_raw_event_store_with_filter() already merges back to back like
samples types for us. This should also fix a regression introduced late
in 3.0 that related to a timeout change, which actually becomes correct
when coupled with this change. Tested with RC6 and RC5 on my own
nuvoton-cir hardware atop vanilla 3.0.0, after verifying quirky
behavior in 3.0 due to the timeout change.

Reported-by: Stephan Raue 
CC: Stephan Raue 
Signed-off-by: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

[media] nuvoton-cir: make idle timeout more sane

2011-07-11T23:52:37+00:00

The nuvoton-cir inherited an insanely low idle timeout value from the
mceusb driver. We're fixing mceusb, should fix this driver too.

Signed-off-by: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab

[media] mceusb: increase default timeout to 100ms

2011-07-11T23:52:27+00:00

This matches the typical timeout advertised by hardware, once we're
actually interpreting it correctly.

Signed-off-by: Rafi Rubin 
Signed-off-by: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab

[media] mceusb: Timeout unit corrections

2011-07-11T23:52:18+00:00

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: Rafi Rubin 
Signed-off-by: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab

[media] rc: call input_sync after scancode reports

2011-07-01T19:34:45+00:00

Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only
becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If
we get a repeat or a scancode we don't have a mapping for, we never call
input_sync, and thus those events don't get reported in a timely
fashion.

For example, take an mceusb transceiver with a default rc6 keymap. Press
buttons on an rc5 remote while monitoring with ir-keytable, and you'll
see nothing. Now press a button on the rc6 remote matching the keymap.
You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6
key spit out all at the same time.

Pressing and holding a button on a remote we do have a keymap for also
works rather unreliably right now, due to repeat events also happening
without a call to input_sync (we bail from ir_do_keydown before getting
to the point where it calls input_sync).

Easy fix though, just add two strategically placed input_sync calls
right after our input_event calls for EV_MSC, and all is well again.
Technically, we probably should have been doing this all along, its just
that it never caused any functional difference until the referenced
change went into the input layer.

input_sync once per IR signal. There was another hidden bug in the code
where we were calling input_report_key using last_keycode instead of our
just discovered keycode, which manifested with the reordering of calling
input_report_key and setting last_keycode.

Reported-by: Stephan Raue 
CC: Stephan Raue 
CC: Mauro Carvalho Chehab 
CC: Jeff Brown 
Acked-by: Dmitry Torokhov 
Signed-off-by: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab

[media] imon: allow either proto on unknown 0xffdc

2011-07-01T19:34:01+00:00

While 0xffdc devices have their IR protocol hard-coded into the firmware
of the device, we have no known way of telling what it is if we don't
have the device's config byte already in the driver. Unknown devices
default to the imon native protocol, but might actually be rc6, so we
should set the driver up such that the user can load the rc6 keytable
from userspace and still have a working device ahead of its config byte
being added to the driver.

Signed-off-by: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab