Skip to contentSkip to conversation

Lirc staging drivers

PATCH In review Sean Young 4 participants 15 messages Dec 20, 2016 – Jan 30, 2017

Subsystems (7)
lore
Share & tools
lore

Sean Young

author maintainer
#0 lore raw

cover Lirc staging drivers

This patch series tries to make some headway with dealing with the lirc staging drivers. Over the last couple of years, I have ported lirc_serial, lirc_ttusbir and lirc_igorplugusb. I have not been able to track down the hardware for the remaining drivers.

Note that the remaining lirc staging drivers were merged in 2010, and other than trival patches, they have not made any progress towards mainline.

ir-rx51 is not a staging driver, but it should not rely on the lirc in-kernel API like the staging drivers do.

Sean Young (5):
[media] ir-rx51: port to rc-core
[media] staging: lirc_sir: port to rc-core
[media] staging: lirc_parallel: remove
[media] staging: lirc_bt829: remove
[media] staging: lirc_imon: port remaining usb ids to imon and remove

 arch/arm/mach-omap2/pdata-quirks.c          |   8 +-
 drivers/media/rc/Kconfig                    |   2 +-
 drivers/media/rc/imon.c                     | 133 +++-
 drivers/media/rc/ir-rx51.c                  | 332 ++++------
 drivers/staging/media/lirc/Kconfig          |  22 +-
 drivers/staging/media/lirc/Makefile         |   3 -
 drivers/staging/media/lirc/lirc_bt829.c     | 401 ------------
 drivers/staging/media/lirc/lirc_imon.c      | 979 ----------------------------
 drivers/staging/media/lirc/lirc_parallel.c  | 741 ---------------------
 drivers/staging/media/lirc/lirc_parallel.h  |  26 -
 drivers/staging/media/lirc/lirc_sir.c       | 296 ++-------
 include/linux/platform_data/media/ir-rx51.h |   6 +-
 12 files changed, 322 insertions(+), 2627 deletions(-)
 delete mode 100644 drivers/staging/media/lirc/lirc_bt829.c
 delete mode 100644 drivers/staging/media/lirc/lirc_imon.c
 delete mode 100644 drivers/staging/media/lirc/lirc_parallel.c
 delete mode 100644 drivers/staging/media/lirc/lirc_parallel.h
Signature · 1 line
2.9.3
author maintainer
#1 lore raw

PATCH 1/5 ir-rx51: port to rc-core

This driver was written using lirc since rc-core did not support transmitter-only hardware at that time. Now that it does, port this driver.

Compile tested only.

Cc Timo Kokkonen <[email protected]>
Cc Ivaylo Dimitrov <[email protected]>
---
 arch/arm/mach-omap2/pdata-quirks.c          |   8 +-
 drivers/media/rc/Kconfig                    |   2 +-
 drivers/media/rc/ir-rx51.c                  | 332 ++++++++++------------------
 include/linux/platform_data/media/ir-rx51.h |   6 +-
 4 files changed, 126 insertions(+), 222 deletions(-)
arch/arm/mach-omap2/pdata-quirks.c +4 -4
index 05e20aa..fdd6e7f 100644
@@ -485,15 +485,15 @@ static struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
 };
 #endif
 
-static struct lirc_rx51_platform_data __maybe_unused rx51_lirc_data = {
+static struct ir_rx51_platform_data __maybe_unused rx51_ir_data = {
 	.set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
 };
 
-static struct platform_device __maybe_unused rx51_lirc_device = {
-	.name           = "lirc_rx51",
+static struct platform_device __maybe_unused rx51_ir_device = {
+	.name           = "ir_rx51",
 	.id             = -1,
 	.dev            = {
-		.platform_data = &rx51_lirc_data,
+		.platform_data = &rx51_ir_data,
 	},
 };
 
drivers/media/rc/Kconfig +1 -1
index 3351e25..d0ddbd3 100644
@@ -345,7 +345,7 @@ config IR_TTUSBIR
 
 config IR_RX51
 	tristate "Nokia N900 IR transmitter diode"
-	depends on OMAP_DM_TIMER && PWM_OMAP_DMTIMER && ARCH_OMAP2PLUS && LIRC
+	depends on (OMAP_DM_TIMER && PWM_OMAP_DMTIMER && ARCH_OMAP2PLUS || COMPILE_TEST) && RC_CORE
 	---help---
 	   Say Y or M here if you want to enable support for the IR
 	   transmitter diode built in the Nokia N900 (RX51) device.
drivers/media/rc/ir-rx51.c +118 -214

496 lines not on this page · raw message

include/linux/platform_data/media/ir-rx51.h +3 -3
index 812d873..2c94ab5 100644
@@ -1,7 +1,7 @@
-#ifndef _LIRC_RX51_H
-#define _LIRC_RX51_H
+#ifndef _IR_RX51_H
+#define _IR_RX51_H
 
-struct lirc_rx51_platform_data {
+struct ir_rx51_platform_data {
 	int(*set_max_mpu_wakeup_lat)(struct device *dev, long t);
 };
 
Signature · 1 line
2.9.3
#2 lore raw

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

Hi,

Quoted 6 lines · Sean Young

This driver was written using lirc since rc-core did not support transmitter-only hardware at that time. Now that it does, port this driver.

Compile tested only.

I guess after that change, there will be no more /dev/lircN device, right? Neither will LIRC_XXX IOCTL codes be supported?

That looks to me as a completely new driver, not a port to new API.

Right now there are applications using the current behaviour (pierogi for example), which will be broken by the change.

Ivo

author maintainer
#3 lore raw

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

Hi Ivo,,

Quoted 10 lines · Ivaylo Dimitrov
Quoted 6 lines · Sean Young

This driver was written using lirc since rc-core did not support transmitter-only hardware at that time. Now that it does, port this driver.

Compile tested only.

I guess after that change, there will be no more /dev/lircN device, right? Neither will LIRC_XXX IOCTL codes be supported?

Quite the opposite, /dev/lircN and all the LIRC_XXX ioctls will still be supported through ir-lirc-codec.c.

By using rc-core, the driver will be more succinct, and some latent bugs will be fixed. For example, at the moment it is possible to write hours of IR data and keep the n900 from suspending.

I'm working on lirc scancode sending and receiving using the IR encoders, and when that is in place, any rc-core driver will get it for free.

Quoted 4 lines

That looks to me as a completely new driver, not a port to new API.

Right now there are applications using the current behaviour (pierogi for example), which will be broken by the change.

Nothing should break.

Thanks,

Sean

author maintainer
#4 lore raw

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

Quoted 24 lines · Sean Young

Hi Ivo,,

Quoted 10 lines · Ivaylo Dimitrov
Quoted 6 lines · Sean Young

This driver was written using lirc since rc-core did not support transmitter-only hardware at that time. Now that it does, port this driver.

Compile tested only.

I guess after that change, there will be no more /dev/lircN device, right? Neither will LIRC_XXX IOCTL codes be supported?

Quite the opposite, /dev/lircN and all the LIRC_XXX ioctls will still be supported through ir-lirc-codec.c.

By using rc-core, the driver will be more succinct, and some latent bugs will be fixed. For example, at the moment it is possible to write hours of IR data and keep the n900 from suspending.

I'm working on lirc scancode sending and receiving using the IR encoders, and when that is in place, any rc-core driver will get it for free.

Quoted 6 lines
Quoted 4 lines

That looks to me as a completely new driver, not a port to new API.

Right now there are applications using the current behaviour (pierogi for example), which will be broken by the change.

Nothing should break.

Speaking of which, if you would please test this, that would be great. My N900 died many years ago.

Many thanks,

Sean

#5 lore raw

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

Quoted 28 lines · Sean Young
Quoted 26 lines · Sean Young

Hi Ivo,,

Quoted 10 lines · Ivaylo Dimitrov
Quoted 6 lines · Sean Young

This driver was written using lirc since rc-core did not support transmitter-only hardware at that time. Now that it does, port this driver.

Compile tested only.

I guess after that change, there will be no more /dev/lircN device, right? Neither will LIRC_XXX IOCTL codes be supported?

Quite the opposite, /dev/lircN and all the LIRC_XXX ioctls will still be supported through ir-lirc-codec.c.

By using rc-core, the driver will be more succinct, and some latent bugs will be fixed. For example, at the moment it is possible to write hours of IR data and keep the n900 from suspending.

I'm working on lirc scancode sending and receiving using the IR encoders, and when that is in place, any rc-core driver will get it for free.

Quoted 2 lines

That looks to me as a completely new driver, not a port to new API.

Quoted 8 lines
Quoted 4 lines
Quoted 2 lines

Right now there are applications using the current behaviour (pierogi for example), which will be broken by the change.

Nothing should break.

Speaking of which, if you would please test this, that would be great. My N900 died many years ago.

Will do, but next year :) .

Thanks,
Ivo

author maintainer
#6 lore raw

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

Hi Ivo,

Quoted 6 lines · Ivaylo Dimitrov
Quoted 3 lines · Sean Young

On Fri, Dec 30, 2016 at 01:07:52PM +0000, Sean Young wrote:
Speaking of which, if you would please test this, that would be great. My N900 died many years ago.

Will do, but next year :) .

Great, thanks!

Sean

author maintainer
#7 lore raw

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

In reply to Ivaylo Dimitrov

Hi Ivo,

Quoted 32 lines · Ivaylo Dimitrov
Quoted 31 lines · Sean Young
Quoted 29 lines · Sean Young

Hi Ivo,,

Quoted 10 lines · Ivaylo Dimitrov
Quoted 6 lines · Sean Young

This driver was written using lirc since rc-core did not support transmitter-only hardware at that time. Now that it does, port this driver.

Compile tested only.

I guess after that change, there will be no more /dev/lircN device, right? Neither will LIRC_XXX IOCTL codes be supported?

Quite the opposite, /dev/lircN and all the LIRC_XXX ioctls will still be supported through ir-lirc-codec.c.

By using rc-core, the driver will be more succinct, and some latent bugs will be fixed. For example, at the moment it is possible to write hours of IR data and keep the n900 from suspending.

I'm working on lirc scancode sending and receiving using the IR encoders, and when that is in place, any rc-core driver will get it for free.

Quoted 4 lines

That looks to me as a completely new driver, not a port to new API.

Right now there are applications using the current behaviour (pierogi for example), which will be broken by the change.

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

Nothing should break.

Speaking of which, if you would please test this, that would be great. My N900 died many years ago.

Will do, but next year :) .

Have you had a chance to test the ir-rx51 changes?

Thanks
Sean

#8 lore raw

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

Hi

Quoted 6 lines · Sean Young

Have you had a chance to test the ir-rx51 changes?

Thanks
Sean

Still no, and afaik there are issues booting n900 with current kernel. Will try to find time over the weekend.

Ivo

#9 lore raw

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

Hi!

Quoted 10 lines · Sean Young
Quoted 6 lines

Have you had a chance to test the ir-rx51 changes?

Thanks
Sean

Still no, and afaik there are issues booting n900 with current kernel. Will try to find time over the weekend.

v4.10-rc3 (?) works for me on n900. Do you want a working .config?

Best regards,
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#10 lore raw

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

Em Mon, 16 Jan 2017 21:13:58 +0100
Pavel Machek <[email protected]> escreveu:

Quoted 6 lines

Hi!

Quoted 4 lines · Sean Young
Quoted 3 lines

Have you had a chance to test the ir-rx51 changes?

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

Thanks
Sean

Still no, and afaik there are issues booting n900 with current kernel. Will try to find time over the weekend.

v4.10-rc3 (?) works for me on n900. Do you want a working .config?

I'm merging this patch at the media tree. Please report if you find any issues for us to fix in time for 4.11.

Thanks,
Mauro

Thanks,
Mauro

author maintainer
#11 lore raw

PATCH 2/5 staging: lirc_sir: port to rc-core

In reply to Sean Young

Before this driver can be moved out of staging, it should be ported to rc-core. I've tried to make the minimum changes possible without upsetting checkpatch.

Compile tested only.

Cc Jarod Wilson <[email protected]>
Cc Christoph Bartelmus <[email protected]>
Cc Milan Pikula <[email protected]>
Cc Frank Przybylski <[email protected]>
---
 drivers/staging/media/lirc/Kconfig    |   2 +-
 drivers/staging/media/lirc/lirc_sir.c | 296 ++++++++--------------------------
 2 files changed, 69 insertions(+), 229 deletions(-)
drivers/staging/media/lirc/Kconfig +1 -1
index 25b7e7c..56e5fd7 100644
@@ -40,7 +40,7 @@ config LIRC_SASEM
 
 config LIRC_SIR
 	tristate "Built-in SIR IrDA port"
-	depends on LIRC
+	depends on RC_CORE
 	help
 	  Driver for the SIR IrDA port
 
drivers/staging/media/lirc/lirc_sir.c +68 -228

472 lines not on this page · raw message

Signature · 1 line
2.9.3
author maintainer
#12 lore raw

PATCH 3/5 staging: lirc_parallel: remove

In reply to Sean Young

The lirc_parallel driver was merged in 2010 and noone has attempted to do the work necessary to get it out of staging (i.e. port it to rc-core). I have not been able to find one of these devices, and a machine with a parallel port is pretty rare too.

Cc Jarod Wilson <[email protected]>
Cc Christoph Bartelmus <[email protected]>
---
 drivers/staging/media/lirc/Kconfig         |   6 -
 drivers/staging/media/lirc/Makefile        |   1 -
 drivers/staging/media/lirc/lirc_parallel.c | 741 -----------------------------
 drivers/staging/media/lirc/lirc_parallel.h |  26 -
 4 files changed, 774 deletions(-)
 delete mode 100644 drivers/staging/media/lirc/lirc_parallel.c
 delete mode 100644 drivers/staging/media/lirc/lirc_parallel.h
drivers/staging/media/lirc/Kconfig +0 -6
index 56e5fd7..7923d3f 100644
@@ -26,12 +26,6 @@ config LIRC_IMON
 
 	  Current generation iMON devices use the input layer imon driver.
 
-config LIRC_PARALLEL
-	tristate "Homebrew Parallel Port Receiver"
-	depends on LIRC && PARPORT
-	help
-	  Driver for Homebrew Parallel Port Receivers
-
 config LIRC_SASEM
 	tristate "Sasem USB IR Remote"
 	depends on LIRC && USB
drivers/staging/media/lirc/Makefile +0 -1
index 7f919ea..ed3091e 100644
@@ -5,7 +5,6 @@
 
 obj-$(CONFIG_LIRC_BT829)	+= lirc_bt829.o
 obj-$(CONFIG_LIRC_IMON)		+= lirc_imon.o
-obj-$(CONFIG_LIRC_PARALLEL)	+= lirc_parallel.o
 obj-$(CONFIG_LIRC_SASEM)	+= lirc_sasem.o
 obj-$(CONFIG_LIRC_SIR)		+= lirc_sir.o
 obj-$(CONFIG_LIRC_ZILOG)	+= lirc_zilog.o
drivers/staging/media/lirc/lirc_parallel.c deleted +0 -741

741 lines not on this page · raw message

drivers/staging/media/lirc/lirc_parallel.h deleted +0 -26
deleted file mode 100644
index 4bed6af..0000000
@@ -1,26 +0,0 @@
-/* lirc_parallel.h */
-
-#ifndef _LIRC_PARALLEL_H
-#define _LIRC_PARALLEL_H
-
-#include <linux/lp.h>
-
-#define LIRC_PORT_LEN 3
-
-#define LIRC_LP_BASE    0
-#define LIRC_LP_STATUS  1
-#define LIRC_LP_CONTROL 2
-
-#define LIRC_PORT_DATA           LIRC_LP_BASE    /* base */
-#define LIRC_PORT_TIMER        LIRC_LP_STATUS    /* status port */
-#define LIRC_PORT_TIMER_BIT          LP_PBUSY    /* busy signal */
-#define LIRC_PORT_SIGNAL       LIRC_LP_STATUS    /* status port */
-#define LIRC_PORT_SIGNAL_BIT          LP_PACK    /* ack signal */
-#define LIRC_PORT_IRQ         LIRC_LP_CONTROL    /* control port */
-
-#define LIRC_SFH506_DELAY 0             /* delay t_phl in usecs */
-
-#define LIRC_PARALLEL_MAX_TRANSMITTERS 8
-#define LIRC_PARALLEL_TRANSMITTER_MASK ((1<<LIRC_PARALLEL_MAX_TRANSMITTERS) - 1)
-
-#endif
Signature · 1 line
2.9.3
author maintainer
#13 lore raw

PATCH 4/5 staging: lirc_bt829: remove

In reply to Sean Young

This driver is for an old mach64 VT board, which also has a framebuffer driver (atyfb) and userspace mach64 X driver.

It was merged in 2010 and noone has attempted to port it to rc-core, which would be necessary to get it out of staging.

I have not been able to track down the hardware either.

Cc Jarod Wilson <[email protected]>
Cc Leonid Froenchenko <[email protected]>
---
 drivers/staging/media/lirc/Kconfig      |   6 -
 drivers/staging/media/lirc/Makefile     |   1 -
 drivers/staging/media/lirc/lirc_bt829.c | 401 --------------------------------
 3 files changed, 408 deletions(-)
 delete mode 100644 drivers/staging/media/lirc/lirc_bt829.c
drivers/staging/media/lirc/Kconfig +0 -6
index 7923d3f..574ab50 100644
@@ -12,12 +12,6 @@ menuconfig LIRC_STAGING
 
 if LIRC_STAGING
 
-config LIRC_BT829
-        tristate "BT829 based hardware"
-	depends on LIRC && PCI
-	help
-	  Driver for the IR interface on BT829-based hardware
-
 config LIRC_IMON
 	tristate "Legacy SoundGraph iMON Receiver and Display"
 	depends on LIRC && USB
drivers/staging/media/lirc/Makefile +0 -1
index ed3091e..3f31116 100644
@@ -3,7 +3,6 @@
 
 # Each configuration option enables a list of files.
 
-obj-$(CONFIG_LIRC_BT829)	+= lirc_bt829.o
 obj-$(CONFIG_LIRC_IMON)		+= lirc_imon.o
 obj-$(CONFIG_LIRC_SASEM)	+= lirc_sasem.o
 obj-$(CONFIG_LIRC_SIR)		+= lirc_sir.o
drivers/staging/media/lirc/lirc_bt829.c deleted +0 -401

401 lines not on this page · raw message

Signature · 1 line
2.9.3
author maintainer
#14 lore raw

PATCH 5/5 staging: lirc_imon: port remaining usb ids to imon and remove

In reply to Sean Young

The staging lirc_imon driver contains 4 usb ids. Two of those have a VFD and two don't. The VFD code is exactly the same in the mainline imon driver, so that part is easily ported.

The staging driver produces raw IR rather than scancodes for the four devices, so I've ported the raw IR code from staging to mainline imon.

Now that mainline imon can handle these four devices, lirc_imon is no longer needed.

Compile tested only.

Cc Venky Raju <[email protected]>
Cc Jarod Wilson <[email protected]>
Cc Alexey Khoroshilov <[email protected]>
---
 drivers/media/rc/imon.c                | 133 ++++-
 drivers/staging/media/lirc/Kconfig     |   8 -
 drivers/staging/media/lirc/Makefile    |   1 -
 drivers/staging/media/lirc/lirc_imon.c | 979 ---------------------------------
 4 files changed, 127 insertions(+), 994 deletions(-)
 delete mode 100644 drivers/staging/media/lirc/lirc_imon.c
drivers/media/rc/imon.c +127 -6
index 4234ae6..af5926f 100644
@@ -96,6 +96,7 @@ struct imon_usb_dev_descr {
 	__u16 flags;
 #define IMON_NO_FLAGS 0
 #define IMON_NEED_20MS_PKT_DELAY 1
+#define IMON_IR_RAW 2
 	struct imon_panel_key_table key_table[];
 };
 
@@ -126,6 +127,12 @@ struct imon_context {
 	unsigned char usb_tx_buf[8];
 	unsigned int send_packet_delay;
 
+	struct rx_data {
+		int count;		/* length of 0 or 1 sequence */
+		int prev_bit;		/* logic level of sequence */
+		int initial_space;	/* initial space flag */
+	} rx;
+
 	struct tx_t {
 		unsigned char data_buf[35];	/* user data buffer */
 		struct completion finished;	/* wait for write to finish */
@@ -328,6 +335,10 @@ static const struct imon_usb_dev_descr imon_DH102 = {
 	}
 };
 
+static const struct imon_usb_dev_descr imon_ir_raw = {
+	.flags = IMON_IR_RAW,
+};
+
 /*
  * USB Device ID for iMON USB Control Boards
  *
@@ -411,6 +422,18 @@ static struct usb_device_id imon_usb_id_table[] = {
 	/* device specifics unknown */
 	{ USB_DEVICE(0x15c2, 0x0046),
 	  .driver_info = (unsigned long)&imon_default_table},
+	/* TriGem iMON (IR only) -- TG_iMON.inf */
+	{ USB_DEVICE(0x0aa8, 0x8001),
+	  .driver_info = (unsigned long)&imon_ir_raw},
+	/* SoundGraph iMON (IR only) -- sg_imon.inf */
+	{ USB_DEVICE(0x04e8, 0xff30),
+	  .driver_info = (unsigned long)&imon_ir_raw},
+	/* SoundGraph iMON VFD (IR & VFD) -- iMON_VFD.inf */
+	{ USB_DEVICE(0x0aa8, 0xffda),
+	  .driver_info = (unsigned long)&imon_ir_raw},
+	/* SoundGraph iMON SS (IR & VFD) -- iMON_SS.inf */
+	{ USB_DEVICE(0x15c2, 0xffda),
+	  .driver_info = (unsigned long)&imon_ir_raw},
 	{}
 };
 
@@ -1577,11 +1600,94 @@ static int imon_parse_press_type(struct imon_context *ictx,
 /**
  * Process the incoming packet
  */
-static void imon_incoming_packet(struct imon_context *ictx,
+/**
+ * Convert bit count to time duration (in us) and submit
+ * the value to lirc_dev.
+ */
+static void submit_data(struct imon_context *context)
+{
+	DEFINE_IR_RAW_EVENT(ev);
+
+	ev.pulse = context->rx.prev_bit;
+	ev.duration = US_TO_NS(context->rx.count * BIT_DURATION);
+	ir_raw_event_store_with_filter(context->rdev, &ev);
+}
+
+/**
+ * Process the incoming packet
+ */
+static void imon_incoming_ir_raw(struct imon_context *context,
 				 struct urb *urb, int intf)
 {
 	int len = urb->actual_length;
 	unsigned char *buf = urb->transfer_buffer;
+	struct device *dev = context->dev;
+	int octet, bit;
+	unsigned char mask;
+
+	if (len != 8) {
+		dev_warn(dev, "imon %s: invalid incoming packet size (len = %d, intf%d)\n",
+			 __func__, len, intf);
+		return;
+	}
+
+	if (debug)
+		dev_info(dev, "raw packet: %*ph\n", len, buf);
+	/*
+	 * Translate received data to pulse and space lengths.
+	 * Received data is active low, i.e. pulses are 0 and
+	 * spaces are 1.
+	 *
+	 * My original algorithm was essentially similar to
+	 * Changwoo Ryu's with the exception that he switched
+	 * the incoming bits to active high and also fed an
+	 * initial space to LIRC at the start of a new sequence
+	 * if the previous bit was a pulse.
+	 *
+	 * I've decided to adopt his algorithm.
+	 */
+
+	if (buf[7] == 1 && context->rx.initial_space) {
+		/* LIRC requires a leading space */
+		context->rx.prev_bit = 0;
+		context->rx.count = 4;
+		submit_data(context);
+		context->rx.count = 0;
+	}
+
+	for (octet = 0; octet < 5; ++octet) {
+		mask = 0x80;
+		for (bit = 0; bit < 8; ++bit) {
+			int curr_bit = !(buf[octet] & mask);
+
+			if (curr_bit != context->rx.prev_bit) {
+				if (context->rx.count) {
+					submit_data(context);
+					context->rx.count = 0;
+				}
+				context->rx.prev_bit = curr_bit;
+			}
+			++context->rx.count;
+			mask >>= 1;
+		}
+	}
+
+	if (buf[7] == 10) {
+		if (context->rx.count) {
+			submit_data(context);
+			context->rx.count = 0;
+		}
+		context->rx.initial_space = context->rx.prev_bit;
+	}
+
+	ir_raw_event_handle(context->rdev);
+}
+
+static void imon_incoming_scancode(struct imon_context *ictx,
+				   struct urb *urb, int intf)
+{
+	int len = urb->actual_length;
+	unsigned char *buf = urb->transfer_buffer;
 	struct device *dev = ictx->dev;
 	unsigned long flags;
 	u32 kc;
@@ -1761,7 +1867,10 @@ static void usb_rx_callback_intf0(struct urb *urb)
 		break;
 
 	case 0:
-		imon_incoming_packet(ictx, urb, intfnum);
+		if (ictx->rdev->driver_type == RC_DRIVER_IR_RAW)
+			imon_incoming_ir_raw(ictx, urb, intfnum);
+		else
+			imon_incoming_scancode(ictx, urb, intfnum);
 		break;
 
 	default:
@@ -1802,7 +1911,10 @@ static void usb_rx_callback_intf1(struct urb *urb)
 		break;
 
 	case 0:
-		imon_incoming_packet(ictx, urb, intfnum);
+		if (ictx->rdev->driver_type == RC_DRIVER_IR_RAW)
+			imon_incoming_ir_raw(ictx, urb, intfnum);
+		else
+			imon_incoming_scancode(ictx, urb, intfnum);
 		break;
 
 	default:
@@ -1910,11 +2022,14 @@ static void imon_set_display_type(struct imon_context *ictx)
 		case 0x0041:
 		case 0x0042:
 		case 0x0043:
+		case 0x8001:
+		case 0xff30:
 			configured_display_type = IMON_DISPLAY_TYPE_NONE;
 			ictx->display_supported = false;
 			break;
 		case 0x0036:
 		case 0x0044:
+		case 0xffda:
 		default:
 			configured_display_type = IMON_DISPLAY_TYPE_VFD;
 			break;
@@ -1939,7 +2054,8 @@ static struct rc_dev *imon_init_rdev(struct imon_context *ictx)
 	const unsigned char fp_packet[] = { 0x40, 0x00, 0x00, 0x00,
 					    0x00, 0x00, 0x00, 0x88 };
 
-	rdev = rc_allocate_device(RC_DRIVER_SCANCODE);
+	rdev = rc_allocate_device(ictx->dev_descr->flags & IMON_IR_RAW ?
+				  RC_DRIVER_IR_RAW : RC_DRIVER_SCANCODE);
 	if (!rdev) {
 		dev_err(ictx->dev, "remote control dev allocation failed\n");
 		goto out;
@@ -1957,7 +2073,11 @@ static struct rc_dev *imon_init_rdev(struct imon_context *ictx)
 	rdev->dev.parent = ictx->dev;
 
 	rdev->priv = ictx;
-	rdev->allowed_protocols = RC_BIT_OTHER | RC_BIT_RC6_MCE; /* iMON PAD or MCE */
+	if (ictx->dev_descr->flags & IMON_IR_RAW)
+		rdev->allowed_protocols = RC_BIT_ALL_IR_DECODER;
+	else
+		/* iMON PAD or MCE */
+		rdev->allowed_protocols = RC_BIT_OTHER | RC_BIT_RC6_MCE;
 	rdev->change_protocol = imon_ir_change_protocol;
 	rdev->driver_name = MOD_NAME;
 
@@ -1975,7 +2095,8 @@ static struct rc_dev *imon_init_rdev(struct imon_context *ictx)
 
 	imon_set_display_type(ictx);
 
-	if (ictx->rc_type == RC_BIT_RC6_MCE)
+	if (ictx->rc_type == RC_BIT_RC6_MCE ||
+	    ictx->dev_descr->flags & IMON_IR_RAW)
 		rdev->map_name = RC_MAP_IMON_MCE;
 	else
 		rdev->map_name = RC_MAP_IMON_PAD;
drivers/staging/media/lirc/Kconfig +0 -8
index 574ab50..bc67da2 100644
@@ -12,14 +12,6 @@ menuconfig LIRC_STAGING
 
 if LIRC_STAGING
 
-config LIRC_IMON
-	tristate "Legacy SoundGraph iMON Receiver and Display"
-	depends on LIRC && USB
-	help
-	  Driver for the original SoundGraph iMON IR Receiver and Display
-
-	  Current generation iMON devices use the input layer imon driver.
-
 config LIRC_SASEM
 	tristate "Sasem USB IR Remote"
 	depends on LIRC && USB
drivers/staging/media/lirc/Makefile +0 -1
index 3f31116..28740c9 100644
@@ -3,7 +3,6 @@
 
 # Each configuration option enables a list of files.
 
-obj-$(CONFIG_LIRC_IMON)		+= lirc_imon.o
 obj-$(CONFIG_LIRC_SASEM)	+= lirc_sasem.o
 obj-$(CONFIG_LIRC_SIR)		+= lirc_sir.o
 obj-$(CONFIG_LIRC_ZILOG)	+= lirc_zilog.o
drivers/staging/media/lirc/lirc_imon.c deleted +0 -979

979 lines not on this page · raw message

Signature · 1 line
2.9.3