Skip to contentSkip to conversation

rc-core: ir-core to rc-core conversion

PATCH In review David Härdeman 3 participants 31 messages Nov 2, 2010 – Nov 12, 2010

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

cover rc-core: ir-core to rc-core conversion

This is my current patch queue, the main change is to make struct rc_dev the primary interface for rc drivers and to abstract away the fact that there's an input device lurking in there somewhere.

In addition, the cx88 and winbond-cir drivers are converted to use rc-core.

The patchset is now based on current linux-2.6 upstream git tree since it carries both the v4l patches from the staging/for_v2.6.37-rc1 branch, large scancode support and bugfixes.

Given the changes, these patches touch every single driver. Obviously I haven't tested them all due to a lack of hardware (I have made sure that all drivers compile without any warnings and I have tested the end result on mceusb and winbond-cir hardware, Jarod Wilson has tested nuvoton-cir, imon and several mceusb devices).

---

David Härdeman (6):
ir-core: convert drivers/media/video/cx88 to ir-core
ir-core: remove remaining users of the ir-functions keyhandlers
ir-core: more cleanups of ir-functions.c
ir-core: merge and rename to rc-core
ir-core: make struct rc_dev the primary interface
rc-core: convert winbond-cir

 drivers/input/misc/Kconfig                  |   18 
 drivers/input/misc/Makefile                 |    1 
 drivers/input/misc/winbond-cir.c            | 1608 ---------------------------
 drivers/media/IR/Kconfig                    |   19 
 drivers/media/IR/Makefile                   |    7 
 drivers/media/IR/ene_ir.c                   |  129 +-
 drivers/media/IR/ene_ir.h                   |    3 
 drivers/media/IR/imon.c                     |   67 -
 drivers/media/IR/ir-core-priv.h             |   26 
 drivers/media/IR/ir-functions.c             |  254 ----
 drivers/media/IR/ir-jvc-decoder.c           |   13 
 drivers/media/IR/ir-keytable.c              |  710 ------------
 drivers/media/IR/ir-lirc-codec.c            |  121 +-
 drivers/media/IR/ir-nec-decoder.c           |   15 
 drivers/media/IR/ir-raw-event.c             |  382 ------
 drivers/media/IR/ir-rc5-decoder.c           |   13 
 drivers/media/IR/ir-rc5-sz-decoder.c        |   13 
 drivers/media/IR/ir-rc6-decoder.c           |   17 
 drivers/media/IR/ir-sony-decoder.c          |   11 
 drivers/media/IR/ir-sysfs.c                 |  362 ------
 drivers/media/IR/mceusb.c                   |  105 +-
 drivers/media/IR/nuvoton-cir.c              |   85 +
 drivers/media/IR/nuvoton-cir.h              |    3 
 drivers/media/IR/rc-main.c                  | 1135 +++++++++++++++++++
 drivers/media/IR/rc-map.c                   |  107 --
 drivers/media/IR/rc-raw.c                   |  371 ++++++
 drivers/media/IR/streamzap.c                |   66 -
 drivers/media/IR/winbond-cir.c              |  932 ++++++++++++++++
 drivers/media/dvb/dm1105/Kconfig            |    3 
 drivers/media/dvb/dm1105/dm1105.c           |   42 -
 drivers/media/dvb/dvb-usb/af9015.c          |   16 
 drivers/media/dvb/dvb-usb/anysee.c          |    2 
 drivers/media/dvb/dvb-usb/dib0700.h         |    2 
 drivers/media/dvb/dvb-usb/dib0700_core.c    |    8 
 drivers/media/dvb/dvb-usb/dib0700_devices.c |  144 +-
 drivers/media/dvb/dvb-usb/dvb-usb-remote.c  |   77 +
 drivers/media/dvb/dvb-usb/dvb-usb.h         |   12 
 drivers/media/dvb/dvb-usb/lmedm04.c         |   42 -
 drivers/media/dvb/mantis/mantis_common.h    |    4 
 drivers/media/dvb/mantis/mantis_input.c     |   71 +
 drivers/media/dvb/siano/smscoreapi.c        |    2 
 drivers/media/dvb/siano/smsir.c             |   52 -
 drivers/media/dvb/siano/smsir.h             |    3 
 drivers/media/dvb/ttpci/Kconfig             |    3 
 drivers/media/dvb/ttpci/budget-ci.c         |   49 -
 drivers/media/video/Kconfig                 |    2 
 drivers/media/video/bt8xx/Kconfig           |    4 
 drivers/media/video/bt8xx/bttv-input.c      |   73 -
 drivers/media/video/bt8xx/bttvp.h           |    1 
 drivers/media/video/cx18/Kconfig            |    3 
 drivers/media/video/cx231xx/Kconfig         |    4 
 drivers/media/video/cx23885/cx23885-input.c |   64 +
 drivers/media/video/cx23885/cx23885.h       |    3 
 drivers/media/video/cx88/Kconfig            |    3 
 drivers/media/video/cx88/cx88-input.c       |  233 +---
 drivers/media/video/em28xx/Kconfig          |    4 
 drivers/media/video/em28xx/em28xx-input.c   |   72 +
 drivers/media/video/ir-kbd-i2c.c            |   28 
 drivers/media/video/ivtv/Kconfig            |    3 
 drivers/media/video/saa7134/Kconfig         |    2 
 drivers/media/video/saa7134/saa7134-input.c |  121 +-
 drivers/media/video/tlg2300/Kconfig         |    4 
 drivers/staging/cx25821/Kconfig             |    4 
 drivers/staging/go7007/Kconfig              |    4 
 drivers/staging/tm6000/tm6000-input.c       |   98 +-
 include/media/ir-common.h                   |   38 -
 include/media/ir-core.h                     |  201 ++-
 include/media/ir-kbd-i2c.h                  |    7 
 68 files changed, 3410 insertions(+), 4691 deletions(-)
 delete mode 100644 drivers/input/misc/winbond-cir.c
 delete mode 100644 drivers/media/IR/ir-keytable.c
 delete mode 100644 drivers/media/IR/ir-raw-event.c
 delete mode 100644 drivers/media/IR/ir-sysfs.c
 create mode 100644 drivers/media/IR/rc-main.c
 delete mode 100644 drivers/media/IR/rc-map.c
 create mode 100644 drivers/media/IR/rc-raw.c
 create mode 100644 drivers/media/IR/winbond-cir.c
Signature · 1 line
David Härdeman
#1 lore raw

PATCH 1/6 ir-core: convert drivers/media/video/cx88 to ir-core

This patch converts the cx88 driver (for sampling hw) to use the decoders provided by ir-core instead of the separate ones provided by ir-functions (and gets rid of those).

The value for MO_DDS_IO had a comment saying it corresponded to a 4kHz samplerate. That comment was unfortunately misleading. The actual samplerate was something like 3250Hz.

The current value has been derived by analyzing the elapsed time between interrupts for different values (knowing that each interrupt corresponds to 32 samples).

Thanks to Mariusz Bialonczyk <[email protected]> for testing my patches (about one a day for two weeks!) on actual hardware.

---
 drivers/media/IR/ir-functions.c       |  134 ---------------------------
 drivers/media/video/cx88/Kconfig      |    2 
 drivers/media/video/cx88/cx88-input.c |  163 +++++++--------------------------
 include/media/ir-common.h             |    3 -
 4 files changed, 37 insertions(+), 265 deletions(-)
drivers/media/IR/ir-functions.c +0 -134
index db591e4..f4c4115 100644
@@ -111,140 +111,6 @@ u32 ir_extract_bits(u32 data, u32 mask)
 }
 EXPORT_SYMBOL_GPL(ir_extract_bits);
 
-static int inline getbit(u32 *samples, int bit)
-{
-	return (samples[bit/32] & (1 << (31-(bit%32)))) ? 1 : 0;
-}
-
-/* sump raw samples for visual debugging ;) */
-int ir_dump_samples(u32 *samples, int count)
-{
-	int i, bit, start;
-
-	printk(KERN_DEBUG "ir samples: ");
-	start = 0;
-	for (i = 0; i < count * 32; i++) {
-		bit = getbit(samples,i);
-		if (bit)
-			start = 1;
-		if (0 == start)
-			continue;
-		printk("%s", bit ? "#" : "_");
-	}
-	printk("\n");
-	return 0;
-}
-EXPORT_SYMBOL_GPL(ir_dump_samples);
-
-/* decode raw samples, pulse distance coding used by NEC remotes */
-int ir_decode_pulsedistance(u32 *samples, int count, int low, int high)
-{
-	int i,last,bit,len;
-	u32 curBit;
-	u32 value;
-
-	/* find start burst */
-	for (i = len = 0; i < count * 32; i++) {
-		bit = getbit(samples,i);
-		if (bit) {
-			len++;
-		} else {
-			if (len >= 29)
-				break;
-			len = 0;
-		}
-	}
-
-	/* start burst to short */
-	if (len < 29)
-		return 0xffffffff;
-
-	/* find start silence */
-	for (len = 0; i < count * 32; i++) {
-		bit = getbit(samples,i);
-		if (bit) {
-			break;
-		} else {
-			len++;
-		}
-	}
-
-	/* silence to short */
-	if (len < 7)
-		return 0xffffffff;
-
-	/* go decoding */
-	len   = 0;
-	last = 1;
-	value = 0; curBit = 1;
-	for (; i < count * 32; i++) {
-		bit  = getbit(samples,i);
-		if (last) {
-			if(bit) {
-				continue;
-			} else {
-				len = 1;
-			}
-		} else {
-			if (bit) {
-				if (len > (low + high) /2)
-					value |= curBit;
-				curBit <<= 1;
-				if (curBit == 1)
-					break;
-			} else {
-				len++;
-			}
-		}
-		last = bit;
-	}
-
-	return value;
-}
-EXPORT_SYMBOL_GPL(ir_decode_pulsedistance);
-
-/* decode raw samples, biphase coding, used by rc5 for example */
-int ir_decode_biphase(u32 *samples, int count, int low, int high)
-{
-	int i,last,bit,len,flips;
-	u32 value;
-
-	/* find start bit (1) */
-	for (i = 0; i < 32; i++) {
-		bit = getbit(samples,i);
-		if (bit)
-			break;
-	}
-
-	/* go decoding */
-	len   = 0;
-	flips = 0;
-	value = 1;
-	for (; i < count * 32; i++) {
-		if (len > high)
-			break;
-		if (flips > 1)
-			break;
-		last = bit;
-		bit  = getbit(samples,i);
-		if (last == bit) {
-			len++;
-			continue;
-		}
-		if (len < low) {
-			len++;
-			flips++;
-			continue;
-		}
-		value <<= 1;
-		value |= bit;
-		flips = 0;
-		len   = 1;
-	}
-	return value;
-}
-EXPORT_SYMBOL_GPL(ir_decode_biphase);
-
 /* RC5 decoding stuff, moved from bttv-input.c to share it with
  * saa7134 */
 
drivers/media/video/cx88/Kconfig +1 -1
index 0fa85cb..bcfd1ac 100644
@@ -1,6 +1,6 @@
 config VIDEO_CX88
 	tristate "Conexant 2388x (bt878 successor) support"
-	depends on VIDEO_DEV && PCI && I2C && INPUT
+	depends on VIDEO_DEV && PCI && I2C && INPUT && IR_CORE
 	select I2C_ALGOBIT
 	select VIDEO_BTCX
 	select VIDEOBUF_DMA_SG
drivers/media/video/cx88/cx88-input.c +36 -127

257 lines not on this page · raw message

include/media/ir-common.h +0 -3
index 528050e..4152420 100644
@@ -96,9 +96,6 @@ void ir_input_nokey(struct input_dev *dev, struct ir_input_state *ir);
 void ir_input_keydown(struct input_dev *dev, struct ir_input_state *ir,
 		      u32 ir_key);
 u32  ir_extract_bits(u32 data, u32 mask);
-int  ir_dump_samples(u32 *samples, int count);
-int  ir_decode_biphase(u32 *samples, int count, int low, int high);
-int  ir_decode_pulsedistance(u32 *samples, int count, int low, int high);
 u32  ir_rc5_decode(unsigned int code);
 
 void ir_rc5_timer_end(unsigned long data);
#2 lore raw

PATCH 2/6 ir-core: remove remaining users of the ir-functions keyhandlers

In reply to David Härdeman

This patch removes the remaining usages of the ir_input_nokey() and ir_input_keydown() functions provided by drivers/media/IR/ir-functions.c by using the corresponding functionality in ir-core instead.

---
 drivers/media/IR/imon.c                     |    9 --
 drivers/media/IR/ir-functions.c             |  101 ++-----------------------
 drivers/media/IR/ir-keytable.c              |  110 ++++++++++++++++++++-------
 drivers/media/video/bt8xx/bttv-input.c      |   32 ++------
 drivers/media/video/bt8xx/bttvp.h           |    1 
 drivers/media/video/cx88/cx88-input.c       |   11 ++-
 drivers/media/video/ir-kbd-i2c.c            |    3 -
 drivers/media/video/saa7134/saa7134-input.c |   49 ++----------
 drivers/staging/tm6000/tm6000-input.c       |   15 +---
 include/media/ir-common.h                   |   31 +-------
 include/media/ir-core.h                     |    3 -
 include/media/ir-kbd-i2c.h                  |    4 -
 12 files changed, 133 insertions(+), 236 deletions(-)
drivers/media/IR/imon.c +2 -7
index bc11806..79f4f58 100644
@@ -1479,17 +1479,12 @@ static void imon_incoming_packet(struct imon_context *ictx,
 	bool norelease = false;
 	int i;
 	u64 scancode;
-	struct input_dev *rdev = NULL;
-	struct ir_input_dev *irdev = NULL;
 	int press_type = 0;
 	int msec;
 	struct timeval t;
 	static struct timeval prev_time = { 0, 0 };
 	u8 ktype;
 
-	rdev = ictx->rdev;
-	irdev = input_get_drvdata(rdev);
-
 	/* filter out junk data on the older 0xffdc imon devices */
 	if ((buf[0] == 0xff) && (buf[1] == 0xff) && (buf[2] == 0xff))
 		return;
@@ -1570,9 +1565,9 @@ static void imon_incoming_packet(struct imon_context *ictx,
 
 	if (ktype != IMON_KEY_PANEL) {
 		if (press_type == 0)
-			ir_keyup(irdev);
+			ir_keyup(ictx->rdev);
 		else {
-			ir_keydown(rdev, ictx->rc_scancode, ictx->rc_toggle);
+			ir_keydown(ictx->rdev, ictx->rc_scancode, ictx->rc_toggle);
 			spin_lock_irqsave(&ictx->kc_lock, flags);
 			ictx->last_keycode = ictx->kc;
 			spin_unlock_irqrestore(&ictx->kc_lock, flags);
drivers/media/IR/ir-functions.c +9 -92

135 lines not on this page · raw message

drivers/media/IR/ir-keytable.c +83 -27

168 lines not on this page · raw message

drivers/media/video/bt8xx/bttv-input.c +9 -23
index 6bf05a7..eb71c3a 100644
@@ -38,8 +38,6 @@ module_param(repeat_period, int, 0644);
 
 static int ir_rc5_remote_gap = 885;
 module_param(ir_rc5_remote_gap, int, 0644);
-static int ir_rc5_key_timeout = 200;
-module_param(ir_rc5_key_timeout, int, 0644);
 
 #undef dprintk
 #define dprintk(arg...) do {	\
@@ -74,18 +72,17 @@ static void ir_handle_key(struct bttv *btv)
 		(gpio & ir->mask_keydown) ? " down" : "",
 		(gpio & ir->mask_keyup)   ? " up"   : "");
 
-	if ((ir->mask_keydown  &&  (0 != (gpio & ir->mask_keydown))) ||
-	    (ir->mask_keyup    &&  (0 == (gpio & ir->mask_keyup)))) {
-		ir_input_keydown(ir->dev, &ir->ir, data);
+	if ((ir->mask_keydown && (gpio & ir->mask_keydown)) ||
+	    (ir->mask_keyup   && !(gpio & ir->mask_keyup))) {
+		ir_keydown_notimeout(ir->dev, data, 0);
 	} else {
 		/* HACK: Probably, ir->mask_keydown is missing
 		   for this board */
 		if (btv->c.type == BTTV_BOARD_WINFAST2000)
-			ir_input_keydown(ir->dev, &ir->ir, data);
+			ir_keydown_notimeout(ir->dev, data, 0);
 
-		ir_input_nokey(ir->dev,&ir->ir);
+		ir_keyup(ir->dev);
 	}
-
 }
 
 static void ir_enltv_handle_key(struct bttv *btv)
@@ -107,9 +104,9 @@ static void ir_enltv_handle_key(struct bttv *btv)
 			gpio, data,
 			(gpio & ir->mask_keyup) ? " up" : "up/down");
 
-		ir_input_keydown(ir->dev, &ir->ir, data);
+		ir_keydown_notimeout(ir->dev, data, 0);
 		if (keyup)
-			ir_input_nokey(ir->dev, &ir->ir);
+			ir_keyup(ir->dev);
 	} else {
 		if ((ir->last_gpio & 1 << 31) == keyup)
 			return;
@@ -119,9 +116,9 @@ static void ir_enltv_handle_key(struct bttv *btv)
 			(gpio & ir->mask_keyup) ? " up" : "down");
 
 		if (keyup)
-			ir_input_nokey(ir->dev, &ir->ir);
+			ir_keyup(ir->dev);
 		else
-			ir_input_keydown(ir->dev, &ir->ir, data);
+			ir_keydown_notimeout(ir->dev, data, 0);
 	}
 
 	ir->last_gpio = data | keyup;
@@ -215,14 +212,9 @@ static void bttv_ir_start(struct bttv *btv, struct card_ir *ir)
 		init_timer(&ir->timer_end);
 		ir->timer_end.function = ir_rc5_timer_end;
 		ir->timer_end.data = (unsigned long)ir;
-
-		init_timer(&ir->timer_keyup);
-		ir->timer_keyup.function = ir_rc5_timer_keyup;
-		ir->timer_keyup.data = (unsigned long)ir;
 		ir->shift_by = 1;
 		ir->start = 3;
 		ir->addr = 0x0;
-		ir->rc5_key_timeout = ir_rc5_key_timeout;
 		ir->rc5_remote_gap = ir_rc5_remote_gap;
 	}
 }
@@ -290,7 +282,6 @@ void __devinit init_bttv_i2c_ir(struct bttv *btv)
 		btv->init_data.name = "PV951";
 		btv->init_data.get_key = get_key_pv951;
 		btv->init_data.ir_codes = RC_MAP_PV951;
-		btv->init_data.type = IR_TYPE_OTHER;
 		info.addr = 0x4b;
 		break;
 	default:
@@ -327,7 +318,6 @@ int bttv_input_init(struct bttv *btv)
 	struct card_ir *ir;
 	char *ir_codes = NULL;
 	struct input_dev *input_dev;
-	u64 ir_type = IR_TYPE_OTHER;
 	int err = -ENOMEM;
 
 	if (!btv->has_remote)
@@ -448,10 +438,6 @@ int bttv_input_init(struct bttv *btv)
 	snprintf(ir->phys, sizeof(ir->phys), "pci-%s/ir0",
 		 pci_name(btv->c.pci));
 
-	err = ir_input_init(input_dev, &ir->ir, ir_type);
-	if (err < 0)
-		goto err_out_free;
-
 	input_dev->name = ir->name;
 	input_dev->phys = ir->phys;
 	input_dev->id.bustype = BUS_PCI;
drivers/media/video/bt8xx/bttvp.h +0 -1
index d1e26a4..157285b 100644
@@ -305,7 +305,6 @@ struct bttv_pll_info {
 /* for gpio-connected remote control */
 struct bttv_input {
 	struct input_dev      *dev;
-	struct ir_input_state ir;
 	char                  name[32];
 	char                  phys[32];
 	u32                   mask_keycode;
drivers/media/video/cx88/cx88-input.c +8 -3
index 436ace8..564e3cb 100644
@@ -131,16 +131,21 @@ static void cx88_ir_handle_key(struct cx88_IR *ir)
 	} else if (ir->mask_keydown) {
 		/* bit set on keydown */
 		if (gpio & ir->mask_keydown)
-			ir_keydown(ir->input, data, 0);
+			ir_keydown_notimeout(ir->input, data, 0);
+		else
+			ir_keyup(ir->input);
 
 	} else if (ir->mask_keyup) {
 		/* bit cleared on keydown */
 		if (0 == (gpio & ir->mask_keyup))
-			ir_keydown(ir->input, data, 0);
+			ir_keydown_notimeout(ir->input, data, 0);
+		else
+			ir_keyup(ir->input);
 
 	} else {
 		/* can't distinguish keydown/up :-/ */
-		ir_keydown(ir->input, data, 0);
+		ir_keydown_notimeout(ir->input, data, 0);
+		ir_keyup(ir->input);
 	}
 }
 
drivers/media/video/ir-kbd-i2c.c +1 -2
index 5a000c6..aee8943 100644
@@ -270,7 +270,7 @@ static int ir_probe(struct i2c_client *client, const struct i2c_device_id *id)
 {
 	char *ir_codes = NULL;
 	const char *name = NULL;
-	u64 ir_type = 0;
+	u64 ir_type = IR_TYPE_UNKNOWN;
 	struct IR_i2c *ir;
 	struct input_dev *input_dev;
 	struct i2c_adapter *adap = client->adapter;
@@ -384,7 +384,6 @@ static int ir_probe(struct i2c_client *client, const struct i2c_device_id *id)
 		 dev_name(&client->dev));
 
 	/* init + register input device */
-	ir->ir_type = ir_type;
 	input_dev->id.bustype = BUS_I2C;
 	input_dev->name       = ir->name;
 	input_dev->phys       = ir->phys;
drivers/media/video/saa7134/saa7134-input.c +10 -39

116 lines not on this page · raw message

drivers/staging/tm6000/tm6000-input.c +4 -11
index 6022caa..3e74884 100644
@@ -25,7 +25,6 @@
 #include <linux/usb.h>
 
 #include <media/ir-core.h>
-#include <media/ir-common.h>
 
 #include "tm6000.h"
 #include "tm6000-regs.h"
@@ -52,7 +51,6 @@ struct tm6000_ir_poll_result {
 struct tm6000_IR {
 	struct tm6000_core	*dev;
 	struct ir_input_dev	*input;
-	struct ir_input_state	ir;
 	char			name[32];
 	char			phys[32];
 
@@ -67,6 +65,7 @@ struct tm6000_IR {
 	int (*get_key) (struct tm6000_IR *, struct tm6000_ir_poll_result *);
 
 	/* IR device properties */
+	u64			ir_type;
 	struct ir_dev_props	props;
 };
 
@@ -145,7 +144,7 @@ static int default_polling_getkey(struct tm6000_IR *ir,
 		return 0;
 
 	if (&dev->int_in) {
-		if (ir->ir.ir_type == IR_TYPE_RC5)
+		if (ir->ir_type == IR_TYPE_RC5)
 			poll_result->rc_data = ir->urb_data[0];
 		else
 			poll_result->rc_data = ir->urb_data[0] | ir->urb_data[1] << 8;
@@ -155,7 +154,7 @@ static int default_polling_getkey(struct tm6000_IR *ir,
 		tm6000_set_reg(dev, REQ_04_EN_DISABLE_MCU_INT, 2, 1);
 		msleep(10);
 
-		if (ir->ir.ir_type == IR_TYPE_RC5) {
+		if (ir->ir_type == IR_TYPE_RC5) {
 			rc = tm6000_read_write_usb(dev, USB_DIR_IN |
 				USB_TYPE_VENDOR | USB_RECIP_DEVICE,
 				REQ_02_GET_IR_CODE, 0, 0, buf, 1);
@@ -201,10 +200,7 @@ static void tm6000_ir_handle_key(struct tm6000_IR *ir)
 	dprintk("ir->get_key result data=%04x\n", poll_result.rc_data);
 
 	if (ir->key) {
-		ir_input_keydown(ir->input->input_dev, &ir->ir,
-				(u32)poll_result.rc_data);
-
-		ir_input_nokey(ir->input->input_dev, &ir->ir);
+		ir_keydown(ir->input->input_dev, poll_result.rc_data, 0);
 		ir->key = 0;
 	}
 	return;
@@ -291,9 +287,6 @@ int tm6000_ir_init(struct tm6000_core *dev)
 	strlcat(ir->phys, "/input0", sizeof(ir->phys));
 
 	tm6000_ir_change_protocol(ir, IR_TYPE_UNKNOWN);
-	err = ir_input_init(ir_input_dev->input_dev, &ir->ir, IR_TYPE_OTHER);
-	if (err < 0)
-		goto err_out_free;
 
 	ir_input_dev->input_dev->name = ir->name;
 	ir_input_dev->input_dev->phys = ir->phys;
include/media/ir-common.h +3 -28
index 4152420..4a32e89 100644
@@ -1,7 +1,7 @@
 /*
- *
- * some common structs and functions to handle infrared remotes via
- * input layer ...
+ * some common functions to handle infrared remote protocol decoding for
+ * drivers which have not yet been (or can't be) converted to use the
+ * regular protocol decoders...
  *
  * (c) 2003 Gerd Knorr <[email protected]> [SuSE Labs]
  *
@@ -33,30 +33,17 @@
 #define RC5_ADDR(x)	(((x)>>6)&31)
 #define RC5_INSTR(x)	((x)&63)
 
-struct ir_input_state {
-	/* configuration */
-	u64      ir_type;
-
-	/* key info */
-	u32                ir_key;      /* ir scancode */
-	u32                keycode;     /* linux key code */
-	int                keypressed;  /* current state */
-};
-
 /* this was saa7134_ir and bttv_ir, moved here for
  * rc5 decoding. */
 struct card_ir {
 	struct input_dev        *dev;
-	struct ir_input_state   ir;
 	char                    name[32];
 	char                    phys[32];
 	int			users;
-
 	u32			running:1;
 	struct ir_dev_props	props;
 
 	/* Usual gpio signalling */
-
 	u32                     mask_keycode;
 	u32                     mask_keydown;
 	u32                     mask_keyup;
@@ -65,7 +52,6 @@ struct card_ir {
 	int			shift_by;
 	int			start; // What should RC5_START() be
 	int			addr; // What RC5_ADDR() should be.
-	int			rc5_key_timeout;
 	int			rc5_remote_gap;
 	struct work_struct      work;
 	struct timer_list       timer;
@@ -73,8 +59,6 @@ struct card_ir {
 	/* RC5 gpio */
 	u32 rc5_gpio;
 	struct timer_list timer_end;	/* timer_end for code completion */
-	struct timer_list timer_keyup;	/* timer_end for key release */
-	u32 last_rc5;			/* last good rc5 code */
 	u32 last_bit;			/* last raw bit seen */
 	u32 code;			/* raw code under construction */
 	struct timeval base_time;	/* time of last seen code */
@@ -89,16 +73,7 @@ struct card_ir {
 };
 
 /* Routines from ir-functions.c */
-
-int ir_input_init(struct input_dev *dev, struct ir_input_state *ir,
-		   const u64 ir_type);
-void ir_input_nokey(struct input_dev *dev, struct ir_input_state *ir);
-void ir_input_keydown(struct input_dev *dev, struct ir_input_state *ir,
-		      u32 ir_key);
 u32  ir_extract_bits(u32 data, u32 mask);
-u32  ir_rc5_decode(unsigned int code);
-
 void ir_rc5_timer_end(unsigned long data);
-void ir_rc5_timer_keyup(unsigned long data);
 
 #endif
include/media/ir-core.h +2 -1
index 6dc37fa..bff75f2 100644
@@ -159,7 +159,8 @@ void ir_input_unregister(struct input_dev *input_dev);
 
 void ir_repeat(struct input_dev *dev);
 void ir_keydown(struct input_dev *dev, int scancode, u8 toggle);
-void ir_keyup(struct ir_input_dev *ir);
+void ir_keydown_notimeout(struct input_dev *dev, int scancode, u8 toggle);
+void ir_keyup(struct input_dev *dev);
 u32 ir_g_keycode_from_table(struct input_dev *input_dev, u32 scancode);
 
 /* From ir-raw-event.c */
include/media/ir-kbd-i2c.h +2 -2
index 557c676..8c37b5e 100644
@@ -12,8 +12,7 @@ struct IR_i2c {
 
 	struct i2c_client      *c;
 	struct input_dev       *input;
-	struct ir_input_state  ir;
-	u64                    ir_type;
+
 	/* Used to avoid fast repeating */
 	unsigned char          old;
 
@@ -41,6 +40,7 @@ struct IR_i2c_init_data {
 	const char		*name;
 	u64			type; /* IR_TYPE_RC5, etc */
 	u32			polling_interval; /* 0 means DEFAULT_POLLING_INTERVAL */
+
 	/*
 	 * Specify either a function pointer or a value indicating one of
 	 * ir_kbd_i2c's internal get_key functions
#3 lore raw

PATCH 3/6 ir-core: more cleanups of ir-functions.c

In reply to David Härdeman

cx88 only depends on VIDEO_IR because it needs ir_extract_bits(). Move that function to ir-core.h and make it inline.

Lots of drivers had dependencies on VIDEO_IR when they really wanted IR_CORE.

The only remaining drivers to depend on VIDEO_IR are bt8xx and saa7134 (ir_rc5_timer_end is the only function exported by ir-functions).

Rename VIDEO_IR -> IR_LEGACY to give a hint to anyone writing or converting drivers to IR_CORE that they do not want a dependency on IR_LEGACY.

---
 drivers/media/IR/Kconfig              |    2 +-
 drivers/media/IR/Makefile             |    2 +-
 drivers/media/IR/ir-functions.c       |   19 -------------------
 drivers/media/dvb/dm1105/Kconfig      |    3 +--
 drivers/media/dvb/ttpci/Kconfig       |    3 +--
 drivers/media/video/Kconfig           |    2 +-
 drivers/media/video/bt8xx/Kconfig     |    4 ++--
 drivers/media/video/cx18/Kconfig      |    3 +--
 drivers/media/video/cx231xx/Kconfig   |    4 ++--
 drivers/media/video/cx88/Kconfig      |    3 +--
 drivers/media/video/cx88/cx88-input.c |    1 -
 drivers/media/video/em28xx/Kconfig    |    4 ++--
 drivers/media/video/ivtv/Kconfig      |    3 +--
 drivers/media/video/saa7134/Kconfig   |    2 +-
 drivers/media/video/tlg2300/Kconfig   |    4 ++--
 drivers/staging/cx25821/Kconfig       |    4 ++--
 drivers/staging/go7007/Kconfig        |    4 ++--
 include/media/ir-common.h             |    1 -
 include/media/ir-core.h               |   19 +++++++++++++++++++
 19 files changed, 40 insertions(+), 47 deletions(-)
drivers/media/IR/Kconfig +1 -1
index aa4163e..20e02a0 100644
@@ -10,7 +10,7 @@ menuconfig IR_CORE
 	  if you don't need IR, as otherwise, you may not be able to
 	  compile the driver for your adapter.
 
-config VIDEO_IR
+config IR_LEGACY
 	tristate
 	depends on IR_CORE
 	default IR_CORE
drivers/media/IR/Makefile +1 -1
index f9574ad..38873cf 100644
@@ -4,7 +4,7 @@ ir-core-objs	:= ir-keytable.o ir-sysfs.o ir-raw-event.o rc-map.o
 obj-y += keymaps/
 
 obj-$(CONFIG_IR_CORE) += ir-core.o
-obj-$(CONFIG_VIDEO_IR) += ir-common.o
+obj-$(CONFIG_IR_LEGACY) += ir-common.o
 obj-$(CONFIG_LIRC) += lirc_dev.o
 obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
 obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
drivers/media/IR/ir-functions.c +0 -19
index fca734c..ec021c9 100644
@@ -31,25 +31,6 @@
 MODULE_AUTHOR("Gerd Knorr <[email protected]> [SuSE Labs]");
 MODULE_LICENSE("GPL");
 
-/* -------------------------------------------------------------------------- */
-/* extract mask bits out of data and pack them into the result */
-u32 ir_extract_bits(u32 data, u32 mask)
-{
-	u32 vbit = 1, value = 0;
-
-	do {
-	    if (mask&1) {
-		if (data&1)
-			value |= vbit;
-		vbit<<=1;
-	    }
-	    data>>=1;
-	} while (mask>>=1);
-
-	return value;
-}
-EXPORT_SYMBOL_GPL(ir_extract_bits);
-
 /* RC5 decoding stuff, moved from bttv-input.c to share it with
  * saa7134 */
 
drivers/media/dvb/dm1105/Kconfig +1 -2
index a6ceb08..576f3b7 100644
@@ -1,7 +1,6 @@
 config DVB_DM1105
 	tristate "SDMC DM1105 based PCI cards"
 	depends on DVB_CORE && PCI && I2C
-	depends on INPUT
 	select DVB_PLL if !DVB_FE_CUSTOMISE
 	select DVB_STV0299 if !DVB_FE_CUSTOMISE
 	select DVB_STV0288 if !DVB_FE_CUSTOMISE
@@ -9,7 +8,7 @@ config DVB_DM1105
 	select DVB_CX24116 if !DVB_FE_CUSTOMISE
 	select DVB_SI21XX if !DVB_FE_CUSTOMISE
 	select DVB_DS3000 if !DVB_FE_CUSTOMISE
-	depends on VIDEO_IR
+	depends on IR_CORE
 	help
 	  Support for cards based on the SDMC DM1105 PCI chip like
 	  DvbWorld 2002
drivers/media/dvb/ttpci/Kconfig +1 -2
index debea8d..0ffd694 100644
@@ -89,7 +89,6 @@ config DVB_BUDGET
 config DVB_BUDGET_CI
 	tristate "Budget cards with onboard CI connector"
 	depends on DVB_BUDGET_CORE && I2C
-	depends on INPUT # due to IR
 	select DVB_STV0297 if !DVB_FE_CUSTOMISE
 	select DVB_STV0299 if !DVB_FE_CUSTOMISE
 	select DVB_TDA1004X if !DVB_FE_CUSTOMISE
@@ -98,7 +97,7 @@ config DVB_BUDGET_CI
 	select DVB_LNBP21 if !DVB_FE_CUSTOMISE
 	select DVB_TDA10023 if !DVB_FE_CUSTOMISE
 	select MEDIA_TUNER_TDA827X if !MEDIA_TUNER_CUSTOMISE
-	depends on VIDEO_IR
+	depends on IR_CORE
 	help
 	  Support for simple SAA7146 based DVB cards
 	  (so called Budget- or Nova-PCI cards) without onboard
drivers/media/video/Kconfig +1 -1
index ac16e81..9c66f50 100644
@@ -96,7 +96,7 @@ config VIDEO_HELPER_CHIPS_AUTO
 
 config VIDEO_IR_I2C
 	tristate "I2C module for IR" if !VIDEO_HELPER_CHIPS_AUTO
-	depends on I2C && VIDEO_IR
+	depends on I2C && IR_CORE
 	default y
 	---help---
 	  Most boards have an IR chip directly connected via GPIO. However,
drivers/media/video/bt8xx/Kconfig +2 -2
index 1a4a89f..659e448 100644
@@ -1,10 +1,10 @@
 config VIDEO_BT848
 	tristate "BT848 Video For Linux"
-	depends on VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT
+	depends on VIDEO_DEV && PCI && I2C && VIDEO_V4L2
 	select I2C_ALGOBIT
 	select VIDEO_BTCX
 	select VIDEOBUF_DMA_SG
-	depends on VIDEO_IR
+	depends on IR_LEGACY
 	select VIDEO_TUNER
 	select VIDEO_TVEEPROM
 	select VIDEO_MSP3400 if VIDEO_HELPER_CHIPS_AUTO
drivers/media/video/cx18/Kconfig +1 -2
index 76c054d..f3c3ccb 100644
@@ -1,9 +1,8 @@
 config VIDEO_CX18
 	tristate "Conexant cx23418 MPEG encoder support"
 	depends on VIDEO_V4L2 && DVB_CORE && PCI && I2C && EXPERIMENTAL
-	depends on INPUT	# due to VIDEO_IR
 	select I2C_ALGOBIT
-	depends on VIDEO_IR
+	depends on IR_CORE
 	select VIDEO_TUNER
 	select VIDEO_TVEEPROM
 	select VIDEO_CX2341X
drivers/media/video/cx231xx/Kconfig +2 -2
index bb04914..99f8683 100644
@@ -1,9 +1,9 @@
 config VIDEO_CX231XX
 	tristate "Conexant cx231xx USB video capture support"
-	depends on VIDEO_DEV && I2C && INPUT
+	depends on VIDEO_DEV && I2C
 	select VIDEO_TUNER
 	select VIDEO_TVEEPROM
-	depends on VIDEO_IR
+	depends on IR_CORE
 	select VIDEOBUF_VMALLOC
 	select VIDEO_CX25840
 	select VIDEO_CX2341X
drivers/media/video/cx88/Kconfig +1 -2
index bcfd1ac..dbae629 100644
@@ -1,12 +1,11 @@
 config VIDEO_CX88
 	tristate "Conexant 2388x (bt878 successor) support"
-	depends on VIDEO_DEV && PCI && I2C && INPUT && IR_CORE
+	depends on VIDEO_DEV && PCI && I2C && IR_CORE
 	select I2C_ALGOBIT
 	select VIDEO_BTCX
 	select VIDEOBUF_DMA_SG
 	select VIDEO_TUNER
 	select VIDEO_TVEEPROM
-	depends on VIDEO_IR
 	select VIDEO_WM8775 if VIDEO_HELPER_CHIPS_AUTO
 	---help---
 	  This is a video4linux driver for Conexant 2388x based
drivers/media/video/cx88/cx88-input.c +0 -1
index 564e3cb..8c41124 100644
@@ -31,7 +31,6 @@
 
 #include "cx88.h"
 #include <media/ir-core.h>
-#include <media/ir-common.h>
 
 #define MODULE_NAME "cx88xx"
 
drivers/media/video/em28xx/Kconfig +2 -2
index 66aefd6..f363069 100644
@@ -1,9 +1,9 @@
 config VIDEO_EM28XX
 	tristate "Empia EM28xx USB video capture support"
-	depends on VIDEO_DEV && I2C && INPUT
+	depends on VIDEO_DEV && I2C
 	select VIDEO_TUNER
 	select VIDEO_TVEEPROM
-	depends on VIDEO_IR
+	depends on IR_CORE
 	select VIDEOBUF_VMALLOC
 	select VIDEO_SAA711X if VIDEO_HELPER_CHIPS_AUTO
 	select VIDEO_TVP5150 if VIDEO_HELPER_CHIPS_AUTO
drivers/media/video/ivtv/Kconfig +1 -2
index be4af1f..c4f1980 100644
@@ -1,9 +1,8 @@
 config VIDEO_IVTV
 	tristate "Conexant cx23416/cx23415 MPEG encoder/decoder support"
 	depends on VIDEO_V4L2 && PCI && I2C
-	depends on INPUT   # due to VIDEO_IR
 	select I2C_ALGOBIT
-	depends on VIDEO_IR
+	depends on IR_CORE
 	select VIDEO_TUNER
 	select VIDEO_TVEEPROM
 	select VIDEO_CX2341X
drivers/media/video/saa7134/Kconfig +1 -1
index 3fe71be..32a95a2 100644
@@ -26,7 +26,7 @@ config VIDEO_SAA7134_ALSA
 
 config VIDEO_SAA7134_RC
 	bool "Philips SAA7134 Remote Controller support"
-	depends on VIDEO_IR
+	depends on IR_LEGACY
 	depends on VIDEO_SAA7134
 	default y
 	---help---
drivers/media/video/tlg2300/Kconfig +2 -2
index 1686ebf..580580e 100644
@@ -1,9 +1,9 @@
 config VIDEO_TLG2300
 	tristate "Telegent TLG2300 USB video capture support"
-	depends on VIDEO_DEV && I2C && INPUT && SND && DVB_CORE
+	depends on VIDEO_DEV && I2C && SND && DVB_CORE
 	select VIDEO_TUNER
 	select VIDEO_TVEEPROM
-	depends on VIDEO_IR
+	depends on IR_CORE
 	select VIDEOBUF_VMALLOC
 	select SND_PCM
 	select VIDEOBUF_DVB
drivers/staging/cx25821/Kconfig +2 -2
index 1d73334..f8f2bb0 100644
@@ -1,11 +1,11 @@
 config VIDEO_CX25821
 	tristate "Conexant cx25821 support"
-	depends on DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT
+	depends on DVB_CORE && VIDEO_DEV && PCI && I2C
 	depends on BKL # please fix
 	select I2C_ALGOBIT
 	select VIDEO_BTCX
 	select VIDEO_TVEEPROM
-	depends on VIDEO_IR
+	depends on IR_CORE
 	select VIDEOBUF_DVB
 	select VIDEOBUF_DMA_SG
 	select VIDEO_CX25840
drivers/staging/go7007/Kconfig +2 -2
index 3aecd30..edc9091 100644
@@ -1,10 +1,10 @@
 config VIDEO_GO7007
 	tristate "WIS GO7007 MPEG encoder support"
-	depends on VIDEO_DEV && PCI && I2C && INPUT
+	depends on VIDEO_DEV && PCI && I2C
 	depends on BKL # please fix
 	depends on SND
 	select VIDEOBUF_DMA_SG
-	depends on VIDEO_IR
+	depends on IR_CORE
 	select VIDEO_TUNER
 	select VIDEO_TVEEPROM
 	select SND_PCM
include/media/ir-common.h +0 -1
index 4a32e89..d1ae869 100644
@@ -73,7 +73,6 @@ struct card_ir {
 };
 
 /* Routines from ir-functions.c */
-u32  ir_extract_bits(u32 data, u32 mask);
 void ir_rc5_timer_end(unsigned long data);
 
 #endif
include/media/ir-core.h +19 -0
index bff75f2..53048a2 100644
@@ -212,4 +212,23 @@ static inline void ir_raw_event_reset(struct input_dev *input_dev)
 	ir_raw_event_handle(input_dev);
 }
 
+
+/* extract mask bits out of data and pack them into the result */
+static inline u32 ir_extract_bits(u32 data, u32 mask)
+{
+	u32 vbit = 1, value = 0;
+
+	do {
+	    if (mask & 1) {
+		if (data & 1)
+			value |= vbit;
+		vbit <<= 1;
+	    }
+	    data >>= 1;
+	} while (mask >>= 1);
+
+	return value;
+}
+
+
 #endif /* _IR_CORE */
#4 lore raw

PATCH 4/6 ir-core: merge and rename to rc-core

In reply to David Härdeman

This patch merges the files which makes up ir-core and renames the resulting module to rc-core. ir-raw-event.c is still kept as a separate file (but renamed to rc-raw.c) as suggested by Mauro.

---
 drivers/media/IR/Makefile       |    4 
 drivers/media/IR/ir-core-priv.h |   10 
 drivers/media/IR/ir-keytable.c  |  766 -------------------------
 drivers/media/IR/ir-raw-event.c |  382 ------------
 drivers/media/IR/ir-sysfs.c     |  362 ------------
 drivers/media/IR/rc-main.c      | 1199 +++++++++++++++++++++++++++++++++++++++
 drivers/media/IR/rc-map.c       |  107 ---
 drivers/media/IR/rc-raw.c       |  382 ++++++++++++
 include/media/ir-core.h         |    2 
 9 files changed, 1583 insertions(+), 1631 deletions(-)
 delete mode 100644 drivers/media/IR/ir-keytable.c
 delete mode 100644 drivers/media/IR/ir-raw-event.c
 delete mode 100644 drivers/media/IR/ir-sysfs.c
 create mode 100644 drivers/media/IR/rc-main.c
 delete mode 100644 drivers/media/IR/rc-map.c
 create mode 100644 drivers/media/IR/rc-raw.c
drivers/media/IR/Makefile +2 -2
index 38873cf..1eb24e6 100644
@@ -1,9 +1,9 @@
 ir-common-objs  := ir-functions.o
-ir-core-objs	:= ir-keytable.o ir-sysfs.o ir-raw-event.o rc-map.o
+rc-core-objs	:= rc-main.o rc-raw.o
 
 obj-y += keymaps/
 
-obj-$(CONFIG_IR_CORE) += ir-core.o
+obj-$(CONFIG_IR_CORE) += rc-core.o
 obj-$(CONFIG_IR_LEGACY) += ir-common.o
 obj-$(CONFIG_LIRC) += lirc_dev.o
 obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
drivers/media/IR/ir-core-priv.h +0 -10
index 81c936b..4be0757 100644
@@ -129,14 +129,6 @@ static inline bool is_timing_event(struct ir_raw_event ev)
 
 #define TO_US(duration)			DIV_ROUND_CLOSEST((duration), 1000)
 #define TO_STR(is_pulse)		((is_pulse) ? "pulse" : "space")
-/*
- * Routines from ir-sysfs.c - Meant to be called only internally inside
- * ir-core
- */
-int ir_register_input(struct input_dev *input_dev);
-
-int ir_register_class(struct input_dev *input_dev);
-void ir_unregister_class(struct input_dev *input_dev);
 
 /*
  * Routines from ir-raw-event.c to be used internally and by decoders
@@ -148,8 +140,6 @@ int ir_raw_handler_register(struct ir_raw_handler *ir_raw_handler);
 void ir_raw_handler_unregister(struct ir_raw_handler *ir_raw_handler);
 void ir_raw_init(void);
 
-int ir_rcmap_init(void);
-void ir_rcmap_cleanup(void);
 /*
  * Decoder initialization code
  *
drivers/media/IR/ir-keytable.c deleted +0 -766

766 lines not on this page · raw message

drivers/media/IR/ir-raw-event.c deleted +0 -382

382 lines not on this page · raw message

drivers/media/IR/ir-sysfs.c deleted +0 -362

362 lines not on this page · raw message

drivers/media/IR/rc-main.c new file +1199 -0

1,199 lines not on this page · raw message

drivers/media/IR/rc-map.c deleted +0 -107

107 lines not on this page · raw message

drivers/media/IR/rc-raw.c new file +382 -0

151 lines not on this page · raw message

include/media/ir-core.h +0 -2
index 53048a2..d41502d 100644

Lines of this file are not shown. View the raw message.

The rest of this diff is not shown. View the raw message.

Part of the diff is not shown here. View the raw message.

#5 lore raw

PATCH 5/6 ir-core: make struct rc_dev the primary interface

In reply to David Härdeman

This patch merges the ir_input_dev and ir_dev_props structs into a single struct called rc_dev. The drivers and various functions in rc-core used by the drivers are also changed to use rc_dev as the primary interface when dealing with rc-core.

This means that the input_dev is abstracted away from the drivers which is necessary if we ever want to support multiple input devs per rc device.

The new API is similar to what the input subsystem uses, i.e:
rc_device_alloc()
rc_device_free()
rc_device_register()
rc_device_unregister()

---
 drivers/media/IR/ene_ir.c                   |  129 +++---
 drivers/media/IR/ene_ir.h                   |    3 
 drivers/media/IR/imon.c                     |   58 +--
 drivers/media/IR/ir-core-priv.h             |   16 -
 drivers/media/IR/ir-jvc-decoder.c           |   13 -
 drivers/media/IR/ir-lirc-codec.c            |  121 ++---
 drivers/media/IR/ir-nec-decoder.c           |   15 -
 drivers/media/IR/ir-rc5-decoder.c           |   13 -
 drivers/media/IR/ir-rc5-sz-decoder.c        |   13 -
 drivers/media/IR/ir-rc6-decoder.c           |   17 -
 drivers/media/IR/ir-sony-decoder.c          |   11 
 drivers/media/IR/mceusb.c                   |  105 ++---
 drivers/media/IR/nuvoton-cir.c              |   85 ++--
 drivers/media/IR/nuvoton-cir.h              |    3 
 drivers/media/IR/rc-main.c                  |  612 ++++++++++++---------------
 drivers/media/IR/rc-raw.c                   |  191 ++++----
 drivers/media/IR/streamzap.c                |   66 +--
 drivers/media/dvb/dm1105/dm1105.c           |   42 +-
 drivers/media/dvb/dvb-usb/af9015.c          |   16 -
 drivers/media/dvb/dvb-usb/anysee.c          |    2 
 drivers/media/dvb/dvb-usb/dib0700.h         |    2 
 drivers/media/dvb/dvb-usb/dib0700_core.c    |    8 
 drivers/media/dvb/dvb-usb/dib0700_devices.c |  144 +++---
 drivers/media/dvb/dvb-usb/dvb-usb-remote.c  |   77 ++-
 drivers/media/dvb/dvb-usb/dvb-usb.h         |   12 -
 drivers/media/dvb/dvb-usb/lmedm04.c         |   42 +-
 drivers/media/dvb/mantis/mantis_common.h    |    4 
 drivers/media/dvb/mantis/mantis_input.c     |   71 ++-
 drivers/media/dvb/siano/smscoreapi.c        |    2 
 drivers/media/dvb/siano/smsir.c             |   52 +-
 drivers/media/dvb/siano/smsir.h             |    3 
 drivers/media/dvb/ttpci/budget-ci.c         |   49 +-
 drivers/media/video/bt8xx/bttv-input.c      |   41 +-
 drivers/media/video/cx23885/cx23885-input.c |   64 +--
 drivers/media/video/cx23885/cx23885.h       |    3 
 drivers/media/video/cx88/cx88-input.c       |   96 ++--
 drivers/media/video/em28xx/em28xx-input.c   |   72 +--
 drivers/media/video/ir-kbd-i2c.c            |   25 +
 drivers/media/video/saa7134/saa7134-input.c |   72 +--
 drivers/staging/tm6000/tm6000-input.c       |   85 ++--
 include/media/ir-common.h                   |    3 
 include/media/ir-core.h                     |  181 ++++----
 include/media/ir-kbd-i2c.h                  |    3 
 43 files changed, 1212 insertions(+), 1430 deletions(-)
drivers/media/IR/ene_ir.c +60 -69
index 7637bab..0a4151f 100644
@@ -37,9 +37,7 @@
 #include <linux/interrupt.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
-#include <linux/input.h>
 #include <media/ir-core.h>
-#include <media/ir-common.h>
 #include "ene_ir.h"
 
 static int sample_period;
@@ -357,7 +355,7 @@ void ene_rx_sense_carrier(struct ene_device *dev)
 		ev.carrier_report = true;
 		ev.carrier = carrier;
 		ev.duty_cycle = duty_cycle;
-		ir_raw_event_store(dev->idev, &ev);
+		ir_raw_event_store(dev->rdev, &ev);
 	}
 }
 
@@ -448,32 +446,32 @@ static void ene_rx_setup(struct ene_device *dev)
 
 select_timeout:
 	if (dev->rx_fan_input_inuse) {
-		dev->props->rx_resolution = MS_TO_NS(ENE_FW_SAMPLE_PERIOD_FAN);
+		dev->rdev->rx_resolution = MS_TO_NS(ENE_FW_SAMPLE_PERIOD_FAN);
 
 		/* Fan input doesn't support timeouts, it just ends the
 			input with a maximum sample */
-		dev->props->min_timeout = dev->props->max_timeout =
+		dev->rdev->min_timeout = dev->rdev->max_timeout =
 			MS_TO_NS(ENE_FW_SMPL_BUF_FAN_MSK *
 				ENE_FW_SAMPLE_PERIOD_FAN);
 	} else {
-		dev->props->rx_resolution = MS_TO_NS(sample_period);
+		dev->rdev->rx_resolution = MS_TO_NS(sample_period);
 
 		/* Theoreticly timeout is unlimited, but we cap it
 		 * because it was seen that on one device, it
 		 * would stop sending spaces after around 250 msec.
 		 * Besides, this is close to 2^32 anyway and timeout is u32.
 		 */
-		dev->props->min_timeout = MS_TO_NS(127 * sample_period);
-		dev->props->max_timeout = MS_TO_NS(200000);
+		dev->rdev->min_timeout = MS_TO_NS(127 * sample_period);
+		dev->rdev->max_timeout = MS_TO_NS(200000);
 	}
 
 	if (dev->hw_learning_and_tx_capable)
-		dev->props->tx_resolution = MS_TO_NS(sample_period);
+		dev->rdev->tx_resolution = MS_TO_NS(sample_period);
 
-	if (dev->props->timeout > dev->props->max_timeout)
-		dev->props->timeout = dev->props->max_timeout;
-	if (dev->props->timeout < dev->props->min_timeout)
-		dev->props->timeout = dev->props->min_timeout;
+	if (dev->rdev->timeout > dev->rdev->max_timeout)
+		dev->rdev->timeout = dev->rdev->max_timeout;
+	if (dev->rdev->timeout < dev->rdev->min_timeout)
+		dev->rdev->timeout = dev->rdev->min_timeout;
 }
 
 /* Enable the device for receive */
@@ -504,7 +502,7 @@ static void ene_rx_enable(struct ene_device *dev)
 	ene_set_reg_mask(dev, ENE_FW1, ENE_FW1_ENABLE | ENE_FW1_IRQ);
 
 	/* enter idle mode */
-	ir_raw_event_set_idle(dev->idev, true);
+	ir_raw_event_set_idle(dev->rdev, true);
 	dev->rx_enabled = true;
 }
 
@@ -518,7 +516,7 @@ static void ene_rx_disable(struct ene_device *dev)
 	/* disable hardware IRQ and firmware flag */
 	ene_clear_reg_mask(dev, ENE_FW1, ENE_FW1_ENABLE | ENE_FW1_IRQ);
 
-	ir_raw_event_set_idle(dev->idev, true);
+	ir_raw_event_set_idle(dev->rdev, true);
 	dev->rx_enabled = false;
 }
 
@@ -805,10 +803,10 @@ static irqreturn_t ene_isr(int irq, void *data)
 
 		ev.duration = MS_TO_NS(hw_sample);
 		ev.pulse = pulse;
-		ir_raw_event_store_with_filter(dev->idev, &ev);
+		ir_raw_event_store_with_filter(dev->rdev, &ev);
 	}
 
-	ir_raw_event_handle(dev->idev);
+	ir_raw_event_handle(dev->rdev);
 unlock:
 	spin_unlock_irqrestore(&dev->hw_lock, flags);
 	return retval;
@@ -823,7 +821,7 @@ static void ene_setup_default_settings(struct ene_device *dev)
 	dev->learning_mode_enabled = learning_mode_force;
 
 	/* Set reasonable default timeout */
-	dev->props->timeout = MS_TO_NS(150000);
+	dev->rdev->timeout = MS_TO_NS(150000);
 }
 
 /* Upload all hardware settings at once. Used at load and resume time */
@@ -838,9 +836,9 @@ static void ene_setup_hw_settings(struct ene_device *dev)
 }
 
 /* outside interface: called on first open*/
-static int ene_open(void *data)
+static int ene_open(struct rc_dev *rdev)
 {
-	struct ene_device *dev = (struct ene_device *)data;
+	struct ene_device *dev = rdev->priv;
 	unsigned long flags;
 
 	spin_lock_irqsave(&dev->hw_lock, flags);
@@ -850,9 +848,9 @@ static int ene_open(void *data)
 }
 
 /* outside interface: called on device close*/
-static void ene_close(void *data)
+static void ene_close(struct rc_dev *rdev)
 {
-	struct ene_device *dev = (struct ene_device *)data;
+	struct ene_device *dev = rdev->priv;
 	unsigned long flags;
 	spin_lock_irqsave(&dev->hw_lock, flags);
 
@@ -861,9 +859,9 @@ static void ene_close(void *data)
 }
 
 /* outside interface: set transmitter mask */
-static int ene_set_tx_mask(void *data, u32 tx_mask)
+static int ene_set_tx_mask(struct rc_dev *rdev, u32 tx_mask)
 {
-	struct ene_device *dev = (struct ene_device *)data;
+	struct ene_device *dev = rdev->priv;
 	dbg("TX: attempt to set transmitter mask %02x", tx_mask);
 
 	/* invalid txmask */
@@ -879,9 +877,9 @@ static int ene_set_tx_mask(void *data, u32 tx_mask)
 }
 
 /* outside interface : set tx carrier */
-static int ene_set_tx_carrier(void *data, u32 carrier)
+static int ene_set_tx_carrier(struct rc_dev *rdev, u32 carrier)
 {
-	struct ene_device *dev = (struct ene_device *)data;
+	struct ene_device *dev = rdev->priv;
 	u32 period = 2000000 / carrier;
 
 	dbg("TX: attempt to set tx carrier to %d kHz", carrier);
@@ -900,9 +898,9 @@ static int ene_set_tx_carrier(void *data, u32 carrier)
 }
 
 /*outside interface : set tx duty cycle */
-static int ene_set_tx_duty_cycle(void *data, u32 duty_cycle)
+static int ene_set_tx_duty_cycle(struct rc_dev *rdev, u32 duty_cycle)
 {
-	struct ene_device *dev = (struct ene_device *)data;
+	struct ene_device *dev = rdev->priv;
 	dbg("TX: setting duty cycle to %d%%", duty_cycle);
 	dev->tx_duty_cycle = duty_cycle;
 	ene_tx_set_carrier(dev);
@@ -910,9 +908,9 @@ static int ene_set_tx_duty_cycle(void *data, u32 duty_cycle)
 }
 
 /* outside interface: enable learning mode */
-static int ene_set_learning_mode(void *data, int enable)
+static int ene_set_learning_mode(struct rc_dev *rdev, int enable)
 {
-	struct ene_device *dev = (struct ene_device *)data;
+	struct ene_device *dev = rdev->priv;
 	unsigned long flags;
 	if (enable == dev->learning_mode_enabled)
 		return 0;
@@ -926,9 +924,9 @@ static int ene_set_learning_mode(void *data, int enable)
 	return 0;
 }
 
-static int ene_set_carrier_report(void *data, int enable)
+static int ene_set_carrier_report(struct rc_dev *rdev, int enable)
 {
-	struct ene_device *dev = (struct ene_device *)data;
+	struct ene_device *dev = rdev->priv;
 	unsigned long flags;
 
 	if (enable == dev->carrier_detect_enabled)
@@ -944,18 +942,20 @@ static int ene_set_carrier_report(void *data, int enable)
 }
 
 /* outside interface: enable or disable idle mode */
-static void ene_set_idle(void *data, bool idle)
+static void ene_set_idle(struct rc_dev *rdev, bool idle)
 {
+	struct ene_device *dev = rdev->priv;
+
 	if (idle) {
-		ene_rx_reset((struct ene_device *)data);
+		ene_rx_reset(dev);
 		dbg("RX: end of data");
 	}
 }
 
 /* outside interface: transmit */
-static int ene_transmit(void *data, int *buf, u32 n)
+static int ene_transmit(struct rc_dev *rdev, int *buf, u32 n)
 {
-	struct ene_device *dev = (struct ene_device *)data;
+	struct ene_device *dev = rdev->priv;
 	unsigned long flags;
 
 	dev->tx_buffer = buf;
@@ -992,16 +992,13 @@ static int ene_transmit(void *data, int *buf, u32 n)
 static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
 {
 	int error = -ENOMEM;
-	struct ir_dev_props *ir_props;
-	struct input_dev *input_dev;
+	struct rc_dev *rdev;
 	struct ene_device *dev;
 
 	/* allocate memory */
-	input_dev = input_allocate_device();
-	ir_props = kzalloc(sizeof(struct ir_dev_props), GFP_KERNEL);
 	dev = kzalloc(sizeof(struct ene_device), GFP_KERNEL);
-
-	if (!input_dev || !ir_props || !dev)
+	rdev = rc_allocate_device();
+	if (!dev || !rdev)
 		goto error1;
 
 	/* validate resources */
@@ -1054,24 +1051,25 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
 	if (!dev->hw_learning_and_tx_capable)
 		learning_mode_force = false;
 
-	ir_props->driver_type = RC_DRIVER_IR_RAW;
-	ir_props->allowed_protos = IR_TYPE_ALL;
-	ir_props->priv = dev;
-	ir_props->open = ene_open;
-	ir_props->close = ene_close;
-	ir_props->s_idle = ene_set_idle;
-
-	dev->props = ir_props;
-	dev->idev = input_dev;
+	rdev->driver_type = RC_DRIVER_IR_RAW;
+	rdev->allowed_protos = IR_TYPE_ALL;
+	rdev->priv = dev;
+	rdev->open = ene_open;
+	rdev->close = ene_close;
+	rdev->s_idle = ene_set_idle;
+	rdev->driver_name = ENE_DRIVER_NAME;
+	rdev->map_name = RC_MAP_RC6_MCE;
+	rdev->input_name = "ENE eHome Infrared Remote Receiver";
 
 	if (dev->hw_learning_and_tx_capable) {
-		ir_props->s_learning_mode = ene_set_learning_mode;
+		rdev->s_learning_mode = ene_set_learning_mode;
 		init_completion(&dev->tx_complete);
-		ir_props->tx_ir = ene_transmit;
-		ir_props->s_tx_mask = ene_set_tx_mask;
-		ir_props->s_tx_carrier = ene_set_tx_carrier;
-		ir_props->s_tx_duty_cycle = ene_set_tx_duty_cycle;
-		ir_props->s_carrier_report = ene_set_carrier_report;
+		rdev->tx_ir = ene_transmit;
+		rdev->s_tx_mask = ene_set_tx_mask;
+		rdev->s_tx_carrier = ene_set_tx_carrier;
+		rdev->s_tx_duty_cycle = ene_set_tx_duty_cycle;
+		rdev->s_carrier_report = ene_set_carrier_report;
+		rdev->input_name = "ENE eHome Infrared Remote Transceiver";
 	}
 
 	ene_rx_setup_hw_buffer(dev);
@@ -1081,16 +1079,11 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
 	device_set_wakeup_capable(&pnp_dev->dev, true);
 	device_set_wakeup_enable(&pnp_dev->dev, true);
 
-	if (dev->hw_learning_and_tx_capable)
-		input_dev->name = "ENE eHome Infrared Remote Transceiver";
-	else
-		input_dev->name = "ENE eHome Infrared Remote Receiver";
-
-	error = -ENODEV;
-	if (ir_input_register(input_dev, RC_MAP_RC6_MCE, ir_props,
-							ENE_DRIVER_NAME))
+	error = rc_register_device(rdev);
+	if (error < 0)
 		goto error;
 
+	dev->rdev = rdev;
 	ene_notice("driver has been succesfully loaded");
 	return 0;
 error:
@@ -1099,8 +1092,7 @@ error:
 	if (dev && dev->hw_io >= 0)
 		release_region(dev->hw_io, ENE_IO_SIZE);
 error1:
-	input_free_device(input_dev);
-	kfree(ir_props);
+	rc_free_device(rdev);
 	kfree(dev);
 	return error;
 }
@@ -1118,8 +1110,7 @@ static void ene_remove(struct pnp_dev *pnp_dev)
 
 	free_irq(dev->irq, dev);
 	release_region(dev->hw_io, ENE_IO_SIZE);
-	ir_input_unregister(dev->idev);
-	kfree(dev->props);
+	rc_unregister_device(dev->rdev);
 	kfree(dev);
 }
 
drivers/media/IR/ene_ir.h +1 -2
index f587066..c179baf 100644
@@ -205,8 +205,7 @@
 
 struct ene_device {
 	struct pnp_dev *pnp_dev;
-	struct input_dev *idev;
-	struct ir_dev_props *props;
+	struct rc_dev *rdev;
 
 	/* hw IO settings */
 	long hw_io;
drivers/media/IR/imon.c +25 -33

132 lines not on this page · raw message

drivers/media/IR/ir-core-priv.h +8 -8
index 4be0757..3616c32 100644
@@ -24,11 +24,11 @@ struct ir_raw_handler {
 	struct list_head list;
 
 	u64 protocols; /* which are handled by this handler */
-	int (*decode)(struct input_dev *input_dev, struct ir_raw_event event);
+	int (*decode)(struct rc_dev *dev, struct ir_raw_event event);
 
 	/* These two should only be used by the lirc decoder */
-	int (*raw_register)(struct input_dev *input_dev);
-	int (*raw_unregister)(struct input_dev *input_dev);
+	int (*raw_register)(struct rc_dev *dev);
+	int (*raw_unregister)(struct rc_dev *dev);
 };
 
 struct ir_raw_event_ctrl {
@@ -38,7 +38,7 @@ struct ir_raw_event_ctrl {
 	struct kfifo			kfifo;		/* fifo for the pulse/space durations */
 	ktime_t				last_event;	/* when last event occurred */
 	enum raw_event_type		last_type;	/* last event type */
-	struct input_dev		*input_dev;	/* pointer to the parent input_dev */
+	struct rc_dev			*dev;		/* pointer to the parent rc_dev */
 	u64				enabled_protocols; /* enabled raw protocol decoders */
 
 	/* raw decoder state follows */
@@ -85,7 +85,7 @@ struct ir_raw_event_ctrl {
 		unsigned wanted_bits;
 	} rc5_sz;
 	struct lirc_codec {
-		struct ir_input_dev *ir_dev;
+		struct rc_dev *dev;
 		struct lirc_driver *drv;
 		int carrier_low;
 
@@ -131,11 +131,11 @@ static inline bool is_timing_event(struct ir_raw_event ev)
 #define TO_STR(is_pulse)		((is_pulse) ? "pulse" : "space")
 
 /*
- * Routines from ir-raw-event.c to be used internally and by decoders
+ * Routines from rc-raw.c to be used internally and by decoders
  */
 u64 ir_raw_get_allowed_protocols(void);
-int ir_raw_event_register(struct input_dev *input_dev);
-void ir_raw_event_unregister(struct input_dev *input_dev);
+int ir_raw_event_register(struct rc_dev *dev);
+void ir_raw_event_unregister(struct rc_dev *dev);
 int ir_raw_handler_register(struct ir_raw_handler *ir_raw_handler);
 void ir_raw_handler_unregister(struct ir_raw_handler *ir_raw_handler);
 void ir_raw_init(void);
drivers/media/IR/ir-jvc-decoder.c +6 -7
index 63dca6e..5d4bc32 100644
@@ -37,17 +37,16 @@ enum jvc_state {
 
 /**
  * ir_jvc_decode() - Decode one JVC pulse or space
- * @input_dev:	the struct input_dev descriptor of the device
+ * @dev:	the struct rc_dev descriptor of the device
  * @duration:   the struct ir_raw_event descriptor of the pulse/space
  *
  * This function returns -EINVAL if the pulse violates the state machine
  */
-static int ir_jvc_decode(struct input_dev *input_dev, struct ir_raw_event ev)
+static int ir_jvc_decode(struct rc_dev *dev, struct ir_raw_event ev)
 {
-	struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
-	struct jvc_dec *data = &ir_dev->raw->jvc;
+	struct jvc_dec *data = &dev->raw->jvc;
 
-	if (!(ir_dev->raw->enabled_protocols & IR_TYPE_JVC))
+	if (!(dev->raw->enabled_protocols & IR_TYPE_JVC))
 		return 0;
 
 	if (!is_timing_event(ev)) {
@@ -140,12 +139,12 @@ again:
 			scancode = (bitrev8((data->bits >> 8) & 0xff) << 8) |
 				   (bitrev8((data->bits >> 0) & 0xff) << 0);
 			IR_dprintk(1, "JVC scancode 0x%04x\n", scancode);
-			ir_keydown(input_dev, scancode, data->toggle);
+			ir_keydown(dev, scancode, data->toggle);
 			data->first = false;
 			data->old_bits = data->bits;
 		} else if (data->bits == data->old_bits) {
 			IR_dprintk(1, "JVC repeat\n");
-			ir_repeat(input_dev);
+			ir_repeat(dev);
 		} else {
 			IR_dprintk(1, "JVC invalid repeat msg\n");
 			break;
drivers/media/IR/ir-lirc-codec.c +56 -65

290 lines not on this page · raw message

drivers/media/IR/ir-nec-decoder.c +7 -8
index 70993f7..7ec1543 100644
@@ -39,19 +39,18 @@ enum nec_state {
 
 /**
  * ir_nec_decode() - Decode one NEC pulse or space
- * @input_dev:	the struct input_dev descriptor of the device
+ * @dev:	the struct rc_dev descriptor of the device
  * @duration:	the struct ir_raw_event descriptor of the pulse/space
  *
  * This function returns -EINVAL if the pulse violates the state machine
  */
-static int ir_nec_decode(struct input_dev *input_dev, struct ir_raw_event ev)
+static int ir_nec_decode(struct rc_dev *dev, struct ir_raw_event ev)
 {
-	struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
-	struct nec_dec *data = &ir_dev->raw->nec;
+	struct nec_dec *data = &dev->raw->nec;
 	u32 scancode;
 	u8 address, not_address, command, not_command;
 
-	if (!(ir_dev->raw->enabled_protocols & IR_TYPE_NEC))
+	if (!(dev->raw->enabled_protocols & IR_TYPE_NEC))
 		return 0;
 
 	if (!is_timing_event(ev)) {
@@ -89,7 +88,7 @@ static int ir_nec_decode(struct input_dev *input_dev, struct ir_raw_event ev)
 			data->state = STATE_BIT_PULSE;
 			return 0;
 		} else if (eq_margin(ev.duration, NEC_REPEAT_SPACE, NEC_UNIT / 2)) {
-			ir_repeat(input_dev);
+			ir_repeat(dev);
 			IR_dprintk(1, "Repeat last key\n");
 			data->state = STATE_TRAILER_PULSE;
 			return 0;
@@ -115,7 +114,7 @@ static int ir_nec_decode(struct input_dev *input_dev, struct ir_raw_event ev)
 			geq_margin(ev.duration,
 			NEC_TRAILER_SPACE, NEC_UNIT / 2)) {
 				IR_dprintk(1, "Repeat last key\n");
-				ir_repeat(input_dev);
+				ir_repeat(dev);
 				data->state = STATE_INACTIVE;
 				return 0;
 
@@ -179,7 +178,7 @@ static int ir_nec_decode(struct input_dev *input_dev, struct ir_raw_event ev)
 		if (data->is_nec_x)
 			data->necx_repeat = true;
 
-		ir_keydown(input_dev, scancode, 0);
+		ir_keydown(dev, scancode, 0);
 		data->state = STATE_INACTIVE;
 		return 0;
 	}
drivers/media/IR/ir-rc5-decoder.c +6 -7
index 572ed4c..e200d5f 100644
@@ -40,19 +40,18 @@ enum rc5_state {
 
 /**
  * ir_rc5_decode() - Decode one RC-5 pulse or space
- * @input_dev:	the struct input_dev descriptor of the device
+ * @dev:	the struct rc_dev descriptor of the device
  * @ev:		the struct ir_raw_event descriptor of the pulse/space
  *
  * This function returns -EINVAL if the pulse violates the state machine
  */
-static int ir_rc5_decode(struct input_dev *input_dev, struct ir_raw_event ev)
+static int ir_rc5_decode(struct rc_dev *dev, struct ir_raw_event ev)
 {
-	struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
-	struct rc5_dec *data = &ir_dev->raw->rc5;
+	struct rc5_dec *data = &dev->raw->rc5;
 	u8 toggle;
 	u32 scancode;
 
-        if (!(ir_dev->raw->enabled_protocols & IR_TYPE_RC5))
+        if (!(dev->raw->enabled_protocols & IR_TYPE_RC5))
                 return 0;
 
 	if (!is_timing_event(ev)) {
@@ -96,7 +95,7 @@ again:
 		return 0;
 
 	case STATE_BIT_END:
-		if (!is_transition(&ev, &ir_dev->raw->prev_ev))
+		if (!is_transition(&ev, &dev->raw->prev_ev))
 			break;
 
 		if (data->count == data->wanted_bits)
@@ -151,7 +150,7 @@ again:
 				   scancode, toggle);
 		}
 
-		ir_keydown(input_dev, scancode, toggle);
+		ir_keydown(dev, scancode, toggle);
 		data->state = STATE_INACTIVE;
 		return 0;
 	}
drivers/media/IR/ir-rc5-sz-decoder.c +6 -7
index 7c41350..1e95b82 100644
@@ -36,19 +36,18 @@ enum rc5_sz_state {
 
 /**
  * ir_rc5_sz_decode() - Decode one RC-5 Streamzap pulse or space
- * @input_dev:	the struct input_dev descriptor of the device
+ * @dev:	the struct rc_dev descriptor of the device
  * @ev:		the struct ir_raw_event descriptor of the pulse/space
  *
  * This function returns -EINVAL if the pulse violates the state machine
  */
-static int ir_rc5_sz_decode(struct input_dev *input_dev, struct ir_raw_event ev)
+static int ir_rc5_sz_decode(struct rc_dev *dev, struct ir_raw_event ev)
 {
-	struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
-	struct rc5_sz_dec *data = &ir_dev->raw->rc5_sz;
+	struct rc5_sz_dec *data = &dev->raw->rc5_sz;
 	u8 toggle, command, system;
 	u32 scancode;
 
-        if (!(ir_dev->raw->enabled_protocols & IR_TYPE_RC5_SZ))
+        if (!(dev->raw->enabled_protocols & IR_TYPE_RC5_SZ))
                 return 0;
 
 	if (!is_timing_event(ev)) {
@@ -91,7 +90,7 @@ again:
 		return 0;
 
 	case STATE_BIT_END:
-		if (!is_transition(&ev, &ir_dev->raw->prev_ev))
+		if (!is_transition(&ev, &dev->raw->prev_ev))
 			break;
 
 		if (data->count == data->wanted_bits)
@@ -115,7 +114,7 @@ again:
 		IR_dprintk(1, "RC5-sz scancode 0x%04x (toggle: %u)\n",
 			   scancode, toggle);
 
-		ir_keydown(input_dev, scancode, toggle);
+		ir_keydown(dev, scancode, toggle);
 		data->state = STATE_INACTIVE;
 		return 0;
 	}
drivers/media/IR/ir-rc6-decoder.c +8 -9
index d25da91..26cf32f 100644
@@ -70,19 +70,18 @@ static enum rc6_mode rc6_mode(struct rc6_dec *data)
 
 /**
  * ir_rc6_decode() - Decode one RC6 pulse or space
- * @input_dev:	the struct input_dev descriptor of the device
+ * @dev:	the struct rc_dev descriptor of the device
  * @ev:		the struct ir_raw_event descriptor of the pulse/space
  *
  * This function returns -EINVAL if the pulse violates the state machine
  */
-static int ir_rc6_decode(struct input_dev *input_dev, struct ir_raw_event ev)
+static int ir_rc6_decode(struct rc_dev *dev, struct ir_raw_event ev)
 {
-	struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
-	struct rc6_dec *data = &ir_dev->raw->rc6;
+	struct rc6_dec *data = &dev->raw->rc6;
 	u32 scancode;
 	u8 toggle;
 
-	if (!(ir_dev->raw->enabled_protocols & IR_TYPE_RC6))
+	if (!(dev->raw->enabled_protocols & IR_TYPE_RC6))
 		return 0;
 
 	if (!is_timing_event(ev)) {
@@ -139,7 +138,7 @@ again:
 		return 0;
 
 	case STATE_HEADER_BIT_END:
-		if (!is_transition(&ev, &ir_dev->raw->prev_ev))
+		if (!is_transition(&ev, &dev->raw->prev_ev))
 			break;
 
 		if (data->count == RC6_HEADER_NBITS)
@@ -159,7 +158,7 @@ again:
 		return 0;
 
 	case STATE_TOGGLE_END:
-		if (!is_transition(&ev, &ir_dev->raw->prev_ev) ||
+		if (!is_transition(&ev, &dev->raw->prev_ev) ||
 		    !geq_margin(ev.duration, RC6_TOGGLE_END, RC6_UNIT / 2))
 			break;
 
@@ -204,7 +203,7 @@ again:
 		return 0;
 
 	case STATE_BODY_BIT_END:
-		if (!is_transition(&ev, &ir_dev->raw->prev_ev))
+		if (!is_transition(&ev, &dev->raw->prev_ev))
 			break;
 
 		if (data->count == data->wanted_bits)
@@ -243,7 +242,7 @@ again:
 			goto out;
 		}
 
-		ir_keydown(input_dev, scancode, toggle);
+		ir_keydown(dev, scancode, toggle);
 		data->state = STATE_INACTIVE;
 		return 0;
 	}
drivers/media/IR/ir-sony-decoder.c +5 -6
index 2d15730..ff1b46d 100644
@@ -33,19 +33,18 @@ enum sony_state {
 
 /**
  * ir_sony_decode() - Decode one Sony pulse or space
- * @input_dev:	the struct input_dev descriptor of the device
+ * @dev:	the struct rc_dev descriptor of the device
  * @ev:         the struct ir_raw_event descriptor of the pulse/space
  *
  * This function returns -EINVAL if the pulse violates the state machine
  */
-static int ir_sony_decode(struct input_dev *input_dev, struct ir_raw_event ev)
+static int ir_sony_decode(struct rc_dev *dev, struct ir_raw_event ev)
 {
-	struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
-	struct sony_dec *data = &ir_dev->raw->sony;
+	struct sony_dec *data = &dev->raw->sony;
 	u32 scancode;
 	u8 device, subdevice, function;
 
-	if (!(ir_dev->raw->enabled_protocols & IR_TYPE_SONY))
+	if (!(dev->raw->enabled_protocols & IR_TYPE_SONY))
 		return 0;
 
 	if (!is_timing_event(ev)) {
@@ -144,7 +143,7 @@ static int ir_sony_decode(struct input_dev *input_dev, struct ir_raw_event ev)
 
 		scancode = device << 16 | subdevice << 8 | function;
 		IR_dprintk(1, "Sony(%u) scancode 0x%05x\n", data->count, scancode);
-		ir_keydown(input_dev, scancode, 0);
+		ir_keydown(dev, scancode, 0);
 		data->state = STATE_INACTIVE;
 		return 0;
 	}
drivers/media/IR/mceusb.c +43 -62

201 lines not on this page · raw message

drivers/media/IR/nuvoton-cir.c +37 -48

159 lines not on this page · raw message

drivers/media/IR/nuvoton-cir.h +1 -2
index 62dc530..1df8235 100644
@@ -66,8 +66,7 @@ static int debug;
 
 struct nvt_dev {
 	struct pnp_dev *pdev;
-	struct input_dev *rdev;
-	struct ir_dev_props *props;
+	struct rc_dev *rdev;
 	struct ir_raw_event rawir;
 
 	spinlock_t nvt_lock;
drivers/media/IR/rc-main.c +274 -338

996 lines not on this page · raw message

drivers/media/IR/rc-raw.c +90 -101

345 lines not on this page · raw message

drivers/media/IR/streamzap.c +26 -40

137 lines not on this page · raw message

drivers/media/dvb/dm1105/dm1105.c +21 -21

88 lines not on this page · raw message

drivers/media/dvb/dvb-usb/af9015.c +5 -11
index 31c0a0e..8b9ab30 100644
@@ -1041,13 +1041,13 @@ static int af9015_rc_query(struct dvb_usb_device *d)
 				priv->rc_keycode = buf[12] << 16 |
 					buf[13] << 8 | buf[14];
 			}
-			ir_keydown(d->rc_input_dev, priv->rc_keycode, 0);
+			ir_keydown(d->rc_dev, priv->rc_keycode, 0);
 		} else {
 			priv->rc_keycode = 0; /* clear just for sure */
 		}
 	} else if (priv->rc_repeat != buf[6] || buf[0]) {
 		deb_rc("%s: key repeated\n", __func__);
-		ir_keydown(d->rc_input_dev, priv->rc_keycode, 0);
+		ir_keydown(d->rc_dev, priv->rc_keycode, 0);
 	} else {
 		deb_rc("%s: no key press\n", __func__);
 	}
@@ -1348,9 +1348,7 @@ static struct dvb_usb_device_properties af9015_properties[] = {
 			.module_name      = "af9015",
 			.rc_query         = af9015_rc_query,
 			.rc_interval      = AF9015_RC_INTERVAL,
-			.rc_props = {
-				.allowed_protos = IR_TYPE_NEC,
-			},
+			.allowed_protos   = IR_TYPE_NEC,
 		},
 
 		.i2c_algo = &af9015_i2c_algo,
@@ -1478,9 +1476,7 @@ static struct dvb_usb_device_properties af9015_properties[] = {
 			.module_name      = "af9015",
 			.rc_query         = af9015_rc_query,
 			.rc_interval      = AF9015_RC_INTERVAL,
-			.rc_props = {
-				.allowed_protos = IR_TYPE_NEC,
-			},
+			.allowed_protos   = IR_TYPE_NEC,
 		},
 
 		.i2c_algo = &af9015_i2c_algo,
@@ -1592,9 +1588,7 @@ static struct dvb_usb_device_properties af9015_properties[] = {
 			.module_name      = "af9015",
 			.rc_query         = af9015_rc_query,
 			.rc_interval      = AF9015_RC_INTERVAL,
-			.rc_props = {
-				.allowed_protos = IR_TYPE_NEC,
-			},
+			.allowed_protos   = IR_TYPE_NEC,
 		},
 
 		.i2c_algo = &af9015_i2c_algo,
drivers/media/dvb/dvb-usb/anysee.c +1 -1
index 1759d26..c6e4ba5 100644
@@ -394,7 +394,7 @@ static int anysee_rc_query(struct dvb_usb_device *d)
 
 	if (ircode[0]) {
 		deb_rc("%s: key pressed %02x\n", __func__, ircode[1]);
-		ir_keydown(d->rc_input_dev, 0x08 << 8 | ircode[1], 0);
+		ir_keydown(d->rc_dev, 0x08 << 8 | ircode[1], 0);
 	}
 
[… more lines in the raw message]

Lines of this file are not shown. View the raw message.

drivers/media/dvb/dvb-usb/dib0700.h +1 -1
index c2c9d23..1e7d780 100644

Lines of this file are not shown. View the raw message.

drivers/media/dvb/dvb-usb/dib0700_core.c +4 -4
index 48397f1..3b58f45 100644

Lines of this file are not shown. View the raw message.

drivers/media/dvb/dvb-usb/dib0700_devices.c +58 -86

144 lines not on this page · raw message

drivers/media/dvb/dvb-usb/dvb-usb-remote.c +46 -31

77 lines not on this page · raw message

drivers/media/dvb/dvb-usb/dvb-usb.h +8 -4
index 34f7b3b..83aa982 100644

Lines of this file are not shown. View the raw message.

drivers/media/dvb/dvb-usb/lmedm04.c +20 -22

42 lines not on this page · raw message

drivers/media/dvb/mantis/mantis_common.h +3 -1
index d0b645a..bd400d2 100644

Lines of this file are not shown. View the raw message.

drivers/media/dvb/mantis/mantis_input.c +41 -30

71 lines not on this page · raw message

drivers/media/dvb/siano/smscoreapi.c +1 -1
index 135e45b..78765ed 100644

Lines of this file are not shown. View the raw message.

drivers/media/dvb/siano/smsir.c +27 -25

52 lines not on this page · raw message

drivers/media/dvb/siano/smsir.h +1 -2
index 926e247..c2f68a4 100644

Lines of this file are not shown. View the raw message.

drivers/media/dvb/ttpci/budget-ci.c +22 -27

49 lines not on this page · raw message

drivers/media/video/bt8xx/bttv-input.c +18 -23

41 lines not on this page · raw message

drivers/media/video/cx23885/cx23885-input.c +30 -34

64 lines not on this page · raw message

drivers/media/video/cx23885/cx23885.h +1 -2
index ed94b17..f350d88 100644

Lines of this file are not shown. View the raw message.

drivers/media/video/cx88/cx88-input.c +47 -49

96 lines not on this page · raw message

drivers/media/video/em28xx/em28xx-input.c +33 -39

72 lines not on this page · raw message

drivers/media/video/ir-kbd-i2c.c +14 -11
index aee8943..55a22e7 100644

Lines of this file are not shown. View the raw message.

drivers/media/video/saa7134/saa7134-input.c +30 -42

72 lines not on this page · raw message

drivers/staging/tm6000/tm6000-input.c +39 -46

85 lines not on this page · raw message

include/media/ir-common.h +1 -2
index d1ae869..41fefd9 100644

Lines of this file are not shown. View the raw message.

include/media/ir-core.h +80 -101

181 lines not on this page · raw message

include/media/ir-kbd-i2c.h +1 -2
index 8c37b5e..4ee9b42 100644

Lines of this file are not shown. View the raw message.

The rest of this diff is not shown. View the raw message.

Part of the diff is not shown here. View the raw message.

#6 lore raw

PATCH 6/6 rc-core: convert winbond-cir

In reply to David Härdeman

Move winbond-cir from drivers/input/misc/ into drivers/media/IR/ and convert it to use rc-core.

---
 drivers/input/misc/Kconfig       |   18 
 drivers/input/misc/Makefile      |    1 
 drivers/input/misc/winbond-cir.c | 1608 --------------------------------------
 drivers/media/IR/Kconfig         |   17 
 drivers/media/IR/Makefile        |    1 
 drivers/media/IR/winbond-cir.c   |  932 ++++++++++++++++++++++
 6 files changed, 950 insertions(+), 1627 deletions(-)
 delete mode 100644 drivers/input/misc/winbond-cir.c
 create mode 100644 drivers/media/IR/winbond-cir.c
drivers/input/misc/Kconfig +0 -18
index b99b8cb..c1a81bc 100644
@@ -294,24 +294,6 @@ config INPUT_SGI_BTNS
 	  To compile this driver as a module, choose M here: the
 	  module will be called sgi_btns.
 
-config INPUT_WINBOND_CIR
-	tristate "Winbond IR remote control"
-	depends on X86 && PNP
-	select NEW_LEDS
-	select LEDS_CLASS
-	select LEDS_TRIGGERS
-	select BITREVERSE
-	help
-	  Say Y here if you want to use the IR remote functionality found
-	  in some Winbond SuperI/O chips. Currently only the WPCD376I
-	  chip is supported (included in some Intel Media series motherboards).
-
-	  IR Receive and wake-on-IR from suspend and power-off is currently
-	  supported.
-
-	  To compile this driver as a module, choose M here: the module will be
-	  called winbond_cir.
-
 config HP_SDC_RTC
 	tristate "HP SDC Real Time Clock"
 	depends on (GSC || HP300) && SERIO
drivers/input/misc/Makefile +0 -1
index 1fe1f6c..06b2b51 100644
@@ -38,7 +38,6 @@ obj-$(CONFIG_INPUT_SPARCSPKR)		+= sparcspkr.o
 obj-$(CONFIG_INPUT_TWL4030_PWRBUTTON)	+= twl4030-pwrbutton.o
 obj-$(CONFIG_INPUT_TWL4030_VIBRA)	+= twl4030-vibra.o
 obj-$(CONFIG_INPUT_UINPUT)		+= uinput.o
-obj-$(CONFIG_INPUT_WINBOND_CIR)		+= winbond-cir.o
 obj-$(CONFIG_INPUT_WISTRON_BTNS)	+= wistron_btns.o
 obj-$(CONFIG_INPUT_WM831X_ON)		+= wm831x-on.o
 obj-$(CONFIG_INPUT_YEALINK)		+= yealink.o
drivers/input/misc/winbond-cir.c deleted +0 -1608

1,608 lines not on this page · raw message

drivers/media/IR/Kconfig +17 -0
index 20e02a0..7929ea7 100644
@@ -164,4 +164,21 @@ config IR_STREAMZAP
 	   To compile this driver as a module, choose M here: the
 	   module will be called streamzap.
 
+config IR_WINBOND_CIR
+        tristate "Winbond IR remote control"
+        depends on X86 && PNP
+	depends on IR_CORE
+        select NEW_LEDS
+        select LEDS_CLASS
+        select LEDS_TRIGGERS
+        select BITREVERSE
+	---help---
+           Say Y here if you want to use the IR remote functionality found
+           in some Winbond SuperI/O chips. Currently only the WPCD376I
+           chip is supported (included in some Intel Media series
+	   motherboards).
+
+           To compile this driver as a module, choose M here: the module will
+	   be called winbond_cir.
+
 endif #IR_CORE
drivers/media/IR/Makefile +1 -0
index 1eb24e6..859c12c 100644
@@ -20,3 +20,4 @@ obj-$(CONFIG_IR_MCEUSB) += mceusb.o
 obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
 obj-$(CONFIG_IR_ENE) += ene_ir.o
 obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
+obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
drivers/media/IR/winbond-cir.c new file +932 -0

932 lines not on this page · raw message

#7 lore raw
In reply to David Härdeman
Quoted 10 lines · David Härdeman

This is my current patch queue, the main change is to make struct rc_dev the primary interface for rc drivers and to abstract away the fact that there's an input device lurking in there somewhere.

In addition, the cx88 and winbond-cir drivers are converted to use rc-core.

The patchset is now based on current linux-2.6 upstream git tree since it carries both the v4l patches from the staging/for_v2.6.37-rc1 branch, large scancode support and bugfixes.

Quoted 5 lines

Given the changes, these patches touch every single driver. Obviously I haven't tested them all due to a lack of hardware (I have made sure that all drivers compile without any warnings and I have tested the end result on mceusb and winbond-cir hardware, Jarod Wilson has tested nuvoton-cir, imon and several mceusb devices).

And streamzap! :)

Mauro's at the kernel summit, but I had a brief moment to talk to him earlier today. He had a few issues he wanted to give feedback on, but I didn't get any specifics yet, other than him not liking the rc-map.c bits merged into rc-main.c, mainly because part of the plan is to remove in-kernel maps entirely in 2.6.38. It doesn't make a big difference to me either way, and rc-main.c is still only 1300-ish lines, and would be even less once rc-map.c bits are ripped out...

Signature · 2 lines
Jarod Wilson
[email protected]
#8 lore raw

Hi David,

Em 02-11-2010 18:26, Jarod Wilson escreveu:

Quoted 19 lines · David Härdeman
Quoted 10 lines

This is my current patch queue, the main change is to make struct rc_dev the primary interface for rc drivers and to abstract away the fact that there's an input device lurking in there somewhere.

In addition, the cx88 and winbond-cir drivers are converted to use rc-core.

The patchset is now based on current linux-2.6 upstream git tree since it carries both the v4l patches from the staging/for_v2.6.37-rc1 branch, large scancode support and bugfixes.

Quoted 5 lines

Given the changes, these patches touch every single driver. Obviously I haven't tested them all due to a lack of hardware (I have made sure that all drivers compile without any warnings and I have tested the end result on mceusb and winbond-cir hardware, Jarod Wilson has tested nuvoton-cir, imon and several mceusb devices).

And streamzap! :)

Quoted 7 lines

Mauro's at the kernel summit, but I had a brief moment to talk to him earlier today. He had a few issues he wanted to give feedback on, but I didn't get any specifics yet, other than him not liking the rc-map.c bits merged into rc-main.c, mainly because part of the plan is to remove in-kernel maps entirely in 2.6.38. It doesn't make a big difference to me either way, and rc-main.c is still only 1300-ish lines, and would be even less once rc-map.c bits are ripped out...

Sorry for giving you a late feedback about those patches. I was busy the last two weeks, due to my trip to US for KS/LPC.

I've applied patches 1 to 3 (in fact, I got the patches from the previous version - unfortunately, patchwork do a very bad job when someone sends a new series that superseeds the previous patches).

I didn't like patch 4 for some reasons: instead of just doing rename, it is a all-in-one patch, doing several things at the same time. It is hard to analyse it by just looking at the diffs, as it is not a pure rename patch. Also, it doesn't rename /drivers/media/IR into something else.

Btw, the patch is currently broken:

$ quilt push
Applying patch patches/lmml_298052_4_6_ir_core_merge_and_rename_to_rc_core.patch
patching file drivers/media/IR/Makefile
patching file drivers/media/IR/ir-core-priv.h
patching file drivers/media/IR/ir-keytable.c
Hunk #1 FAILED at 1.
File drivers/media/IR/ir-keytable.c is not empty after patch, as expected
1 out of 1 hunk FAILED -- rejects in file drivers/media/IR/ir-keytable.c
patching file drivers/media/IR/ir-raw-event.c
patching file drivers/media/IR/ir-sysfs.c
patching file drivers/media/IR/rc-main.c
patching file drivers/media/IR/rc-map.c
patching file drivers/media/IR/rc-raw.c
patching file include/media/ir-core.h
Patch patches/lmml_298052_4_6_ir_core_merge_and_rename_to_rc_core.patch does not apply (enforce with -f)

I think that the better is if I write a few patches doing the basic rename stuff, based on my current tip, and then we can discuss about merging things into a fewer number of files, as you're proposing, and apply patch 5/6 and 6/6.

Not sure why, but patchwork didn't seem to catch patch 6/6. I suspect that it is because your name is not encoded with UTF-8 inside the driver. I've picked it manually here, and fixed the naming stuff, but it needs patch 5/6, in order to work.

I'll be pushing the renaming stuff soon at ML. I'll try to use your naming convention and, if I do it well, maybe I can apply patches 5/6 and 6/6 on it without rebasing. Well, let's see.

Cheers,
Mauro

#9 lore raw

On Tue, Nov 9, 2010 at 8:50 PM, Mauro Carvalho Chehab <[email protected]> wrote:
...

Quoted 7 lines

Sorry for giving you a late feedback about those patches. I was busy the last two weeks, due to my trip to US for KS/LPC.

I've applied patches 1 to 3 (in fact, I got the patches from the previous version - unfortunately, patchwork do a very bad job when someone sends a new series that superseeds the previous patches).

Quoted 6 lines

I didn't like patch 4 for some reasons: instead of just doing rename, it is a all-in-one patch, doing several things at the same time. It is hard to analyse it by just looking at the diffs, as it is not a pure rename patch. Also, it doesn't rename /drivers/media/IR into something else.

Btw, the patch is currently broken:

Hm, the series applied cleanly against 2.6.37-rc1 a bit ago:

http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/staging

Signature · 2 lines
Jarod Wilson
[email protected]
#10 lore raw

Em 10-11-2010 01:25, Jarod Wilson escreveu:

Quoted 15 lines

On Tue, Nov 9, 2010 at 8:50 PM, Mauro Carvalho Chehab <[email protected]> wrote:
...

Quoted 12 lines

Sorry for giving you a late feedback about those patches. I was busy the last two weeks, due to my trip to US for KS/LPC.

I've applied patches 1 to 3 (in fact, I got the patches from the previous version - unfortunately, patchwork do a very bad job when someone sends a new series that superseeds the previous patches).

I didn't like patch 4 for some reasons: instead of just doing rename, it is a all-in-one patch, doing several things at the same time. It is hard to analyse it by just looking at the diffs, as it is not a pure rename patch. Also, it doesn't rename /drivers/media/IR into something else.

Quoted 5 lines
Quoted 1 line

Btw, the patch is currently broken:

Hm, the series applied cleanly against 2.6.37-rc1 a bit ago:

http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/staging

Probably, some other RC patch broke it. It doesn't apply cleanly against staging/for_v2.6.38.

Cheers,
Mauro

#11 lore raw
In reply to Jarod Wilson
Quoted 4 lines · Jarod Wilson

On Tue, Nov 9, 2010 at 8:50 PM, Mauro Carvalho Chehab <[email protected]> wrote:
...

Quoted 1 line

Sorry for giving you a late feedback about those patches. I was busy

the

Quoted 10 lines
Quoted 10 lines

last two
weeks, due to my trip to US for KS/LPC.

I've applied patches 1 to 3 (in fact, I got the patches from the previous version -
unfortunately, patchwork do a very bad job when someone sends a new series that superseeds
the previous patches).

I didn't like patch 4 for some reasons: instead of just doing rename,

it

Quoted 7 lines
Quoted 7 lines

is a
all-in-one patch, doing several things at the same time. It is hard to analyse it by
just looking at the diffs, as it is not a pure rename patch. Also, it doesn't rename
/drivers/media/IR into something else.

Quoted 5 lines
Quoted 1 line

Btw, the patch is currently broken:

Hm, the series applied cleanly against 2.6.37-rc1 a bit ago:

http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/staging

Still does, and it's no wonder it doesn't apply to staging/for_v2.6.38 since it's a franken-branch of 2.6.36 + staging/for_v2.6.37 + some more patches.

Signature · 1 line
David Härdeman
#12 lore raw
In reply to Mauro Carvalho Chehab
Quoted 6 lines · Mauro Carvalho Chehab

Hi David,

Em 02-11-2010 18:26, Jarod Wilson escreveu:

Quoted 3 lines
Quoted 1 line · David Härdeman

This is my current patch queue, the main change is to make struct

rc_dev

Quoted 1 line
Quoted 1 line
Quoted 1 line

the primary interface for rc drivers and to abstract away the fact

that

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines

there's an input device lurking in there somewhere.

In addition, the cx88 and winbond-cir drivers are converted to use rc-core.

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines

The patchset is now based on current linux-2.6 upstream git tree since it
carries both the v4l patches from the staging/for_v2.6.37-rc1 branch, large
scancode support and bugfixes.

Given the changes, these patches touch every single driver. Obviously

I

Quoted 1 line
Quoted 1 line
Quoted 1 line

haven't tested them all due to a lack of hardware (I have made sure

that

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

all drivers compile without any warnings and I have tested the end result
on mceusb and winbond-cir hardware, Jarod Wilson has tested

nuvoton-cir,

Quoted 12 lines
Quoted 11 lines
Quoted 1 line

imon and several mceusb devices).

And streamzap! :)

Mauro's at the kernel summit, but I had a brief moment to talk to him earlier today. He had a few issues he wanted to give feedback on, but I didn't get any specifics yet, other than him not liking the rc-map.c bits merged into rc-main.c, mainly because part of the plan is to remove in-kernel maps entirely in 2.6.38. It doesn't make a big difference to me either way, and rc-main.c is still only 1300-ish lines, and would be even less once rc-map.c bits are ripped out...

Quoted 5 lines

Sorry for giving you a late feedback about those patches. I was busy the last two
weeks, due to my trip to US for KS/LPC.

I've applied patches 1 to 3 (in fact, I got the patches from the

previous

Quoted 2 lines

version -
unfortunately, patchwork do a very bad job when someone sends a new

series

Quoted 2 lines

that superseeds
the previous patches).

Kinda makes it pointless to refresh patchsets, doesn't it?

Quoted 5 lines

I didn't like patch 4 for some reasons: instead of just doing rename, it is a
all-in-one patch, doing several things at the same time. It is hard to analyse it by
just looking at the diffs, as it is not a pure rename patch.

It was an almost pure merge + rename (it added only the things that follow from the merger...forward declarations and making functions static).

The real problem is that, since it includes the removal of files, those files need to be identical.

Quoted 3 lines

Also, it
doesn't rename
/drivers/media/IR into something else.

No, of course not, that would have made the patch even larger for little gain.

I see that you've included a renaming patch in your patchset sent to the list, but wouldn't it be easier to apply it after all the other patches rather than before?

Quoted 10 lines

Btw, the patch is currently broken:

$ quilt push
Applying patch
patches/lmml_298052_4_6_ir_core_merge_and_rename_to_rc_core.patch
patching file drivers/media/IR/Makefile
patching file drivers/media/IR/ir-core-priv.h
patching file drivers/media/IR/ir-keytable.c
Hunk #1 FAILED at 1.
File drivers/media/IR/ir-keytable.c is not empty after patch, as

expected

Quoted 1 line

1 out of 1 hunk FAILED -- rejects in file drivers/media/IR/ir-keytable.c

Not sure if you used the most recent version of patch 4/6 or not.

If you used the most recent, it's based on 2.6.37-rc1 upstream which has both the large-input-scancodes patches as well as two important bugfixes to ir-keytable.c, so since your staging/for_v2.6.38 is based on 2.6.36 plus the staging/for_v2.6.37-rc1 branch, it won't apply.

If you used to second most recent, then it's based on the input-large-scancodes being merged but not the two upstream bugfixes which followed it.

Whichever way you choose, those two bugfixes should not get lost in the noise.

Quoted 10 lines

patching file drivers/media/IR/ir-raw-event.c
patching file drivers/media/IR/ir-sysfs.c
patching file drivers/media/IR/rc-main.c
patching file drivers/media/IR/rc-map.c
patching file drivers/media/IR/rc-raw.c
patching file include/media/ir-core.h
Patch patches/lmml_298052_4_6_ir_core_merge_and_rename_to_rc_core.patch does not apply (enforce with -f)

I think that the better is if I write a few patches doing the basic

rename

Quoted 6 lines

stuff, based on my
current tip, and then we can discuss about merging things into a fewer number of files, as
you're proposing, and apply patch 5/6 and 6/6.

Not sure why, but patchwork didn't seem to catch patch 6/6. I suspect

that

Quoted 2 lines

it is because your
name is not encoded with UTF-8 inside the driver. I've picked it

manually

Quoted 2 lines

here, and fixed
the naming stuff, but it needs patch 5/6, in order to work.

My name used to be UTF-8 encoded in winbond-cir, and it was changed upstream (not by me), so I'm not going to revert it.

Quoted 1 line

I'll be pushing the renaming stuff soon at ML. I'll try to use your

naming

Quoted 3 lines

convention and, if
I do it well, maybe I can apply patches 5/6 and 6/6 on it without rebasing. Well, let's see.

I'll wait for more feedback then?

Signature · 1 line
David Härdeman
#13 lore raw

Em 10-11-2010 07:24, David Härdeman escreveu:

Quoted 47 lines
Quoted 6 lines · Mauro Carvalho Chehab

Hi David,

Em 02-11-2010 18:26, Jarod Wilson escreveu:

Quoted 3 lines
Quoted 1 line · David Härdeman

This is my current patch queue, the main change is to make struct

rc_dev

Quoted 1 line
Quoted 1 line
Quoted 1 line

the primary interface for rc drivers and to abstract away the fact

that

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines

there's an input device lurking in there somewhere.

In addition, the cx88 and winbond-cir drivers are converted to use rc-core.

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines

The patchset is now based on current linux-2.6 upstream git tree since it
carries both the v4l patches from the staging/for_v2.6.37-rc1 branch, large
scancode support and bugfixes.

Given the changes, these patches touch every single driver. Obviously

I

Quoted 1 line
Quoted 1 line
Quoted 1 line

haven't tested them all due to a lack of hardware (I have made sure

that

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

all drivers compile without any warnings and I have tested the end result
on mceusb and winbond-cir hardware, Jarod Wilson has tested

nuvoton-cir,

Quoted 12 lines
Quoted 11 lines
Quoted 1 line

imon and several mceusb devices).

And streamzap! :)

Mauro's at the kernel summit, but I had a brief moment to talk to him earlier today. He had a few issues he wanted to give feedback on, but I didn't get any specifics yet, other than him not liking the rc-map.c bits merged into rc-main.c, mainly because part of the plan is to remove in-kernel maps entirely in 2.6.38. It doesn't make a big difference to me either way, and rc-main.c is still only 1300-ish lines, and would be even less once rc-map.c bits are ripped out...

Quoted 5 lines

Sorry for giving you a late feedback about those patches. I was busy the last two
weeks, due to my trip to US for KS/LPC.

I've applied patches 1 to 3 (in fact, I got the patches from the

Quoted 8 lines

previous

Quoted 2 lines

version -
unfortunately, patchwork do a very bad job when someone sends a new

series

Quoted 2 lines

that superseeds
the previous patches).

Kinda makes it pointless to refresh patchsets, doesn't it?

Yes.

Quoted 17 lines
Quoted 6 lines

I didn't like patch 4 for some reasons: instead of just doing rename, it is a
all-in-one patch, doing several things at the same time. It is hard to analyse it by
just looking at the diffs, as it is not a pure rename patch.

It was an almost pure merge + rename (it added only the things that follow from the merger...forward declarations and making functions static).

The real problem is that, since it includes the removal of files, those files need to be identical.

Quoted 3 lines

Also, it
doesn't rename
/drivers/media/IR into something else.

Quoted 6 lines

No, of course not, that would have made the patch even larger for little gain.

I see that you've included a renaming patch in your patchset sent to the list, but wouldn't it be easier to apply it after all the other patches rather than before?

When such change is done as I did, git is smart enough to do the right thing. So, even if the file suffered changes, it is still a rename operation there, even if the file had changes.

Quoted 12 lines
Quoted 11 lines

Btw, the patch is currently broken:

$ quilt push
Applying patch
patches/lmml_298052_4_6_ir_core_merge_and_rename_to_rc_core.patch
patching file drivers/media/IR/Makefile
patching file drivers/media/IR/ir-core-priv.h
patching file drivers/media/IR/ir-keytable.c
Hunk #1 FAILED at 1.
File drivers/media/IR/ir-keytable.c is not empty after patch, as

expected

Quoted 8 lines
Quoted 1 line

1 out of 1 hunk FAILED -- rejects in file drivers/media/IR/ir-keytable.c

Not sure if you used the most recent version of patch 4/6 or not.

If you used the most recent, it's based on 2.6.37-rc1 upstream which has both the large-input-scancodes patches as well as two important bugfixes to ir-keytable.c, so since your staging/for_v2.6.38 is based on 2.6.36 plus the staging/for_v2.6.37-rc1 branch, it won't apply.

Gah! Yeah, my tree is based on 2.6.36, but we need to be based on .37-rc1. I'll merge .37-rc1.

Quoted 6 lines

If you used to second most recent, then it's based on the input-large-scancodes being merged but not the two upstream bugfixes which followed it.

Whichever way you choose, those two bugfixes should not get lost in the noise.

Yeah, sure. The git renaming patches will probably do the right thing. I'll double check.

Quoted 18 lines
Quoted 10 lines

patching file drivers/media/IR/ir-raw-event.c
patching file drivers/media/IR/ir-sysfs.c
patching file drivers/media/IR/rc-main.c
patching file drivers/media/IR/rc-map.c
patching file drivers/media/IR/rc-raw.c
patching file include/media/ir-core.h
Patch patches/lmml_298052_4_6_ir_core_merge_and_rename_to_rc_core.patch does not apply (enforce with -f)

I think that the better is if I write a few patches doing the basic

rename

Quoted 6 lines

stuff, based on my
current tip, and then we can discuss about merging things into a fewer number of files, as
you're proposing, and apply patch 5/6 and 6/6.

Not sure why, but patchwork didn't seem to catch patch 6/6. I suspect

that

Quoted 8 lines
Quoted 2 lines

it is because your
name is not encoded with UTF-8 inside the driver. I've picked it

manually

Quoted 2 lines

here, and fixed
the naming stuff, but it needs patch 5/6, in order to work.

My name used to be UTF-8 encoded in winbond-cir, and it was changed upstream (not by me), so I'm not going to revert it.

Patchwork handles very badly charset encodings, due to Python. I sent several patches for it to fix several problems I noticed there.
Basically, Python kills any script if the an invalid character is inserted on a string. E. g., if your emailer says that the email is encoded as UTF-8, and a non-UTF-8 character is found on any part of the email, the script will die, as it will try to write the email contents on some vars.

Due to that, a patch/email with an invalid character on his charset will be silently discarded by patchwork, as the script will die.

I suspect that your emailer might be doing some bad things also, as I need to manually fix your author's name every time. In general the SOB on your emails have one encoding, while the From: has another encoding.

Quoted 7 lines
Quoted 1 line

I'll be pushing the renaming stuff soon at ML. I'll try to use your

naming

Quoted 3 lines

convention and, if
I do it well, maybe I can apply patches 5/6 and 6/6 on it without rebasing. Well, let's see.

I'll wait for more feedback then?

I'm pulling from 2.6.37-rc1 on my tree. I prefer to keep my approach of using the git rename stuff on separate patches, as the patches become smaller and easier to review, and git should probably handle it well, when merged upstream.

So, I'll try to merge the pending patches from your tree. I'll let you know if I have any problems.

Cheers,
Mauro

Quoted 1 line
#14 lore raw
Quoted 4 lines · Mauro Carvalho Chehab

Em 10-11-2010 07:24, David Härdeman escreveu:

Quoted 3 lines

Not sure if you used the most recent version of patch 4/6 or not.

If you used the most recent, it's based on 2.6.37-rc1 upstream which

has

Quoted 1 line
Quoted 1 line

both the large-input-scancodes patches as well as two important

bugfixes

Quoted 4 lines
Quoted 2 lines

to ir-keytable.c, so since your staging/for_v2.6.38 is based on 2.6.36 plus the staging/for_v2.6.37-rc1 branch, it won't apply.

Gah! Yeah, my tree is based on 2.6.36, but we need to be based on

.37-rc1.

Quoted 1 line

I'll merge .37-rc1.

I think/hope my patches will apply with little to no fuzz once you've done that.

Quoted 7 lines
Quoted 2 lines

My name used to be UTF-8 encoded in winbond-cir, and it was changed upstream (not by me), so I'm not going to revert it.

Patchwork handles very badly charset encodings, due to Python. I sent several
patches for it to fix several problems I noticed there. Basically, Python kills any script if the an invalid character is

inserted

Quoted 8 lines

on a string. E. g., if your emailer says that the email is encoded as UTF-8, and
a non-UTF-8 character is found on any part of the email, the script will die, as
it will try to write the email contents on some vars.

Due to that, a patch/email with an invalid character on his charset will be silently discarded by patchwork, as the script will die.

Not much I can do there :)

Quoted 1 line

I suspect that your emailer might be doing some bad things also, as I

need

Quoted 1 line

to manually fix your author's name every time. In general the SOB on

your

Quoted 1 line

emails have one encoding, while the From: has another encoding.

I didn't know that, I'll have a look. I'm guessing that both iso88591-1 and utf-8 encodings are used.

Quoted 2 lines

So, I'll try to merge the pending patches from your tree. I'll let you know if I have any problems.

Sounds good. Thanks.

Signature · 1 line
David Härdeman
#15 lore raw

Em 10-11-2010 11:06, David Härdeman escreveu:

Quoted 7 lines
Quoted 2 lines · Mauro Carvalho Chehab

So, I'll try to merge the pending patches from your tree. I'll let you know if I have any problems.

Sounds good. Thanks.

David/Jarod,

I pushed the merged patches at the tmp_rc tree:

http://git.linuxtv.org/mchehab/tmp_rc.git

Please test and give me some feedback. It ended that the rc function renaming patch (6/7) broke both mceusb (due to TX changes) and cx231xx-input (a new driver from me, for some devices that uses a crappy i2c uP, instead of the excellent in-cx231xx IR support).

I did no tests at all, except for compilation. So, I need your feedback if the patches didn't actually break anything.

I'll do some tests with cx231xx-input/mceusb probably later today.

Cheers,
Mauro.

#16 lore raw
Quoted 15 lines · Mauro Carvalho Chehab

Em 10-11-2010 11:06, David Härdeman escreveu:

Quoted 7 lines
Quoted 2 lines · Mauro Carvalho Chehab

So, I'll try to merge the pending patches from your tree. I'll let you know if I have any problems.

Sounds good. Thanks.

David/Jarod,

I pushed the merged patches at the tmp_rc tree:

http://git.linuxtv.org/mchehab/tmp_rc.git

Quoted 7 lines

Please test and give me some feedback. It ended that the rc function renaming patch (6/7) broke both mceusb (due to TX changes) and cx231xx-input (a new driver from me, for some devices that uses a crappy i2c uP, instead of the excellent in-cx231xx IR support).

I did no tests at all, except for compilation. So, I need your feedback if the patches didn't actually break anything.

So far I've noticed that this patch:
[media] rc-core: convert winbond-cir

removed the old winbond-cir.c file but doesn't add one in the drivers/media/rc/ directory.

Signature · 1 line
David Härdeman
#17 lore raw

Em 10-11-2010 20:01, David Härdeman escreveu:

Quoted 21 lines · Mauro Carvalho Chehab
Quoted 20 lines

Em 10-11-2010 11:06, David Härdeman escreveu:

Quoted 7 lines
Quoted 2 lines · Mauro Carvalho Chehab

So, I'll try to merge the pending patches from your tree. I'll let you know if I have any problems.

Sounds good. Thanks.

David/Jarod,

I pushed the merged patches at the tmp_rc tree:

http://git.linuxtv.org/mchehab/tmp_rc.git

Please test and give me some feedback. It ended that the rc function renaming patch (6/7) broke both mceusb (due to TX changes) and cx231xx-input (a new driver from me, for some devices that uses a crappy i2c uP, instead of the excellent in-cx231xx IR support).

Quoted 9 lines
Quoted 2 lines

I did no tests at all, except for compilation. So, I need your feedback if the patches didn't actually break anything.

So far I've noticed that this patch:
[media] rc-core: convert winbond-cir

removed the old winbond-cir.c file but doesn't add one in the drivers/media/rc/ directory.

Weird... it seems that i forgot to add the new file on my tree. I think I know why... there are two files from kernel tree that got deleted during the build time. So, I had to manually revert and re-do the commit. I suspect that there's something bad with those two files at -rc1...

Anyway, my rebase to the patch that created the rc_register_device() functions were not ok, as it broke cx231xx-input (a new IR driver added before your series). While debugging the reason, I discovered some problems at the original patch. I just sent an update for it.

The bad news is that ir-kbd-i2c also needs the stuff that are inside ir.props (e. g., the IR configuration logic). I wrote and just sent 2 patches to the ML with the fix patches, against my media-tree.git, branch staging/for_v2.6.38. For now, only one field of props is used, but other fields there are likely needed for the other places where this driver is used, like the open/close callbacks, allowed_protocols, etc.

I don't like the idea of just copying all those config stuff into struct IR_i2c, and then at struct rc_dev, and then at struct input_dev. It is too much data duplication for no good reason.

So, I think we should re-think about your patch 6/7.

Comments?
Mauro

#18 lore raw
Quoted 10 lines · Mauro Carvalho Chehab

The bad news is that ir-kbd-i2c also needs the stuff that are inside ir.props (e. g., the IR configuration logic). I wrote and just sent 2 patches to the ML with the fix patches, against my media-tree.git, branch staging/for_v2.6.38. For now, only one field
of props is used, but other fields there are likely needed for the other places where this driver is used, like the open/close callbacks, allowed_protocols, etc.

I don't like the idea of just copying all those config stuff into struct IR_i2c, and then at struct rc_dev,

Which is the way it is with or without my patch, either a struct ir_dev_props or a subset of the former members of that struct are in IR_i2c, same data. And right now you would need to have a mix between ir_dev_props data and additional ir_dev related data in struct IR_i2c (the rc map name is outside of ir_dev_props).

Note that the patch *removes* > 200 lines of code (without any loss of functionality) - and that's because the interface is simplified. Simple is good.

Quoted 1 line

and then at struct input_dev.

struct input_dev only gets input_name, input_phys and input_id from struct rc_dev, and I did it that way because I didn't want to remove all that information from all drivers (and fill input_dev with generic information instead). We'll have to readdress that issue once multi-input-devs-per-rc-dev functionality is implemented.

Quoted 1 line

It is too much data duplication for no good reason.

And you believe it's an important feature that props used to be a struct and that you could pass a pointer (and take care of initializing rc_map) instead of initializing a couple of members in rc_dev directly?

The use of struct ir_dev_props was a truely bizarre interface. For
example: setting the props member was optional, and a ir_input_dev struct without a props member lacks a driver_type submember. So all codepaths need to know what the default driver_type is when props is not set. Not to mention the number of oops reports that linux-media has already seen, caused by code which didn't check ->props before dereferencing it. That's of course a bug in code, but it's a bug caused by a non-intuitive interface.

The new struct is much more straightforward, and your worries about additional pain caused by not having a struct ir_dev_props did not materialize in any of the changes I did (see for example drivers/media/dvb/dvb-usb/dib0700_devices.c which had similar requirements to struct IR_i2c).

Quoted 1 line

So, I think we should re-think about your patch 6/7.

What's your suggestion?

Quoted 1 line

Comments?

Unsurprisingly, I disagree on the whole re-think part :)

Signature · 1 line
David Härdeman
#19 lore raw

Em 11-11-2010 13:19, David Härdeman escreveu:

Quoted 23 lines
Quoted 10 lines · Mauro Carvalho Chehab

The bad news is that ir-kbd-i2c also needs the stuff that are inside ir.props (e. g., the IR configuration logic). I wrote and just sent 2 patches to the ML with the fix patches, against my media-tree.git, branch staging/for_v2.6.38. For now, only one field
of props is used, but other fields there are likely needed for the other places where this driver is used, like the open/close callbacks, allowed_protocols, etc.

I don't like the idea of just copying all those config stuff into struct IR_i2c, and then at struct rc_dev,

Which is the way it is with or without my patch, either a struct ir_dev_props or a subset of the former members of that struct are in IR_i2c, same data. And right now you would need to have a mix between ir_dev_props data and additional ir_dev related data in struct IR_i2c (the rc map name is outside of ir_dev_props).

Note that the patch *removes* > 200 lines of code (without any loss of functionality) - and that's because the interface is simplified. Simple is good.

Quoted 6 lines
Quoted 1 line

and then at struct input_dev.

struct input_dev only gets input_name, input_phys and input_id from struct rc_dev, and I did it that way because I didn't want to remove all that information from all drivers (and fill input_dev with generic information instead).

input_dev fields need to be properly filled, but just duplicating the same info on both structs and copying from one to the other doesn't seem the better way. Why not just initialize rc_dev->input_dev fields directly, not duplicating the data (or having a helper in-lined routine) to initialize those fields?

Ok, but the point is that a driver like ir-kbd-i2c (and other I2C drivers like lirc-zilog - after ported to rc-core) will require several additional fields that are added at rc_dev (basically, all fields that are, currently, at ir_dev_props structs may be needed by an i2c driver).

Quoted 8 lines

We'll have to readdress that issue once multi-input-devs-per-rc-dev functionality is implemented.

Quoted 1 line

It is too much data duplication for no good reason.

And you believe it's an important feature that props used to be a struct and that you could pass a pointer (and take care of initializing rc_map) instead of initializing a couple of members in rc_dev directly?

Duplicating dozens of fields is not a good idea.

Quoted 3 lines

The use of struct ir_dev_props was a truely bizarre interface. For
example: setting the props member was optional, and a ir_input_dev struct without a props member lacks a driver_type submember.

It were added as optional, to avoid many changes at the drivers, as a way to speedup drivers porting, but I think that all drivers should properly initialize the fields there.

Quoted 7 lines

So all codepaths need
to know what the default driver_type is when props is not set. Not to mention the number of oops reports that linux-media has already seen, caused by code which didn't check ->props before dereferencing it. That's of course a bug in code, but it's a bug caused by a non-intuitive interface.

Quoted 5 lines

The new struct is much more straightforward, and your worries about additional pain caused by not having a struct ir_dev_props did not materialize in any of the changes I did (see for example drivers/media/dvb/dvb-usb/dib0700_devices.c which had similar requirements to struct IR_i2c).

dvb-usb uses a large struct to device dvb devices, and, due to the way it were done, every single field at RC should be inititialized, per device. I don't like the way it is, but I didn't want to delay the rc_core port on it, due to some discussions about how to re-structure it to avoid the large amount of data duplication there. So, I just added the absolute minimum fields there. IMO, we should do later a large cleanup on it. Yet, it is different than ir-kdb-i2c, since since the beginning, the complete IR code is exported on DVB drivers, while V4L drivers use to export just a few bits of the IR code (up to seven bits). So, it is not a good example.

A good exercise would be to port lirc-zilog and see what happens.

Quoted 3 lines
Quoted 1 line

So, I think we should re-think about your patch 6/7.

What's your suggestion?

One idea could be to initialize rc_dev at the caller drivers, passing it via platform_data for the I2C drivers.

Also, instead of duplicating input_dev fields, directly initialize them inside the drivers, and not at rc-core.

I like the idea of having an inlined function (like usb_fill_control_urb), to be sure that all mandatory fields are initialized by the drivers.

Quoted 4 lines
Quoted 2 lines

Comments?

Unsurprisingly, I disagree on the whole re-think part :)

:)

Cheers,
Mauro.

#20 lore raw
Quoted 31 lines · Mauro Carvalho Chehab

Em 11-11-2010 13:19, David Härdeman escreveu:

Quoted 23 lines
Quoted 10 lines · Mauro Carvalho Chehab

The bad news is that ir-kbd-i2c also needs the stuff that are inside ir.props (e. g., the IR configuration logic). I wrote and just sent 2 patches to the ML with the fix patches, against my media-tree.git, branch staging/for_v2.6.38. For now, only one field
of props is used, but other fields there are likely needed for the other places where this driver is used, like the open/close callbacks, allowed_protocols, etc.

I don't like the idea of just copying all those config stuff into struct IR_i2c, and then at struct rc_dev,

Which is the way it is with or without my patch, either a struct ir_dev_props or a subset of the former members of that struct are in IR_i2c, same data. And right now you would need to have a mix between ir_dev_props data and additional ir_dev related data in struct IR_i2c (the rc map name is outside of ir_dev_props).

Note that the patch *removes* > 200 lines of code (without any loss of functionality) - and that's because the interface is simplified. Simple is good.

Quoted 6 lines
Quoted 1 line

and then at struct input_dev.

struct input_dev only gets input_name, input_phys and input_id from struct rc_dev, and I did it that way because I didn't want to remove all that information from all drivers (and fill input_dev with generic information instead).

Quoted 4 lines

input_dev fields need to be properly filled, but just duplicating the same info on both structs and copying from one to the other doesn't seem the better way. Why not just initialize rc_dev->input_dev fields directly, not duplicating the data (or having a helper in-lined routine) to initialize those fields?

The data is not duplicated, input_name and input_phys are passed around as pointers.

And the reason it looks the way it does is, again, that multiple-input-devices-per-rc-device will be broken if drivers fiddle with the input_dev directly. Not to mention it's a layering violation to expect rc drivers to also know about the underlying input devices.

(Yes, you could say that input_name, input_phys and input_id are layering violations as well, but they are not an equally problematic violation and they're a stopgap measure).

Quoted 4 lines

Ok, but the point is that a driver like ir-kbd-i2c (and other I2C drivers like lirc-zilog - after ported to rc-core) will require several additional fields that are added at rc_dev (basically, all fields that are, currently, at ir_dev_props structs may be needed by an i2c driver).

I don't think it's a problem. Making rc-core ir-kbd-i2c friendly is putting the cart before the horse, ir-kbd-i2c is but one user of rc-core (and I also doubt that you'll actually need to duplicate all members, i2c hardware is too basic to need all bells and whistles of rc-core).

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

It is too much data duplication for no good reason.

And you believe it's an important feature that props used to be a struct and that you could pass a pointer (and take care of initializing rc_map) instead of initializing a couple of members in rc_dev directly?

Duplicating dozens of fields is not a good idea.

Duplicating dozens of fields is a perfectly good idea if the other ideas are worse. The reason why code duplication is usually bad is that there are several implementations of the same function, each slightly different and some likely to be missed if new features are added to one of them. Here the duplication only exists in headers, not in actual code, and only comes into play if e.g. a callback function signature is changed.

Say that the signature of a callback function in struct ir_dev_props/rc_dev was changed in a patch.

With the struct ir_dev_props scenario, you'd need to change one line in ir-core.h (change the function signature in struct ir_dev_props) and one line in each and every one of 30 or so different drivers (31 lines changed).

After my patch, you'd need to change one line in ir-core.h (change the function signature in struct ir_dev_props) and one line in each and every one of 30 or so different drivers + a one line change to files like ir-kbd-i2c.h which have a duplicate definition of the callback function (say...34 lines changed?).

Not a big deal. And in both scenarios, the compiler will warn you about each and every necessary change.

(Talking of duplication, having every driver do an identical kzalloc(), check if kzalloc succeeds, additional error path, and kfree() in the unregister phase for the ir_dev_props struct is also duplication. *Some* duplication is unavoidable).

Quoted 7 lines
Quoted 3 lines

The use of struct ir_dev_props was a truely bizarre interface. For
example: setting the props member was optional, and a ir_input_dev struct without a props member lacks a driver_type submember.

It were added as optional, to avoid many changes at the drivers, as a way to speedup drivers porting, but I think that all drivers should properly initialize the fields there.

It's still a bizarre interface no matter why it was originally added.

Quoted 17 lines
Quoted 5 lines

The new struct is much more straightforward, and your worries about additional pain caused by not having a struct ir_dev_props did not materialize in any of the changes I did (see for example drivers/media/dvb/dvb-usb/dib0700_devices.c which had similar requirements to struct IR_i2c).

dvb-usb uses a large struct to device dvb devices, and, due to the way it were done, every single field at RC should be inititialized, per device. I don't like the way it is, but I didn't want to delay the rc_core port on it, due to some discussions about how to re-structure it to avoid the large amount of data duplication there. So, I just added the absolute minimum fields there. IMO, we should do later a large cleanup on it. Yet, it is different than ir-kdb-i2c, since since the beginning, the complete IR code is exported on DVB drivers, while V4L drivers use to export just a few bits of the IR code (up to seven bits). So, it is not a good example.

Quoted 1 line

A good exercise would be to port lirc-zilog and see what happens.

I had a quick look at lirc-zilog and I doubt it would be a good candidate to integrate with ir-kbd-i2c.c (I assume that's what you were implying?). Which code from ir-kbd-i2c would it actually be using?

Quoted 4 lines
Quoted 1 line

What's your suggestion?

One idea could be to initialize rc_dev at the caller drivers, passing it via platform_data for the I2C drivers.

Having a subsystem mucking around in a struct embedded as part of the platform data of a higher level driver sounds iffy. You'll never (for example) be able to const'ify platform_data...

Quoted 2 lines

Also, instead of duplicating input_dev fields, directly initialize them inside the drivers, and not at rc-core.

Won't work for the reasons explained above.

Quoted 3 lines

I like the idea of having an inlined function (like usb_fill_control_urb), to be sure that all mandatory fields are initialized by the drivers.

I like the idea of having a function, let's call it rc_register_device(), which makes sure that all mandatory fields are initialized by the drivers :)

Signature · 1 line
David Härdeman
#21 lore raw
Quoted 1 line · David Härdeman

On Thu, Nov 11, 2010 at 02:00:38PM -0200, Mauro Carvalho Chehab wrote:

...

Quoted 27 lines
Quoted 9 lines
Quoted 4 lines

struct input_dev only gets input_name, input_phys and input_id from struct rc_dev, and I did it that way because I didn't want to remove all that information from all drivers (and fill input_dev with generic information instead).

input_dev fields need to be properly filled, but just duplicating the same info on both structs and copying from one to the other doesn't seem the better way. Why not just initialize rc_dev->input_dev fields directly, not duplicating the data (or having a helper in-lined routine) to initialize those fields?

The data is not duplicated, input_name and input_phys are passed around as pointers.

And the reason it looks the way it does is, again, that multiple-input-devices-per-rc-device will be broken if drivers fiddle with the input_dev directly. Not to mention it's a layering violation to expect rc drivers to also know about the underlying input devices.

(Yes, you could say that input_name, input_phys and input_id are layering violations as well, but they are not an equally problematic violation and they're a stopgap measure).

Quoted 4 lines

Ok, but the point is that a driver like ir-kbd-i2c (and other I2C drivers like lirc-zilog - after ported to rc-core) will require several additional fields that are added at rc_dev (basically, all fields that are, currently, at ir_dev_props structs may be needed by an i2c driver).

Quoted 4 lines

I don't think it's a problem. Making rc-core ir-kbd-i2c friendly is putting the cart before the horse, ir-kbd-i2c is but one user of rc-core (and I also doubt that you'll actually need to duplicate all members, i2c hardware is too basic to need all bells and whistles of rc-core).

And just for the record, lirc_zilog probably needs a fairly massive overhaul, so I'd definitely not worry about it *too* much...

Quoted 17 lines
Quoted 17 lines
Quoted 5 lines

The new struct is much more straightforward, and your worries about additional pain caused by not having a struct ir_dev_props did not materialize in any of the changes I did (see for example drivers/media/dvb/dvb-usb/dib0700_devices.c which had similar requirements to struct IR_i2c).

dvb-usb uses a large struct to device dvb devices, and, due to the way it were done, every single field at RC should be inititialized, per device. I don't like the way it is, but I didn't want to delay the rc_core port on it, due to some discussions about how to re-structure it to avoid the large amount of data duplication there. So, I just added the absolute minimum fields there. IMO, we should do later a large cleanup on it. Yet, it is different than ir-kdb-i2c, since since the beginning, the complete IR code is exported on DVB drivers, while V4L drivers use to export just a few bits of the IR code (up to seven bits). So, it is not a good example.

Quoted 5 lines
Quoted 1 line

A good exercise would be to port lirc-zilog and see what happens.

I had a quick look at lirc-zilog and I doubt it would be a good candidate to integrate with ir-kbd-i2c.c (I assume that's what you were implying?). Which code from ir-kbd-i2c would it actually be using?

On the receive side, lirc_zilog was pretty similar to lirc_i2c, which we dropped entirely, as ir-kbd-i2c handles receive just fine for all the relevant rx-only devices lirc_i2c worked with. So in theory, ir-kbd-i2c might want to just grow tx support, but I think I'm more inclined to make it a new stand-alone rx and tx capable driver.

Quoted 14 lines
Quoted 4 lines
Quoted 1 line

What's your suggestion?

One idea could be to initialize rc_dev at the caller drivers, passing it via platform_data for the I2C drivers.

Having a subsystem mucking around in a struct embedded as part of the platform data of a higher level driver sounds iffy. You'll never (for example) be able to const'ify platform_data...

Quoted 2 lines

Also, instead of duplicating input_dev fields, directly initialize them inside the drivers, and not at rc-core.

Won't work for the reasons explained above.

Quoted 7 lines
Quoted 3 lines

I like the idea of having an inlined function (like usb_fill_control_urb), to be sure that all mandatory fields are initialized by the drivers.

I like the idea of having a function, let's call it rc_register_device(), which makes sure that all mandatory fields are initialized by the drivers :)

rc_register_device(rc, name, phys, id); to further prevent duplicate struct members? :)

I still really like this interface change, even if its going to cause short-term issues for i2c devices. I think we just extend this as needed to handle the i2c bits. That said, I haven't really looked all that closely at how much that entails...

Signature · 2 lines
Jarod Wilson
[email protected]
#22 lore raw

Em 11-11-2010 21:40, Jarod Wilson escreveu:

Quoted 61 lines · David Härdeman
Quoted 1 line · Mauro Carvalho Chehab

...

Quoted 27 lines
Quoted 9 lines
Quoted 4 lines

struct input_dev only gets input_name, input_phys and input_id from struct rc_dev, and I did it that way because I didn't want to remove all that information from all drivers (and fill input_dev with generic information instead).

input_dev fields need to be properly filled, but just duplicating the same info on both structs and copying from one to the other doesn't seem the better way. Why not just initialize rc_dev->input_dev fields directly, not duplicating the data (or having a helper in-lined routine) to initialize those fields?

The data is not duplicated, input_name and input_phys are passed around as pointers.

And the reason it looks the way it does is, again, that multiple-input-devices-per-rc-device will be broken if drivers fiddle with the input_dev directly. Not to mention it's a layering violation to expect rc drivers to also know about the underlying input devices.

(Yes, you could say that input_name, input_phys and input_id are layering violations as well, but they are not an equally problematic violation and they're a stopgap measure).

Quoted 4 lines

Ok, but the point is that a driver like ir-kbd-i2c (and other I2C drivers like lirc-zilog - after ported to rc-core) will require several additional fields that are added at rc_dev (basically, all fields that are, currently, at ir_dev_props structs may be needed by an i2c driver).

Quoted 4 lines

I don't think it's a problem. Making rc-core ir-kbd-i2c friendly is putting the cart before the horse, ir-kbd-i2c is but one user of rc-core (and I also doubt that you'll actually need to duplicate all members, i2c hardware is too basic to need all bells and whistles of rc-core).

And just for the record, lirc_zilog probably needs a fairly massive overhaul, so I'd definitely not worry about it *too* much...

Quoted 17 lines
Quoted 17 lines
Quoted 5 lines

The new struct is much more straightforward, and your worries about additional pain caused by not having a struct ir_dev_props did not materialize in any of the changes I did (see for example drivers/media/dvb/dvb-usb/dib0700_devices.c which had similar requirements to struct IR_i2c).

dvb-usb uses a large struct to device dvb devices, and, due to the way it were done, every single field at RC should be inititialized, per device. I don't like the way it is, but I didn't want to delay the rc_core port on it, due to some discussions about how to re-structure it to avoid the large amount of data duplication there. So, I just added the absolute minimum fields there. IMO, we should do later a large cleanup on it. Yet, it is different than ir-kdb-i2c, since since the beginning, the complete IR code is exported on DVB drivers, while V4L drivers use to export just a few bits of the IR code (up to seven bits). So, it is not a good example.

Quoted 5 lines
Quoted 1 line

A good exercise would be to port lirc-zilog and see what happens.

I had a quick look at lirc-zilog and I doubt it would be a good candidate to integrate with ir-kbd-i2c.c (I assume that's what you were implying?). Which code from ir-kbd-i2c would it actually be using?

Quoted 5 lines

On the receive side, lirc_zilog was pretty similar to lirc_i2c, which we dropped entirely, as ir-kbd-i2c handles receive just fine for all the relevant rx-only devices lirc_i2c worked with. So in theory, ir-kbd-i2c might want to just grow tx support, but I think I'm more inclined to make it a new stand-alone rx and tx capable driver.

It doesn't matter much if we'll grow ir-kbd-i2c or convert lirc_zilog. The point is that rc_register_device() should be called inside the i2c driver, but several parameters should be passed to it via platform_data, in a way that is similar to ir-kbd-i2c.

Maybe one solution would be to pass rc_dev via platform_data.

Quoted 18 lines
Quoted 18 lines
Quoted 4 lines
Quoted 1 line

What's your suggestion?

One idea could be to initialize rc_dev at the caller drivers, passing it via platform_data for the I2C drivers.

Having a subsystem mucking around in a struct embedded as part of the platform data of a higher level driver sounds iffy. You'll never (for example) be able to const'ify platform_data...

Quoted 2 lines

Also, instead of duplicating input_dev fields, directly initialize them inside the drivers, and not at rc-core.

Won't work for the reasons explained above.

Quoted 3 lines

I like the idea of having an inlined function (like usb_fill_control_urb), to be sure that all mandatory fields are initialized by the drivers.

Quoted 6 lines
Quoted 3 lines

I like the idea of having a function, let's call it rc_register_device(), which makes sure that all mandatory fields are initialized by the drivers :)

rc_register_device(rc, name, phys, id); to further prevent duplicate struct members? :)

Seems a good idea to me. It is easier and more direct to pass those info as parameter, than to have some code inside rc_register_device to check for the mandatory data.

Quoted 5 lines

I still really like this interface change, even if its going to cause short-term issues for i2c devices. I think we just extend this as needed to handle the i2c bits. That said, I haven't really looked all that closely at how much that entails...

I think I'll apply the cx231xx fixes and then rebase the rc_register_device patch on the top of it, doing a minimal change at IR_i2c. Currently, we just need to pass one extra parameter. After this, we can work to improve it.

Cheers,
Mauro

#23 lore raw
Quoted 15 lines · Mauro Carvalho Chehab

Em 11-11-2010 21:40, Jarod Wilson escreveu:

Quoted 8 lines · David Härdeman
Quoted 6 lines · Mauro Carvalho Chehab
Quoted 1 line

A good exercise would be to port lirc-zilog and see what happens.

I had a quick look at lirc-zilog and I doubt it would be a good candidate to integrate with ir-kbd-i2c.c (I assume that's what you were implying?). Which code from ir-kbd-i2c would it actually be using?

Quoted 5 lines

On the receive side, lirc_zilog was pretty similar to lirc_i2c, which we dropped entirely, as ir-kbd-i2c handles receive just fine for all the relevant rx-only devices lirc_i2c worked with. So in theory, ir-kbd-i2c might want to just grow tx support, but I think I'm more inclined to make it a new stand-alone rx and tx capable driver.

Quoted 4 lines

It doesn't matter much if we'll grow ir-kbd-i2c or convert lirc_zilog. The point is that rc_register_device() should be called inside the i2c driver, but several parameters should be passed to it via platform_data, in a way that is similar to ir-kbd-i2c.

Yes, but if lirc_zilog doesn't use ir-kbd-i2c, there might not be a need for the large number of rc-specific members in platform_data?

Quoted 1 line

Maybe one solution would be to pass rc_dev via platform_data.

Shouldn't platform_data be const? And you'll break the refcounting done in rc_allocate_device() and rc_free_device() / rc_unregister_device(). Not to mention the silent bugs that may be introduced if anyone modifies rc_allocate_device() without noticing that one driver isn't using it.

Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines

I like the idea of having an inlined function (like usb_fill_control_urb), to be sure that all mandatory fields are initialized by the drivers.

I like the idea of having a function, let's call it rc_register_device(), which makes sure that all mandatory fields are initialized by the drivers :)

Quoted 6 lines
Quoted 2 lines

rc_register_device(rc, name, phys, id); to further prevent duplicate struct members? :)

Seems a good idea to me. It is easier and more direct to pass those info as parameter, than to have some code inside rc_register_device to check for the mandatory data.

See my reply to Jarod.

And also, rc_register_device() is anyway going to check other mandatory fields so having it check all of them in one go is just good consistency IMHO.

Quoted 10 lines
Quoted 5 lines

I still really like this interface change, even if its going to cause short-term issues for i2c devices. I think we just extend this as needed to handle the i2c bits. That said, I haven't really looked all that closely at how much that entails...

I think I'll apply the cx231xx fixes and then rebase the rc_register_device patch on the top of it, doing a minimal change at IR_i2c. Currently, we just need to pass one extra parameter. After this, we can work to improve it.

Meaning that you'll my patch with the rc_dev API the way it is basically and then we can revisit the IR_i2c debate later if necessary? If that's what you mean I'm all for it.

Signature · 1 line
David Härdeman
#24 lore raw

Em 12-11-2010 10:12, David Härdeman escreveu:

Quoted 16 lines · Mauro Carvalho Chehab
Quoted 15 lines

Em 11-11-2010 21:40, Jarod Wilson escreveu:

Quoted 13 lines · David Härdeman
Quoted 6 lines · Mauro Carvalho Chehab
Quoted 1 line

A good exercise would be to port lirc-zilog and see what happens.

I had a quick look at lirc-zilog and I doubt it would be a good candidate to integrate with ir-kbd-i2c.c (I assume that's what you were implying?). Which code from ir-kbd-i2c would it actually be using?

On the receive side, lirc_zilog was pretty similar to lirc_i2c, which we dropped entirely, as ir-kbd-i2c handles receive just fine for all the relevant rx-only devices lirc_i2c worked with. So in theory, ir-kbd-i2c might want to just grow tx support, but I think I'm more inclined to make it a new stand-alone rx and tx capable driver.

Quoted 7 lines
Quoted 4 lines

It doesn't matter much if we'll grow ir-kbd-i2c or convert lirc_zilog. The point is that rc_register_device() should be called inside the i2c driver, but several parameters should be passed to it via platform_data, in a way that is similar to ir-kbd-i2c.

Yes, but if lirc_zilog doesn't use ir-kbd-i2c, there might not be a need for the large number of rc-specific members in platform_data?

This device is more complex than the current I2C devices, so, this will basically depend on the diversity of devices that are/will be supported. Yet, things like open/close callbacks are interesting, as they allow to turn off RC support when a table is empty, turning it on when the table is filled and some userspace app opens the input device.

Quoted 6 lines
Quoted 1 line

Maybe one solution would be to pass rc_dev via platform_data.

Shouldn't platform_data be const? And you'll break the refcounting done in rc_allocate_device() and rc_free_device() / rc_unregister_device(). Not to mention the silent bugs that may be introduced if anyone modifies rc_allocate_device() without noticing that one driver isn't using it.

It will still be const. platform_data will pass a pointer to some struct. The value of the pointer won't change. I don't see why this would break refcounting, as what will happen is that the caller driver will call rc_allocate_device() and fill some fields there, instead of ir_kbd_i2c.

I'm working on a patch for it right now.

Basically, drivers that need to use other fields will do:

	dev->init_data->rc = rc_allocate_device();
        if (!dev->init_data.rc)  
                return -ENOMEM;
	dev->init_data.rc->driver_name = "foo_driver";
	...
	i2c_new_device(&i2c_adap, &info)
Quoted 27 lines
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines

I like the idea of having an inlined function (like usb_fill_control_urb), to be sure that all mandatory fields are initialized by the drivers.

I like the idea of having a function, let's call it rc_register_device(), which makes sure that all mandatory fields are initialized by the drivers :)

Quoted 6 lines
Quoted 2 lines

rc_register_device(rc, name, phys, id); to further prevent duplicate struct members? :)

Seems a good idea to me. It is easier and more direct to pass those info as parameter, than to have some code inside rc_register_device to check for the mandatory data.

See my reply to Jarod.

And also, rc_register_device() is anyway going to check other mandatory fields so having it check all of them in one go is just good consistency IMHO.

Quoted 6 lines
Quoted 5 lines

I still really like this interface change, even if its going to cause short-term issues for i2c devices. I think we just extend this as needed to handle the i2c bits. That said, I haven't really looked all that closely at how much that entails...

Quoted 9 lines
Quoted 4 lines

I think I'll apply the cx231xx fixes and then rebase the rc_register_device patch on the top of it, doing a minimal change at IR_i2c. Currently, we just need to pass one extra parameter. After this, we can work to improve it.

Meaning that you'll my patch with the rc_dev API the way it is basically and then we can revisit the IR_i2c debate later if necessary? If that's what you mean I'm all for it.

Ok. I'll do some tests here with the changes, and see if the i2c remotes will keep working after your and my patch. If they're ok, I'll post the patches to the ML and commit on my main tree.

Cheers,
Mauro

#25 lore raw
Quoted 11 lines · Mauro Carvalho Chehab

Em 12-11-2010 10:12, David Härdeman escreveu:

Quoted 5 lines

Shouldn't platform_data be const? And you'll break the refcounting done in rc_allocate_device() and rc_free_device() / rc_unregister_device(). Not to mention the silent bugs that may be introduced if anyone modifies rc_allocate_device() without noticing that one driver isn't using it.

It will still be const. platform_data will pass a pointer to some struct. The value of the pointer won't change. I don't see why this would break refcounting, as what will happen is that the caller driver will call rc_allocate_device() and fill some fields there, instead of ir_kbd_i2c.

I think I've misunderstood what you've been proposing for ir_kbd_i2c. That sounds like a good solution.

Quoted 1 line

I'm working on a patch for it right now.

Good, I'll just wait until the patches are available to comment :)

Signature · 1 line
David Härdeman
#26 lore raw

Em 12-11-2010 12:08, David Härdeman escreveu:

Quoted 13 lines · Mauro Carvalho Chehab
Quoted 11 lines

Em 12-11-2010 10:12, David Härdeman escreveu:

Quoted 5 lines

Shouldn't platform_data be const? And you'll break the refcounting done in rc_allocate_device() and rc_free_device() / rc_unregister_device(). Not to mention the silent bugs that may be introduced if anyone modifies rc_allocate_device() without noticing that one driver isn't using it.

It will still be const. platform_data will pass a pointer to some struct. The value of the pointer won't change. I don't see why this would break refcounting, as what will happen is that the caller driver will call rc_allocate_device() and fill some fields there, instead of ir_kbd_i2c.

Quoted 6 lines

I think I've misunderstood what you've been proposing for ir_kbd_i2c. That sounds like a good solution.

Quoted 1 line

I'm working on a patch for it right now.

Good, I'll just wait until the patches are available to comment :)

They are there already ;)

http://www.spinics.net/lists/linux-media/msg24987.html
http://www.spinics.net/lists/linux-media/msg24986.html

Tested with a i2c-based cx231xx device (Pixelview Hybrid).

Cheers,
Mauro

#27 lore raw
In reply to Jarod Wilson
Quoted 6 lines · Jarod Wilson
Quoted 5 lines · David Härdeman
Quoted 3 lines · Mauro Carvalho Chehab

I like the idea of having an inlined function (like usb_fill_control_urb), to be sure that all mandatory fields are initialized by the drivers.

Quoted 6 lines
Quoted 3 lines

I like the idea of having a function, let's call it rc_register_device(), which makes sure that all mandatory fields are initialized by the drivers :)

rc_register_device(rc, name, phys, id); to further prevent duplicate struct members? :)

As I said before, that won't work with multiple input devices per rc dev. And it's a poorly designed API (IMHO) which expects you to set a few properties in a struct and then add a few more via a function call.

Notes wrt. a future multi-input support:

First, realize that the name/phys/id of an input device is primarily used to distinguish them from each other in user-space. Which means having a shared name/phys/id triplet for all input devices belonging to one rc device only makes them pointless.

So, I think we'll want something similar to name/phys/id, but for the rc device (can be exported via sysfs). Input name/phys/id can then be derived from the rc device for each input subdev (or name could perhaps be set to some user-friendly description of the actual remote control by whichever user-space tool loads the corresponding keymap).

Example:
rc_dev->name = "FooBar IR-Masta 2000" rc_dev->phys = "PNP0BAR/rc0"
(would be available from /sys/class/rc/rc0/{name|phys})

/* Not set by the driver, available with lsinput */ rc_dev->input_devs[0]->name = "FooBar IR-Masta 2000 Remote 1" rc_dev->input_devs[0]->phys = "PNP0BAR/rc0/input0" rc_dev->input_devs[0]->id.bustype = BUS_RC; rc_dev->input_devs[1]->name = "FooBar IR-Masta 2000 Remote 2" rc_dev->input_devs[1]->phys = "PNP0BAR/rc0/input1" rc_dev->input_devs[1]->id.bustype = BUS_RC;

(Just an example, don't overanalyse the details)

As you see, the rc_dev->input_name/phys/id is just a stopgap measure for now, and I certainly don't think future development will be helped by moving any input related fields up to the rc_register_device() level when they should instead go further "down".

Quoted 3 lines

I still really like this interface change, even if its going to cause short-term issues for i2c devices. I think we just extend this as needed to handle the i2c bits.

Agreed.

Signature · 1 line
David Härdeman
#28 lore raw
In reply to David Härdeman

Em 10-11-2010 20:01, David Härdeman escreveu:

Quoted 21 lines · Mauro Carvalho Chehab
Quoted 20 lines

Em 10-11-2010 11:06, David Härdeman escreveu:

Quoted 7 lines
Quoted 2 lines · Mauro Carvalho Chehab

So, I'll try to merge the pending patches from your tree. I'll let you know if I have any problems.

Sounds good. Thanks.

David/Jarod,

I pushed the merged patches at the tmp_rc tree:

http://git.linuxtv.org/mchehab/tmp_rc.git

Please test and give me some feedback. It ended that the rc function renaming patch (6/7) broke both mceusb (due to TX changes) and cx231xx-input (a new driver from me, for some devices that uses a crappy i2c uP, instead of the excellent in-cx231xx IR support).

Quoted 8 lines
Quoted 2 lines

I did no tests at all, except for compilation. So, I need your feedback if the patches didn't actually break anything.

So far I've noticed that this patch:
[media] rc-core: convert winbond-cir

removed the old winbond-cir.c file but doesn't add one in the drivers/media/rc/ directory.

Fixed:

	http://git.linuxtv.org/mchehab/tmp_rc.git?a=commit;h=b84d81386621b2c56b65f80f9428a516a330b095

(note that I rebased the temporary branch, and that the latest patch on it is incomplete and broken)

#29 lore raw
In reply to David Härdeman
Quoted 3 lines · David Härdeman

This is my current patch queue, the main change is to make struct rc_dev the primary interface for rc drivers and to abstract away the fact that there's an input device lurking in there somewhere.

Mauro,

you have neither commented on the patches nor committed them. At the same time you've created a "for_v2.6.38" branch where you've already committed other IR related patches. Could you please provide some feedback on what the plan is?

Signature · 1 line
David Härdeman
#30 lore raw

Hi David,

Em 09-11-2010 08:27, David Härdeman escreveu:

Quoted 6 lines
Quoted 3 lines · David Härdeman

This is my current patch queue, the main change is to make struct rc_dev the primary interface for rc drivers and to abstract away the fact that there's an input device lurking in there somewhere.

Quoted 6 lines

Mauro,

you have neither commented on the patches nor committed them. At the same time you've created a "for_v2.6.38" branch where you've already committed other IR related patches. Could you please provide some feedback on what the plan is?

I've returned from LPC at Sunday. In the last two weeks, I received about 140+ patches at patchwork, plus 8 pull requests, plus tons of emails that I received at the last week. So, I have lots of backlog to handle.

My intention is to handle the pending stuff during this week.

Cheers,
Mauro