rc-core: ir-core to rc-core conversion
Subsystems (3)
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
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
@@ -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
@@ -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
@@ -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);
PATCH 2/6 ir-core: remove remaining users of the ir-functions keyhandlers
In reply to David HärdemanThis 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 3/6 ir-core: more cleanups of ir-functions.c
In reply to David Härdemancx88 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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 */
PATCH 4/6 ir-core: merge and rename to rc-core
In reply to David HärdemanThis 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
@@ -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
@@ -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
The rest of this diff is not shown. View the raw message.
Part of the diff is not shown here. View the raw message.
PATCH 5/6 ir-core: make struct rc_dev the primary interface
In reply to David HärdemanThis 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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 ); }
Lines of this file are not shown. View the raw message.
drivers/media/dvb/dvb-usb/dib0700_core.c +4 -4
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/lmedm04.c +20 -22
42 lines not on this page · raw message
drivers/media/dvb/mantis/mantis_common.h +3 -1
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/smsir.c +27 -25
52 lines not on this page · 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/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/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-core.h +80 -101
181 lines not on this page · 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.
PATCH 6/6 rc-core: convert winbond-cir
In reply to David HärdemanMove 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
@@ -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
@@ -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
@@ -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
@@ -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
Quoted 10 lines · David Härdeman
This is my current patch queue, the main change is to make struct
rc_devthe 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]
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_devthe 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.cbits merged intorc-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, andrc-main.cis still only 1300-ish lines, and would be even less oncerc-map.cbits 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
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]
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
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
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.cbits merged intorc-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, andrc-main.cis still only 1300-ish lines, and would be even less oncerc-map.cbits 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 filedrivers/media/IR/ir-sysfs.c
patching filedrivers/media/IR/rc-main.c
patching filedrivers/media/IR/rc-map.c
patching filedrivers/media/IR/rc-raw.c
patching fileinclude/media/ir-core.h
Patchpatches/lmml_298052_4_6_ir_core_merge_and_rename_to_rc_core.patchdoes 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
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_devQuoted 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 testednuvoton-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.cbits merged intorc-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, andrc-main.cis still only 1300-ish lines, and would be even less oncerc-map.cbits 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 newseries
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, asexpected
Quoted 8 lines
Quoted 1 line
1 out of 1 hunk FAILED -- rejects in file
drivers/media/IR/ir-keytable.cNot 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 filedrivers/media/IR/ir-sysfs.c
patching filedrivers/media/IR/rc-main.c
patching filedrivers/media/IR/rc-map.c
patching filedrivers/media/IR/rc-raw.c
patching fileinclude/media/ir-core.h
Patchpatches/lmml_298052_4_6_ir_core_merge_and_rename_to_rc_core.patchdoes 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 itmanually
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
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
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.
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_rctree:
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
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_rctree: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-cirremoved the old
winbond-cir.cfile but doesn't add one in thedrivers/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
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 structrc_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
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 structrc_dev,Which is the way it is with or without my patch, either a struct
ir_dev_propsor a subset of the former members of that struct are inIR_i2c, same data. And right now you would need to have a mix betweenir_dev_propsdata and additionalir_devrelated data in structIR_i2c(the rc map name is outside ofir_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_devonly getsinput_name,input_physandinput_idfrom structrc_dev, and I did it that way because I didn't want to remove all that information from all drivers (and fillinput_devwith 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 inrc_devdirectly?
Duplicating dozens of fields is not a good idea.
Quoted 3 lines
The use of struct
ir_dev_propswas a truely bizarre interface. For
example: setting the props member was optional, and air_input_devstruct without a props member lacks adriver_typesubmember.
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 defaultdriver_typeis 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_propsdid not materialize in any of the changes I did (see for exampledrivers/media/dvb/dvb-usb/dib0700_devices.cwhich had similar requirements to structIR_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.
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 structrc_dev,Which is the way it is with or without my patch, either a struct
ir_dev_propsor a subset of the former members of that struct are inIR_i2c, same data. And right now you would need to have a mix betweenir_dev_propsdata and additionalir_devrelated data in structIR_i2c(the rc map name is outside ofir_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_devonly getsinput_name,input_physandinput_idfrom structrc_dev, and I did it that way because I didn't want to remove all that information from all drivers (and fillinput_devwith generic information instead).
Quoted 4 lines
input_devfields 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 initializerc_dev->input_devfields 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, atir_dev_propsstructs 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 inrc_devdirectly?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_propswas a truely bizarre interface. For
example: setting the props member was optional, and air_input_devstruct without a props member lacks adriver_typesubmember.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_propsdid not materialize in any of the changes I did (see for exampledrivers/media/dvb/dvb-usb/dib0700_devices.cwhich had similar requirements to structIR_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_coreport 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_devat the caller drivers, passing it viaplatform_datafor 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_devfields, 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
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_devonly getsinput_name,input_physandinput_idfrom structrc_dev, and I did it that way because I didn't want to remove all that information from all drivers (and fillinput_devwith generic information instead).
input_devfields 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 initializerc_dev->input_devfields directly, not duplicating the data (or having a helper in-lined routine) to initialize those fields?The data is not duplicated,
input_nameandinput_physare 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_devdirectly. 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_physandinput_idare 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, atir_dev_propsstructs 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_propsdid not materialize in any of the changes I did (see for exampledrivers/media/dvb/dvb-usb/dib0700_devices.cwhich had similar requirements to structIR_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_coreport 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_devat the caller drivers, passing it viaplatform_datafor 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_devfields, 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]
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_devonly getsinput_name,input_physandinput_idfrom structrc_dev, and I did it that way because I didn't want to remove all that information from all drivers (and fillinput_devwith generic information instead).
input_devfields 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 initializerc_dev->input_devfields directly, not duplicating the data (or having a helper in-lined routine) to initialize those fields?The data is not duplicated,
input_nameandinput_physare 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_devdirectly. 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_physandinput_idare 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, atir_dev_propsstructs 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_zilogprobably 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_propsdid not materialize in any of the changes I did (see for exampledrivers/media/dvb/dvb-usb/dib0700_devices.cwhich had similar requirements to structIR_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_coreport 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_zilogwas pretty similar tolirc_i2c, which we dropped entirely, as ir-kbd-i2c handles receive just fine for all the relevant rx-only deviceslirc_i2cworked 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_devat the caller drivers, passing it viaplatform_datafor 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_devfields, 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
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_zilogwas pretty similar tolirc_i2c, which we dropped entirely, as ir-kbd-i2c handles receive just fine for all the relevant rx-only deviceslirc_i2cworked 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 thatrc_register_device()should be called inside the i2c driver, but several parameters should be passed to it viaplatform_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_devviaplatform_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_deviceto 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_devicepatch on the top of it, doing a minimal change atIR_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
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_zilogwas pretty similar tolirc_i2c, which we dropped entirely, as ir-kbd-i2c handles receive just fine for all the relevant rx-only deviceslirc_i2cworked 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 thatrc_register_device()should be called inside the i2c driver, but several parameters should be passed to it viaplatform_data, in a way that is similar to ir-kbd-i2c.Yes, but if
lirc_zilogdoesn't use ir-kbd-i2c, there might not be a need for the large number of rc-specific members inplatform_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_devviaplatform_data.Shouldn't
platform_databe const? And you'll break the refcounting done inrc_allocate_device()andrc_free_device()/rc_unregister_device(). Not to mention the silent bugs that may be introduced if anyone modifiesrc_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_deviceto 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_devicepatch on the top of it, doing a minimal change atIR_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_devAPI the way it is basically and then we can revisit theIR_i2cdebate 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
Quoted 11 lines · Mauro Carvalho Chehab
Em 12-11-2010 10:12, David Härdeman escreveu:
Quoted 5 lines
Shouldn't
platform_databe const? And you'll break the refcounting done inrc_allocate_device()andrc_free_device()/rc_unregister_device(). Not to mention the silent bugs that may be introduced if anyone modifiesrc_allocate_device()without noticing that one driver isn't using it.It will still be const.
platform_datawill 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 callrc_allocate_device()and fill some fields there, instead ofir_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
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_databe const? And you'll break the refcounting done inrc_allocate_device()andrc_free_device()/rc_unregister_device(). Not to mention the silent bugs that may be introduced if anyone modifiesrc_allocate_device()without noticing that one driver isn't using it.It will still be const.
platform_datawill 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 callrc_allocate_device()and fill some fields there, instead ofir_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
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
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_rctree: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-cirremoved the old
winbond-cir.cfile but doesn't add one in thedrivers/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)
Quoted 3 lines · David Härdeman
This is my current patch queue, the main change is to make struct
rc_devthe 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
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_devthe 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