linux-toradex.git/drivers/media/rc/ir-nec-decoder.c, branch v4.4.156

[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-core: do not change 32bit NEC scancode format for now

2014-04-06T14:26:04+00:00

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 
Acked-by: James Hogan 
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

[media, edac] Change my email address

2014-02-07T10:03:07+00:00

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

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

2014-02-06T11:20:07+00:00

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 
Cc: Mauro Carvalho Chehab 
Cc: Jarod Wilson 
Cc: linux-media@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab

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

2013-03-23T14:25:54+00:00

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 .
Fix both issues by introducing a separate enabled_protocols member to
struct rc_dev.

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

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

2012-10-27T13:49:51+00:00

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 
Cc: Andy Walls 
Cc: Maxim Levitsky 
Cc: Antti Palosaari 
Cc: Mike Isely 
Signed-off-by: Mauro Carvalho Chehab

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

2012-08-11T20:31:22+00:00

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

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab

Merge tag 'v3.2-rc2' into staging/for_v3.3

2011-11-23T21:42:09+00:00

* tag 'v3.2-rc2': (3068 commits)
  Linux 3.2-rc2
  hfs: add sanity check for file name length
  fsl-rio: fix compile error
  blackfin: Fixup export.h includes
  Blackfin: add serial TX IRQ in individual platform resource
  virtio-pci: fix use after free
  ACPI / cpuidle: Remove acpi_idle_suspend (to fix suspend regression)
  drm/radeon/kms/combios: fix dynamic allocation of PM clock modes
  [CPUFREQ] db8500: fix build error due to undeclared i variable
  bma023: Add SFI translation for this device
  vrtc: change its year offset from 1960 to 1972
  ce4100: fix a build error
  arm/imx: fix imx6q mmc error when mounting rootfs
  arm/imx: fix AUTO_ZRELADDR selection
  arm/imx: fix the references to ARCH_MX3
  ARM: mx51/53: set pwm clock parent to ipg_perclk
  btrfs: rename the option to nospace_cache
  drm/radeon/kms/pm: switch to dynamically allocating clock mode array
  drm/radeon/kms: optimize r600_pm_profile_init
  drm/radeon/kms/pm: add a proper pm profile init function for fusion
  ...

Conflicts:
	drivers/media/radio/Kconfig