linux-toradex.git/drivers/media/rc/ir-rc5-decoder.c, branch v4.9.97

[media] Fix RC5 decoding with Fintek CIR chipset

2016-07-09T14:47:28+00:00

Fix RC5 decoding with Fintek CIR chipset

Commit e87b540be2dd02552fb9244d50ae8b4e4619a34b tightened up the RC5
decoding by adding a check for trailing silence to ensure a valid RC5
command had been received. Unfortunately the trailer length checked was
10 units and the Fintek CIR device does not want to provide details of a
space longer than 6350us. This meant that RC5 remotes working on a
Fintek setup on 3.16 failed on 3.17 and later. Fix this by shortening
the trailer check to 6 units (allowing for a previous space in the
received remote command).

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117221

Signed-off-by: Jonathan McDowell 
Cc: stable@vger.kernel.org
Signed-off-by: David Härdeman 
Signed-off-by: Mauro Carvalho Chehab

[media] media: rc: move check whether a protocol is enabled to the core

2015-11-19T13:39:17+00:00

Checking whether a protocol is enabled and calling the related decoder
functions should be done by the rc core, not the protocol handlers.

Properly handle lirc considering that no protocol bit is set for lirc.

Signed-off-by: Heiner Kallweit 
Signed-off-by: Mauro Carvalho Chehab

Revert "[media] rc: ir-rc5-decoder: Add encode capability"

2015-08-19T10:03:09+00:00

This reverts commit a0466f15b4654cf1ac9e387d7c1a401eff494b4f.

The current code is not mature enough, the API should allow a single
protocol to be specified. Also, the current code contains heuristics
that will depend on module load order.

Signed-off-by: David Härdeman 
Acked-by: Antti Seppälä 
Signed-off-by: Mauro Carvalho Chehab

[media] rc: ir-rc5-decoder: Add encode capability

2015-05-14T17:32:04+00:00

Add the capability to encode RC-5, RC-5X and RC-5-SZ scancodes as raw
events. The protocol is chosen based on the specified protocol mask,
and whether all the required bits are set in the scancode mask, and
none of the unused bits are set in the scancode data. For example a
scancode filter with bit 16 set in both data and mask is unambiguously
RC-5X.

The Manchester modulation helper is used, and for RC-5X it is used twice
with two sets of timings, the first with a short trailer space for the
space in the middle, and the second with no leader so that it can
continue the space.

The encoding in RC-5-SZ first inserts a pulse and then simply utilizes
the generic Manchester encoder available in rc-core.

Signed-off-by: James Hogan 
Signed-off-by: Antti Seppälä 
Cc: David Härdeman 
Signed-off-by: Mauro Carvalho Chehab

[media] rc5-decoder: BZ#85721: Fix RC5-SZ decoding

2014-10-30T11:09:28+00:00

Changeset e87b540be2dd broke RC5-SZ decoding, as it forgot to add
the extra bit check for the enabled protocols at the beginning of
the logic.

Signed-off-by: Mauro Carvalho Chehab 
Acked-by: David Härdeman 
Signed-off-by: Mauro Carvalho Chehab

[media] ir-rc5-decoder: print where decoding fails

2014-07-30T18:49:35+00:00

The IR dprintk message that prints a RC5 decoding failure
is not much helpful, as it doesn't tell on what bit the
error occurred.

Add such information, in order to make the debug message
more useful.

Signed-off-by: Mauro Carvalho Chehab

[media] rc-core: merge rc5 and streamzap decoders

2014-07-25T22:10:44+00:00

Now that the protocol is part of the scancode, it is pretty easy to merge
the rc5 and streamzap decoders. An additional advantage is that the decoder
is now stricter as it waits for the trailing silence before determining that
a command is a valid rc5/streamzap command (which avoids collisions that I've
seen with e.g. Sony protocols).

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

[media] rc-core: remove protocol arrays

2014-07-25T22:10:43+00:00

The basic API of rc-core used to be:

	dev = rc_allocate_device();
	dev->x = a;
	dev->y = b;
	dev->z = c;
	rc_register_device();

which is a pretty common pattern in the kernel, after the introduction of
protocol arrays the API looks something like:

	dev = rc_allocate_device();
	dev->x = a;
	rc_set_allowed_protocols(dev, RC_BIT_X);
	dev->z = c;
	rc_register_device();

There's no real need for the protocols to be an array, so change it
back to be consistent (and in preparation for the following patches).

[m.chehab@samsung.com: added missing changes at some files]
Signed-off-by: David Härdeman 
Signed-off-by: Mauro Carvalho Chehab

[media] rc-core: document the protocol type

2014-07-24T00:50:48+00:00

Right now the protocol information is not preserved, rc-core gets handed a
scancode but has no idea which protocol it corresponds to.

This patch (which required reading through the source/keymap for all drivers,
not fun) makes the protocol information explicit which is important
documentation and makes it easier to e.g. support multiple protocols with one
decoder (think rc5 and rc-streamzap). The information isn't used yet so there
should be no functional changes.

[m.chehab@samsung.com: rebased, added cxusb and removed bad whitespacing]
Signed-off-by: David Härdeman 
Signed-off-by: Mauro Carvalho Chehab

[media] rc: abstract access to allowed/enabled protocols

2014-03-11T16:24:39+00:00

The allowed and enabled protocol masks need to be expanded to be per
filter type in order to support wakeup filter protocol selection. To
ease that process abstract access to the rc_dev::allowed_protos and
rc_dev::enabled_protocols members with inline functions.

Signed-off-by: James Hogan 
Reviewed-by: Antti Seppälä 
Signed-off-by: Mauro Carvalho Chehab