summaryrefslogtreecommitdiffstats
path: root/drivers/media/rc/ir-sharp-decoder.c
Commit message (Collapse)AuthorAgeFilesLines
* [media] media: rc: move check whether a protocol is enabled to the coreHeiner Kallweit2015-11-191-3/+0Star
| | | | | | | | | | 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 <hkallweit1@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
* [media] media: rc: ir-sharp-decoder: add support for Denon variant of the ↵Heiner Kallweit2015-11-191-1/+3
| | | | | | | | | | | | | | protocol Denon also uses the Sharp protocol, however with different check bits. It would have been also possible to add this as a separate protocol but this may not be worth the effort. Successfully tested with a Denon RC-1002 remote control. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
* [media] rc-core: remove protocol arraysDavid Härdeman2014-07-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] rc-core: document the protocol typeDavid Härdeman2014-07-241-1/+1
| | | | | | | | | | | | | | | 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 <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] rc: abstract access to allowed/enabled protocolsJames Hogan2014-03-111-1/+1
| | | | | | | | | | | 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 <james.hogan@imgtec.com> Reviewed-by: Antti Seppälä <a.seppala@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media, edac] Change my email addressMauro Carvalho Chehab2014-02-071-1/+1
| | | | | | | | There are several left overs with my old email address. Remove their occurrences and add myself at CREDITS, to allow people to be able to reach me on my new addresses. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] media: rc: add raw decoder for Sharp protocolJames Hogan2014-02-041-0/+200
Add a raw decoder for the Sharp protocol. It uses a pulse distance modulation with a pulse of 320us and a bit period of 2ms for a logical 1 and 1ms for a logical 0. The first part of the message consists of a 5-bit address, an 8-bit command, and two other bits, followed by a 40ms gap before the echo message which is an inverted version of the main message except for the address bits. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com> Cc: linux-media@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>