media: rc-core: rename ir_raw_event_reset to ir_raw_event_overflow

The driver report a reset event when the hardware reports and overflow.
There is no reason to have a generic "reset" event.

Signed

media: rc-core: rename ir_raw_event_reset to ir_raw_event_overflow

The driver report a reset event when the hardware reports and overflow.
There is no reason to have a generic "reset" event.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...

media: rc: harmonize infrared durations to microseconds

rc-core kapi uses nanoseconds for infrared durations for receiving, and
microseconds for sending. The uapi already uses microseconds for both,

media: rc: harmonize infrared durations to microseconds

rc-core kapi uses nanoseconds for infrared durations for receiving, and
microseconds for sending. The uapi already uses microseconds for both,
so this patch does not change the uapi.

Infrared durations do not need nanosecond resolution. IR protocols do not
have durations shorter than about 100 microseconds. Some IR hardware offers
250 microseconds resolution, which is sufficient for most protocols.
Better hardware has 50 microsecond resolution and is enough for every
protocol I am aware off.

Unify on microseconds everywhere. This simplifies the code since less
conversion between microseconds and nanoseconds needs to be done.

This affects:
- rx_resolution member of struct rc_dev
- timeout member of struct rc_dev
- duration member in struct ir_raw_event

Cc: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Patrick Lerda <patrick9876@free.fr>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: "David Härdeman" <david@hardeman.nu>
Cc: Benjamin Valentin <benpicco@googlemail.com>
Cc: Antti Palosaari <crope@iki.fi>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...

media: rc: set timeout to smallest value required by enabled protocols

The longer the IR timeout, the longer the rc device waits until delivering
the trailing space. So, by reducing this timeout, we

media: rc: set timeout to smallest value required by enabled protocols

The longer the IR timeout, the longer the rc device waits until delivering
the trailing space. So, by reducing this timeout, we reduce the delay for
the last scancode to be delivered.

Note that the lirc daemon disables all protocols, in which case we revert
back to the default value.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

show more ...

media: rc: replace IR_dprintk() with dev_dbg in IR decoders

Use dev_dbg() rather than custom debug function.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@

media: rc: replace IR_dprintk() with dev_dbg in IR decoders

Use dev_dbg() rather than custom debug function.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

show more ...

media: lirc: use the correct carrier for scancode transmit

If the lirc device supports it, set the carrier for the protocol.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho

media: lirc: use the correct carrier for scancode transmit

If the lirc device supports it, set the carrier for the protocol.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

show more ...

media: rc: add SPDX identifiers to the code I wrote

As we're now using SPDX identifiers, on the several
media drivers I wrote, add the proper SPDX, identifying
the license I meant.

As we're now usi

media: rc: add SPDX identifiers to the code I wrote

As we're now using SPDX identifiers, on the several
media drivers I wrote, add the proper SPDX, identifying
the license I meant.

As we're now using the short license, it doesn't make sense to
keep the original license text.

Also, fix MODULE_LICENSE to properly identify GPL v2.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

show more ...

media: ir-nec-decoder: fix kernel-doc parameters

Some parameters aren't correctly identified, as noticed by
those warnings:
drivers/media/rc/ir-nec-decoder.c:49: warning: No description found for p

media: ir-nec-decoder: fix kernel-doc parameters

Some parameters aren't correctly identified, as noticed by
those warnings:
drivers/media/rc/ir-nec-decoder.c:49: warning: No description found for parameter 'ev'
drivers/media/rc/ir-nec-decoder.c:49: warning: Excess function parameter 'duration' description in 'ir_nec_decode'
drivers/media/rc/ir-nec-decoder.c:189: warning: Excess function parameter 'raw' description in 'ir_nec_scancode_to_raw'

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

show more ...

media: rc: nec decoder should not send both repeat and keycode

When receiving an nec repeat, rc_repeat() is called and then rc_keydown()
with the last decoded scancode. That last call is redundant.

media: rc: nec decoder should not send both repeat and keycode

When receiving an nec repeat, rc_repeat() is called and then rc_keydown()
with the last decoded scancode. That last call is redundant.

Fixes: 265a2988d202 ("media: rc-core: consistent use of rc_repeat()")

Cc: <stable@vger.kernel.org> # v4.14
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

show more ...

media: rc: rename RC_TYPE_* to RC_PROTO_* and RC_BIT_* to RC_PROTO_BIT_*

RC_TYPE is confusing and it's just the protocol. So rename it.

Suggested-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-of

media: rc: rename RC_TYPE_* to RC_PROTO_* and RC_BIT_* to RC_PROTO_BIT_*

RC_TYPE is confusing and it's just the protocol. So rename it.

Suggested-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Sean Young <sean@mess.org>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

show more ...

media: rc: ir-nec-decoder: move scancode composing code into a shared function

The NEC scancode composing and protocol type detection in
ir_nec_decode() is generic enough to be a shared function. L

media: rc: ir-nec-decoder: move scancode composing code into a shared function

The NEC scancode composing and protocol type detection in
ir_nec_decode() is generic enough to be a shared function. Let's create
an inline function in rc-core.h, so that other remote control drivers
can reuse this function to save some code.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

show more ...

media: rc-core: consistent use of rc_repeat()

The NEC decoder and the Sanyo decoders check if dev->keypressed is true
before calling rc_repeat (without holding dev->keylock).

Meanwhile, the XMP and

media: rc-core: consistent use of rc_repeat()

The NEC decoder and the Sanyo decoders check if dev->keypressed is true
before calling rc_repeat (without holding dev->keylock).

Meanwhile, the XMP and JVC decoders do no such checks.

This patch makes sure all users of rc_repeat() do so consistently by
removing extra checks in NEC/Sanyo and modifying the check a bit in
rc_repeat() so that no input event is generated if the key isn't pressed.

Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

show more ...

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

Add the capability to encode NEC scancodes as raw events. The
scancode_to_raw is pretty much taken from the img-ir NEC filter()
callback, and modula

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

Add the capability to encode NEC scancodes as raw events. The
scancode_to_raw is pretty much taken from the img-ir NEC filter()
callback, and modulation uses the pulse distance helper added in a
previous commit.

Signed-off-by: James Hogan <james@albanarts.com>
Signed-off-by: Sean Young <sean@mess.org>
Cc: Antti Seppälä <a.seppala@gmail.com>
Cc: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

show more ...

[media] rc: unify nec32 protocol scancode format

There are two different encodings used for nec32:
- The ir-nec-decoder.c decoder treats it as 32 bit msb first.
- The img-ir decoder/encoder, winbo

[media] rc: unify nec32 protocol scancode format

There are two different encodings used for nec32:
- The ir-nec-decoder.c decoder treats it as 32 bit msb first.
- The img-ir decoder/encoder, winbond wakeup, dib0700, ir-ctl userspace,
treat nec32 analogous to necx and nec: 4 bytes, each lsb first. So this
format reverses the 4 bytes.

There are arguments to be had for both formats, but we should not use
different formats in different parts of the kernel. Selecting the second
format introduces the least code churn. It does mean that the TiVo keymap
needs updating.

This change was submitted before as "18bc174 [media] media: rc: change
32bit NEC scancode format", which was reverted because it was unclear
what scancode rc drivers produce. There are now more examples of drivers
which produce nec32 in lsb format.

The TiVo keymap is verified against the Nero Liquid TiVo remote. The
keymap is not for the Tivo DVR remote, which uses rc-5.

Signed-off-by: Sean Young <sean@mess.org>
Cc: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

show more ...

[media] rc: split nec protocol into its three variants

Currently we do not know what variant (bit length) of the nec protocol
is used, other than from guessing from the length of the scancode. Now
n

[media] rc: split nec protocol into its three variants

Currently we do not know what variant (bit length) of the nec protocol
is used, other than from guessing from the length of the scancode. Now
nec will be handled the same way as the sony protocol or the rc6 protocol;
one variant per bit length.

In the future we might want to expose the rc protocol type to userspace
and we don't want to be introducing this world of pain into userspace
too.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

show more ...

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

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

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

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>

show more ...

[media] rc-core: remove protocol arrays

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 pat

[media] rc-core: remove protocol arrays

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>

show more ...

[media] rc-core: document the protocol type

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 r

[media] rc-core: document the protocol type

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>

show more ...

[media] rc-core: do not change 32bit NEC scancode format for now

This reverts 18bc17448147e93f31cc9b1a83be49f1224657b2 and changes
the code at img-ir-nec.c to use the order used by the other NEC dec

[media] rc-core: do not change 32bit NEC scancode format for now

This reverts 18bc17448147e93f31cc9b1a83be49f1224657b2 and changes
the code at img-ir-nec.c to use the order used by the other NEC decoders.

The original patch ignored the fact that NEC32 scancodes are generated not
only in the NEC raw decoder but also directly in some drivers. Whichever
approach is chosen it should be consistent across drivers and this patch
needs more discussion.

Furthermore, I'm convinced that we have to stop playing games trying to
decipher the "meaning" of NEC scancodes (what's the customer/vendor/address,
which byte is the MSB, etc).

Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>

show more ...

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

The allowed and enabled protocol masks need to be expanded to be per
filter type in order to support wakeup filter protocol selection. To
eas

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

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>

show more ...

[media, edac] Change my email address

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 add

[media, edac] Change my email address

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>

show more ...

[media] media: rc: change 32bit NEC scancode format

Change 32bit NEC scancode format (used by Apple and TiVo remotes) to
encode the data with the correct bit order. Previously the raw bits were
used

[media] media: rc: change 32bit NEC scancode format

Change 32bit NEC scancode format (used by Apple and TiVo remotes) to
encode the data with the correct bit order. Previously the raw bits were
used without being bit reversed, now each 16bit half is bit reversed
compared to before.

So for the raw NEC data:
(LSB/First) 0xAAaaCCcc (MSB/Last)
(where traditionally AA=address, aa=~address, CC=command, cc=~command)

We now generate the scancodes:
(MSB) 0x0000AACC (LSB) (normal NEC)
(MSB) 0x00AAaaCC (LSB) (extended NEC, address check wrong)
(MSB) 0xaaAAccCC (LSB) (32-bit NEC, command check wrong)

Note that the address byte order in 32-bit NEC scancodes is different to
that of the extended NEC scancodes. I chose this way as it maintains the
order of the bits in the address/command fields, and CC is clearly
intended to be the LSB of the command if the TiVo codes are anything to
go by so it makes sense for AA to also be the LSB.

The TiVo keymap is updated accordingly.

Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Jarod Wilson <jarod@redhat.com>
Cc: linux-media@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>

show more ...

[media] rc-core: don't treat dev->rc_map.rc_type as a bitmap

store_protocols() treats dev->rc_map.rc_type as a bitmap which is wrong for
two reasons. First of all, it is pretty bogus to change the p

[media] rc-core: don't treat dev->rc_map.rc_type as a bitmap

store_protocols() treats dev->rc_map.rc_type as a bitmap which is wrong for
two reasons. First of all, it is pretty bogus to change the protocol type of
the keymap just because the hardware has been asked to decode a different
protocol.
Second, dev->rc_map.rc_type is an enum (i.e. a single protocol) as pointed
out by James Hogan <james.hogan@imgtec.com>.
Fix both issues by introducing a separate enabled_protocols member to
struct rc_dev.

Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

show more ...

[media] rc-core: add separate defines for protocol bitmaps and numbers

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

[media] rc-core: add separate defines for protocol bitmaps and numbers

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: David 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: Mauro Carvalho Chehab <mchehab@redhat.com>

show more ...

[media] nec-decoder: fix NEC decoding for Pioneer Laserdisc CU-700 remote

This remote sends a header pulse of 8150us followed by a space of 4000us.

Signed-off-by: Sean Young <sean@mess.org>
Signed-

[media] nec-decoder: fix NEC decoding for Pioneer Laserdisc CU-700 remote

This remote sends a header pulse of 8150us followed by a space of 4000us.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

show more ...

[media] ir-nec-decoder: Report what bit failed at debug msg

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