Lirc staging drivers
Subsystems (7)
Sean Young
maintainercover 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
Sean Young
maintainerPATCH 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.
--- 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
@@ -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
@@ -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
@@ -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
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
Sean Young
maintainerRe: [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/lircNdevice, right? Neither willLIRC_XXXIOCTL 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
Sean Young
maintainerRe: [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/lircNdevice, right? Neither willLIRC_XXXIOCTL codes be supported?Quite the opposite,
/dev/lircNand all theLIRC_XXXioctls will still be supported throughir-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
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/lircNdevice, right? Neither willLIRC_XXXIOCTL codes be supported?Quite the opposite,
/dev/lircNand all theLIRC_XXXioctls will still be supported throughir-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
Sean Young
maintainerRe: [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
Sean Young
maintainerRe: [PATCH 1/5] [media] ir-rx51: port to rc-core
In reply to Ivaylo DimitrovHi 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/lircNdevice, right? Neither willLIRC_XXXIOCTL codes be supported?Quite the opposite,
/dev/lircNand all theLIRC_XXXioctls will still be supported throughir-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
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
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
SeanStill 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
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
SeanStill 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
Sean Young
maintainerPATCH 2/5 staging: lirc_sir: port to rc-core
In reply to Sean YoungBefore 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.
--- 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
@@ -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
Sean Young
maintainerPATCH 3/5 staging: lirc_parallel: remove
In reply to Sean YoungThe 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.
--- 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
@@ -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
@@ -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
@@ -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
Sean Young
maintainerPATCH 4/5 staging: lirc_bt829: remove
In reply to Sean YoungThis 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.
--- 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
@@ -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
@@ -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
Sean Young
maintainerPATCH 5/5 staging: lirc_imon: port remaining usb ids to imon and remove
In reply to Sean YoungThe 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.
--- 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
@@ -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 2struct 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
@@ -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
@@ -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