[PATCH 0/9 v2] IR: few fixes, additions and ENE driver

[PATCH 0/9 v2] IR: few fixes, additions and ENE driver

[Maxim Levitsky]

Hi,

This is third revision of my patchset.

Notable changes:

* Added whitespace fixes from Jarod Wilson
* 4 new bugs fixed (patches 04-07). Now in-kernel decoding
  works perfectly with all protocols it supports.
* lirc interface additions cleaned up.
  no more wrong support for timeout reports
  new ioctl for learning mode
  still need to add carrier detect, timeout reports, and rx filter
* replaced int with bool in my driver, plus few cleanups.
* added myself to maintainers of the ene driver
* added another PNP ID to ene driver

Best regards,
	Maxim Levitsky

[PATCH 01/13] IR: Kconfig fixes

[Maxim Levitsky]

Move IR drives below separate menu.
This allows to disable them.
Also correct a typo.

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 drivers/media/IR/Kconfig |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index e557ae0..fc48a3f 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -1,8 +1,10 @@
-config IR_CORE
-	tristate
+menuconfig IR_CORE
+	tristate "Infrared remote controller adapters"
 	depends on INPUT
 	default INPUT
 
+if IR_CORE
+
 config VIDEO_IR
 	tristate
 	depends on IR_CORE
@@ -16,7 +18,7 @@ config LIRC
 	   Enable this option to build the Linux Infrared Remote
 	   Control (LIRC) core device interface driver. The LIRC
 	   interface passes raw IR to and from userspace, where the
-	   LIRC daemon handles protocol decoding for IR reception ann
+	   LIRC daemon handles protocol decoding for IR reception and
 	   encoding for IR transmitting (aka "blasting").
 
 source "drivers/media/IR/keymaps/Kconfig"
@@ -102,3 +104,5 @@ config IR_MCEUSB
 
 	   To compile this driver as a module, choose M here: the
 	   module will be called mceusb.
+
+endif #IR_CORE
-- 
1.7.0.4

[PATCH 02/13] IR: minor fixes:

[Maxim Levitsky]

* lirc: Don't propagate reset event to userspace
* lirc: Remove strange logic from lirc that would make first sample always be pulse
* Make TO_US macro actualy print what it should.

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 drivers/media/IR/ir-core-priv.h  |    4 +---
 drivers/media/IR/ir-lirc-codec.c |   14 ++++++++------
 drivers/media/IR/ir-raw-event.c  |    3 +++
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index babd520..dc26e2b 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -76,7 +76,6 @@ struct ir_raw_event_ctrl {
 	struct lirc_codec {
 		struct ir_input_dev *ir_dev;
 		struct lirc_driver *drv;
-		int lircdata;
 	} lirc;
 };
 
@@ -104,10 +103,9 @@ static inline void decrease_duration(struct ir_raw_event *ev, unsigned duration)
 		ev->duration -= duration;
 }
 
-#define TO_US(duration)			(((duration) + 500) / 1000)
+#define TO_US(duration)			DIV_ROUND_CLOSEST((duration), 1000)
 #define TO_STR(is_pulse)		((is_pulse) ? "pulse" : "space")
 #define IS_RESET(ev)			(ev.duration == 0)
-
 /*
  * Routines from ir-sysfs.c - Meant to be called only internally inside
  * ir-core
diff --git a/drivers/media/IR/ir-lirc-codec.c b/drivers/media/IR/ir-lirc-codec.c
index 3ba482d..8ca01fd 100644
--- a/drivers/media/IR/ir-lirc-codec.c
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -32,6 +32,7 @@
 static int ir_lirc_decode(struct input_dev *input_dev, struct ir_raw_event ev)
 {
 	struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
+	int sample;
 
 	if (!(ir_dev->raw->enabled_protocols & IR_TYPE_LIRC))
 		return 0;
@@ -39,18 +40,21 @@ static int ir_lirc_decode(struct input_dev *input_dev, struct ir_raw_event ev)
 	if (!ir_dev->raw->lirc.drv || !ir_dev->raw->lirc.drv->rbuf)
 		return -EINVAL;
 
+	if (IS_RESET(ev))
+		return 0;
+
 	IR_dprintk(2, "LIRC data transfer started (%uus %s)\n",
 		   TO_US(ev.duration), TO_STR(ev.pulse));
 
-	ir_dev->raw->lirc.lircdata += ev.duration / 1000;
+
+	sample = ev.duration / 1000;
 	if (ev.pulse)
-		ir_dev->raw->lirc.lircdata |= PULSE_BIT;
+		sample |= PULSE_BIT;
 
 	lirc_buffer_write(ir_dev->raw->lirc.drv->rbuf,
-			  (unsigned char *) &ir_dev->raw->lirc.lircdata);
+			  (unsigned char *) &sample);
 	wake_up(&ir_dev->raw->lirc.drv->rbuf->wait_poll);
 
-	ir_dev->raw->lirc.lircdata = 0;
 
 	return 0;
 }
@@ -224,8 +228,6 @@ static int ir_lirc_register(struct input_dev *input_dev)
 
 	ir_dev->raw->lirc.drv = drv;
 	ir_dev->raw->lirc.ir_dev = ir_dev;
-	ir_dev->raw->lirc.lircdata = PULSE_MASK;
-
 	return 0;
 
 lirc_register_failed:
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index 6f192ef..51f65da 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -66,6 +66,9 @@ int ir_raw_event_store(struct input_dev *input_dev, struct ir_raw_event *ev)
 	if (!ir->raw)
 		return -EINVAL;
 
+	IR_dprintk(2, "sample: (05%dus %s)\n",
+		TO_US(ev->duration), TO_STR(ev->pulse));
+
 	if (kfifo_in(&ir->raw->kfifo, ev, sizeof(*ev)) != sizeof(*ev))
 		return -ENOMEM;
 
-- 
1.7.0.4

[PATCH 03/13] IR: replace spinlock with mutex.

[Maxim Levitsky]

Some handlers (lirc for example) allocates memory on initialization,
doing so in atomic context is cumbersome.
Fixes warning about sleeping function in atomic context.

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 drivers/media/IR/ir-raw-event.c |   28 ++++++++++++++--------------
 1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index 51f65da..9d5c029 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -13,7 +13,7 @@
  */
 
 #include <linux/workqueue.h>
-#include <linux/spinlock.h>
+#include <linux/mutex.h>
 #include <linux/sched.h>
 #include "ir-core-priv.h"
 
@@ -24,7 +24,7 @@
 static LIST_HEAD(ir_raw_client_list);
 
 /* Used to handle IR raw handler extensions */
-static DEFINE_SPINLOCK(ir_raw_handler_lock);
+static DEFINE_MUTEX(ir_raw_handler_lock);
 static LIST_HEAD(ir_raw_handler_list);
 static u64 available_protocols;
 
@@ -41,10 +41,10 @@ static void ir_raw_event_work(struct work_struct *work)
 		container_of(work, struct ir_raw_event_ctrl, rx_work);
 
 	while (kfifo_out(&raw->kfifo, &ev, sizeof(ev)) == sizeof(ev)) {
-		spin_lock(&ir_raw_handler_lock);
+		mutex_lock(&ir_raw_handler_lock);
 		list_for_each_entry(handler, &ir_raw_handler_list, list)
 			handler->decode(raw->input_dev, ev);
-		spin_unlock(&ir_raw_handler_lock);
+		mutex_unlock(&ir_raw_handler_lock);
 		raw->prev_ev = ev;
 	}
 }
@@ -150,9 +150,9 @@ u64
 ir_raw_get_allowed_protocols()
 {
 	u64 protocols;
-	spin_lock(&ir_raw_handler_lock);
+	mutex_lock(&ir_raw_handler_lock);
 	protocols = available_protocols;
-	spin_unlock(&ir_raw_handler_lock);
+	mutex_unlock(&ir_raw_handler_lock);
 	return protocols;
 }
 
@@ -180,12 +180,12 @@ int ir_raw_event_register(struct input_dev *input_dev)
 		return rc;
 	}
 
-	spin_lock(&ir_raw_handler_lock);
+	mutex_lock(&ir_raw_handler_lock);
 	list_add_tail(&ir->raw->list, &ir_raw_client_list);
 	list_for_each_entry(handler, &ir_raw_handler_list, list)
 		if (handler->raw_register)
 			handler->raw_register(ir->raw->input_dev);
-	spin_unlock(&ir_raw_handler_lock);
+	mutex_unlock(&ir_raw_handler_lock);
 
 	return 0;
 }
@@ -200,12 +200,12 @@ void ir_raw_event_unregister(struct input_dev *input_dev)
 
 	cancel_work_sync(&ir->raw->rx_work);
 
-	spin_lock(&ir_raw_handler_lock);
+	mutex_lock(&ir_raw_handler_lock);
 	list_del(&ir->raw->list);
 	list_for_each_entry(handler, &ir_raw_handler_list, list)
 		if (handler->raw_unregister)
 			handler->raw_unregister(ir->raw->input_dev);
-	spin_unlock(&ir_raw_handler_lock);
+	mutex_unlock(&ir_raw_handler_lock);
 
 	kfifo_free(&ir->raw->kfifo);
 	kfree(ir->raw);
@@ -220,13 +220,13 @@ int ir_raw_handler_register(struct ir_raw_handler *ir_raw_handler)
 {
 	struct ir_raw_event_ctrl *raw;
 
-	spin_lock(&ir_raw_handler_lock);
+	mutex_lock(&ir_raw_handler_lock);
 	list_add_tail(&ir_raw_handler->list, &ir_raw_handler_list);
 	if (ir_raw_handler->raw_register)
 		list_for_each_entry(raw, &ir_raw_client_list, list)
 			ir_raw_handler->raw_register(raw->input_dev);
 	available_protocols |= ir_raw_handler->protocols;
-	spin_unlock(&ir_raw_handler_lock);
+	mutex_unlock(&ir_raw_handler_lock);
 
 	return 0;
 }
@@ -236,13 +236,13 @@ void ir_raw_handler_unregister(struct ir_raw_handler *ir_raw_handler)
 {
 	struct ir_raw_event_ctrl *raw;
 
-	spin_lock(&ir_raw_handler_lock);
+	mutex_lock(&ir_raw_handler_lock);
 	list_del(&ir_raw_handler->list);
 	if (ir_raw_handler->raw_unregister)
 		list_for_each_entry(raw, &ir_raw_client_list, list)
 			ir_raw_handler->raw_unregister(raw->input_dev);
 	available_protocols &= ~ir_raw_handler->protocols;
-	spin_unlock(&ir_raw_handler_lock);
+	mutex_unlock(&ir_raw_handler_lock);
 }
 EXPORT_SYMBOL(ir_raw_handler_unregister);
 
-- 
1.7.0.4

[PATCH 04/13] IR: fix locking in ir_raw_event_work

[Maxim Levitsky]

It is prefectly possible to have ir_raw_event_work
running concurently on two cpus, thus we must protect
it from that situation.

Maybe better solution is to ditch the workqueue at all
and use good 'ol thread per receiver, and just wake it up...

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 drivers/media/IR/ir-raw-event.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index 9d5c029..4098748 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -40,13 +40,16 @@ static void ir_raw_event_work(struct work_struct *work)
 	struct ir_raw_event_ctrl *raw =
 		container_of(work, struct ir_raw_event_ctrl, rx_work);
 
+	mutex_lock(&ir_raw_handler_lock);
+
 	while (kfifo_out(&raw->kfifo, &ev, sizeof(ev)) == sizeof(ev)) {
-		mutex_lock(&ir_raw_handler_lock);
 		list_for_each_entry(handler, &ir_raw_handler_list, list)
 			handler->decode(raw->input_dev, ev);
-		mutex_unlock(&ir_raw_handler_lock);
 		raw->prev_ev = ev;
 	}
+
+	mutex_unlock(&ir_raw_handler_lock);
+
 }
 
 /**
-- 
1.7.0.4

Re: [PATCH 04/13] IR: fix locking in ir_raw_event_work

[Andy Walls]

On Fri, 2010-07-30 at 05:17 +0300, Maxim Levitsky wrote:
> It is prefectly possible to have ir_raw_event_work
> running concurently on two cpus, thus we must protect
> it from that situation.

Yup, the work is marked as not pending (and hence reschedulable) just
before the work handler is run.


> Maybe better solution is to ditch the workqueue at all
> and use good 'ol thread per receiver, and just wake it up...

I suppose you could also use a single threaded workqueue instead of a
mutex, and let a bit test provide exclusivity.  With the mutex, when the
second thread finally obtains the lock, there will likely not be
anything for it to do.

Regards,
Andy


> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> ---
>  drivers/media/IR/ir-raw-event.c |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
> index 9d5c029..4098748 100644
> --- a/drivers/media/IR/ir-raw-event.c
> +++ b/drivers/media/IR/ir-raw-event.c
> @@ -40,13 +40,16 @@ static void ir_raw_event_work(struct work_struct *work)
>  	struct ir_raw_event_ctrl *raw =
>  		container_of(work, struct ir_raw_event_ctrl, rx_work);
>  
> +	mutex_lock(&ir_raw_handler_lock);
> +
>  	while (kfifo_out(&raw->kfifo, &ev, sizeof(ev)) == sizeof(ev)) {
> -		mutex_lock(&ir_raw_handler_lock);
>  		list_for_each_entry(handler, &ir_raw_handler_list, list)
>  			handler->decode(raw->input_dev, ev);
> -		mutex_unlock(&ir_raw_handler_lock);
>  		raw->prev_ev = ev;
>  	}
> +
> +	mutex_unlock(&ir_raw_handler_lock);
> +
>  }
>  
>  /**

Re: [PATCH 04/13] IR: fix locking in ir_raw_event_work

[Maxim Levitsky]

On Thu, 2010-07-29 at 22:42 -0400, Andy Walls wrote: 
> On Fri, 2010-07-30 at 05:17 +0300, Maxim Levitsky wrote:
> > It is prefectly possible to have ir_raw_event_work
> > running concurently on two cpus, thus we must protect
> > it from that situation.
> 
> Yup, the work is marked as not pending (and hence reschedulable) just
> before the work handler is run.
> 
> 
> > Maybe better solution is to ditch the workqueue at all
> > and use good 'ol thread per receiver, and just wake it up...
> 
> I suppose you could also use a single threaded workqueue instead of a
> mutex, and let a bit test provide exclusivity.  With the mutex, when the
> second thread finally obtains the lock, there will likely not be
> anything for it to do.
Mutex there is for another reason, to protect against decoder
insert/removal.

However, I think its best just to use a bare kthread for the purpose of
this.

Best regards,
Maxim Levitsky

[PATCH 05/13] IR: JVC: make repeat work

[Maxim Levitsky]

Currently, jvc decoder will attempt misdetect next press as a repeat
of last keypress, therefore second keypress isn't detected.

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 drivers/media/IR/ir-jvc-decoder.c |   14 +++++++++++++-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/drivers/media/IR/ir-jvc-decoder.c b/drivers/media/IR/ir-jvc-decoder.c
index 8894d8b..77a89c4 100644
--- a/drivers/media/IR/ir-jvc-decoder.c
+++ b/drivers/media/IR/ir-jvc-decoder.c
@@ -32,6 +32,7 @@ enum jvc_state {
 	STATE_BIT_SPACE,
 	STATE_TRAILER_PULSE,
 	STATE_TRAILER_SPACE,
+	STATE_CHECK_REPEAT,
 };
 
 /**
@@ -60,6 +61,7 @@ static int ir_jvc_decode(struct input_dev *input_dev, struct ir_raw_event ev)
 	IR_dprintk(2, "JVC decode started at state %d (%uus %s)\n",
 		   data->state, TO_US(ev.duration), TO_STR(ev.pulse));
 
+again:
 	switch (data->state) {
 
 	case STATE_INACTIVE:
@@ -149,8 +151,18 @@ static int ir_jvc_decode(struct input_dev *input_dev, struct ir_raw_event ev)
 		}
 
 		data->count = 0;
-		data->state = STATE_BIT_PULSE;
+		data->state = STATE_CHECK_REPEAT;
 		return 0;
+
+	case STATE_CHECK_REPEAT:
+		if (!ev.pulse)
+			break;
+
+		if (eq_margin(ev.duration, JVC_HEADER_PULSE, JVC_UNIT / 2))
+			data->state = STATE_INACTIVE;
+  else
+			data->state = STATE_BIT_PULSE;
+		goto again;
 	}
 
 out:
-- 
1.7.0.4

[PATCH 06/13] IR: nec decoder: fix repeat.

[Maxim Levitsky]

Repeat space is 4 units, not 8.
Current code would never trigger a repeat.

However that isn't true for NECX, so repeat there
must be handled differently.

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 drivers/media/IR/ir-nec-decoder.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/IR/ir-nec-decoder.c b/drivers/media/IR/ir-nec-decoder.c
index 52e0f37..1c0cf03 100644
--- a/drivers/media/IR/ir-nec-decoder.c
+++ b/drivers/media/IR/ir-nec-decoder.c
@@ -20,7 +20,7 @@
 #define NEC_HEADER_PULSE	(16 * NEC_UNIT)
 #define NECX_HEADER_PULSE	(8  * NEC_UNIT) /* Less common NEC variant */
 #define NEC_HEADER_SPACE	(8  * NEC_UNIT)
-#define NEC_REPEAT_SPACE	(8  * NEC_UNIT)
+#define NEC_REPEAT_SPACE	(4  * NEC_UNIT)
 #define NEC_BIT_PULSE		(1  * NEC_UNIT)
 #define NEC_BIT_0_SPACE		(1  * NEC_UNIT)
 #define NEC_BIT_1_SPACE		(3  * NEC_UNIT)
-- 
1.7.0.4

Re: [PATCH 06/13] IR: nec decoder: fix repeat.

[Andy Walls]

On Fri, 2010-07-30 at 05:17 +0300, Maxim Levitsky wrote:
> Repeat space is 4 units, not 8.
> Current code would never trigger a repeat.


Yup.  Page 11, line (4)

http://www.datasheetcatalog.org/datasheet/nec/UPD6122G-002.pdf

Reviewed-by: Andy Walls <awalls@md.metrocast.net>

Regards,
Andy

> However that isn't true for NECX, so repeat there
> must be handled differently.
> 
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> ---
>  drivers/media/IR/ir-nec-decoder.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/IR/ir-nec-decoder.c b/drivers/media/IR/ir-nec-decoder.c
> index 52e0f37..1c0cf03 100644
> --- a/drivers/media/IR/ir-nec-decoder.c
> +++ b/drivers/media/IR/ir-nec-decoder.c
> @@ -20,7 +20,7 @@
>  #define NEC_HEADER_PULSE	(16 * NEC_UNIT)
>  #define NECX_HEADER_PULSE	(8  * NEC_UNIT) /* Less common NEC variant */
>  #define NEC_HEADER_SPACE	(8  * NEC_UNIT)
> -#define NEC_REPEAT_SPACE	(8  * NEC_UNIT)
> +#define NEC_REPEAT_SPACE	(4  * NEC_UNIT)
>  #define NEC_BIT_PULSE		(1  * NEC_UNIT)
>  #define NEC_BIT_0_SPACE		(1  * NEC_UNIT)
>  #define NEC_BIT_1_SPACE		(3  * NEC_UNIT)

[PATCH 07/13] IR: NECX: support repeat

[Maxim Levitsky]

This adds support for repeat detecting for NECX variant
Tested with uneversal remote

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 drivers/media/IR/ir-core-priv.h   |    1 +
 drivers/media/IR/ir-nec-decoder.c |   16 ++++++++++++++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index dc26e2b..494e1f8 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -45,6 +45,7 @@ struct ir_raw_event_ctrl {
 		int state;
 		unsigned count;
 		u32 bits;
+		bool is_nec_x;
 	} nec;
 	struct rc5_dec {
 		int state;
diff --git a/drivers/media/IR/ir-nec-decoder.c b/drivers/media/IR/ir-nec-decoder.c
index 1c0cf03..59127b1 100644
--- a/drivers/media/IR/ir-nec-decoder.c
+++ b/drivers/media/IR/ir-nec-decoder.c
@@ -26,6 +26,7 @@
 #define NEC_BIT_1_SPACE		(3  * NEC_UNIT)
 #define	NEC_TRAILER_PULSE	(1  * NEC_UNIT)
 #define	NEC_TRAILER_SPACE	(10 * NEC_UNIT) /* even longer in reality */
+#define NECX_REPEAT_BITS	1
 
 enum nec_state {
 	STATE_INACTIVE,
@@ -67,8 +68,11 @@ static int ir_nec_decode(struct input_dev *input_dev, struct ir_raw_event ev)
 		if (!ev.pulse)
 			break;
 
-		if (!eq_margin(ev.duration, NEC_HEADER_PULSE, NEC_UNIT / 2) &&
-		    !eq_margin(ev.duration, NECX_HEADER_PULSE, NEC_UNIT / 2))
+		if (eq_margin(ev.duration, NEC_HEADER_PULSE, NEC_UNIT / 2))
+			data->is_nec_x = false;
+		else if (eq_margin(ev.duration, NECX_HEADER_PULSE, NEC_UNIT / 2))
+			data->is_nec_x = true;
+		else
 			break;
 
 		data->count = 0;
@@ -105,6 +109,14 @@ static int ir_nec_decode(struct input_dev *input_dev, struct ir_raw_event ev)
 		if (ev.pulse)
 			break;
 
+		if (geq_margin(ev.duration, NEC_TRAILER_SPACE, NEC_UNIT / 2) &&
+			data->is_nec_x && data->count == NECX_REPEAT_BITS) {
+				IR_dprintk(1, "Repeat last key\n");
+				ir_repeat(input_dev);
+				data->state = STATE_INACTIVE;
+				return 0;
+			}
+
 		data->bits <<= 1;
 		if (eq_margin(ev.duration, NEC_BIT_1_SPACE, NEC_UNIT / 2))
 			data->bits |= 1;
-- 
1.7.0.4

[PATCH 08/13] IR: Allow not to compile keymaps in.

[Maxim Levitsky]

Currently, ir device registration fails if keymap requested by driver is not found.
Fix that by always compiling in the empty keymap, and using it as a failback.

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 drivers/media/IR/ir-core-priv.h     |    3 +-
 drivers/media/IR/ir-sysfs.c         |    2 +
 drivers/media/IR/keymaps/Makefile   |    1 -
 drivers/media/IR/keymaps/rc-empty.c |   44 -----------------------------------
 drivers/media/IR/rc-map.c           |   23 ++++++++++++++++++
 include/media/ir-core.h             |    8 ++++-
 6 files changed, 33 insertions(+), 48 deletions(-)
 delete mode 100644 drivers/media/IR/keymaps/rc-empty.c

diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 494e1f8..fe84374 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -125,7 +125,8 @@ 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
  *
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index a841e51..936dff8 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -341,6 +341,7 @@ static int __init ir_core_init(void)
 
 	/* Initialize/load the decoders/keymap code that will be used */
 	ir_raw_init();
+	ir_rcmap_init();
 
 	return 0;
 }
@@ -348,6 +349,7 @@ static int __init ir_core_init(void)
 static void __exit ir_core_exit(void)
 {
 	class_unregister(&ir_input_class);
+	ir_rcmap_cleanup();
 }
 
 module_init(ir_core_init);
diff --git a/drivers/media/IR/keymaps/Makefile b/drivers/media/IR/keymaps/Makefile
index 86d3d1f..24992cd 100644
--- a/drivers/media/IR/keymaps/Makefile
+++ b/drivers/media/IR/keymaps/Makefile
@@ -17,7 +17,6 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
 			rc-dm1105-nec.o \
 			rc-dntv-live-dvb-t.o \
 			rc-dntv-live-dvbt-pro.o \
-			rc-empty.o \
 			rc-em-terratec.o \
 			rc-encore-enltv2.o \
 			rc-encore-enltv.o \
diff --git a/drivers/media/IR/keymaps/rc-empty.c b/drivers/media/IR/keymaps/rc-empty.c
deleted file mode 100644
index 3b338d8..0000000
--- a/drivers/media/IR/keymaps/rc-empty.c
+++ /dev/null
@@ -1,44 +0,0 @@
-/* empty.h - Keytable for empty Remote Controller
- *
- * keymap imported from ir-keymaps.c
- *
- * Copyright (c) 2010 by Mauro Carvalho Chehab <mchehab@redhat.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include <media/rc-map.h>
-
-/* empty keytable, can be used as placeholder for not-yet created keytables */
-
-static struct ir_scancode empty[] = {
-	{ 0x2a, KEY_COFFEE },
-};
-
-static struct rc_keymap empty_map = {
-	.map = {
-		.scan    = empty,
-		.size    = ARRAY_SIZE(empty),
-		.ir_type = IR_TYPE_UNKNOWN,	/* Legacy IR type */
-		.name    = RC_MAP_EMPTY,
-	}
-};
-
-static int __init init_rc_map_empty(void)
-{
-	return ir_register_map(&empty_map);
-}
-
-static void __exit exit_rc_map_empty(void)
-{
-	ir_unregister_map(&empty_map);
-}
-
-module_init(init_rc_map_empty)
-module_exit(exit_rc_map_empty)
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Mauro Carvalho Chehab <mchehab@redhat.com>");
diff --git a/drivers/media/IR/rc-map.c b/drivers/media/IR/rc-map.c
index 46a8f15..689143f 100644
--- a/drivers/media/IR/rc-map.c
+++ b/drivers/media/IR/rc-map.c
@@ -82,3 +82,26 @@ void ir_unregister_map(struct rc_keymap *map)
 }
 EXPORT_SYMBOL_GPL(ir_unregister_map);
 
+
+static struct ir_scancode empty[] = {
+	{ 0x2a, KEY_COFFEE },
+};
+
+static struct rc_keymap empty_map = {
+	.map = {
+		.scan    = empty,
+		.size    = ARRAY_SIZE(empty),
+		.ir_type = IR_TYPE_UNKNOWN,	/* Legacy IR type */
+		.name    = RC_MAP_EMPTY,
+	}
+};
+
+int ir_rcmap_init(void)
+{
+	return ir_register_map(&empty_map);
+}
+
+void ir_rcmap_cleanup(void)
+{
+	ir_unregister_map(&empty_map);
+}
diff --git a/include/media/ir-core.h b/include/media/ir-core.h
index 513e60d..197d05a 100644
--- a/include/media/ir-core.h
+++ b/include/media/ir-core.h
@@ -110,8 +110,12 @@ static inline int ir_input_register(struct input_dev *dev,
 		return -EINVAL;
 
 	ir_codes = get_rc_map(map_name);
-	if (!ir_codes)
-		return -EINVAL;
+	if (!ir_codes) {
+		ir_codes = get_rc_map(RC_MAP_EMPTY);
+
+		if (!ir_codes)
+			return -EINVAL;
+	}
 
 	rc = __ir_input_register(dev, ir_codes, props, driver_name);
 	if (rc < 0)
-- 
1.7.0.4

[PATCH 09/13] IR: add helper function for hardware with small o/b buffer.

[Maxim Levitsky]

Some ir input devices have small buffer, and interrupt the host
each time it is full (or half full)

Add a helper that automaticly handles timeouts, and also
automaticly merges samples of same time (space-space)
Such samples might be placed by hardware because size of
sample in the buffer is small (a byte for example).

Also remove constness from ir_dev_props, because it now contains timeout
settings that driver might want to change

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 drivers/media/IR/ir-core-priv.h |    1 +
 drivers/media/IR/ir-keytable.c  |    2 +-
 drivers/media/IR/ir-raw-event.c |   84 +++++++++++++++++++++++++++++++++++++++
 include/media/ir-core.h         |   23 +++++++++-
 4 files changed, 106 insertions(+), 4 deletions(-)

diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index fe84374..841b76c 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -41,6 +41,7 @@ struct ir_raw_event_ctrl {
 
 	/* raw decoder state follows */
 	struct ir_raw_event prev_ev;
+	struct ir_raw_event this_ev;
 	struct nec_dec {
 		int state;
 		unsigned count;
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 94a8577..34b9c07 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -428,7 +428,7 @@ static void ir_close(struct input_dev *input_dev)
  */
 int __ir_input_register(struct input_dev *input_dev,
 		      const struct ir_scancode_table *rc_tab,
-		      const struct ir_dev_props *props,
+		      struct ir_dev_props *props,
 		      const char *driver_name)
 {
 	struct ir_input_dev *ir_dev;
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index 4098748..5a6f8ce 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -132,6 +132,90 @@ int ir_raw_event_store_edge(struct input_dev *input_dev, enum raw_event_type typ
 EXPORT_SYMBOL_GPL(ir_raw_event_store_edge);
 
 /**
+ * ir_raw_event_store_with_filter() - pass next pulse/space to decoders with some processing
+ * @input_dev:	the struct input_dev device descriptor
+ * @type:	the type of the event that has occurred
+ *
+ * This routine (which may be called from an interrupt context) works
+ * in similiar manner to ir_raw_event_store_edge.
+ * This routine is intended for devices with limited internal buffer
+ * It automerges samples of same type, and handles timeouts
+ */
+int ir_raw_event_store_with_filter(struct input_dev *input_dev,
+						struct ir_raw_event *ev)
+{
+	struct ir_input_dev *ir = input_get_drvdata(input_dev);
+	struct ir_raw_event_ctrl *raw = ir->raw;
+
+	if (!raw || !ir->props)
+		return -EINVAL;
+
+	/* Ignore spaces in idle mode */
+	if (ir->idle && !ev->pulse)
+		return 0;
+	else if (ir->idle)
+		ir_raw_event_set_idle(input_dev, 0);
+
+	if (!raw->this_ev.duration) {
+		raw->this_ev = *ev;
+	} else if (ev->pulse == raw->this_ev.pulse) {
+		raw->this_ev.duration += ev->duration;
+	} else {
+		ir_raw_event_store(input_dev, &raw->this_ev);
+		raw->this_ev = *ev;
+	}
+
+	/* Enter idle mode if nessesary */
+	if (!ev->pulse && ir->props->timeout &&
+		raw->this_ev.duration >= ir->props->timeout)
+		ir_raw_event_set_idle(input_dev, 1);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(ir_raw_event_store_with_filter);
+
+void ir_raw_event_set_idle(struct input_dev *input_dev, int idle)
+{
+	struct ir_input_dev *ir = input_get_drvdata(input_dev);
+	struct ir_raw_event_ctrl *raw = ir->raw;
+	ktime_t now;
+	u64 delta;
+
+	if (!ir->props)
+		return;
+
+	if (!ir->raw)
+		goto out;
+
+	if (idle) {
+		IR_dprintk(2, "enter idle mode\n");
+		raw->last_event = ktime_get();
+	} else {
+		IR_dprintk(2, "exit idle mode\n");
+
+		now = ktime_get();
+		delta = ktime_to_ns(ktime_sub(now, ir->raw->last_event));
+
+		WARN_ON(raw->this_ev.pulse);
+
+		raw->this_ev.duration =
+			min(raw->this_ev.duration + delta,
+						(u64)IR_MAX_DURATION);
+
+		ir_raw_event_store(input_dev, &raw->this_ev);
+
+		if (raw->this_ev.duration == IR_MAX_DURATION)
+			ir_raw_event_reset(input_dev);
+
+		raw->this_ev.duration = 0;
+	}
+out:
+	if (ir->props->s_idle)
+		ir->props->s_idle(ir->props->priv, idle);
+	ir->idle = idle;
+}
+EXPORT_SYMBOL_GPL(ir_raw_event_set_idle);
+
+/**
  * ir_raw_event_handle() - schedules the decoding of stored ir data
  * @input_dev:	the struct input_dev device descriptor
  *
diff --git a/include/media/ir-core.h b/include/media/ir-core.h
index 197d05a..7ad39fe 100644
--- a/include/media/ir-core.h
+++ b/include/media/ir-core.h
@@ -41,6 +41,9 @@ enum rc_driver_type {
  *	anything with it. Yet, as the same keycode table can be used with other
  *	devices, a mask is provided to allow its usage. Drivers should generally
  *	leave this field in blank
+ * @timeout: optional time after which device stops sending data
+ * @min_timeout: minimum timeout supported by device
+ * @max_timeout: maximum timeout supported by device
  * @priv: driver-specific data, to be used on the callbacks
  * @change_protocol: allow changing the protocol used on hardware decoders
  * @open: callback to allow drivers to enable polling/irq when IR input device
@@ -50,11 +53,19 @@ enum rc_driver_type {
  * @s_tx_mask: set transmitter mask (for devices with multiple tx outputs)
  * @s_tx_carrier: set transmit carrier frequency
  * @tx_ir: transmit IR
+ * @s_idle: optional: enable/disable hardware idle mode, upon which,
+ *	device doesn't interrupt host untill it sees IR data
  */
 struct ir_dev_props {
 	enum rc_driver_type	driver_type;
 	unsigned long		allowed_protos;
 	u32			scanmask;
+
+	u64			timeout;
+	u64			min_timeout;
+	u64			max_timeout;
+
+
 	void			*priv;
 	int			(*change_protocol)(void *priv, u64 ir_type);
 	int			(*open)(void *priv);
@@ -62,6 +73,7 @@ struct ir_dev_props {
 	int			(*s_tx_mask)(void *priv, u32 mask);
 	int			(*s_tx_carrier)(void *priv, u32 carrier);
 	int			(*tx_ir)(void *priv, int *txbuf, u32 n);
+	void			(*s_idle)(void *priv, int enable);
 };
 
 struct ir_input_dev {
@@ -69,9 +81,10 @@ struct ir_input_dev {
 	char				*driver_name;	/* Name of the driver module */
 	struct ir_scancode_table	rc_tab;		/* scan/key table */
 	unsigned long			devno;		/* device number */
-	const struct ir_dev_props	*props;		/* Device properties */
+	struct ir_dev_props		*props;		/* Device properties */
 	struct ir_raw_event_ctrl	*raw;		/* for raw pulse/space events */
 	struct input_dev		*input_dev;	/* the input device associated with this device */
+	bool				idle;
 
 	/* key info - needed by IR keycode handlers */
 	spinlock_t			keylock;	/* protects the below members */
@@ -95,12 +108,12 @@ enum raw_event_type {
 /* From ir-keytable.c */
 int __ir_input_register(struct input_dev *dev,
 		      const struct ir_scancode_table *ir_codes,
-		      const struct ir_dev_props *props,
+		      struct ir_dev_props *props,
 		      const char *driver_name);
 
 static inline int ir_input_register(struct input_dev *dev,
 		      const char *map_name,
-		      const struct ir_dev_props *props,
+		      struct ir_dev_props *props,
 		      const char *driver_name) {
 	struct ir_scancode_table *ir_codes;
 	struct ir_input_dev *ir_dev;
@@ -148,6 +161,10 @@ struct ir_raw_event {
 void ir_raw_event_handle(struct input_dev *input_dev);
 int ir_raw_event_store(struct input_dev *input_dev, struct ir_raw_event *ev);
 int ir_raw_event_store_edge(struct input_dev *input_dev, enum raw_event_type type);
+int ir_raw_event_store_with_filter(struct input_dev *input_dev,
+				struct ir_raw_event *ev);
+void ir_raw_event_set_idle(struct input_dev *input_dev, int idle);
+
 static inline void ir_raw_event_reset(struct input_dev *input_dev)
 {
 	struct ir_raw_event ev = { .pulse = false, .duration = 0 };
-- 
1.7.0.4

[PATCH 10/13] IR: extend interfaces to support more device settings LIRC: add new IOCTL that enables learning mode (wide band receiver)

[Maxim Levitsky]

Still missing features: carrier report & timeout reports.
Will need to pack these into ir_raw_event


Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 drivers/media/IR/ir-core-priv.h  |    1 +
 drivers/media/IR/ir-lirc-codec.c |  112 +++++++++++++++++++++++++++++++-------
 include/media/ir-core.h          |   14 +++++
 include/media/lirc.h             |    5 ++-
 4 files changed, 112 insertions(+), 20 deletions(-)

diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 841b76c..068807d 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -78,6 +78,7 @@ struct ir_raw_event_ctrl {
 	struct lirc_codec {
 		struct ir_input_dev *ir_dev;
 		struct lirc_driver *drv;
+		int carrier_low;
 	} lirc;
 };
 
diff --git a/drivers/media/IR/ir-lirc-codec.c b/drivers/media/IR/ir-lirc-codec.c
index 8ca01fd..5d5150f 100644
--- a/drivers/media/IR/ir-lirc-codec.c
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -46,7 +46,6 @@ static int ir_lirc_decode(struct input_dev *input_dev, struct ir_raw_event ev)
 	IR_dprintk(2, "LIRC data transfer started (%uus %s)\n",
 		   TO_US(ev.duration), TO_STR(ev.pulse));
 
-
 	sample = ev.duration / 1000;
 	if (ev.pulse)
 		sample |= PULSE_BIT;
@@ -96,13 +95,14 @@ out:
 	return ret;
 }
 
-static long ir_lirc_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
+static long ir_lirc_ioctl(struct file *filep, unsigned int cmd,
+			unsigned long __user arg)
 {
 	struct lirc_codec *lirc;
 	struct ir_input_dev *ir_dev;
 	int ret = 0;
 	void *drv_data;
-	unsigned long val;
+	unsigned long val = 0;
 
 	lirc = lirc_get_pdata(filep);
 	if (!lirc)
@@ -114,47 +114,106 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int cmd, unsigned long ar
 
 	drv_data = ir_dev->props->priv;
 
-	switch (cmd) {
-	case LIRC_SET_TRANSMITTER_MASK:
+	if (_IOC_DIR(cmd) & _IOC_WRITE) {
 		ret = get_user(val, (unsigned long *)arg);
 		if (ret)
 			return ret;
+	}
+
+	switch (cmd) {
+
+	/* legacy support */
+	case LIRC_GET_SEND_MODE:
+		val = LIRC_CAN_SEND_PULSE & LIRC_CAN_SEND_MASK;
+		break;
+
+	case LIRC_SET_SEND_MODE:
+		if (val != (LIRC_MODE_PULSE & LIRC_CAN_SEND_MASK))
+			return -EINVAL;
+		break;
 
-		if (ir_dev->props && ir_dev->props->s_tx_mask)
+	/* TX settings */
+	case LIRC_SET_TRANSMITTER_MASK:
+		if (ir_dev->props->s_tx_mask)
 			ret = ir_dev->props->s_tx_mask(drv_data, (u32)val);
 		else
 			return -EINVAL;
 		break;
 
 	case LIRC_SET_SEND_CARRIER:
-		ret = get_user(val, (unsigned long *)arg);
-		if (ret)
-			return ret;
-
-		if (ir_dev->props && ir_dev->props->s_tx_carrier)
+		if (ir_dev->props->s_tx_carrier)
 			ir_dev->props->s_tx_carrier(drv_data, (u32)val);
 		else
 			return -EINVAL;
 		break;
 
-	case LIRC_GET_SEND_MODE:
-		val = LIRC_CAN_SEND_PULSE & LIRC_CAN_SEND_MASK;
-		ret = put_user(val, (unsigned long *)arg);
+	case LIRC_SET_SEND_DUTY_CYCLE:
+		if (!ir_dev->props->s_tx_duty_cycle)
+			return -ENOSYS;
+
+		if (val <= 0 || val >= 100)
+			return -EINVAL;
+
+		ir_dev->props->s_tx_duty_cycle(ir_dev->props->priv, val);
 		break;
 
-	case LIRC_SET_SEND_MODE:
-		ret = get_user(val, (unsigned long *)arg);
-		if (ret)
-			return ret;
+	/* RX settings */
+	case LIRC_SET_REC_CARRIER:
+		if (ir_dev->props->s_rx_carrier_range)
+			ret = ir_dev->props->s_rx_carrier_range(
+				ir_dev->props->priv,
+				ir_dev->raw->lirc.carrier_low, val);
+		else
+			return -ENOSYS;
 
-		if (val != (LIRC_MODE_PULSE & LIRC_CAN_SEND_MASK))
+		if (!ret)
+			ir_dev->raw->lirc.carrier_low = 0;
+		break;
+
+	case LIRC_SET_REC_CARRIER_RANGE:
+		if (val >= 0)
+			ir_dev->raw->lirc.carrier_low = val;
+		break;
+
+
+	case LIRC_GET_REC_RESOLUTION:
+		val = ir_dev->props->rx_resolution;
+		break;
+
+	case LIRC_SET_WIDEBAND_RECEIVER:
+		if (ir_dev->props->s_learning_mode)
+			return ir_dev->props->s_learning_mode(
+				ir_dev->props->priv, !!val);
+		else
+			return -ENOSYS;
+
+	/* Generic timeout support */
+	case LIRC_GET_MIN_TIMEOUT:
+		if (!ir_dev->props->max_timeout)
+			return -ENOSYS;
+		val = ir_dev->props->min_timeout / 1000;
+		break;
+
+	case LIRC_GET_MAX_TIMEOUT:
+		if (!ir_dev->props->max_timeout)
+			return -ENOSYS;
+		val = ir_dev->props->max_timeout / 1000;
+		break;
+
+	case LIRC_SET_REC_TIMEOUT:
+		if (val < ir_dev->props->min_timeout ||
+		    val > ir_dev->props->max_timeout)
 			return -EINVAL;
+		ir_dev->props->timeout = val * 1000;
 		break;
 
 	default:
 		return lirc_dev_fop_ioctl(filep, cmd, arg);
 	}
 
+	if (_IOC_DIR(cmd) & _IOC_READ)
+		ret = put_user(val, (unsigned long *)arg);
+
 	return ret;
 }
 
@@ -200,13 +259,28 @@ static int ir_lirc_register(struct input_dev *input_dev)
 
 	features = LIRC_CAN_REC_MODE2;
 	if (ir_dev->props->tx_ir) {
+
 		features |= LIRC_CAN_SEND_PULSE;
 		if (ir_dev->props->s_tx_mask)
 			features |= LIRC_CAN_SET_TRANSMITTER_MASK;
 		if (ir_dev->props->s_tx_carrier)
 			features |= LIRC_CAN_SET_SEND_CARRIER;
+
+		if (ir_dev->props->s_tx_duty_cycle)
+			features |= LIRC_CAN_SET_REC_DUTY_CYCLE;
 	}
 
+	if (ir_dev->props->s_rx_carrier_range)
+		features |= LIRC_CAN_SET_REC_CARRIER |
+			LIRC_CAN_SET_REC_CARRIER_RANGE;
+
+	if (ir_dev->props->s_learning_mode)
+		features |= LIRC_CAN_HAVE_WIDEBAND_RECEIVER;
+
+	if (ir_dev->props->max_timeout)
+		features |= LIRC_CAN_SET_REC_TIMEOUT;
+
+
 	snprintf(drv->name, sizeof(drv->name), "ir-lirc-codec (%s)",
 		 ir_dev->driver_name);
 	drv->minor = -1;
diff --git a/include/media/ir-core.h b/include/media/ir-core.h
index 7ad39fe..ed9c1cb 100644
--- a/include/media/ir-core.h
+++ b/include/media/ir-core.h
@@ -44,6 +44,8 @@ enum rc_driver_type {
  * @timeout: optional time after which device stops sending data
  * @min_timeout: minimum timeout supported by device
  * @max_timeout: maximum timeout supported by device
+ * @rx_resolution : resolution (in ns) of input sampler
+ * @tx_resolution: resolution (in ns) of output sampler
  * @priv: driver-specific data, to be used on the callbacks
  * @change_protocol: allow changing the protocol used on hardware decoders
  * @open: callback to allow drivers to enable polling/irq when IR input device
@@ -52,9 +54,16 @@ enum rc_driver_type {
  *	is opened.
  * @s_tx_mask: set transmitter mask (for devices with multiple tx outputs)
  * @s_tx_carrier: set transmit carrier frequency
+ * @s_tx_duty_cycle: set transmit duty cycle (0% - 100%)
+ * @s_rx_carrier: inform driver about carrier it is expected to handle
  * @tx_ir: transmit IR
  * @s_idle: optional: enable/disable hardware idle mode, upon which,
+<<<<<<< current
  *	device doesn't interrupt host untill it sees IR data
+=======
+	device doesn't interrupt host untill it sees IR data
+ * @s_learning_mode: enable wide band receiver used for learning
+>>>>>>> patched
  */
 struct ir_dev_props {
 	enum rc_driver_type	driver_type;
@@ -65,6 +74,8 @@ struct ir_dev_props {
 	u64			min_timeout;
 	u64			max_timeout;
 
+	u32			rx_resolution;
+	u32			tx_resolution;
 
 	void			*priv;
 	int			(*change_protocol)(void *priv, u64 ir_type);
@@ -72,8 +83,11 @@ struct ir_dev_props {
 	void			(*close)(void *priv);
 	int			(*s_tx_mask)(void *priv, u32 mask);
 	int			(*s_tx_carrier)(void *priv, u32 carrier);
+	int			(*s_tx_duty_cycle)(void *priv, u32 duty_cycle);
+	int			(*s_rx_carrier_range)(void *priv, u32 min, u32 max);
 	int			(*tx_ir)(void *priv, int *txbuf, u32 n);
 	void			(*s_idle)(void *priv, int enable);
+	int			(*s_learning_mode)(void *priv, int enable);
 };
 
 struct ir_input_dev {
diff --git a/include/media/lirc.h b/include/media/lirc.h
index 42c467c..bda3d03 100644
--- a/include/media/lirc.h
+++ b/include/media/lirc.h
@@ -77,6 +77,7 @@
 #define LIRC_CAN_SET_REC_FILTER           0x08000000
 
 #define LIRC_CAN_MEASURE_CARRIER          0x02000000
+#define LIRC_CAN_HAVE_WIDEBAND_RECEIVER   0x04000000
 
 #define LIRC_CAN_SEND(x) ((x)&LIRC_CAN_SEND_MASK)
 #define LIRC_CAN_REC(x) ((x)&LIRC_CAN_REC_MASK)
@@ -145,7 +146,7 @@
  * if enabled from the next key press on the driver will send
  * LIRC_MODE2_FREQUENCY packets
  */
-#define LIRC_SET_MEASURE_CARRIER_MODE  _IOW('i', 0x0000001d, __u32)
+#define LIRC_SET_MEASURE_CARRIER_MODE	_IOW('i', 0x0000001d, __u32)
 
 /*
  * to set a range use
@@ -162,4 +163,6 @@
 #define LIRC_SETUP_START               _IO('i', 0x00000021)
 #define LIRC_SETUP_END                 _IO('i', 0x00000022)
 
+#define LIRC_SET_WIDEBAND_RECEIVER     _IOW('i', 0x00000023, __u32)
+
 #endif
-- 
1.7.0.4

[PATCH 11/13] IR: report unknown scancodes the in-kernel decoders found.

[Maxim Levitsky]

This way it is possible to use evtest to create keymap for unknown remote.

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 drivers/media/IR/ir-keytable.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 34b9c07..ba7678a 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -339,6 +339,8 @@ void ir_repeat(struct input_dev *dev)
 
 	spin_lock_irqsave(&ir->keylock, flags);
 
+	input_event(dev, EV_MSC, MSC_SCAN, ir->last_scancode);
+
 	if (!ir->keypressed)
 		goto out;
 
@@ -370,6 +372,8 @@ void ir_keydown(struct input_dev *dev, int scancode, u8 toggle)
 
 	spin_lock_irqsave(&ir->keylock, flags);
 
+	input_event(dev, EV_MSC, MSC_SCAN, scancode);
+
 	/* Repeat event? */
 	if (ir->keypressed &&
 	    ir->last_scancode == scancode &&
@@ -383,9 +387,11 @@ void ir_keydown(struct input_dev *dev, int scancode, u8 toggle)
 	ir->last_toggle = toggle;
 	ir->last_keycode = keycode;
 
+
 	if (keycode == KEY_RESERVED)
 		goto out;
 
+
 	/* Register a keypress */
 	ir->keypressed = true;
 	IR_dprintk(1, "%s: key down event, key 0x%04x, scancode 0x%04x\n",
@@ -480,6 +486,8 @@ int __ir_input_register(struct input_dev *input_dev,
 
 	set_bit(EV_KEY, input_dev->evbit);
 	set_bit(EV_REP, input_dev->evbit);
+	set_bit(EV_MSC, input_dev->evbit);
+	set_bit(MSC_SCAN, input_dev->mscbit);
 
 	if (ir_setkeytable(input_dev, &ir_dev->rc_tab, rc_tab)) {
 		rc = -ENOMEM;
-- 
1.7.0.4

[PATCH 12/13] STAGING: remove lirc_ene0100 driver.

[Maxim Levitsky]

Add latest unported version of this driver to media/IR.
Next patch will port it to ir core.

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 drivers/media/IR/ene_ir.c           | 1176 +++++++++++++++++++++++++++++++++++
 drivers/media/IR/ene_ir.h           |  240 +++++++
 drivers/staging/lirc/Kconfig        |    8 -
 drivers/staging/lirc/Makefile       |    1 -
 drivers/staging/lirc/lirc_ene0100.c |  646 -------------------
 drivers/staging/lirc/lirc_ene0100.h |  169 -----
 6 files changed, 1416 insertions(+), 824 deletions(-)
 create mode 100644 drivers/media/IR/ene_ir.c
 create mode 100644 drivers/media/IR/ene_ir.h
 delete mode 100644 drivers/staging/lirc/lirc_ene0100.c
 delete mode 100644 drivers/staging/lirc/lirc_ene0100.h

diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c
new file mode 100644
index 0000000..9d11caf
--- /dev/null
+++ b/drivers/media/IR/ene_ir.c
@@ -0,0 +1,1176 @@
+/*
+ * driver for ENE KB3926 B/C/D CIR (also known as ENE0100/ENE0200/ENE0201)
+ *
+ * Copyright (C) 2010 Maxim Levitsky <maximlevitsky@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/pnp.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/sched.h>
+#include <linux/uaccess.h>
+#include "lirc_ene0100.h"
+
+
+static int sample_period = -1;
+static int enable_idle = 1;
+static int enable_duty_carrier;
+static int input = 1;
+static int debug;
+static int txsim;
+
+static void ene_rx_set_idle(struct ene_device *dev, int idle);
+static int ene_irq_status(struct ene_device *dev);
+static void ene_send_sample(struct ene_device *dev, unsigned long sample);
+
+/* read a hardware register */
+static u8 ene_hw_read_reg(struct ene_device *dev, u16 reg)
+{
+	u8 retval;
+	outb(reg >> 8, dev->hw_io + ENE_ADDR_HI);
+	outb(reg & 0xFF, dev->hw_io + ENE_ADDR_LO);
+	retval = inb(dev->hw_io + ENE_IO);
+
+	ene_dbg_verbose("reg %04x == %02x", reg, retval);
+	return retval;
+}
+
+/* write a hardware register */
+static void ene_hw_write_reg(struct ene_device *dev, u16 reg, u8 value)
+{
+	outb(reg >> 8, dev->hw_io + ENE_ADDR_HI);
+	outb(reg & 0xFF, dev->hw_io + ENE_ADDR_LO);
+	outb(value, dev->hw_io + ENE_IO);
+
+	ene_dbg_verbose("reg %04x <- %02x", reg, value);
+}
+
+/* change specific bits in hardware register */
+static void ene_hw_write_reg_mask(struct ene_device *dev,
+				  u16 reg, u8 value, u8 mask)
+{
+	u8 regvalue;
+
+	outb(reg >> 8, dev->hw_io + ENE_ADDR_HI);
+	outb(reg & 0xFF, dev->hw_io + ENE_ADDR_LO);
+
+	regvalue = inb(dev->hw_io + ENE_IO) & ~mask;
+	regvalue |= (value & mask);
+	outb(regvalue, dev->hw_io + ENE_IO);
+
+	ene_dbg_verbose("reg %04x <- %02x (mask=%02x)", reg, value, mask);
+}
+
+/* detect hardware features */
+static int ene_hw_detect(struct ene_device *dev)
+{
+	u8 chip_major, chip_minor;
+	u8 hw_revision, old_ver;
+	u8 tmp;
+	u8 fw_capabilities;
+
+	tmp = ene_hw_read_reg(dev, ENE_HW_UNK);
+	ene_hw_write_reg(dev, ENE_HW_UNK, tmp & ~ENE_HW_UNK_CLR);
+
+	chip_major = ene_hw_read_reg(dev, ENE_HW_VER_MAJOR);
+	chip_minor = ene_hw_read_reg(dev, ENE_HW_VER_MINOR);
+
+	ene_hw_write_reg(dev, ENE_HW_UNK, tmp);
+	hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
+	old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
+
+	if (hw_revision == 0xFF) {
+
+		ene_printk(KERN_WARNING, "device seems to be disabled\n");
+		ene_printk(KERN_WARNING,
+			"send a mail to lirc-list@lists.sourceforge.net\n");
+		ene_printk(KERN_WARNING, "please attach output of acpidump\n");
+		return -ENODEV;
+	}
+
+	if (chip_major == 0x33) {
+		ene_printk(KERN_WARNING, "chips 0x33xx aren't supported\n");
+		return -ENODEV;
+	}
+
+	if (chip_major == 0x39 && chip_minor == 0x26 && hw_revision == 0xC0) {
+		dev->hw_revision = ENE_HW_C;
+	} else if (old_ver == 0x24 && hw_revision == 0xC0) {
+		dev->hw_revision = ENE_HW_B;
+		ene_printk(KERN_NOTICE, "KB3926B detected\n");
+	} else {
+		dev->hw_revision = ENE_HW_D;
+		ene_printk(KERN_WARNING,
+			"unknown ENE chip detected, assuming KB3926D\n");
+		ene_printk(KERN_WARNING,
+			"driver support might be not complete");
+
+	}
+
+	ene_printk(KERN_DEBUG,
+		"chip is 0x%02x%02x - kbver = 0x%02x, rev = 0x%02x\n",
+			chip_major, chip_minor, old_ver, hw_revision);
+
+	/* detect features hardware supports */
+	if (dev->hw_revision < ENE_HW_C)
+		return 0;
+
+	fw_capabilities = ene_hw_read_reg(dev, ENE_FW2);
+	ene_dbg("Firmware capabilities: %02x", fw_capabilities);
+
+	dev->hw_gpio40_learning = fw_capabilities & ENE_FW2_GP40_AS_LEARN;
+	dev->hw_learning_and_tx_capable = fw_capabilities & ENE_FW2_LEARNING;
+
+	dev->hw_fan_as_normal_input = dev->hw_learning_and_tx_capable &&
+	    (fw_capabilities & ENE_FW2_FAN_AS_NRML_IN);
+
+	ene_printk(KERN_NOTICE, "hardware features:\n");
+	ene_printk(KERN_NOTICE,
+		"learning and transmit %s, gpio40_learn %s, fan_in %s\n",
+	       dev->hw_learning_and_tx_capable ? "on" : "off",
+	       dev->hw_gpio40_learning ? "on" : "off",
+	       dev->hw_fan_as_normal_input ? "on" : "off");
+
+	if (dev->hw_learning_and_tx_capable) {
+		ene_printk(KERN_WARNING,
+		"Device supports transmitting, but that support is\n");
+		ene_printk(KERN_WARNING,
+		"lightly tested. Please test it and mail\n");
+		ene_printk(KERN_WARNING,
+		"lirc-list@lists.sourceforge.net\n");
+	}
+	return 0;
+}
+
+/* this enables/disables IR input via gpio40*/
+static void ene_enable_gpio40_recieve(struct ene_device *dev, int enable)
+{
+	ene_hw_write_reg_mask(dev, ENE_CIR_CONF2, enable ?
+			      0 : ENE_CIR_CONF2_GPIO40DIS,
+			      ENE_CIR_CONF2_GPIO40DIS);
+}
+
+/* this enables/disables IR via standard input */
+static void ene_enable_normal_recieve(struct ene_device *dev, int enable)
+{
+	ene_hw_write_reg(dev, ENE_CIR_CONF1, enable ? ENE_CIR_CONF1_RX_ON : 0);
+}
+
+/* this enables/disables IR input via unused fan tachtometer input */
+static void ene_enable_fan_recieve(struct ene_device *dev, int enable)
+{
+	if (!enable)
+		ene_hw_write_reg(dev, ENE_FAN_AS_IN1, 0);
+	else {
+		ene_hw_write_reg(dev, ENE_FAN_AS_IN1, ENE_FAN_AS_IN1_EN);
+		ene_hw_write_reg(dev, ENE_FAN_AS_IN2, ENE_FAN_AS_IN2_EN);
+	}
+	dev->rx_fan_input_inuse = enable;
+}
+
+
+/* Sense current recieved carrier */
+static int ene_rx_sense_carrier(struct ene_device *dev)
+{
+	int period = ene_hw_read_reg(dev, ENE_RX_CARRIER);
+	int carrier;
+	ene_dbg("RX: hardware carrier period = %02x", period);
+
+	if (!(period & ENE_RX_CARRIER_VALID))
+		return 0;
+
+	period &= ~ENE_RX_CARRIER_VALID;
+
+	if (!period)
+		return 0;
+
+	carrier = 2000000 / period;
+	ene_dbg("RX: sensed carrier = %d Hz", carrier);
+	return carrier;
+}
+
+/* determine which input to use*/
+static void ene_rx_set_inputs(struct ene_device *dev)
+{
+	int learning_mode = dev->learning_enabled || dev->rx_carrier_sense;
+
+	ene_dbg("RX: setup reciever, learning mode = %d", learning_mode);
+
+	ene_enable_normal_recieve(dev, 1);
+
+	/* old hardware doesn't support learning mode for sure */
+	if (dev->hw_revision <= ENE_HW_B)
+		return;
+
+	/* reciever not learning capable, still set gpio40 correctly */
+	if (!dev->hw_learning_and_tx_capable) {
+		ene_enable_gpio40_recieve(dev, !dev->hw_gpio40_learning);
+		return;
+	}
+
+	/* enable learning mode */
+	if (learning_mode) {
+		ene_enable_gpio40_recieve(dev, dev->hw_gpio40_learning);
+
+		/* fan input is not used for learning */
+		if (dev->hw_fan_as_normal_input)
+			ene_enable_fan_recieve(dev, 0);
+
+	/* disable learning mode */
+	} else {
+		if (dev->hw_fan_as_normal_input) {
+			ene_enable_fan_recieve(dev, 1);
+			ene_enable_normal_recieve(dev, 0);
+		} else
+			ene_enable_gpio40_recieve(dev,
+					!dev->hw_gpio40_learning);
+	}
+
+	/* set few additional settings for this mode */
+	ene_hw_write_reg_mask(dev, ENE_CIR_CONF1, learning_mode ?
+			      ENE_CIR_CONF1_LEARN1 : 0, ENE_CIR_CONF1_LEARN1);
+
+	ene_hw_write_reg_mask(dev, ENE_CIR_CONF2, learning_mode ?
+			      ENE_CIR_CONF2_LEARN2 : 0, ENE_CIR_CONF2_LEARN2);
+}
+
+/* Enable the device for receive */
+static void ene_rx_enable(struct ene_device *dev)
+{
+	u8 reg_value;
+
+	if (dev->hw_revision < ENE_HW_C) {
+		ene_hw_write_reg(dev, ENEB_IRQ, dev->irq << 1);
+		ene_hw_write_reg(dev, ENEB_IRQ_UNK1, 0x01);
+	} else {
+		reg_value = ene_hw_read_reg(dev, ENEC_IRQ) & 0xF0;
+		reg_value |= ENEC_IRQ_UNK_EN;
+		reg_value &= ~ENEC_IRQ_STATUS;
+		reg_value |= (dev->irq & ENEC_IRQ_MASK);
+		ene_hw_write_reg(dev, ENEC_IRQ, reg_value);
+		ene_hw_write_reg(dev, ENE_TX_UNK1, 0x63);
+	}
+
+	ene_hw_write_reg(dev, ENE_CIR_CONF2, 0x00);
+	ene_rx_set_inputs(dev);
+
+	/* set sampling period */
+	ene_hw_write_reg(dev, ENE_CIR_SAMPLE_PERIOD, sample_period);
+
+	/* ack any pending irqs - just in case */
+	ene_irq_status(dev);
+
+	/* enter idle mode */
+	ene_rx_set_idle(dev, 1);
+
+	/* enable firmware bits */
+	ene_hw_write_reg_mask(dev, ENE_FW1,
+			      ENE_FW1_ENABLE | ENE_FW1_IRQ,
+			      ENE_FW1_ENABLE | ENE_FW1_IRQ);
+}
+
+/* Disable the device reciever */
+static void ene_rx_disable(struct ene_device *dev)
+{
+	/* disable inputs */
+	ene_enable_normal_recieve(dev, 0);
+
+	if (dev->hw_fan_as_normal_input)
+		ene_enable_fan_recieve(dev, 0);
+
+	/* disable hardware IRQ and firmware flag */
+	ene_hw_write_reg_mask(dev, ENE_FW1, 0, ENE_FW1_ENABLE | ENE_FW1_IRQ);
+
+	ene_rx_set_idle(dev, 1);
+}
+
+/*  send current sample to the user */
+static void ene_rx_flush(struct ene_device *dev, int timeout)
+{
+	unsigned long value;
+
+	value =	dev->rx_sample_pulse ? LIRC_PULSE(dev->rx_sample) :
+					LIRC_SPACE(dev->rx_sample);
+	ene_send_sample(dev, value);
+	dev->rx_sample = 0;
+	dev->rx_sample_pulse = 0;
+}
+
+/* recieve new sample and process it */
+static void ene_rx_sample(struct ene_device *dev, int sample, int is_pulse)
+{
+	ene_dbg("RX: sample %8d (%s)", sample, is_pulse ? "pulse" : "space");
+
+	/* ignore spaces in idle mode, can get them on revC */
+	/* also ignore a space in front of first pulse */
+	if (dev->rx_idle && !is_pulse)
+		return;
+
+	/* get out of idle mode now */
+	if (dev->rx_idle)
+		ene_rx_set_idle(dev, 0);
+
+	if (!dev->rx_sample) {
+		dev->rx_sample = sample;
+		dev->rx_sample_pulse = is_pulse;
+	} else if (is_pulse == dev->rx_sample_pulse)
+		dev->rx_sample += sample;
+	else {
+		ene_rx_flush(dev, 0);
+		dev->rx_sample = sample;
+		dev->rx_sample_pulse = is_pulse;
+	}
+
+	if (is_pulse)
+		return;
+
+	/* overflow sample from fan input recieved, enable idle mode */
+	if (dev->rx_fan_input_inuse &&
+		sample == ENE_FAN_VALUE_MASK * ENE_SAMPLE_PERIOD_FAN) {
+		ene_rx_set_idle(dev, 1);
+		return;
+	}
+
+	if (!dev->rx_fan_input_inuse) {
+		/* Report timeout if enabled */
+		if (dev->rx_timeout && dev->rx_send_timeout_packet &&
+			!dev->rx_timeout_sent &&
+				dev->rx_sample > dev->rx_timeout) {
+			ene_dbg("RX: sending timeout sample");
+			ene_send_sample(dev, LIRC_TIMEOUT(dev->rx_sample));
+			dev->rx_timeout_sent = 1;
+		}
+
+		/* too large sample accumulated via normal input.
+		note that on revC, hardware idle mode turns on automaticly,
+			so max gap should be less that the gap after which
+			hw stops sending samples */
+		if (dev->rx_sample > ENE_MAXGAP) {
+			ene_rx_set_idle(dev, 1);
+			return;
+		}
+	}
+}
+
+/* enable or disable idle mode */
+static void ene_rx_set_idle(struct ene_device *dev, int idle)
+{
+	struct timeval now;
+	int disable_sampler = 0;
+
+
+	/* Also put hardware sampler in 'idle' mode on revB*/
+	/* revC and higher do that automaticly (firmware does?) */
+	if ((dev->hw_revision < ENE_HW_C) && enable_idle)
+		if (idle)
+			disable_sampler = 1;
+
+	ene_hw_write_reg_mask(dev, ENE_CIR_SAMPLE_PERIOD,
+			      disable_sampler ? 0 : ENE_CIR_SAMPLE_OVERFLOW,
+			      ENE_CIR_SAMPLE_OVERFLOW);
+	dev->rx_idle = idle;
+
+	/* remember when we have entered the idle mode */
+	if (idle) {
+		ene_dbg("RX: going into idle mode");
+		do_gettimeofday(&dev->rx_gap_start);
+		return;
+	}
+
+	ene_dbg("RX: back from idle mode");
+
+	/* send the gap between keypresses now */
+	do_gettimeofday(&now);
+
+	if (dev->rx_sample_pulse) {
+		ene_dbg("RX: somehow we recieved a pulse before idle mode???");
+		return;
+	}
+
+	/* manually calculate and recieve the gap between keypresses */
+	if (now.tv_sec - dev->rx_gap_start.tv_sec > 16)
+		dev->rx_sample = LIRC_SPACE(LIRC_VALUE_MASK);
+	else
+		dev->rx_sample +=
+		    1000000ull * (now.tv_sec - dev->rx_gap_start.tv_sec)
+		    + now.tv_usec - dev->rx_gap_start.tv_usec;
+
+	if (dev->rx_sample > LIRC_SPACE(LIRC_VALUE_MASK))
+		dev->rx_sample = LIRC_SPACE(LIRC_VALUE_MASK);
+
+	ene_rx_flush(dev, 0);
+	dev->rx_timeout_sent = 0;
+}
+
+/* prepare transmission */
+static void ene_tx_prepare(struct ene_device *dev)
+{
+	u8 conf1;
+
+	conf1 = ene_hw_read_reg(dev, ENE_CIR_CONF1);
+	dev->saved_conf1 = conf1;
+
+	if (dev->hw_revision == ENE_HW_C)
+		conf1 &= ~ENE_CIR_CONF1_TX_CLEAR;
+
+	/* Enable TX engine */
+	conf1 |= ENE_CIR_CONF1_TX_ON;
+
+	/* Set carrier */
+	if (dev->tx_period) {
+
+		int tx_period_in500ns = dev->tx_period * 2;
+
+		int tx_pulse_width_in_500ns =
+			tx_period_in500ns / (100 / dev->tx_duty_cycle);
+
+		if (!tx_pulse_width_in_500ns)
+			tx_pulse_width_in_500ns = 1;
+
+		ene_dbg("TX: pulse distance = %d * 500 ns", tx_period_in500ns);
+		ene_dbg("TX: pulse width = %d * 500 ns",
+						tx_pulse_width_in_500ns);
+
+		ene_hw_write_reg(dev, ENE_TX_PERIOD, ENE_TX_PERIOD_UNKBIT |
+					tx_period_in500ns);
+
+		ene_hw_write_reg(dev, ENE_TX_PERIOD_PULSE,
+					tx_pulse_width_in_500ns);
+
+		conf1 |= ENE_CIR_CONF1_TX_CARR;
+	} else
+		conf1 &= ~ENE_CIR_CONF1_TX_CARR;
+
+	ene_hw_write_reg(dev, ENE_CIR_CONF1, conf1);
+	dev->tx_underway = 1;
+
+}
+
+/* end transmission */
+static void ene_tx_complete(struct ene_device *dev)
+{
+	ene_hw_write_reg(dev, ENE_CIR_CONF1, dev->saved_conf1);
+	dev->tx_underway = 0;
+}
+
+/* set transmit mask */
+static void ene_tx_set_transmiter_mask(struct ene_device *dev)
+{
+	u8 txport1 = ene_hw_read_reg(dev, ENE_TX_PORT1) & ~ENE_TX_PORT1_EN;
+	u8 txport2 = ene_hw_read_reg(dev, ENE_TX_PORT2) & ~ENE_TX_PORT2_EN;
+
+	if (dev->transmitter_mask & 0x01)
+		txport1 |= ENE_TX_PORT1_EN;
+
+	if (dev->transmitter_mask & 0x02)
+		txport2 |= ENE_TX_PORT2_EN;
+
+	ene_hw_write_reg(dev, ENE_TX_PORT1, txport1);
+	ene_hw_write_reg(dev, ENE_TX_PORT2, txport2);
+}
+
+/* TX one sample - must be called with dev->hw_lock*/
+static void ene_tx_sample(struct ene_device *dev)
+{
+	u8 raw_tx;
+	u32 sample;
+
+	if (!dev->tx_underway) {
+		ene_dbg("TX: attempt to transmit while hw isn't setup");
+		return;
+	}
+
+	/* Grab next TX sample */
+	if (!dev->tx_sample) {
+again:
+		if (dev->tx_pos == dev->tx_len + 1) {
+			if (!dev->tx_done) {
+				ene_dbg("TX: no more data to send");
+				dev->tx_done = 1;
+				goto exit;
+			} else {
+				ene_dbg("TX: last sample sent by hardware");
+				ene_tx_complete(dev);
+				complete(&dev->tx_complete);
+				return;
+			}
+		}
+
+		sample = dev->tx_buffer[dev->tx_pos++];
+		dev->tx_sample_pulse = !dev->tx_sample_pulse;
+
+		ene_dbg("TX: sample %8d (%s)", sample, dev->tx_sample_pulse ?
+							"pulse" : "space");
+
+		dev->tx_sample = DIV_ROUND_CLOSEST(sample, ENE_TX_SMPL_PERIOD);
+
+		/* guard against too short samples */
+		if (!dev->tx_sample)
+			goto again;
+	}
+
+	raw_tx = min(dev->tx_sample , (unsigned int)ENE_TX_SMLP_MASK);
+	dev->tx_sample -= raw_tx;
+
+	if (dev->tx_sample_pulse)
+		raw_tx |= ENE_TX_PULSE_MASK;
+
+	ene_hw_write_reg(dev, ENE_TX_INPUT1 + dev->tx_reg, raw_tx);
+	dev->tx_reg = !dev->tx_reg;
+exit:
+	/* simulate TX done interrupt */
+	if (txsim)
+		mod_timer(&dev->tx_sim_timer, jiffies + HZ / 500);
+}
+
+/* timer to simulate tx done interrupt */
+static void ene_tx_irqsim(unsigned long data)
+{
+	struct ene_device *dev = (struct ene_device *)data;
+	unsigned long flags;
+
+	spin_lock_irqsave(&dev->hw_lock, flags);
+	ene_tx_sample(dev);
+	spin_unlock_irqrestore(&dev->hw_lock, flags);
+}
+
+
+/* read irq status and ack it */
+static int ene_irq_status(struct ene_device *dev)
+{
+	u8 irq_status;
+	u8 fw_flags1, fw_flags2;
+	int cur_rx_pointer;
+	int retval = 0;
+
+	fw_flags2 = ene_hw_read_reg(dev, ENE_FW2);
+	cur_rx_pointer = !!(fw_flags2 & ENE_FW2_BUF_HIGH);
+
+	if (dev->hw_revision < ENE_HW_C) {
+		irq_status = ene_hw_read_reg(dev, ENEB_IRQ_STATUS);
+
+		if (!(irq_status & ENEB_IRQ_STATUS_IR))
+			return 0;
+
+		ene_hw_write_reg(dev, ENEB_IRQ_STATUS,
+				 irq_status & ~ENEB_IRQ_STATUS_IR);
+		dev->rx_pointer = cur_rx_pointer;
+		return ENE_IRQ_RX;
+	}
+
+	irq_status = ene_hw_read_reg(dev, ENEC_IRQ);
+
+	if (!(irq_status & ENEC_IRQ_STATUS))
+		return 0;
+
+	/* original driver does that twice - a workaround ? */
+	ene_hw_write_reg(dev, ENEC_IRQ, irq_status & ~ENEC_IRQ_STATUS);
+	ene_hw_write_reg(dev, ENEC_IRQ, irq_status & ~ENEC_IRQ_STATUS);
+
+	/* clear unknown flag in F8F9 */
+	if (fw_flags2 & ENE_FW2_IRQ_CLR)
+		ene_hw_write_reg(dev, ENE_FW2, fw_flags2 & ~ENE_FW2_IRQ_CLR);
+
+	/* check if this is a TX interrupt */
+	fw_flags1 = ene_hw_read_reg(dev, ENE_FW1);
+	if (fw_flags1 & ENE_FW1_TXIRQ) {
+		ene_hw_write_reg(dev, ENE_FW1, fw_flags1 & ~ENE_FW1_TXIRQ);
+		retval |= ENE_IRQ_TX;
+	}
+
+	/* Check if this is RX interrupt */
+	if (dev->rx_pointer != cur_rx_pointer) {
+		retval |= ENE_IRQ_RX;
+		dev->rx_pointer = cur_rx_pointer;
+
+	} else if (!(retval & ENE_IRQ_TX)) {
+		ene_dbg("RX: interrupt without change in RX pointer(%d)",
+			dev->rx_pointer);
+		retval |= ENE_IRQ_RX;
+	}
+
+	if ((retval & ENE_IRQ_RX) && (retval & ENE_IRQ_TX))
+		ene_dbg("both RX and TX interrupt at same time");
+
+	return retval;
+}
+
+/* interrupt handler */
+static irqreturn_t ene_isr(int irq, void *data)
+{
+	u16 hw_value;
+	int i, hw_sample;
+	int pulse;
+	int irq_status;
+	unsigned long flags;
+	int carrier = 0;
+	irqreturn_t retval = IRQ_NONE;
+	struct ene_device *dev = (struct ene_device *)data;
+
+
+	spin_lock_irqsave(&dev->hw_lock, flags);
+	irq_status = ene_irq_status(dev);
+
+	if (!irq_status)
+		goto unlock;
+
+	retval = IRQ_HANDLED;
+
+	if (irq_status & ENE_IRQ_TX) {
+
+		if (!dev->hw_learning_and_tx_capable) {
+			ene_dbg("TX interrupt on unsupported device!");
+			goto unlock;
+		}
+		ene_tx_sample(dev);
+	}
+
+	if (!(irq_status & ENE_IRQ_RX))
+		goto unlock;
+
+
+	if ((debug && dev->learning_enabled) || dev->rx_carrier_sense)
+		carrier = ene_rx_sense_carrier(dev);
+
+	if (dev->rx_carrier_sense && carrier)
+		ene_send_sample(dev, LIRC_FREQUENCY(carrier));
+
+
+	for (i = 0; i < ENE_SAMPLES_SIZE; i++) {
+		hw_value = ene_hw_read_reg(dev,
+				ENE_SAMPLE_BUFFER + dev->rx_pointer * 4 + i);
+
+		if (dev->rx_fan_input_inuse) {
+			/* read high part of the sample */
+			hw_value |= ene_hw_read_reg(dev,
+			    ENE_SAMPLE_BUFFER_FAN +
+					dev->rx_pointer * 4 + i) << 8;
+			pulse = hw_value & ENE_FAN_SMPL_PULS_MSK;
+
+			/* clear space bit, and other unused bits */
+			hw_value &= ENE_FAN_VALUE_MASK;
+			hw_sample = hw_value * ENE_SAMPLE_PERIOD_FAN;
+
+		} else {
+			pulse = !(hw_value & ENE_SAMPLE_SPC_MASK);
+			hw_value &= ENE_SAMPLE_VALUE_MASK;
+			hw_sample = hw_value * sample_period;
+		}
+		/* no more data */
+		if (!(hw_value))
+			break;
+
+		ene_rx_sample(dev, hw_sample, pulse);
+	}
+unlock:
+	spin_unlock_irqrestore(&dev->hw_lock, flags);
+	return retval;
+}
+
+/* Initialize default settings */
+static void ene_setup_settings(struct ene_device *dev)
+{
+	dev->rx_send_timeout_packet = 0;
+	dev->rx_timeout = ENE_MAXGAP;
+	dev->tx_period = 32;
+	dev->tx_duty_cycle = 25; /*%*/
+	dev->transmitter_mask = 3;
+
+	/* Force learning mode if (input == 2), otherwise
+		let user set it with LIRC_SET_REC_CARRIER */
+	dev->learning_enabled =
+		(input == 2 && dev->hw_learning_and_tx_capable);
+
+	/* Clear accumulated sample bufer */
+	dev->rx_sample = 0;
+	dev->rx_sample_pulse = 0;
+	dev->rx_pointer = -1;
+	dev->rx_carrier_sense = 0;
+
+}
+
+/* outside interface: called on first open*/
+static int ene_open(void *data)
+{
+	struct ene_device *dev = (struct ene_device *)data;
+	unsigned long flags;
+
+	spin_lock_irqsave(&dev->hw_lock, flags);
+	dev->in_use = 1;
+	ene_setup_settings(dev);
+	ene_rx_enable(dev);
+	spin_unlock_irqrestore(&dev->hw_lock, flags);
+	return 0;
+}
+
+/* outside interface: called on device close*/
+static void ene_close(void *data)
+{
+	struct ene_device *dev = (struct ene_device *)data;
+	unsigned long flags;
+	spin_lock_irqsave(&dev->hw_lock, flags);
+
+	ene_rx_disable(dev);
+	dev->in_use = 0;
+	spin_unlock_irqrestore(&dev->hw_lock, flags);
+}
+
+/* outside interface for settings */
+static int ene_ioctl(struct inode *node, struct file *file,
+		      unsigned int cmd, unsigned long arg)
+{
+	int lvalue = 0, retval, tmp;
+	unsigned long flags;
+	struct ene_device *dev = lirc_get_pdata(file);
+
+
+	switch (cmd) {
+	case LIRC_SET_SEND_CARRIER:
+	case LIRC_SET_SEND_DUTY_CYCLE:
+	case LIRC_SET_TRANSMITTER_MASK:
+	case LIRC_SET_MEASURE_CARRIER_MODE:
+	case LIRC_SET_REC_CARRIER:
+		/* All these aren't possible without this */
+		if (!dev->hw_learning_and_tx_capable)
+			return -ENOSYS;
+		/* Fall through */
+	case LIRC_SET_REC_TIMEOUT:
+	case LIRC_SET_REC_TIMEOUT_REPORTS:
+		retval = get_user(lvalue, (unsigned int *) arg);
+		if (retval)
+			return retval;
+	}
+
+	switch (cmd) {
+	case LIRC_SET_SEND_CARRIER:
+		ene_dbg("TX: attempt to set tx carrier to %d kHz", lvalue);
+		tmp = 1000000 / lvalue; /* (1 / freq) (* # usec in 1 sec) */
+
+		if (tmp && (tmp > ENE_TX_PERIOD_MAX ||
+				tmp < ENE_TX_PERIOD_MIN)) {
+
+			ene_dbg("TX: out of range %d-%d carrier, "
+				"falling back to 32 kHz",
+				1000 / ENE_TX_PERIOD_MIN,
+				1000 / ENE_TX_PERIOD_MAX);
+
+			tmp = 32; /* this is just a coincidence!!! */
+		}
+		ene_dbg("TX: set carrier to %d kHz", lvalue);
+
+		spin_lock_irqsave(&dev->hw_lock, flags);
+		dev->tx_period = tmp;
+		spin_unlock_irqrestore(&dev->hw_lock, flags);
+		break;
+	case LIRC_SET_SEND_DUTY_CYCLE:
+		ene_dbg("TX: attempt to set duty cycle to %d%%", lvalue);
+
+		if ((lvalue >= 100) || (lvalue <= 0)) {
+			retval = -EINVAL;
+			break;
+		}
+		spin_lock_irqsave(&dev->hw_lock, flags);
+		dev->tx_duty_cycle = lvalue;
+		spin_unlock_irqrestore(&dev->hw_lock, flags);
+		break;
+	case LIRC_SET_TRANSMITTER_MASK:
+		ene_dbg("TX: attempt to set transmitter mask %02x", lvalue);
+
+		/* invalid txmask */
+		if (!lvalue || lvalue & ~0x3) {
+			ene_dbg("TX: invalid mask");
+			/* this supposed to return num of transmitters */
+			retval =  2;
+			break;
+		}
+		spin_lock_irqsave(&dev->hw_lock, flags);
+		dev->transmitter_mask = lvalue;
+		spin_unlock_irqrestore(&dev->hw_lock, flags);
+		break;
+	case LIRC_SET_REC_CARRIER:
+		tmp = (lvalue > ENE_NORMAL_RX_HI || lvalue < ENE_NORMAL_RX_LOW);
+
+		if (tmp != dev->learning_enabled) {
+			spin_lock_irqsave(&dev->hw_lock, flags);
+			dev->learning_enabled = tmp;
+			ene_rx_set_inputs(dev);
+			spin_unlock_irqrestore(&dev->hw_lock, flags);
+		}
+		break;
+	case LIRC_SET_REC_TIMEOUT:
+		spin_lock_irqsave(&dev->hw_lock, flags);
+		dev->rx_timeout = lvalue;
+		spin_unlock_irqrestore(&dev->hw_lock, flags);
+		ene_dbg("RX: set rx report timeout to %d", dev->rx_timeout);
+		break;
+	case LIRC_SET_REC_TIMEOUT_REPORTS:
+		spin_lock_irqsave(&dev->hw_lock, flags);
+		dev->rx_send_timeout_packet = lvalue;
+		spin_unlock_irqrestore(&dev->hw_lock, flags);
+		ene_dbg("RX: %sable timeout reports",
+				dev->rx_send_timeout_packet ? "en" : "dis");
+		break;
+	case LIRC_SET_MEASURE_CARRIER_MODE:
+		if (dev->rx_carrier_sense == lvalue)
+			break;
+		spin_lock_irqsave(&dev->hw_lock, flags);
+		dev->rx_carrier_sense = lvalue;
+		ene_rx_set_inputs(dev);
+		spin_unlock_irqrestore(&dev->hw_lock, flags);
+		break;
+	case LIRC_GET_REC_RESOLUTION:
+		tmp = dev->rx_fan_input_inuse ?
+			ENE_SAMPLE_PERIOD_FAN : sample_period;
+		retval = put_user(tmp, (unsigned long *) arg);
+		break;
+	default:
+		retval = -ENOIOCTLCMD;
+		break;
+	}
+
+	return retval;
+}
+
+/* outside interface: transmit */
+static ssize_t ene_transmit(struct file *file, const char *buf,
+				  size_t n, loff_t *ppos)
+{
+	struct ene_device *dev = lirc_get_pdata(file);
+	unsigned long flags;
+
+	if (!dev)
+		return -EFAULT;
+
+	if (!dev->hw_learning_and_tx_capable)
+		return -ENODEV;
+
+	if (n % sizeof(int))
+		return -EINVAL;
+
+	if (n > ENE_TXBUF_SIZE * sizeof(int))
+		return -ENOMEM;
+
+	if (copy_from_user(dev->tx_buffer, buf, n))
+		return -EFAULT;
+
+	dev->tx_len = n / sizeof(int);
+	dev->tx_pos = 0;
+	dev->tx_reg = 0;
+	dev->tx_done = 0;
+	dev->tx_sample = 0;
+	dev->tx_sample_pulse = 0;
+
+	ene_dbg("TX: %d samples", dev->tx_len);
+
+	spin_lock_irqsave(&dev->hw_lock, flags);
+
+	ene_tx_set_transmiter_mask(dev);
+	ene_tx_prepare(dev);
+
+	/* Transmit first two samples */
+	ene_tx_sample(dev);
+	ene_tx_sample(dev);
+
+	spin_unlock_irqrestore(&dev->hw_lock, flags);
+
+	if (wait_for_completion_timeout(&dev->tx_complete, 2 * HZ) == 0) {
+		ene_dbg("TX: timeout");
+		spin_lock_irqsave(&dev->hw_lock, flags);
+		ene_tx_complete(dev);
+		spin_unlock_irqrestore(&dev->hw_lock, flags);
+	} else
+		ene_dbg("TX: done");
+
+	return n;
+}
+
+/* Sends one sample to the user */
+static void ene_send_sample(struct ene_device *dev, unsigned long sample)
+{
+	if (!lirc_buffer_full(dev->lirc_driver->rbuf)) {
+		lirc_buffer_write(dev->lirc_driver->rbuf, (void *)&sample);
+		wake_up(&dev->lirc_driver->rbuf->wait_poll);
+	}
+}
+
+
+static const struct file_operations ene_fops = {
+	.owner		= THIS_MODULE,
+	.write		= ene_transmit,
+	.ioctl		= ene_ioctl,
+};
+
+/* main load function */
+static int ene_probe(struct pnp_dev *pnp_dev,
+		     const struct pnp_device_id *dev_id)
+{
+	struct ene_device *dev;
+	struct lirc_driver *lirc_driver;
+	int error = -ENOMEM;
+
+	dev = kzalloc(sizeof(struct ene_device), GFP_KERNEL);
+
+	if (!dev)
+		goto err1;
+
+	dev->pnp_dev = pnp_dev;
+	pnp_set_drvdata(pnp_dev, dev);
+
+	/* prepare lirc interface */
+	error = -ENOMEM;
+	lirc_driver = kzalloc(sizeof(struct lirc_driver), GFP_KERNEL);
+
+	if (!lirc_driver)
+		goto err2;
+
+	dev->lirc_driver = lirc_driver;
+
+	strcpy(lirc_driver->name, ENE_DRIVER_NAME);
+	lirc_driver->minor = -1;
+	lirc_driver->code_length = sizeof(int) * 8;
+	lirc_driver->features = LIRC_CAN_REC_MODE2 |
+				LIRC_CAN_GET_REC_RESOLUTION |
+				LIRC_CAN_SET_REC_TIMEOUT;
+	lirc_driver->data = dev;
+	lirc_driver->set_use_inc = ene_open;
+	lirc_driver->set_use_dec = ene_close;
+	lirc_driver->dev = &pnp_dev->dev;
+	lirc_driver->owner = THIS_MODULE;
+	lirc_driver->fops = &ene_fops;
+	lirc_driver->min_timeout = ENE_MINGAP;
+	lirc_driver->max_timeout = ENE_MAXGAP;
+	lirc_driver->rbuf = kzalloc(sizeof(struct lirc_buffer), GFP_KERNEL);
+
+	if (!lirc_driver->rbuf)
+		goto err3;
+
+	if (lirc_buffer_init(lirc_driver->rbuf, sizeof(int), sizeof(int) * 512))
+		goto err4;
+
+	/* validate resources */
+	if (!pnp_port_valid(pnp_dev, 0) ||
+	    pnp_port_len(pnp_dev, 0) < ENE_MAX_IO)
+		goto err5;
+
+	if (!pnp_irq_valid(pnp_dev, 0))
+		goto err5;
+
+	dev->hw_io = pnp_port_start(pnp_dev, 0);
+	dev->irq = pnp_irq(pnp_dev, 0);
+	spin_lock_init(&dev->hw_lock);
+
+	/* claim the resources */
+	error = -EBUSY;
+	if (!request_region(dev->hw_io, ENE_MAX_IO, ENE_DRIVER_NAME))
+		goto err5;
+
+	if (request_irq(dev->irq, ene_isr,
+			IRQF_SHARED, ENE_DRIVER_NAME, (void *)dev))
+		goto err6;
+
+	/* detect hardware version and features */
+	error = ene_hw_detect(dev);
+	if (error)
+		goto err7;
+
+	ene_setup_settings(dev);
+
+	if (!dev->hw_learning_and_tx_capable && txsim) {
+		dev->hw_learning_and_tx_capable = 1;
+		setup_timer(&dev->tx_sim_timer, ene_tx_irqsim,
+						(long unsigned int)dev);
+		ene_printk(KERN_WARNING,
+			"Simulation of TX activated\n");
+	}
+
+	if (dev->hw_learning_and_tx_capable) {
+		lirc_driver->features |= LIRC_CAN_SEND_PULSE |
+					 LIRC_CAN_SET_SEND_CARRIER |
+					 LIRC_CAN_SET_TRANSMITTER_MASK;
+
+		if (enable_duty_carrier)
+			lirc_driver->features |= LIRC_CAN_SET_SEND_DUTY_CYCLE;
+
+		if (input == 0)
+			lirc_driver->features |= LIRC_CAN_SET_REC_CARRIER;
+
+		init_completion(&dev->tx_complete);
+	}
+
+	/* don't allow too short/long sample periods */
+	if (sample_period < 5 || sample_period > 0x7F)
+		sample_period = -1;
+
+	/* choose default sample period */
+	if (sample_period == -1) {
+
+		sample_period = 50;
+
+		/* on revB, hardware idle mode eats first sample
+		  if we set too low sample period */
+		if (dev->hw_revision == ENE_HW_B && enable_idle)
+			sample_period = 75;
+	}
+
+	device_set_wakeup_capable(&pnp_dev->dev, 1);
+	device_set_wakeup_enable(&pnp_dev->dev, 1);
+
+	error = -ENODEV;
+	if (lirc_register_driver(lirc_driver))
+		goto err7;
+
+	ene_printk(KERN_NOTICE, "driver has been succesfully loaded\n");
+	return 0;
+
+err7:
+	free_irq(dev->irq, dev);
+err6:
+	release_region(dev->hw_io, ENE_MAX_IO);
+err5:
+	lirc_buffer_free(lirc_driver->rbuf);
+err4:
+	kfree(lirc_driver->rbuf);
+err3:
+	kfree(lirc_driver);
+err2:
+	kfree(dev);
+err1:
+	return error;
+}
+
+/* main unload function */
+static void ene_remove(struct pnp_dev *pnp_dev)
+{
+	struct ene_device *dev = pnp_get_drvdata(pnp_dev);
+	unsigned long flags;
+
+	spin_lock_irqsave(&dev->hw_lock, flags);
+	ene_rx_disable(dev);
+	spin_unlock_irqrestore(&dev->hw_lock, flags);
+
+	free_irq(dev->irq, dev);
+	release_region(dev->hw_io, ENE_MAX_IO);
+	lirc_unregister_driver(dev->lirc_driver->minor);
+	lirc_buffer_free(dev->lirc_driver->rbuf);
+	kfree(dev->lirc_driver);
+	kfree(dev);
+}
+
+/* enable wake on IR (wakes on specific button on original remote) */
+static void ene_enable_wake(struct ene_device *dev, int enable)
+{
+	enable = enable && device_may_wakeup(&dev->pnp_dev->dev);
+
+	ene_dbg("wake on IR %s", enable ? "enabled" : "disabled");
+
+	ene_hw_write_reg_mask(dev, ENE_FW1, enable ?
+		ENE_FW1_WAKE : 0, ENE_FW1_WAKE);
+}
+
+#ifdef CONFIG_PM
+static int ene_suspend(struct pnp_dev *pnp_dev, pm_message_t state)
+{
+	struct ene_device *dev = pnp_get_drvdata(pnp_dev);
+	ene_enable_wake(dev, 1);
+	return 0;
+}
+
+static int ene_resume(struct pnp_dev *pnp_dev)
+{
+	struct ene_device *dev = pnp_get_drvdata(pnp_dev);
+	if (dev->in_use)
+		ene_rx_enable(dev);
+
+	ene_enable_wake(dev, 0);
+	return 0;
+}
+#endif
+
+static void ene_shutdown(struct pnp_dev *pnp_dev)
+{
+	struct ene_device *dev = pnp_get_drvdata(pnp_dev);
+	ene_enable_wake(dev, 1);
+}
+
+static const struct pnp_device_id ene_ids[] = {
+	{.id = "ENE0100",},
+	{.id = "ENE0200",},
+	{.id = "ENE0201",},
+	{},
+};
+
+static struct pnp_driver ene_driver = {
+	.name = ENE_DRIVER_NAME,
+	.id_table = ene_ids,
+	.flags = PNP_DRIVER_RES_DO_NOT_CHANGE,
+
+	.probe = ene_probe,
+	.remove = __devexit_p(ene_remove),
+#ifdef CONFIG_PM
+	.suspend = ene_suspend,
+	.resume = ene_resume,
+#endif
+	.shutdown = ene_shutdown,
+};
+
+static int __init ene_init(void)
+{
+	return pnp_register_driver(&ene_driver);
+}
+
+static void ene_exit(void)
+{
+	pnp_unregister_driver(&ene_driver);
+}
+
+module_param(sample_period, int, S_IRUGO);
+MODULE_PARM_DESC(sample_period, "Hardware sample period (50 us default)");
+
+module_param(enable_idle, bool, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(enable_idle,
+	"Enables turning off signal sampling after long inactivity time; "
+	"if disabled might help detecting input signal (default: enabled)"
+	" (KB3926B only)");
+
+module_param(input, bool, S_IRUGO);
+MODULE_PARM_DESC(input, "select which input to use "
+	"0 - auto, 1 - standard, 2 - wideband(KB3926C+)");
+
+module_param(debug, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(debug, "Enable debug (debug=2 verbose debug output)");
+
+module_param(txsim, bool, S_IRUGO);
+MODULE_PARM_DESC(txsim,
+	"Simulate TX features on unsupported hardware (dangerous)");
+
+module_param(enable_duty_carrier, bool, S_IRUGO);
+MODULE_PARM_DESC(enable_duty_carrier,
+	"Enable a code that might allow to to set TX carrier duty cycle");
+
+MODULE_DEVICE_TABLE(pnp, ene_ids);
+MODULE_DESCRIPTION
+	("LIRC driver for KB3926B/KB3926C/KB3926D "
+	"(aka ENE0100/ENE0200/ENE0201) CIR port");
+
+MODULE_AUTHOR("Maxim Levitsky");
+MODULE_LICENSE("GPL");
+
+module_init(ene_init);
+module_exit(ene_exit);
diff --git a/drivers/media/IR/ene_ir.h b/drivers/media/IR/ene_ir.h
new file mode 100644
index 0000000..06453a8
--- /dev/null
+++ b/drivers/media/IR/ene_ir.h
@@ -0,0 +1,240 @@
+/*
+ * driver for ENE KB3926 B/C/D CIR (also known as ENE0100/ENE0200/ENE0201)
+ *
+ * Copyright (C) 2010 Maxim Levitsky <maximlevitsky@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ */
+#include <linux/spinlock.h>
+#include <media/lirc.h>
+#include <media/lirc_dev.h>
+
+/* hardware address */
+#define ENE_STATUS		0	/* hardware status - unused */
+#define ENE_ADDR_HI		1	/* hi byte of register address */
+#define ENE_ADDR_LO		2	/* low byte of register address */
+#define ENE_IO			3	/* read/write window */
+#define ENE_MAX_IO		4
+
+/* 8 bytes of samples, divided in 2 halfs*/
+#define ENE_SAMPLE_BUFFER	0xF8F0	/* regular sample buffer */
+#define ENE_SAMPLE_SPC_MASK	0x80	/* sample is space */
+#define ENE_SAMPLE_VALUE_MASK	0x7F
+#define ENE_SAMPLE_OVERFLOW	0x7F
+#define ENE_SAMPLES_SIZE	4
+
+/* fan input sample buffer */
+#define ENE_SAMPLE_BUFFER_FAN	0xF8FB	/* this buffer holds high byte of */
+					/* each sample of normal buffer */
+#define ENE_FAN_SMPL_PULS_MSK	0x8000	/* this bit of combined sample */
+					/* if set, says that sample is pulse */
+#define ENE_FAN_VALUE_MASK	0x0FFF  /* mask for valid bits of the value */
+
+/* first firmware register */
+#define ENE_FW1			0xF8F8
+#define	ENE_FW1_ENABLE		0x01	/* enable fw processing */
+#define ENE_FW1_TXIRQ		0x02	/* TX interrupt pending */
+#define ENE_FW1_WAKE		0x40	/* enable wake from S3 */
+#define ENE_FW1_IRQ		0x80	/* enable interrupt */
+
+/* second firmware register */
+#define ENE_FW2			0xF8F9
+#define ENE_FW2_BUF_HIGH	0x01	/* which half of the buffer to read */
+#define ENE_FW2_IRQ_CLR		0x04	/* clear this on IRQ */
+#define ENE_FW2_GP40_AS_LEARN	0x08	/* normal input is used as */
+					/* learning input */
+#define ENE_FW2_FAN_AS_NRML_IN	0x40	/* fan is used as normal input */
+#define ENE_FW2_LEARNING	0x80	/* hardware supports learning and TX */
+
+/* transmitter ports */
+#define ENE_TX_PORT2		0xFC01	/* this enables one or both */
+#define ENE_TX_PORT2_EN		0x20	/* TX ports */
+#define ENE_TX_PORT1		0xFC08	
+#define ENE_TX_PORT1_EN		0x02
+
+/* IRQ registers block (for revision B) */
+#define ENEB_IRQ		0xFD09	/* IRQ number */
+#define ENEB_IRQ_UNK1		0xFD17	/* unknown setting = 1 */
+#define ENEB_IRQ_STATUS		0xFD80	/* irq status */
+#define ENEB_IRQ_STATUS_IR	0x20	/* IR irq */
+
+/* fan as input settings - only if learning capable */
+#define ENE_FAN_AS_IN1		0xFE30  /* fan init reg 1 */
+#define ENE_FAN_AS_IN1_EN	0xCD
+#define ENE_FAN_AS_IN2		0xFE31  /* fan init reg 2 */
+#define ENE_FAN_AS_IN2_EN	0x03
+#define ENE_SAMPLE_PERIOD_FAN   61	/* fan input has fixed sample period */
+
+/* IRQ registers block (for revision C,D) */
+#define ENEC_IRQ		0xFE9B	/* new irq settings register */
+#define ENEC_IRQ_MASK		0x0F	/* irq number mask */
+#define ENEC_IRQ_UNK_EN		0x10	/* always enabled */
+#define ENEC_IRQ_STATUS		0x20	/* irq status and ACK */
+
+/* CIR block settings */
+#define ENE_CIR_CONF1		0xFEC0
+#define ENE_CIR_CONF1_TX_CLEAR	0x01	/* clear that on revC */
+					/* while transmitting */
+#define ENE_CIR_CONF1_RX_ON	0x07	/* normal reciever enabled */
+#define ENE_CIR_CONF1_LEARN1	0x08	/* enabled on learning mode */
+#define ENE_CIR_CONF1_TX_ON	0x30	/* enabled on transmit */
+#define ENE_CIR_CONF1_TX_CARR	0x80	/* send TX carrier or not */
+
+#define ENE_CIR_CONF2		0xFEC1	/* unknown setting = 0 */
+#define ENE_CIR_CONF2_LEARN2	0x10	/* set on enable learning */
+#define ENE_CIR_CONF2_GPIO40DIS	0x20	/* disable input via gpio40 */
+
+#define ENE_CIR_SAMPLE_PERIOD	0xFEC8	/* sample period in us */
+#define ENE_CIR_SAMPLE_OVERFLOW	0x80	/* interrupt on overflows if set */
+
+
+/* Two byte tx buffer */
+#define ENE_TX_INPUT1		0xFEC9
+#define ENE_TX_INPUT2		0xFECA
+#define ENE_TX_PULSE_MASK	0x80	/* Transmitted sample is pulse */
+#define ENE_TX_SMLP_MASK	0x7F
+#define ENE_TX_SMPL_PERIOD	50	/* transmit sample period - fixed */
+
+
+/* Unknown TX setting - TX sample period ??? */
+#define ENE_TX_UNK1		0xFECB	/* set to 0x63 */
+
+/* Current recieved carrier period */
+#define ENE_RX_CARRIER		0xFECC	/* RX period (500 ns) */
+#define ENE_RX_CARRIER_VALID	0x80	/* Register content valid */
+
+
+/* TX period (1/carrier) */
+#define ENE_TX_PERIOD		0xFECE	/* TX period (500 ns) */
+#define ENE_TX_PERIOD_UNKBIT	0x80	/* This bit set on transmit*/
+#define ENE_TX_PERIOD_PULSE	0xFECF	/* TX pulse period (500 ns)*/
+
+/* Hardware versions */
+#define ENE_HW_VERSION		0xFF00	/* hardware revision */
+#define ENE_HW_UNK		0xFF1D
+#define ENE_HW_UNK_CLR		0x04
+#define ENE_HW_VER_MAJOR	0xFF1E	/* chip version */
+#define ENE_HW_VER_MINOR	0xFF1F
+#define ENE_HW_VER_OLD		0xFD00
+
+/* Normal/Learning carrier ranges - only valid if we have learning input*/
+/* TODO: test */
+#define ENE_NORMAL_RX_LOW	34
+#define ENE_NORMAL_RX_HI	38
+
+/* Tx carrier range */
+/* Hardware might be able to do more, but this range is enough for
+   all purposes */
+#define ENE_TX_PERIOD_MAX	32	/* corresponds to 29.4 kHz */
+#define ENE_TX_PERIOD_MIN	16	/* corrsponds to 62.5 kHz */
+
+
+
+/* Minimal and maximal gaps */
+
+/* Normal case:
+	Minimal gap is 0x7F * sample period
+	Maximum gap depends on hardware.
+	For KB3926B, it is unlimited, for newer models its around
+	250000, after which HW stops sending samples, and that is
+	not possible to change */
+
+/* Fan case:
+	Both minimal and maximal gaps are same, and equal to 0xFFF * 0x61
+	And there is nothing to change this setting
+*/
+
+#define ENE_MAXGAP		250000
+#define ENE_MINGAP		(127 * sample_period)
+
+/******************************************************************************/
+
+#define ENE_DRIVER_NAME		"enecir"
+#define ENE_TXBUF_SIZE (500 * sizeof(int))	/* 500 samples (arbitary) */
+
+#define ENE_IRQ_RX		1
+#define ENE_IRQ_TX		2
+
+#define  ENE_HW_B		1	/* 3926B */
+#define  ENE_HW_C		2	/* 3926C */
+#define  ENE_HW_D		3	/* 3926D */
+
+#define ene_printk(level, text, ...) \
+	printk(level ENE_DRIVER_NAME ": " text, ## __VA_ARGS__)
+
+#define ene_dbg(text, ...) \
+	if (debug) \
+		printk(KERN_DEBUG \
+			ENE_DRIVER_NAME ": " text "\n" , ## __VA_ARGS__)
+
+#define ene_dbg_verbose(text, ...) \
+	if (debug > 1) \
+		printk(KERN_DEBUG \
+			ENE_DRIVER_NAME ": " text "\n" , ## __VA_ARGS__)
+
+
+struct ene_device {
+	struct pnp_dev *pnp_dev;
+	struct lirc_driver *lirc_driver;
+	int in_use;
+
+	/* hw IO settings */
+	unsigned long hw_io;
+	int irq;
+	spinlock_t hw_lock;
+
+	/* HW features */
+	int hw_revision;			/* hardware revision */
+	int hw_learning_and_tx_capable;		/* learning capable */
+	int hw_gpio40_learning;			/* gpio40 is learning */
+	int hw_fan_as_normal_input;		/* fan input is used as */
+						/* regular input */
+	/* HW state*/
+	int rx_pointer;				/* hw pointer to rx buffer */
+	int rx_fan_input_inuse;			/* is fan input in use for rx*/
+	int tx_reg;				/* current reg used for TX */
+	u8  saved_conf1;			/* saved FEC0 reg */
+	int learning_enabled;			/* learning input enabled */
+
+	/* RX sample handling */
+	int rx_sample;				/* current recieved sample */
+	int rx_sample_pulse;			/* recieved sample is pulse */
+	int rx_idle;				/* idle mode for RX activated */
+	struct timeval rx_gap_start;		/* time of start of idle */
+	int rx_timeout;				/* time in ms of RX timeout */
+	int rx_send_timeout_packet;		/* do we send RX timeout */
+	int rx_timeout_sent;			/* we sent the timeout packet */
+	int rx_carrier_sense;			/* sense carrier */
+
+	/* TX sample handling */
+	unsigned int tx_sample;			/* current sample for TX */
+	int tx_sample_pulse;			/* current sample is pulse */
+
+	/* TX buffer */
+	int tx_buffer[ENE_TXBUF_SIZE];		/* input samples buffer*/
+	int tx_pos;				/* position in that bufer */
+	int tx_len;				/* current len of tx buffer */
+	int tx_underway;			/* TX is under way*/
+	int tx_done;				/* done transmitting */
+						/* one more sample pending*/
+	struct completion tx_complete;		/* TX completion */
+	struct timer_list tx_sim_timer;
+
+	/*TX settings */
+	int tx_period;
+	int tx_duty_cycle;
+	int transmitter_mask;
+};
diff --git a/drivers/staging/lirc/Kconfig b/drivers/staging/lirc/Kconfig
index 968c2ad..d199165 100644
--- a/drivers/staging/lirc/Kconfig
+++ b/drivers/staging/lirc/Kconfig
@@ -17,14 +17,6 @@ config LIRC_BT829
 	help
 	  Driver for the IR interface on BT829-based hardware
 
-config LIRC_ENE0100
-	tristate "ENE KB3924/ENE0100 CIR Port Reciever"
-	depends on LIRC_STAGING
-	help
-	  This is a driver for CIR port handled by ENE KB3924 embedded
-	  controller found on some notebooks.
-	  It appears on PNP list as ENE0100.
-
 config LIRC_I2C
 	tristate "I2C Based IR Receivers"
 	depends on LIRC_STAGING
diff --git a/drivers/staging/lirc/Makefile b/drivers/staging/lirc/Makefile
index a019182..7011d6c 100644
--- a/drivers/staging/lirc/Makefile
+++ b/drivers/staging/lirc/Makefile
@@ -4,7 +4,6 @@
 # Each configuration option enables a list of files.
 
 obj-$(CONFIG_LIRC_BT829)	+= lirc_bt829.o
-obj-$(CONFIG_LIRC_ENE0100)	+= lirc_ene0100.o
 obj-$(CONFIG_LIRC_I2C)		+= lirc_i2c.o
 obj-$(CONFIG_LIRC_IGORPLUGUSB)	+= lirc_igorplugusb.o
 obj-$(CONFIG_LIRC_IMON)		+= lirc_imon.o
diff --git a/drivers/staging/lirc/lirc_ene0100.c b/drivers/staging/lirc/lirc_ene0100.c
deleted file mode 100644
index a152c52..0000000
--- a/drivers/staging/lirc/lirc_ene0100.c
+++ /dev/null
@@ -1,646 +0,0 @@
-/*
- * driver for ENE KB3926 B/C/D CIR (also known as ENE0100)
- *
- * Copyright (C) 2009 Maxim Levitsky <maximlevitsky@gmail.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
- * USA
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/pnp.h>
-#include <linux/io.h>
-#include <linux/interrupt.h>
-#include <linux/sched.h>
-#include "lirc_ene0100.h"
-
-static int sample_period = 75;
-static int enable_idle = 1;
-static int enable_learning;
-
-static void ene_set_idle(struct ene_device *dev, int idle);
-static void ene_set_inputs(struct ene_device *dev, int enable);
-
-/* read a hardware register */
-static u8 ene_hw_read_reg(struct ene_device *dev, u16 reg)
-{
-	outb(reg >> 8, dev->hw_io + ENE_ADDR_HI);
-	outb(reg & 0xFF, dev->hw_io + ENE_ADDR_LO);
-	return inb(dev->hw_io + ENE_IO);
-}
-
-/* write a hardware register */
-static void ene_hw_write_reg(struct ene_device *dev, u16 reg, u8 value)
-{
-	outb(reg >> 8, dev->hw_io + ENE_ADDR_HI);
-	outb(reg & 0xFF, dev->hw_io + ENE_ADDR_LO);
-	outb(value, dev->hw_io + ENE_IO);
-}
-
-/* change specific bits in hardware register */
-static void ene_hw_write_reg_mask(struct ene_device *dev,
-				  u16 reg, u8 value, u8 mask)
-{
-	u8 regvalue;
-
-	outb(reg >> 8, dev->hw_io + ENE_ADDR_HI);
-	outb(reg & 0xFF, dev->hw_io + ENE_ADDR_LO);
-
-	regvalue = inb(dev->hw_io + ENE_IO) & ~mask;
-	regvalue |= (value & mask);
-	outb(regvalue, dev->hw_io + ENE_IO);
-}
-
-/* read irq status and ack it */
-static int ene_hw_irq_status(struct ene_device *dev, int *buffer_pointer)
-{
-	u8 irq_status;
-	u8 fw_flags1, fw_flags2;
-
-	fw_flags2 = ene_hw_read_reg(dev, ENE_FW2);
-
-	if (buffer_pointer)
-		*buffer_pointer = 4 * (fw_flags2 & ENE_FW2_BUF_HIGH);
-
-	if (dev->hw_revision < ENE_HW_C) {
-		irq_status = ene_hw_read_reg(dev, ENEB_IRQ_STATUS);
-
-		if (!(irq_status & ENEB_IRQ_STATUS_IR))
-			return 0;
-		ene_hw_write_reg(dev, ENEB_IRQ_STATUS,
-				 irq_status & ~ENEB_IRQ_STATUS_IR);
-
-		/* rev B support only recieving */
-		return ENE_IRQ_RX;
-	}
-
-	irq_status = ene_hw_read_reg(dev, ENEC_IRQ);
-
-	if (!(irq_status & ENEC_IRQ_STATUS))
-		return 0;
-
-	/* original driver does that twice - a workaround ? */
-	ene_hw_write_reg(dev, ENEC_IRQ, irq_status & ~ENEC_IRQ_STATUS);
-	ene_hw_write_reg(dev, ENEC_IRQ, irq_status & ~ENEC_IRQ_STATUS);
-
-	/* clear unknown flag in F8F9 */
-	if (fw_flags2 & ENE_FW2_IRQ_CLR)
-		ene_hw_write_reg(dev, ENE_FW2, fw_flags2 & ~ENE_FW2_IRQ_CLR);
-
-	/* check if this is a TX interrupt */
-	fw_flags1 = ene_hw_read_reg(dev, ENE_FW1);
-
-	if (fw_flags1 & ENE_FW1_TXIRQ) {
-		ene_hw_write_reg(dev, ENE_FW1, fw_flags1 & ~ENE_FW1_TXIRQ);
-		return ENE_IRQ_TX;
-	} else
-		return ENE_IRQ_RX;
-}
-
-static int ene_hw_detect(struct ene_device *dev)
-{
-	u8 chip_major, chip_minor;
-	u8 hw_revision, old_ver;
-	u8 tmp;
-	u8 fw_capabilities;
-
-	tmp = ene_hw_read_reg(dev, ENE_HW_UNK);
-	ene_hw_write_reg(dev, ENE_HW_UNK, tmp & ~ENE_HW_UNK_CLR);
-
-	chip_major = ene_hw_read_reg(dev, ENE_HW_VER_MAJOR);
-	chip_minor = ene_hw_read_reg(dev, ENE_HW_VER_MINOR);
-
-	ene_hw_write_reg(dev, ENE_HW_UNK, tmp);
-	hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
-	old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
-
-	if (hw_revision == 0xFF) {
-
-		ene_printk(KERN_WARNING, "device seems to be disabled\n");
-		ene_printk(KERN_WARNING,
-			"send a mail to lirc-list@lists.sourceforge.net\n");
-		ene_printk(KERN_WARNING, "please attach output of acpidump\n");
-
-		return -ENODEV;
-	}
-
-	if (chip_major == 0x33) {
-		ene_printk(KERN_WARNING, "chips 0x33xx aren't supported yet\n");
-		return -ENODEV;
-	}
-
-	if (chip_major == 0x39 && chip_minor == 0x26 && hw_revision == 0xC0) {
-		dev->hw_revision = ENE_HW_C;
-		ene_printk(KERN_WARNING,
-		       "KB3926C detected, driver support is not complete!\n");
-
-	} else if (old_ver == 0x24 && hw_revision == 0xC0) {
-		dev->hw_revision = ENE_HW_B;
-		ene_printk(KERN_NOTICE, "KB3926B detected\n");
-	} else {
-		dev->hw_revision = ENE_HW_D;
-		ene_printk(KERN_WARNING,
-			"unknown ENE chip detected, assuming KB3926D\n");
-		ene_printk(KERN_WARNING, "driver support incomplete");
-
-	}
-
-	ene_printk(KERN_DEBUG, "chip is 0x%02x%02x - 0x%02x, 0x%02x\n",
-		chip_major, chip_minor, old_ver, hw_revision);
-
-
-	/* detect features hardware supports */
-
-	if (dev->hw_revision < ENE_HW_C)
-		return 0;
-
-	fw_capabilities = ene_hw_read_reg(dev, ENE_FW2);
-
-	dev->hw_gpio40_learning = fw_capabilities & ENE_FW2_GP40_AS_LEARN;
-	dev->hw_learning_and_tx_capable = fw_capabilities & ENE_FW2_LEARNING;
-
-	dev->hw_fan_as_normal_input = dev->hw_learning_and_tx_capable &&
-	    fw_capabilities & ENE_FW2_FAN_AS_NRML_IN;
-
-	ene_printk(KERN_NOTICE, "hardware features:\n");
-	ene_printk(KERN_NOTICE,
-		"learning and tx %s, gpio40_learn %s, fan_in %s\n",
-	       dev->hw_learning_and_tx_capable ? "on" : "off",
-	       dev->hw_gpio40_learning ? "on" : "off",
-	       dev->hw_fan_as_normal_input ? "on" : "off");
-
-	if (!dev->hw_learning_and_tx_capable && enable_learning)
-		enable_learning = 0;
-
-	if (dev->hw_learning_and_tx_capable) {
-		ene_printk(KERN_WARNING,
-		"Device supports transmitting, but the driver doesn't\n");
-		ene_printk(KERN_WARNING,
-		"due to lack of hardware to test against.\n");
-		ene_printk(KERN_WARNING,
-		"Send a mail to: lirc-list@lists.sourceforge.net\n");
-	}
-	return 0;
-}
-
-/* hardware initialization */
-static int ene_hw_init(void *data)
-{
-	u8 reg_value;
-	struct ene_device *dev = (struct ene_device *)data;
-	dev->in_use = 1;
-
-	if (dev->hw_revision < ENE_HW_C) {
-		ene_hw_write_reg(dev, ENEB_IRQ, dev->irq << 1);
-		ene_hw_write_reg(dev, ENEB_IRQ_UNK1, 0x01);
-	} else {
-		reg_value = ene_hw_read_reg(dev, ENEC_IRQ) & 0xF0;
-		reg_value |= ENEC_IRQ_UNK_EN;
-		reg_value &= ~ENEC_IRQ_STATUS;
-		reg_value |= (dev->irq & ENEC_IRQ_MASK);
-		ene_hw_write_reg(dev, ENEC_IRQ, reg_value);
-		ene_hw_write_reg(dev, ENE_TX_UNK1, 0x63);
-	}
-
-	ene_hw_write_reg(dev, ENE_CIR_CONF2, 0x00);
-	ene_set_inputs(dev, enable_learning);
-
-	/* set sampling period */
-	ene_hw_write_reg(dev, ENE_CIR_SAMPLE_PERIOD, sample_period);
-
-	/* ack any pending irqs - just in case */
-	ene_hw_irq_status(dev, NULL);
-
-	/* enter idle mode */
-	ene_set_idle(dev, 1);
-
-	/* enable firmware bits */
-	ene_hw_write_reg_mask(dev, ENE_FW1,
-			      ENE_FW1_ENABLE | ENE_FW1_IRQ,
-			      ENE_FW1_ENABLE | ENE_FW1_IRQ);
-	/* clear stats */
-	dev->sample = 0;
-	return 0;
-}
-
-/* this enables gpio40 signal, used if connected to wide band input*/
-static void ene_enable_gpio40(struct ene_device *dev, int enable)
-{
-	ene_hw_write_reg_mask(dev, ENE_CIR_CONF1, enable ?
-			      0 : ENE_CIR_CONF2_GPIO40DIS,
-			      ENE_CIR_CONF2_GPIO40DIS);
-}
-
-/* this enables the classic sampler */
-static void ene_enable_normal_recieve(struct ene_device *dev, int enable)
-{
-	ene_hw_write_reg(dev, ENE_CIR_CONF1, enable ? ENE_CIR_CONF1_ADC_ON : 0);
-}
-
-/* this enables recieve via fan input */
-static void ene_enable_fan_recieve(struct ene_device *dev, int enable)
-{
-	if (!enable)
-		ene_hw_write_reg(dev, ENE_FAN_AS_IN1, 0);
-	else {
-		ene_hw_write_reg(dev, ENE_FAN_AS_IN1, ENE_FAN_AS_IN1_EN);
-		ene_hw_write_reg(dev, ENE_FAN_AS_IN2, ENE_FAN_AS_IN2_EN);
-	}
-	dev->fan_input_inuse = enable;
-}
-
-/* determine which input to use*/
-static void ene_set_inputs(struct ene_device *dev, int learning_enable)
-{
-	ene_enable_normal_recieve(dev, 1);
-
-	/* old hardware doesn't support learning mode for sure */
-	if (dev->hw_revision <= ENE_HW_B)
-		return;
-
-	/* reciever not learning capable, still set gpio40 correctly */
-	if (!dev->hw_learning_and_tx_capable) {
-		ene_enable_gpio40(dev, !dev->hw_gpio40_learning);
-		return;
-	}
-
-	/* enable learning mode */
-	if (learning_enable) {
-		ene_enable_gpio40(dev, dev->hw_gpio40_learning);
-
-		/* fan input is not used for learning */
-		if (dev->hw_fan_as_normal_input)
-			ene_enable_fan_recieve(dev, 0);
-
-	/* disable learning mode */
-	} else {
-		if (dev->hw_fan_as_normal_input) {
-			ene_enable_fan_recieve(dev, 1);
-			ene_enable_normal_recieve(dev, 0);
-		} else
-			ene_enable_gpio40(dev, !dev->hw_gpio40_learning);
-	}
-
-	/* set few additional settings for this mode */
-	ene_hw_write_reg_mask(dev, ENE_CIR_CONF1, learning_enable ?
-			      ENE_CIR_CONF1_LEARN1 : 0, ENE_CIR_CONF1_LEARN1);
-
-	ene_hw_write_reg_mask(dev, ENE_CIR_CONF2, learning_enable ?
-			      ENE_CIR_CONF2_LEARN2 : 0, ENE_CIR_CONF2_LEARN2);
-}
-
-/* deinitialization */
-static void ene_hw_deinit(void *data)
-{
-	struct ene_device *dev = (struct ene_device *)data;
-
-	/* disable samplers */
-	ene_enable_normal_recieve(dev, 0);
-
-	if (dev->hw_fan_as_normal_input)
-		ene_enable_fan_recieve(dev, 0);
-
-	/* disable hardware IRQ and firmware flag */
-	ene_hw_write_reg_mask(dev, ENE_FW1, 0, ENE_FW1_ENABLE | ENE_FW1_IRQ);
-
-	ene_set_idle(dev, 1);
-	dev->in_use = 0;
-}
-
-/*  sends current sample to userspace */
-static void send_sample(struct ene_device *dev)
-{
-	int value = abs(dev->sample) & PULSE_MASK;
-
-	if (dev->sample > 0)
-		value |= PULSE_BIT;
-
-	if (!lirc_buffer_full(dev->lirc_driver->rbuf)) {
-		lirc_buffer_write(dev->lirc_driver->rbuf, (void *)&value);
-		wake_up(&dev->lirc_driver->rbuf->wait_poll);
-	}
-	dev->sample = 0;
-}
-
-/*  this updates current sample */
-static void update_sample(struct ene_device *dev, int sample)
-{
-	if (!dev->sample)
-		dev->sample = sample;
-	else if (same_sign(dev->sample, sample))
-		dev->sample += sample;
-	else {
-		send_sample(dev);
-		dev->sample = sample;
-	}
-}
-
-/* enable or disable idle mode */
-static void ene_set_idle(struct ene_device *dev, int idle)
-{
-	struct timeval now;
-	int disable = idle && enable_idle && (dev->hw_revision < ENE_HW_C);
-
-	ene_hw_write_reg_mask(dev, ENE_CIR_SAMPLE_PERIOD,
-			      disable ? 0 : ENE_CIR_SAMPLE_OVERFLOW,
-			      ENE_CIR_SAMPLE_OVERFLOW);
-	dev->idle = idle;
-
-	/* remember when we have entered the idle mode */
-	if (idle) {
-		do_gettimeofday(&dev->gap_start);
-		return;
-	}
-
-	/* send the gap between keypresses now */
-	do_gettimeofday(&now);
-
-	if (now.tv_sec - dev->gap_start.tv_sec > 16)
-		dev->sample = space(PULSE_MASK);
-	else
-		dev->sample = dev->sample +
-		    space(1000000ull * (now.tv_sec - dev->gap_start.tv_sec))
-		    + space(now.tv_usec - dev->gap_start.tv_usec);
-
-	if (abs(dev->sample) > PULSE_MASK)
-		dev->sample = space(PULSE_MASK);
-	send_sample(dev);
-}
-
-/* interrupt handler */
-static irqreturn_t ene_hw_irq(int irq, void *data)
-{
-	u16 hw_value;
-	int i, hw_sample;
-	int space;
-	int buffer_pointer;
-	int irq_status;
-
-	struct ene_device *dev = (struct ene_device *)data;
-	irq_status = ene_hw_irq_status(dev, &buffer_pointer);
-
-	if (!irq_status)
-		return IRQ_NONE;
-
-	/* TODO: only RX for now */
-	if (irq_status == ENE_IRQ_TX)
-		return IRQ_HANDLED;
-
-	for (i = 0; i < ENE_SAMPLES_SIZE; i++) {
-
-		hw_value = ene_hw_read_reg(dev,
-				ENE_SAMPLE_BUFFER + buffer_pointer + i);
-
-		if (dev->fan_input_inuse) {
-			/* read high part of the sample */
-			hw_value |= ene_hw_read_reg(dev,
-			    ENE_SAMPLE_BUFFER_FAN + buffer_pointer + i) << 8;
-
-			/* test for _space_ bit */
-			space = !(hw_value & ENE_FAN_SMPL_PULS_MSK);
-
-			/* clear space bit, and other unused bits */
-			hw_value &= ENE_FAN_VALUE_MASK;
-			hw_sample = hw_value * ENE_SAMPLE_PERIOD_FAN;
-
-		} else {
-			space = hw_value & ENE_SAMPLE_SPC_MASK;
-			hw_value &= ENE_SAMPLE_VALUE_MASK;
-			hw_sample = hw_value * sample_period;
-		}
-
-		/* no more data */
-		if (!(hw_value))
-			break;
-
-		if (space)
-			hw_sample *= -1;
-
-		/* overflow sample recieved, handle it */
-
-		if (!dev->fan_input_inuse && hw_value == ENE_SAMPLE_OVERFLOW) {
-
-			if (dev->idle)
-				continue;
-
-			if (dev->sample > 0 || abs(dev->sample) <= ENE_MAXGAP)
-				update_sample(dev, hw_sample);
-			else
-				ene_set_idle(dev, 1);
-
-			continue;
-		}
-
-		/* normal first sample recieved */
-		if (!dev->fan_input_inuse && dev->idle) {
-			ene_set_idle(dev, 0);
-
-			/* discard first recieved value, its random
-			   since its the time signal was off before
-			   first pulse if idle mode is enabled, HW
-			   does that for us */
-
-			if (!enable_idle)
-				continue;
-		}
-		update_sample(dev, hw_sample);
-		send_sample(dev);
-	}
-	return IRQ_HANDLED;
-}
-
-static int ene_probe(struct pnp_dev *pnp_dev,
-		     const struct pnp_device_id *dev_id)
-{
-	struct ene_device *dev;
-	struct lirc_driver *lirc_driver;
-	int error = -ENOMEM;
-
-	dev = kzalloc(sizeof(struct ene_device), GFP_KERNEL);
-
-	if (!dev)
-		goto err1;
-
-	dev->pnp_dev = pnp_dev;
-	pnp_set_drvdata(pnp_dev, dev);
-
-
-	/* prepare lirc interface */
-	error = -ENOMEM;
-	lirc_driver = kzalloc(sizeof(struct lirc_driver), GFP_KERNEL);
-
-	if (!lirc_driver)
-		goto err2;
-
-	dev->lirc_driver = lirc_driver;
-
-	strcpy(lirc_driver->name, ENE_DRIVER_NAME);
-	lirc_driver->minor = -1;
-	lirc_driver->code_length = sizeof(int) * 8;
-	lirc_driver->features = LIRC_CAN_REC_MODE2;
-	lirc_driver->data = dev;
-	lirc_driver->set_use_inc = ene_hw_init;
-	lirc_driver->set_use_dec = ene_hw_deinit;
-	lirc_driver->dev = &pnp_dev->dev;
-	lirc_driver->owner = THIS_MODULE;
-
-	lirc_driver->rbuf = kzalloc(sizeof(struct lirc_buffer), GFP_KERNEL);
-
-	if (!lirc_driver->rbuf)
-		goto err3;
-
-	if (lirc_buffer_init(lirc_driver->rbuf, sizeof(int), sizeof(int) * 256))
-		goto err4;
-
-	error = -ENODEV;
-	if (lirc_register_driver(lirc_driver))
-		goto err5;
-
-	/* validate resources */
-	if (!pnp_port_valid(pnp_dev, 0) ||
-	    pnp_port_len(pnp_dev, 0) < ENE_MAX_IO)
-		goto err6;
-
-	if (!pnp_irq_valid(pnp_dev, 0))
-		goto err6;
-
-	dev->hw_io = pnp_port_start(pnp_dev, 0);
-	dev->irq = pnp_irq(pnp_dev, 0);
-
-	/* claim the resources */
-	error = -EBUSY;
-	if (!request_region(dev->hw_io, ENE_MAX_IO, ENE_DRIVER_NAME))
-		goto err6;
-
-	if (request_irq(dev->irq, ene_hw_irq,
-			IRQF_SHARED, ENE_DRIVER_NAME, (void *)dev))
-		goto err7;
-
-	/* detect hardware version and features */
-	error = ene_hw_detect(dev);
-	if (error)
-		goto err8;
-
-	ene_printk(KERN_NOTICE, "driver has been succesfully loaded\n");
-	return 0;
-
-err8:
-	free_irq(dev->irq, dev);
-err7:
-	release_region(dev->hw_io, ENE_MAX_IO);
-err6:
-	lirc_unregister_driver(lirc_driver->minor);
-err5:
-	lirc_buffer_free(lirc_driver->rbuf);
-err4:
-	kfree(lirc_driver->rbuf);
-err3:
-	kfree(lirc_driver);
-err2:
-	kfree(dev);
-err1:
-	return error;
-}
-
-static void ene_remove(struct pnp_dev *pnp_dev)
-{
-	struct ene_device *dev = pnp_get_drvdata(pnp_dev);
-	ene_hw_deinit(dev);
-	free_irq(dev->irq, dev);
-	release_region(dev->hw_io, ENE_MAX_IO);
-	lirc_unregister_driver(dev->lirc_driver->minor);
-	lirc_buffer_free(dev->lirc_driver->rbuf);
-	kfree(dev->lirc_driver);
-	kfree(dev);
-}
-
-#ifdef CONFIG_PM
-
-/* TODO: make 'wake on IR' configurable and add .shutdown */
-/* currently impossible due to lack of kernel support */
-
-static int ene_suspend(struct pnp_dev *pnp_dev, pm_message_t state)
-{
-	struct ene_device *dev = pnp_get_drvdata(pnp_dev);
-	ene_hw_write_reg_mask(dev, ENE_FW1, ENE_FW1_WAKE, ENE_FW1_WAKE);
-	return 0;
-}
-
-static int ene_resume(struct pnp_dev *pnp_dev)
-{
-	struct ene_device *dev = pnp_get_drvdata(pnp_dev);
-	if (dev->in_use)
-		ene_hw_init(dev);
-
-	ene_hw_write_reg_mask(dev, ENE_FW1, 0, ENE_FW1_WAKE);
-	return 0;
-}
-
-#endif
-
-static const struct pnp_device_id ene_ids[] = {
-	{.id = "ENE0100",},
-	{},
-};
-
-static struct pnp_driver ene_driver = {
-	.name = ENE_DRIVER_NAME,
-	.id_table = ene_ids,
-	.flags = PNP_DRIVER_RES_DO_NOT_CHANGE,
-
-	.probe = ene_probe,
-	.remove = __devexit_p(ene_remove),
-
-#ifdef CONFIG_PM
-	.suspend = ene_suspend,
-	.resume = ene_resume,
-#endif
-};
-
-static int __init ene_init(void)
-{
-	if (sample_period < 5) {
-		ene_printk(KERN_ERR, "sample period must be at\n");
-		ene_printk(KERN_ERR, "least 5 us, (at least 30 recommended)\n");
-		return -EINVAL;
-	}
-	return pnp_register_driver(&ene_driver);
-}
-
-static void ene_exit(void)
-{
-	pnp_unregister_driver(&ene_driver);
-}
-
-module_param(sample_period, int, S_IRUGO);
-MODULE_PARM_DESC(sample_period, "Hardware sample period (75 us default)");
-
-module_param(enable_idle, bool, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(enable_idle,
-	"Enables turning off signal sampling after long inactivity time; "
-	"if disabled might help detecting input signal (default: enabled)");
-
-module_param(enable_learning, bool, S_IRUGO);
-MODULE_PARM_DESC(enable_learning, "Use wide band (learning) reciever");
-
-MODULE_DEVICE_TABLE(pnp, ene_ids);
-MODULE_DESCRIPTION
-    ("LIRC driver for KB3926B/KB3926C/KB3926D (aka ENE0100) CIR port");
-MODULE_AUTHOR("Maxim Levitsky");
-MODULE_LICENSE("GPL");
-
-module_init(ene_init);
-module_exit(ene_exit);
diff --git a/drivers/staging/lirc/lirc_ene0100.h b/drivers/staging/lirc/lirc_ene0100.h
deleted file mode 100644
index 825045d..0000000
--- a/drivers/staging/lirc/lirc_ene0100.h
+++ /dev/null
@@ -1,169 +0,0 @@
-/*
- * driver for ENE KB3926 B/C/D CIR (also known as ENE0100)
- *
- * Copyright (C) 2009 Maxim Levitsky <maximlevitsky@gmail.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
- * USA
- */
-
-#include <media/lirc.h>
-#include <media/lirc_dev.h>
-
-/* hardware address */
-#define ENE_STATUS		0	 /* hardware status - unused */
-#define ENE_ADDR_HI 		1	 /* hi byte of register address */
-#define ENE_ADDR_LO 		2	 /* low byte of register address */
-#define ENE_IO 			3	 /* read/write window */
-#define ENE_MAX_IO		4
-
-/* 8 bytes of samples, divided in 2 halfs*/
-#define ENE_SAMPLE_BUFFER 	0xF8F0	 /* regular sample buffer */
-#define ENE_SAMPLE_SPC_MASK 	(1 << 7) /* sample is space */
-#define ENE_SAMPLE_VALUE_MASK	0x7F
-#define ENE_SAMPLE_OVERFLOW	0x7F
-#define ENE_SAMPLES_SIZE	4
-
-/* fan input sample buffer */
-#define ENE_SAMPLE_BUFFER_FAN	0xF8FB	 /* this buffer holds high byte of */
-					 /* each sample of normal buffer */
-
-#define ENE_FAN_SMPL_PULS_MSK	0x8000	 /* this bit of combined sample */
-					 /* if set, says that sample is pulse */
-#define ENE_FAN_VALUE_MASK	0x0FFF   /* mask for valid bits of the value */
-
-/* first firmware register */
-#define ENE_FW1			0xF8F8
-#define	ENE_FW1_ENABLE		(1 << 0) /* enable fw processing */
-#define ENE_FW1_TXIRQ		(1 << 1) /* TX interrupt pending */
-#define ENE_FW1_WAKE		(1 << 6) /* enable wake from S3 */
-#define ENE_FW1_IRQ		(1 << 7) /* enable interrupt */
-
-/* second firmware register */
-#define ENE_FW2			0xF8F9
-#define ENE_FW2_BUF_HIGH	(1 << 0) /* which half of the buffer to read */
-#define ENE_FW2_IRQ_CLR		(1 << 2) /* clear this on IRQ */
-#define ENE_FW2_GP40_AS_LEARN	(1 << 4) /* normal input is used as */
-					 /* learning input */
-#define ENE_FW2_FAN_AS_NRML_IN	(1 << 6) /* fan is used as normal input */
-#define ENE_FW2_LEARNING	(1 << 7) /* hardware supports learning and TX */
-
-/* fan as input settings - only if learning capable */
-#define ENE_FAN_AS_IN1		0xFE30   /* fan init reg 1 */
-#define ENE_FAN_AS_IN1_EN	0xCD
-#define ENE_FAN_AS_IN2		0xFE31   /* fan init reg 2 */
-#define ENE_FAN_AS_IN2_EN	0x03
-#define ENE_SAMPLE_PERIOD_FAN   61	 /* fan input has fixed sample period */
-
-/* IRQ registers block (for revision B) */
-#define ENEB_IRQ		0xFD09	 /* IRQ number */
-#define ENEB_IRQ_UNK1		0xFD17	 /* unknown setting = 1 */
-#define ENEB_IRQ_STATUS		0xFD80	 /* irq status */
-#define ENEB_IRQ_STATUS_IR	(1 << 5) /* IR irq */
-
-/* IRQ registers block (for revision C,D) */
-#define ENEC_IRQ		0xFE9B	 /* new irq settings register */
-#define ENEC_IRQ_MASK		0x0F	 /* irq number mask */
-#define ENEC_IRQ_UNK_EN		(1 << 4) /* always enabled */
-#define ENEC_IRQ_STATUS		(1 << 5) /* irq status and ACK */
-
-/* CIR block settings */
-#define ENE_CIR_CONF1		0xFEC0
-#define ENE_CIR_CONF1_ADC_ON	0x7	 /* reciever on gpio40 enabled */
-#define ENE_CIR_CONF1_LEARN1	(1 << 3) /* enabled on learning mode */
-#define ENE_CIR_CONF1_TX_ON	0x30	 /* enabled on transmit */
-#define ENE_CIR_CONF1_TX_CARR	(1 << 7) /* send TX carrier or not */
-
-#define ENE_CIR_CONF2		0xFEC1	 /* unknown setting = 0 */
-#define ENE_CIR_CONF2_LEARN2	(1 << 4) /* set on enable learning */
-#define ENE_CIR_CONF2_GPIO40DIS	(1 << 5) /* disable normal input via gpio40 */
-
-#define ENE_CIR_SAMPLE_PERIOD	0xFEC8	 /* sample period in us */
-#define ENE_CIR_SAMPLE_OVERFLOW	(1 << 7) /* interrupt on overflows if set */
-
-
-/* transmitter - not implemented yet */
-/* KB3926C and higher */
-/* transmission is very similiar to recieving, a byte is written to */
-/* ENE_TX_INPUT, in same manner as it is read from sample buffer */
-/* sample period is fixed*/
-
-
-/* transmitter ports */
-#define ENE_TX_PORT1		0xFC01	 /* this enables one or both */
-#define ENE_TX_PORT1_EN		(1 << 5) /* TX ports */
-#define ENE_TX_PORT2		0xFC08
-#define ENE_TX_PORT2_EN		(1 << 1)
-
-#define ENE_TX_INPUT		0xFEC9	 /* next byte to transmit */
-#define ENE_TX_SPC_MASK 	(1 << 7) /* Transmitted sample is space */
-#define ENE_TX_UNK1		0xFECB	 /* set to 0x63 */
-#define ENE_TX_SMPL_PERIOD	50	 /* transmit sample period */
-
-
-#define ENE_TX_CARRIER		0xFECE	 /* TX carrier * 2 (khz) */
-#define ENE_TX_CARRIER_UNKBIT	0x80	 /* This bit set on transmit */
-#define ENE_TX_CARRIER_LOW	0xFECF	 /* TX carrier / 2 */
-
-/* Hardware versions */
-#define ENE_HW_VERSION		0xFF00	 /* hardware revision */
-#define ENE_HW_UNK 		0xFF1D
-#define ENE_HW_UNK_CLR		(1 << 2)
-#define ENE_HW_VER_MAJOR	0xFF1E	 /* chip version */
-#define ENE_HW_VER_MINOR	0xFF1F
-#define ENE_HW_VER_OLD		0xFD00
-
-#define same_sign(a, b) ((((a) > 0) && (b) > 0) || ((a) < 0 && (b) < 0))
-
-#define ENE_DRIVER_NAME 	"enecir"
-#define ENE_MAXGAP 		250000	 /* this is amount of time we wait
-					 before turning the sampler, chosen
-					 arbitry */
-
-#define space(len) 	       (-(len))	 /* add a space */
-
-/* software defines */
-#define ENE_IRQ_RX		1
-#define ENE_IRQ_TX		2
-
-#define  ENE_HW_B		1	/* 3926B */
-#define  ENE_HW_C		2	/* 3926C */
-#define  ENE_HW_D		3	/* 3926D */
-
-#define ene_printk(level, text, ...) \
-	printk(level ENE_DRIVER_NAME ": " text, ## __VA_ARGS__)
-
-struct ene_device {
-	struct pnp_dev *pnp_dev;
-	struct lirc_driver *lirc_driver;
-
-	/* hw settings */
-	unsigned long hw_io;
-	int irq;
-
-	int hw_revision;			/* hardware revision */
-	int hw_learning_and_tx_capable;		/* learning capable */
-	int hw_gpio40_learning;			/* gpio40 is learning */
-	int hw_fan_as_normal_input;	/* fan input is used as regular input */
-
-	/* device data */
-	int idle;
-	int fan_input_inuse;
-
-	int sample;
-	int in_use;
-
-	struct timeval gap_start;
-};
-- 
1.7.0.4

[PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Maxim Levitsky]

note that error_adjustment module option is added.
This allows to reduce input samples by a percent.
This makes input on my system more correct.

Default is 4% as it works best here.

Note that only normal input is adjusted. I don't know
what ajustements to apply to fan tachtometer input.
Maybe it is accurate already.

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
 MAINTAINERS               |    6 +
 drivers/media/IR/Kconfig  |   14 +
 drivers/media/IR/Makefile |    1 +
 drivers/media/IR/ene_ir.c |  591 +++++++++++++++++----------------------------
 drivers/media/IR/ene_ir.h |   47 ++---
 5 files changed, 258 insertions(+), 401 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 56a36d7..587785a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2188,6 +2188,12 @@ F:	drivers/misc/cb710/
 F:	drivers/mmc/host/cb710-mmc.*
 F:	include/linux/cb710.h
 
+ENE KB2426 (ENE0100/ENE020XX) INFRARED RECEIVER
+M:	Maxim Levitsky <maximlevitsky@gmail.com>
+S:	Maintained
+F:	drivers/media/IR/ene_ir.c
+F:	drivers/media/IR/ene_ir.h
+
 EPSON 1355 FRAMEBUFFER DRIVER
 M:	Christopher Hoover <ch@murgatroid.com>
 M:	Christopher Hoover <ch@hpl.hp.com>
diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index fc48a3f..3f62bf9 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -105,4 +105,18 @@ config IR_MCEUSB
 	   To compile this driver as a module, choose M here: the
 	   module will be called mceusb.
 
+config IR_ENE
+	tristate "ENE eHome Receiver/Transciever (pnp id: ENE0100/ENE02xxx)"
+	depends on PNP
+	depends on IR_CORE
+	---help---
+	   Say Y here to enable support for integrated infrared receiver
+	   /transciever made by ENE.
+
+	   You can see if you have it by looking at lspnp output.
+	   Output should include ENE0100 ENE0200 or something similiar.
+
+	   To compile this driver as a module, choose M here: the
+	   module will be called ene_ir.
+
 endif #IR_CORE
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index 2ae4f3a..3262a68 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
 # stand-alone IR receivers/transmitters
 obj-$(CONFIG_IR_IMON) += imon.o
 obj-$(CONFIG_IR_MCEUSB) += mceusb.o
+obj-$(CONFIG_IR_ENE) += ene_ir.o
diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c
index 9d11caf..297cfed 100644
--- a/drivers/media/IR/ene_ir.c
+++ b/drivers/media/IR/ene_ir.c
@@ -1,5 +1,5 @@
 /*
- * driver for ENE KB3926 B/C/D CIR (also known as ENE0100/ENE0200/ENE0201)
+ * driver for ENE KB3926 B/C/D CIR (pnp id: ENE0XXX)
  *
  * Copyright (C) 2010 Maxim Levitsky <maximlevitsky@gmail.com>
  *
@@ -25,20 +25,21 @@
 #include <linux/io.h>
 #include <linux/interrupt.h>
 #include <linux/sched.h>
-#include <linux/uaccess.h>
-#include "lirc_ene0100.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 = -1;
 static int enable_idle = 1;
-static int enable_duty_carrier;
+static int error_adjustment = 4;
 static int input = 1;
 static int debug;
 static int txsim;
 
-static void ene_rx_set_idle(struct ene_device *dev, int idle);
 static int ene_irq_status(struct ene_device *dev);
-static void ene_send_sample(struct ene_device *dev, unsigned long sample);
 
 /* read a hardware register */
 static u8 ene_hw_read_reg(struct ene_device *dev, u16 reg)
@@ -160,7 +161,7 @@ static int ene_hw_detect(struct ene_device *dev)
 }
 
 /* this enables/disables IR input via gpio40*/
-static void ene_enable_gpio40_recieve(struct ene_device *dev, int enable)
+static void ene_enable_gpio40_receive(struct ene_device *dev, int enable)
 {
 	ene_hw_write_reg_mask(dev, ENE_CIR_CONF2, enable ?
 			      0 : ENE_CIR_CONF2_GPIO40DIS,
@@ -168,13 +169,13 @@ static void ene_enable_gpio40_recieve(struct ene_device *dev, int enable)
 }
 
 /* this enables/disables IR via standard input */
-static void ene_enable_normal_recieve(struct ene_device *dev, int enable)
+static void ene_enable_normal_receive(struct ene_device *dev, int enable)
 {
 	ene_hw_write_reg(dev, ENE_CIR_CONF1, enable ? ENE_CIR_CONF1_RX_ON : 0);
 }
 
 /* this enables/disables IR input via unused fan tachtometer input */
-static void ene_enable_fan_recieve(struct ene_device *dev, int enable)
+static void ene_enable_fan_receive(struct ene_device *dev, int enable)
 {
 	if (!enable)
 		ene_hw_write_reg(dev, ENE_FAN_AS_IN1, 0);
@@ -186,7 +187,7 @@ static void ene_enable_fan_recieve(struct ene_device *dev, int enable)
 }
 
 
-/* Sense current recieved carrier */
+/* Sense current received carrier */
 static int ene_rx_sense_carrier(struct ene_device *dev)
 {
 	int period = ene_hw_read_reg(dev, ENE_RX_CARRIER);
@@ -209,37 +210,37 @@ static int ene_rx_sense_carrier(struct ene_device *dev)
 /* determine which input to use*/
 static void ene_rx_set_inputs(struct ene_device *dev)
 {
-	int learning_mode = dev->learning_enabled || dev->rx_carrier_sense;
+	int learning_mode = dev->learning_enabled;
 
-	ene_dbg("RX: setup reciever, learning mode = %d", learning_mode);
+	ene_dbg("RX: setup receiver, learning mode = %d", learning_mode);
 
-	ene_enable_normal_recieve(dev, 1);
+	ene_enable_normal_receive(dev, 1);
 
 	/* old hardware doesn't support learning mode for sure */
 	if (dev->hw_revision <= ENE_HW_B)
 		return;
 
-	/* reciever not learning capable, still set gpio40 correctly */
+	/* receiver not learning capable, still set gpio40 correctly */
 	if (!dev->hw_learning_and_tx_capable) {
-		ene_enable_gpio40_recieve(dev, !dev->hw_gpio40_learning);
+		ene_enable_gpio40_receive(dev, !dev->hw_gpio40_learning);
 		return;
 	}
 
 	/* enable learning mode */
 	if (learning_mode) {
-		ene_enable_gpio40_recieve(dev, dev->hw_gpio40_learning);
+		ene_enable_gpio40_receive(dev, dev->hw_gpio40_learning);
 
 		/* fan input is not used for learning */
 		if (dev->hw_fan_as_normal_input)
-			ene_enable_fan_recieve(dev, 0);
+			ene_enable_fan_receive(dev, 0);
 
 	/* disable learning mode */
 	} else {
 		if (dev->hw_fan_as_normal_input) {
-			ene_enable_fan_recieve(dev, 1);
-			ene_enable_normal_recieve(dev, 0);
+			ene_enable_fan_receive(dev, 1);
+			ene_enable_normal_receive(dev, 0);
 		} else
-			ene_enable_gpio40_recieve(dev,
+			ene_enable_gpio40_receive(dev,
 					!dev->hw_gpio40_learning);
 	}
 
@@ -249,6 +250,16 @@ static void ene_rx_set_inputs(struct ene_device *dev)
 
 	ene_hw_write_reg_mask(dev, ENE_CIR_CONF2, learning_mode ?
 			      ENE_CIR_CONF2_LEARN2 : 0, ENE_CIR_CONF2_LEARN2);
+
+	if (dev->rx_fan_input_inuse) {
+		dev->props->rx_resolution = ENE_SAMPLE_PERIOD_FAN * 1000;
+
+		dev->props->timeout =
+			ENE_FAN_VALUE_MASK * ENE_SAMPLE_PERIOD_FAN * 1000;
+	} else {
+		dev->props->rx_resolution = sample_period * 1000;
+		dev->props->timeout = ENE_MAXGAP * 1000;
+	}
 }
 
 /* Enable the device for receive */
@@ -277,147 +288,33 @@ static void ene_rx_enable(struct ene_device *dev)
 	/* ack any pending irqs - just in case */
 	ene_irq_status(dev);
 
-	/* enter idle mode */
-	ene_rx_set_idle(dev, 1);
-
 	/* enable firmware bits */
 	ene_hw_write_reg_mask(dev, ENE_FW1,
 			      ENE_FW1_ENABLE | ENE_FW1_IRQ,
 			      ENE_FW1_ENABLE | ENE_FW1_IRQ);
+
+	/* enter idle mode */
+	ir_raw_event_set_idle(dev->idev, 1);
+	ir_raw_event_reset(dev->idev);
+
 }
 
-/* Disable the device reciever */
+/* Disable the device receiver */
 static void ene_rx_disable(struct ene_device *dev)
 {
 	/* disable inputs */
-	ene_enable_normal_recieve(dev, 0);
+	ene_enable_normal_receive(dev, 0);
 
 	if (dev->hw_fan_as_normal_input)
-		ene_enable_fan_recieve(dev, 0);
+		ene_enable_fan_receive(dev, 0);
 
 	/* disable hardware IRQ and firmware flag */
 	ene_hw_write_reg_mask(dev, ENE_FW1, 0, ENE_FW1_ENABLE | ENE_FW1_IRQ);
 
-	ene_rx_set_idle(dev, 1);
-}
-
-/*  send current sample to the user */
-static void ene_rx_flush(struct ene_device *dev, int timeout)
-{
-	unsigned long value;
-
-	value =	dev->rx_sample_pulse ? LIRC_PULSE(dev->rx_sample) :
-					LIRC_SPACE(dev->rx_sample);
-	ene_send_sample(dev, value);
-	dev->rx_sample = 0;
-	dev->rx_sample_pulse = 0;
+	ir_raw_event_set_idle(dev->idev, 1);
+	ir_raw_event_reset(dev->idev);
 }
 
-/* recieve new sample and process it */
-static void ene_rx_sample(struct ene_device *dev, int sample, int is_pulse)
-{
-	ene_dbg("RX: sample %8d (%s)", sample, is_pulse ? "pulse" : "space");
-
-	/* ignore spaces in idle mode, can get them on revC */
-	/* also ignore a space in front of first pulse */
-	if (dev->rx_idle && !is_pulse)
-		return;
-
-	/* get out of idle mode now */
-	if (dev->rx_idle)
-		ene_rx_set_idle(dev, 0);
-
-	if (!dev->rx_sample) {
-		dev->rx_sample = sample;
-		dev->rx_sample_pulse = is_pulse;
-	} else if (is_pulse == dev->rx_sample_pulse)
-		dev->rx_sample += sample;
-	else {
-		ene_rx_flush(dev, 0);
-		dev->rx_sample = sample;
-		dev->rx_sample_pulse = is_pulse;
-	}
-
-	if (is_pulse)
-		return;
-
-	/* overflow sample from fan input recieved, enable idle mode */
-	if (dev->rx_fan_input_inuse &&
-		sample == ENE_FAN_VALUE_MASK * ENE_SAMPLE_PERIOD_FAN) {
-		ene_rx_set_idle(dev, 1);
-		return;
-	}
-
-	if (!dev->rx_fan_input_inuse) {
-		/* Report timeout if enabled */
-		if (dev->rx_timeout && dev->rx_send_timeout_packet &&
-			!dev->rx_timeout_sent &&
-				dev->rx_sample > dev->rx_timeout) {
-			ene_dbg("RX: sending timeout sample");
-			ene_send_sample(dev, LIRC_TIMEOUT(dev->rx_sample));
-			dev->rx_timeout_sent = 1;
-		}
-
-		/* too large sample accumulated via normal input.
-		note that on revC, hardware idle mode turns on automaticly,
-			so max gap should be less that the gap after which
-			hw stops sending samples */
-		if (dev->rx_sample > ENE_MAXGAP) {
-			ene_rx_set_idle(dev, 1);
-			return;
-		}
-	}
-}
-
-/* enable or disable idle mode */
-static void ene_rx_set_idle(struct ene_device *dev, int idle)
-{
-	struct timeval now;
-	int disable_sampler = 0;
-
-
-	/* Also put hardware sampler in 'idle' mode on revB*/
-	/* revC and higher do that automaticly (firmware does?) */
-	if ((dev->hw_revision < ENE_HW_C) && enable_idle)
-		if (idle)
-			disable_sampler = 1;
-
-	ene_hw_write_reg_mask(dev, ENE_CIR_SAMPLE_PERIOD,
-			      disable_sampler ? 0 : ENE_CIR_SAMPLE_OVERFLOW,
-			      ENE_CIR_SAMPLE_OVERFLOW);
-	dev->rx_idle = idle;
-
-	/* remember when we have entered the idle mode */
-	if (idle) {
-		ene_dbg("RX: going into idle mode");
-		do_gettimeofday(&dev->rx_gap_start);
-		return;
-	}
-
-	ene_dbg("RX: back from idle mode");
-
-	/* send the gap between keypresses now */
-	do_gettimeofday(&now);
-
-	if (dev->rx_sample_pulse) {
-		ene_dbg("RX: somehow we recieved a pulse before idle mode???");
-		return;
-	}
-
-	/* manually calculate and recieve the gap between keypresses */
-	if (now.tv_sec - dev->rx_gap_start.tv_sec > 16)
-		dev->rx_sample = LIRC_SPACE(LIRC_VALUE_MASK);
-	else
-		dev->rx_sample +=
-		    1000000ull * (now.tv_sec - dev->rx_gap_start.tv_sec)
-		    + now.tv_usec - dev->rx_gap_start.tv_usec;
-
-	if (dev->rx_sample > LIRC_SPACE(LIRC_VALUE_MASK))
-		dev->rx_sample = LIRC_SPACE(LIRC_VALUE_MASK);
-
-	ene_rx_flush(dev, 0);
-	dev->rx_timeout_sent = 0;
-}
 
 /* prepare transmission */
 static void ene_tx_prepare(struct ene_device *dev)
@@ -436,6 +333,8 @@ static void ene_tx_prepare(struct ene_device *dev)
 	/* Set carrier */
 	if (dev->tx_period) {
 
+		/* NOTE: duty cycle handling is just a guess, it might
+			not be aviable. Default values were tested */
 		int tx_period_in500ns = dev->tx_period * 2;
 
 		int tx_pulse_width_in_500ns =
@@ -459,7 +358,6 @@ static void ene_tx_prepare(struct ene_device *dev)
 		conf1 &= ~ENE_CIR_CONF1_TX_CARR;
 
 	ene_hw_write_reg(dev, ENE_CIR_CONF1, conf1);
-	dev->tx_underway = 1;
 
 }
 
@@ -467,11 +365,11 @@ static void ene_tx_prepare(struct ene_device *dev)
 static void ene_tx_complete(struct ene_device *dev)
 {
 	ene_hw_write_reg(dev, ENE_CIR_CONF1, dev->saved_conf1);
-	dev->tx_underway = 0;
+	dev->tx_buffer = NULL;
 }
 
 /* set transmit mask */
-static void ene_tx_set_transmiter_mask(struct ene_device *dev)
+static void ene_tx_hw_set_transmiter_mask(struct ene_device *dev)
 {
 	u8 txport1 = ene_hw_read_reg(dev, ENE_TX_PORT1) & ~ENE_TX_PORT1_EN;
 	u8 txport2 = ene_hw_read_reg(dev, ENE_TX_PORT2) & ~ENE_TX_PORT2_EN;
@@ -492,8 +390,8 @@ static void ene_tx_sample(struct ene_device *dev)
 	u8 raw_tx;
 	u32 sample;
 
-	if (!dev->tx_underway) {
-		ene_dbg("TX: attempt to transmit while hw isn't setup");
+	if (!dev->tx_buffer) {
+		ene_dbg("TX: attempt to transmit NULL buffer");
 		return;
 	}
 
@@ -623,6 +521,7 @@ static irqreturn_t ene_isr(int irq, void *data)
 	int carrier = 0;
 	irqreturn_t retval = IRQ_NONE;
 	struct ene_device *dev = (struct ene_device *)data;
+	struct ir_raw_event ev;
 
 
 	spin_lock_irqsave(&dev->hw_lock, flags);
@@ -646,12 +545,13 @@ static irqreturn_t ene_isr(int irq, void *data)
 		goto unlock;
 
 
-	if ((debug && dev->learning_enabled) || dev->rx_carrier_sense)
+	if (dev->carrier_detect_enabled || debug)
 		carrier = ene_rx_sense_carrier(dev);
-
-	if (dev->rx_carrier_sense && carrier)
-		ene_send_sample(dev, LIRC_FREQUENCY(carrier));
-
+#if 0
+	/* TODO */
+	if (dev->carrier_detect_enabled && carrier)
+		ir_raw_event_report_frequency(dev->idev, carrier);
+#endif
 
 	for (i = 0; i < ENE_SAMPLES_SIZE; i++) {
 		hw_value = ene_hw_read_reg(dev,
@@ -672,13 +572,25 @@ static irqreturn_t ene_isr(int irq, void *data)
 			pulse = !(hw_value & ENE_SAMPLE_SPC_MASK);
 			hw_value &= ENE_SAMPLE_VALUE_MASK;
 			hw_sample = hw_value * sample_period;
+
+			if (error_adjustment && error_adjustment < 100) {
+				hw_sample *= (100 - error_adjustment);
+				hw_sample /= 100;
+			}
 		}
 		/* no more data */
 		if (!(hw_value))
 			break;
 
-		ene_rx_sample(dev, hw_sample, pulse);
+		ene_dbg("RX: %d (%s)", hw_sample, pulse ? "pulse" : "space");
+
+
+		ev.duration = hw_sample * 1000;
+		ev.pulse = pulse;
+		ir_raw_event_store_with_filter(dev->idev, &ev);
 	}
+
+	ir_raw_event_handle(dev->idev);
 unlock:
 	spin_unlock_irqrestore(&dev->hw_lock, flags);
 	return retval;
@@ -687,8 +599,6 @@ unlock:
 /* Initialize default settings */
 static void ene_setup_settings(struct ene_device *dev)
 {
-	dev->rx_send_timeout_packet = 0;
-	dev->rx_timeout = ENE_MAXGAP;
 	dev->tx_period = 32;
 	dev->tx_duty_cycle = 25; /*%*/
 	dev->transmitter_mask = 3;
@@ -698,11 +608,7 @@ static void ene_setup_settings(struct ene_device *dev)
 	dev->learning_enabled =
 		(input == 2 && dev->hw_learning_and_tx_capable);
 
-	/* Clear accumulated sample bufer */
-	dev->rx_sample = 0;
-	dev->rx_sample_pulse = 0;
 	dev->rx_pointer = -1;
-	dev->rx_carrier_sense = 0;
 
 }
 
@@ -732,144 +638,97 @@ static void ene_close(void *data)
 	spin_unlock_irqrestore(&dev->hw_lock, flags);
 }
 
-/* outside interface for settings */
-static int ene_ioctl(struct inode *node, struct file *file,
-		      unsigned int cmd, unsigned long arg)
+/* outside interface: set transmitter mask */
+static int ene_set_tx_mask(void *data, u32 tx_mask)
 {
-	int lvalue = 0, retval, tmp;
+	struct ene_device *dev = (struct ene_device *)data;
 	unsigned long flags;
-	struct ene_device *dev = lirc_get_pdata(file);
-
-
-	switch (cmd) {
-	case LIRC_SET_SEND_CARRIER:
-	case LIRC_SET_SEND_DUTY_CYCLE:
-	case LIRC_SET_TRANSMITTER_MASK:
-	case LIRC_SET_MEASURE_CARRIER_MODE:
-	case LIRC_SET_REC_CARRIER:
-		/* All these aren't possible without this */
-		if (!dev->hw_learning_and_tx_capable)
-			return -ENOSYS;
-		/* Fall through */
-	case LIRC_SET_REC_TIMEOUT:
-	case LIRC_SET_REC_TIMEOUT_REPORTS:
-		retval = get_user(lvalue, (unsigned int *) arg);
-		if (retval)
-			return retval;
+	ene_dbg("TX: attempt to set transmitter mask %02x", tx_mask);
+
+	/* invalid txmask */
+	if (!tx_mask || tx_mask & ~0x3) {
+		ene_dbg("TX: invalid mask");
+		/* return count of transmitters */
+		return 2;
 	}
 
-	switch (cmd) {
-	case LIRC_SET_SEND_CARRIER:
-		ene_dbg("TX: attempt to set tx carrier to %d kHz", lvalue);
-		tmp = 1000000 / lvalue; /* (1 / freq) (* # usec in 1 sec) */
+	spin_lock_irqsave(&dev->hw_lock, flags);
+	dev->transmitter_mask = tx_mask;
+	spin_unlock_irqrestore(&dev->hw_lock, flags);
+	return 0;
+}
 
-		if (tmp && (tmp > ENE_TX_PERIOD_MAX ||
-				tmp < ENE_TX_PERIOD_MIN)) {
+/* outside interface : set tx carrier */
+static int ene_set_tx_carrier(void *data, u32 carrier)
+{
+	struct ene_device *dev = (struct ene_device *)data;
+	unsigned long flags;
+	u32 period = 1000000 / carrier; /* (1 / freq) (* # usec in 1 sec) */
 
-			ene_dbg("TX: out of range %d-%d carrier, "
-				"falling back to 32 kHz",
-				1000 / ENE_TX_PERIOD_MIN,
-				1000 / ENE_TX_PERIOD_MAX);
+	ene_dbg("TX: attempt to set tx carrier to %d kHz", carrier);
 
-			tmp = 32; /* this is just a coincidence!!! */
-		}
-		ene_dbg("TX: set carrier to %d kHz", lvalue);
+	if (period && (period > ENE_TX_PERIOD_MAX ||
+			period < ENE_TX_PERIOD_MIN)) {
 
-		spin_lock_irqsave(&dev->hw_lock, flags);
-		dev->tx_period = tmp;
-		spin_unlock_irqrestore(&dev->hw_lock, flags);
-		break;
-	case LIRC_SET_SEND_DUTY_CYCLE:
-		ene_dbg("TX: attempt to set duty cycle to %d%%", lvalue);
+		ene_dbg("TX: out of range %d-%d carrier, "
+			"falling back to 32 kHz",
+			1000 / ENE_TX_PERIOD_MIN,
+			1000 / ENE_TX_PERIOD_MAX);
 
-		if ((lvalue >= 100) || (lvalue <= 0)) {
-			retval = -EINVAL;
-			break;
-		}
-		spin_lock_irqsave(&dev->hw_lock, flags);
-		dev->tx_duty_cycle = lvalue;
-		spin_unlock_irqrestore(&dev->hw_lock, flags);
-		break;
-	case LIRC_SET_TRANSMITTER_MASK:
-		ene_dbg("TX: attempt to set transmitter mask %02x", lvalue);
-
-		/* invalid txmask */
-		if (!lvalue || lvalue & ~0x3) {
-			ene_dbg("TX: invalid mask");
-			/* this supposed to return num of transmitters */
-			retval =  2;
-			break;
-		}
-		spin_lock_irqsave(&dev->hw_lock, flags);
-		dev->transmitter_mask = lvalue;
-		spin_unlock_irqrestore(&dev->hw_lock, flags);
-		break;
-	case LIRC_SET_REC_CARRIER:
-		tmp = (lvalue > ENE_NORMAL_RX_HI || lvalue < ENE_NORMAL_RX_LOW);
-
-		if (tmp != dev->learning_enabled) {
-			spin_lock_irqsave(&dev->hw_lock, flags);
-			dev->learning_enabled = tmp;
-			ene_rx_set_inputs(dev);
-			spin_unlock_irqrestore(&dev->hw_lock, flags);
-		}
-		break;
-	case LIRC_SET_REC_TIMEOUT:
-		spin_lock_irqsave(&dev->hw_lock, flags);
-		dev->rx_timeout = lvalue;
-		spin_unlock_irqrestore(&dev->hw_lock, flags);
-		ene_dbg("RX: set rx report timeout to %d", dev->rx_timeout);
-		break;
-	case LIRC_SET_REC_TIMEOUT_REPORTS:
-		spin_lock_irqsave(&dev->hw_lock, flags);
-		dev->rx_send_timeout_packet = lvalue;
-		spin_unlock_irqrestore(&dev->hw_lock, flags);
-		ene_dbg("RX: %sable timeout reports",
-				dev->rx_send_timeout_packet ? "en" : "dis");
-		break;
-	case LIRC_SET_MEASURE_CARRIER_MODE:
-		if (dev->rx_carrier_sense == lvalue)
-			break;
-		spin_lock_irqsave(&dev->hw_lock, flags);
-		dev->rx_carrier_sense = lvalue;
-		ene_rx_set_inputs(dev);
-		spin_unlock_irqrestore(&dev->hw_lock, flags);
-		break;
-	case LIRC_GET_REC_RESOLUTION:
-		tmp = dev->rx_fan_input_inuse ?
-			ENE_SAMPLE_PERIOD_FAN : sample_period;
-		retval = put_user(tmp, (unsigned long *) arg);
-		break;
-	default:
-		retval = -ENOIOCTLCMD;
-		break;
+		period = 32; /* this is just a coincidence!!! */
 	}
+	ene_dbg("TX: set carrier to %d kHz", carrier);
 
-	return retval;
+	spin_lock_irqsave(&dev->hw_lock, flags);
+	dev->tx_period = period;
+	spin_unlock_irqrestore(&dev->hw_lock, flags);
+	return 0;
 }
 
-/* outside interface: transmit */
-static ssize_t ene_transmit(struct file *file, const char *buf,
-				  size_t n, loff_t *ppos)
+
+/* outside interface: enable learning mode */
+static int ene_set_learning_mode(void *data, int enable)
 {
-	struct ene_device *dev = lirc_get_pdata(file);
+	struct ene_device *dev = (struct ene_device *)data;
 	unsigned long flags;
+	if (enable == dev->learning_enabled)
+		return 0;
 
-	if (!dev)
-		return -EFAULT;
+	spin_lock_irqsave(&dev->hw_lock, flags);
+	dev->learning_enabled = enable;
+	ene_rx_set_inputs(dev);
+	spin_unlock_irqrestore(&dev->hw_lock, flags);
+	return 0;
+}
 
-	if (!dev->hw_learning_and_tx_capable)
-		return -ENODEV;
+/* outside interface: set rec carrier */
+static int ene_set_rec_carrier(void *data, u32 min, u32 max)
+{
+	struct ene_device *dev = (struct ene_device *)data;
+	ene_set_learning_mode(dev,
+		max > ENE_NORMAL_RX_HI || min < ENE_NORMAL_RX_LOW);
+	return 0;
+}
 
-	if (n % sizeof(int))
-		return -EINVAL;
+/* outside interface: enable or disable idle mode */
+static void ene_rx_set_idle(void *data, int idle)
+{
+	struct ene_device *dev = (struct ene_device *)data;
+	ene_dbg("%sabling idle mode", idle ? "en" : "dis");
 
-	if (n > ENE_TXBUF_SIZE * sizeof(int))
-		return -ENOMEM;
+	ene_hw_write_reg_mask(dev, ENE_CIR_SAMPLE_PERIOD,
+		(enable_idle && idle) ? 0 : ENE_CIR_SAMPLE_OVERFLOW,
+			ENE_CIR_SAMPLE_OVERFLOW);
+}
 
-	if (copy_from_user(dev->tx_buffer, buf, n))
-		return -EFAULT;
 
+/* outside interface: transmit */
+static int ene_transmit(void *data, int *buf, u32 n)
+{
+	struct ene_device *dev = (struct ene_device *)data;
+	unsigned long flags;
+
+	dev->tx_buffer = buf;
 	dev->tx_len = n / sizeof(int);
 	dev->tx_pos = 0;
 	dev->tx_reg = 0;
@@ -881,7 +740,7 @@ static ssize_t ene_transmit(struct file *file, const char *buf,
 
 	spin_lock_irqsave(&dev->hw_lock, flags);
 
-	ene_tx_set_transmiter_mask(dev);
+	ene_tx_hw_set_transmiter_mask(dev);
 	ene_tx_prepare(dev);
 
 	/* Transmit first two samples */
@@ -897,80 +756,35 @@ static ssize_t ene_transmit(struct file *file, const char *buf,
 		spin_unlock_irqrestore(&dev->hw_lock, flags);
 	} else
 		ene_dbg("TX: done");
-
 	return n;
 }
 
-/* Sends one sample to the user */
-static void ene_send_sample(struct ene_device *dev, unsigned long sample)
-{
-	if (!lirc_buffer_full(dev->lirc_driver->rbuf)) {
-		lirc_buffer_write(dev->lirc_driver->rbuf, (void *)&sample);
-		wake_up(&dev->lirc_driver->rbuf->wait_poll);
-	}
-}
-
 
-static const struct file_operations ene_fops = {
-	.owner		= THIS_MODULE,
-	.write		= ene_transmit,
-	.ioctl		= ene_ioctl,
-};
-
-/* main load function */
-static int ene_probe(struct pnp_dev *pnp_dev,
-		     const struct pnp_device_id *dev_id)
+/* probe entry */
+static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
 {
-	struct ene_device *dev;
-	struct lirc_driver *lirc_driver;
 	int error = -ENOMEM;
+	struct ir_dev_props *ir_props;
+	struct input_dev *input_dev;
+	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 (!dev)
-		goto err1;
-
-	dev->pnp_dev = pnp_dev;
-	pnp_set_drvdata(pnp_dev, dev);
-
-	/* prepare lirc interface */
-	error = -ENOMEM;
-	lirc_driver = kzalloc(sizeof(struct lirc_driver), GFP_KERNEL);
-
-	if (!lirc_driver)
-		goto err2;
-
-	dev->lirc_driver = lirc_driver;
-
-	strcpy(lirc_driver->name, ENE_DRIVER_NAME);
-	lirc_driver->minor = -1;
-	lirc_driver->code_length = sizeof(int) * 8;
-	lirc_driver->features = LIRC_CAN_REC_MODE2 |
-				LIRC_CAN_GET_REC_RESOLUTION |
-				LIRC_CAN_SET_REC_TIMEOUT;
-	lirc_driver->data = dev;
-	lirc_driver->set_use_inc = ene_open;
-	lirc_driver->set_use_dec = ene_close;
-	lirc_driver->dev = &pnp_dev->dev;
-	lirc_driver->owner = THIS_MODULE;
-	lirc_driver->fops = &ene_fops;
-	lirc_driver->min_timeout = ENE_MINGAP;
-	lirc_driver->max_timeout = ENE_MAXGAP;
-	lirc_driver->rbuf = kzalloc(sizeof(struct lirc_buffer), GFP_KERNEL);
-
-	if (!lirc_driver->rbuf)
-		goto err3;
-
-	if (lirc_buffer_init(lirc_driver->rbuf, sizeof(int), sizeof(int) * 512))
-		goto err4;
+	if (!input_dev || !ir_props || !dev)
+		goto error;
 
 	/* validate resources */
+	error = -ENODEV;
+
 	if (!pnp_port_valid(pnp_dev, 0) ||
 	    pnp_port_len(pnp_dev, 0) < ENE_MAX_IO)
-		goto err5;
+		goto error;
 
 	if (!pnp_irq_valid(pnp_dev, 0))
-		goto err5;
+		goto error;
 
 	dev->hw_io = pnp_port_start(pnp_dev, 0);
 	dev->irq = pnp_irq(pnp_dev, 0);
@@ -979,16 +793,19 @@ static int ene_probe(struct pnp_dev *pnp_dev,
 	/* claim the resources */
 	error = -EBUSY;
 	if (!request_region(dev->hw_io, ENE_MAX_IO, ENE_DRIVER_NAME))
-		goto err5;
+		goto error;
 
 	if (request_irq(dev->irq, ene_isr,
 			IRQF_SHARED, ENE_DRIVER_NAME, (void *)dev))
-		goto err6;
+		goto error;
+
+	pnp_set_drvdata(pnp_dev, dev);
+	dev->pnp_dev = pnp_dev;
 
 	/* detect hardware version and features */
 	error = ene_hw_detect(dev);
 	if (error)
-		goto err7;
+		goto error;
 
 	ene_setup_settings(dev);
 
@@ -1000,19 +817,21 @@ static int ene_probe(struct pnp_dev *pnp_dev,
 			"Simulation of TX activated\n");
 	}
 
-	if (dev->hw_learning_and_tx_capable) {
-		lirc_driver->features |= LIRC_CAN_SEND_PULSE |
-					 LIRC_CAN_SET_SEND_CARRIER |
-					 LIRC_CAN_SET_TRANSMITTER_MASK;
+	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->min_timeout = ENE_MINGAP * 1000;
+	ir_props->max_timeout = ENE_MAXGAP * 1000;
+	ir_props->timeout = ENE_MAXGAP * 1000;
 
-		if (enable_duty_carrier)
-			lirc_driver->features |= LIRC_CAN_SET_SEND_DUTY_CYCLE;
+	if (dev->hw_revision == ENE_HW_B)
+		ir_props->s_idle = ene_rx_set_idle;
 
-		if (input == 0)
-			lirc_driver->features |= LIRC_CAN_SET_REC_CARRIER;
 
-		init_completion(&dev->tx_complete);
-	}
+	dev->props = ir_props;
+	dev->idev = input_dev;
 
 	/* don't allow too short/long sample periods */
 	if (sample_period < 5 || sample_period > 0x7F)
@@ -1029,29 +848,50 @@ static int ene_probe(struct pnp_dev *pnp_dev,
 			sample_period = 75;
 	}
 
+	ir_props->rx_resolution = sample_period * 1000;
+
+	if (dev->hw_learning_and_tx_capable) {
+
+		ir_props->s_learning_mode = ene_set_learning_mode;
+
+		if (input == 0)
+			ir_props->s_rx_carrier_range = ene_set_rec_carrier;
+
+		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->tx_resolution = ENE_TX_SMPL_PERIOD * 1000;
+		/* ir_props->s_carrier_report = ene_set_carrier_report; */
+	}
+
+
 	device_set_wakeup_capable(&pnp_dev->dev, 1);
 	device_set_wakeup_enable(&pnp_dev->dev, 1);
 
+	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 (lirc_register_driver(lirc_driver))
-		goto err7;
+	if (ir_input_register(input_dev, RC_MAP_RC6_MCE, ir_props,
+							ENE_DRIVER_NAME))
+		goto error;
+
 
 	ene_printk(KERN_NOTICE, "driver has been succesfully loaded\n");
 	return 0;
-
-err7:
-	free_irq(dev->irq, dev);
-err6:
-	release_region(dev->hw_io, ENE_MAX_IO);
-err5:
-	lirc_buffer_free(lirc_driver->rbuf);
-err4:
-	kfree(lirc_driver->rbuf);
-err3:
-	kfree(lirc_driver);
-err2:
+error:
+	if (dev->irq)
+		free_irq(dev->irq, dev);
+	if (dev->hw_io)
+		release_region(dev->hw_io, ENE_MAX_IO);
+
+	input_free_device(input_dev);
+	kfree(ir_props);
 	kfree(dev);
-err1:
 	return error;
 }
 
@@ -1067,9 +907,8 @@ static void ene_remove(struct pnp_dev *pnp_dev)
 
 	free_irq(dev->irq, dev);
 	release_region(dev->hw_io, ENE_MAX_IO);
-	lirc_unregister_driver(dev->lirc_driver->minor);
-	lirc_buffer_free(dev->lirc_driver->rbuf);
-	kfree(dev->lirc_driver);
+	ir_input_unregister(dev->idev);
+	kfree(dev->props);
 	kfree(dev);
 }
 
@@ -1113,6 +952,7 @@ static const struct pnp_device_id ene_ids[] = {
 	{.id = "ENE0100",},
 	{.id = "ENE0200",},
 	{.id = "ENE0201",},
+	{.id = "ENE0202",},
 	{},
 };
 
@@ -1160,13 +1000,18 @@ module_param(txsim, bool, S_IRUGO);
 MODULE_PARM_DESC(txsim,
 	"Simulate TX features on unsupported hardware (dangerous)");
 
-module_param(enable_duty_carrier, bool, S_IRUGO);
-MODULE_PARM_DESC(enable_duty_carrier,
-	"Enable a code that might allow to to set TX carrier duty cycle");
+
+module_param(error_adjustment, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(error_adjustment,
+	"Correct incoming samples by error_adjustment percent\n"
+	"A default value of 4% seems to help with signal decoding");
+
+
+
 
 MODULE_DEVICE_TABLE(pnp, ene_ids);
 MODULE_DESCRIPTION
-	("LIRC driver for KB3926B/KB3926C/KB3926D "
+	("Infrared input driver for KB3926B/KB3926C/KB3926D "
 	"(aka ENE0100/ENE0200/ENE0201) CIR port");
 
 MODULE_AUTHOR("Maxim Levitsky");
diff --git a/drivers/media/IR/ene_ir.h b/drivers/media/IR/ene_ir.h
index 06453a8..21fdecf 100644
--- a/drivers/media/IR/ene_ir.h
+++ b/drivers/media/IR/ene_ir.h
@@ -1,5 +1,5 @@
 /*
- * driver for ENE KB3926 B/C/D CIR (also known as ENE0100/ENE0200/ENE0201)
+ * driver for ENE KB3926 B/C/D CIR (also known as ENE0XXX)
  *
  * Copyright (C) 2010 Maxim Levitsky <maximlevitsky@gmail.com>
  *
@@ -19,8 +19,7 @@
  * USA
  */
 #include <linux/spinlock.h>
-#include <media/lirc.h>
-#include <media/lirc_dev.h>
+
 
 /* hardware address */
 #define ENE_STATUS		0	/* hardware status - unused */
@@ -62,7 +61,7 @@
 /* transmitter ports */
 #define ENE_TX_PORT2		0xFC01	/* this enables one or both */
 #define ENE_TX_PORT2_EN		0x20	/* TX ports */
-#define ENE_TX_PORT1		0xFC08	
+#define ENE_TX_PORT1		0xFC08
 #define ENE_TX_PORT1_EN		0x02
 
 /* IRQ registers block (for revision B) */
@@ -88,7 +87,7 @@
 #define ENE_CIR_CONF1		0xFEC0
 #define ENE_CIR_CONF1_TX_CLEAR	0x01	/* clear that on revC */
 					/* while transmitting */
-#define ENE_CIR_CONF1_RX_ON	0x07	/* normal reciever enabled */
+#define ENE_CIR_CONF1_RX_ON	0x07	/* normal receiver enabled */
 #define ENE_CIR_CONF1_LEARN1	0x08	/* enabled on learning mode */
 #define ENE_CIR_CONF1_TX_ON	0x30	/* enabled on transmit */
 #define ENE_CIR_CONF1_TX_CARR	0x80	/* send TX carrier or not */
@@ -112,7 +111,7 @@
 /* Unknown TX setting - TX sample period ??? */
 #define ENE_TX_UNK1		0xFECB	/* set to 0x63 */
 
-/* Current recieved carrier period */
+/* Current received carrier period */
 #define ENE_RX_CARRIER		0xFECC	/* RX period (500 ns) */
 #define ENE_RX_CARRIER_VALID	0x80	/* Register content valid */
 
@@ -162,8 +161,7 @@
 
 /******************************************************************************/
 
-#define ENE_DRIVER_NAME		"enecir"
-#define ENE_TXBUF_SIZE (500 * sizeof(int))	/* 500 samples (arbitary) */
+#define ENE_DRIVER_NAME		"ene_ir"
 
 #define ENE_IRQ_RX		1
 #define ENE_IRQ_TX		2
@@ -188,7 +186,8 @@
 
 struct ene_device {
 	struct pnp_dev *pnp_dev;
-	struct lirc_driver *lirc_driver;
+	struct input_dev *idev;
+	struct ir_dev_props *props;
 	int in_use;
 
 	/* hw IO settings */
@@ -198,43 +197,35 @@ struct ene_device {
 
 	/* HW features */
 	int hw_revision;			/* hardware revision */
-	int hw_learning_and_tx_capable;		/* learning capable */
-	int hw_gpio40_learning;			/* gpio40 is learning */
-	int hw_fan_as_normal_input;		/* fan input is used as */
+	bool hw_learning_and_tx_capable;	/* learning capable */
+	bool hw_gpio40_learning;		/* gpio40 is learning */
+	bool hw_fan_as_normal_input;		/* fan input is used as */
 						/* regular input */
 	/* HW state*/
 	int rx_pointer;				/* hw pointer to rx buffer */
-	int rx_fan_input_inuse;			/* is fan input in use for rx*/
+	bool rx_fan_input_inuse;		/* is fan input in use for rx*/
 	int tx_reg;				/* current reg used for TX */
 	u8  saved_conf1;			/* saved FEC0 reg */
-	int learning_enabled;			/* learning input enabled */
-
-	/* RX sample handling */
-	int rx_sample;				/* current recieved sample */
-	int rx_sample_pulse;			/* recieved sample is pulse */
-	int rx_idle;				/* idle mode for RX activated */
-	struct timeval rx_gap_start;		/* time of start of idle */
-	int rx_timeout;				/* time in ms of RX timeout */
-	int rx_send_timeout_packet;		/* do we send RX timeout */
-	int rx_timeout_sent;			/* we sent the timeout packet */
-	int rx_carrier_sense;			/* sense carrier */
 
 	/* TX sample handling */
 	unsigned int tx_sample;			/* current sample for TX */
-	int tx_sample_pulse;			/* current sample is pulse */
+	bool tx_sample_pulse;			/* current sample is pulse */
 
 	/* TX buffer */
-	int tx_buffer[ENE_TXBUF_SIZE];		/* input samples buffer*/
+	int *tx_buffer;				/* input samples buffer*/
 	int tx_pos;				/* position in that bufer */
 	int tx_len;				/* current len of tx buffer */
-	int tx_underway;			/* TX is under way*/
 	int tx_done;				/* done transmitting */
 						/* one more sample pending*/
 	struct completion tx_complete;		/* TX completion */
 	struct timer_list tx_sim_timer;
 
-	/*TX settings */
+	/* TX settings */
 	int tx_period;
 	int tx_duty_cycle;
 	int transmitter_mask;
+
+	/* RX settings */
+	bool learning_enabled;			/* learning input enabled */
+	bool carrier_detect_enabled;		/* carrier detect enabled */
 };
-- 
1.7.0.4

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
<maximlevitsky@gmail.com> wrote:
> note that error_adjustment module option is added.
> This allows to reduce input samples by a percent.
> This makes input on my system more correct.
>
> Default is 4% as it works best here.
>
> Note that only normal input is adjusted. I don't know
> what adjustments to apply to fan tachometer input.
> Maybe it is accurate already.

Do you have the manual for the ENE chip in English? or do you read Chinese?

Maybe you can figure out why the readings are off by 4%. I suspect
that someone has set a clock divider wrong when programming the chip.
For example setting the divider for a 25Mhz clock when the clock is
actually 26Mhz would cause the error you are seeing. Or they just made
a mistake in computing the divisor. It is probably a bug in the BIOS
of your laptop.  If that's the case you could add a quirk in the
system boot code to fix the register setting.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Andy Walls]

On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
> On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
> <maximlevitsky@gmail.com> wrote:
> > note that error_adjustment module option is added.
> > This allows to reduce input samples by a percent.
> > This makes input on my system more correct.
> >
> > Default is 4% as it works best here.
> >
> > Note that only normal input is adjusted. I don't know
> > what adjustments to apply to fan tachometer input.
> > Maybe it is accurate already.
> 
> Do you have the manual for the ENE chip in English? or do you read Chinese?

The datasheet for a similar chip, the KB3700, is out there in English,
but it doesn't have CIR.

You might find these links mildly interesting:

http://www.coreboot.org/Embedded_controller
http://wiki.laptop.org/go/Embedded_controller
http://lists.laptop.org/pipermail/openec/2008-July/000108.html

Regards,
Andy

> Maybe you can figure out why the readings are off by 4%. I suspect
> that someone has set a clock divider wrong when programming the chip.
> For example setting the divider for a 25Mhz clock when the clock is
> actually 26Mhz would cause the error you are seeing. Or they just made
> a mistake in computing the divisor. It is probably a bug in the BIOS
> of your laptop.  If that's the case you could add a quirk in the
> system boot code to fix the register setting.
> 

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Maxim Levitsky]

On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote: 
> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
> > <maximlevitsky@gmail.com> wrote:
> > > note that error_adjustment module option is added.
> > > This allows to reduce input samples by a percent.
> > > This makes input on my system more correct.
> > >
> > > Default is 4% as it works best here.
> > >
> > > Note that only normal input is adjusted. I don't know
> > > what adjustments to apply to fan tachometer input.
> > > Maybe it is accurate already.
> > 
> > Do you have the manual for the ENE chip in English? or do you read Chinese?
> 
> The datasheet for a similar chip, the KB3700, is out there in English,
> but it doesn't have CIR.
> 
> You might find these links mildly interesting:
> 
> http://www.coreboot.org/Embedded_controller
> http://wiki.laptop.org/go/Embedded_controller
> http://lists.laptop.org/pipermail/openec/2008-July/000108.html

Nope, I have read that. 
> 
> Regards,
> Andy
> 
> > Maybe you can figure out why the readings are off by 4%. I suspect
> > that someone has set a clock divider wrong when programming the chip.
> > For example setting the divider for a 25Mhz clock when the clock is
> > actually 26Mhz would cause the error you are seeing. Or they just made
> > a mistake in computing the divisor. It is probably a bug in the BIOS
> > of your laptop.  If that's the case you could add a quirk in the
> > system boot code to fix the register setting.

I figured out how windows driver compensates for the offset, and do the
same in my driver. I think the problem is solved.


Best regards,
Maxim Levitsky

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
>> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
>> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
>> > <maximlevitsky@gmail.com> wrote:
>> > > note that error_adjustment module option is added.
>> > > This allows to reduce input samples by a percent.
>> > > This makes input on my system more correct.
>> > >
>> > > Default is 4% as it works best here.
>> > >
>> > > Note that only normal input is adjusted. I don't know
>> > > what adjustments to apply to fan tachometer input.
>> > > Maybe it is accurate already.
>> >
>> > Do you have the manual for the ENE chip in English? or do you read Chinese?
>>
>> The datasheet for a similar chip, the KB3700, is out there in English,
>> but it doesn't have CIR.
>>
>> You might find these links mildly interesting:
>>
>> http://www.coreboot.org/Embedded_controller
>> http://wiki.laptop.org/go/Embedded_controller
>> http://lists.laptop.org/pipermail/openec/2008-July/000108.html
>
> Nope, I have read that.
>>
>> Regards,
>> Andy
>>
>> > Maybe you can figure out why the readings are off by 4%. I suspect
>> > that someone has set a clock divider wrong when programming the chip.
>> > For example setting the divider for a 25Mhz clock when the clock is
>> > actually 26Mhz would cause the error you are seeing. Or they just made
>> > a mistake in computing the divisor. It is probably a bug in the BIOS
>> > of your laptop.  If that's the case you could add a quirk in the
>> > system boot code to fix the register setting.
>
> I figured out how windows driver compensates for the offset, and do the
> same in my driver. I think the problem is solved.
>

Should that be a <= or >= instead of !=?
+       if (pll_freq != 1000)

Programming the PLL wrong would cause the 4% error.

       hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
       old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);

+       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
+
+       if (pll_freq != 1000)
+               dev->rx_period_adjust = 4;
+       else
+               dev->rx_period_adjust = 2;
+
+
+       ene_printk(KERN_NOTICE, "PLL freq = %d\n", pll_freq);
+
       if (hw_revision == 0xFF) {



>
> Best regards,
> Maxim Levitsky
>
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
>> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
>> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
>> > <maximlevitsky@gmail.com> wrote:
>> > > note that error_adjustment module option is added.
>> > > This allows to reduce input samples by a percent.
>> > > This makes input on my system more correct.
>> > >
>> > > Default is 4% as it works best here.
>> > >
>> > > Note that only normal input is adjusted. I don't know
>> > > what adjustments to apply to fan tachometer input.
>> > > Maybe it is accurate already.
>> >
>> > Do you have the manual for the ENE chip in English? or do you read Chinese?
>>
>> The datasheet for a similar chip, the KB3700, is out there in English,
>> but it doesn't have CIR.
>>
>> You might find these links mildly interesting:
>>
>> http://www.coreboot.org/Embedded_controller
>> http://wiki.laptop.org/go/Embedded_controller
>> http://lists.laptop.org/pipermail/openec/2008-July/000108.html
>
> Nope, I have read that.
>>
>> Regards,
>> Andy
>>
>> > Maybe you can figure out why the readings are off by 4%. I suspect
>> > that someone has set a clock divider wrong when programming the chip.
>> > For example setting the divider for a 25Mhz clock when the clock is
>> > actually 26Mhz would cause the error you are seeing. Or they just made
>> > a mistake in computing the divisor. It is probably a bug in the BIOS
>> > of your laptop.  If that's the case you could add a quirk in the
>> > system boot code to fix the register setting.
>
> I figured out how windows driver compensates for the offset, and do the
> same in my driver. I think the problem is solved.
>

Should that be a <= or >= instead of !=?
+       if (pll_freq != 1000)

Programming the PLL wrong would cause the 4% error.

       hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
       old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);

+       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
+
+       if (pll_freq != 1000)
+               dev->rx_period_adjust = 4;
+       else
+               dev->rx_period_adjust = 2;
+
+
+       ene_printk(KERN_NOTICE, "PLL freq = %d\n", pll_freq);
+
       if (hw_revision == 0xFF) {



>
> Best regards,
> Maxim Levitsky
>
>



-- 
Jon Smirl
jonsmirl@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Maxim Levitsky]

On Fri, 2010-07-30 at 07:51 -0400, Jon Smirl wrote: 
> On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
> >> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
> >> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
> >> > <maximlevitsky@gmail.com> wrote:
> >> > > note that error_adjustment module option is added.
> >> > > This allows to reduce input samples by a percent.
> >> > > This makes input on my system more correct.
> >> > >
> >> > > Default is 4% as it works best here.
> >> > >
> >> > > Note that only normal input is adjusted. I don't know
> >> > > what adjustments to apply to fan tachometer input.
> >> > > Maybe it is accurate already.
> >> >
> >> > Do you have the manual for the ENE chip in English? or do you read Chinese?
> >>
> >> The datasheet for a similar chip, the KB3700, is out there in English,
> >> but it doesn't have CIR.
> >>
> >> You might find these links mildly interesting:
> >>
> >> http://www.coreboot.org/Embedded_controller
> >> http://wiki.laptop.org/go/Embedded_controller
> >> http://lists.laptop.org/pipermail/openec/2008-July/000108.html
> >
> > Nope, I have read that.
> >>
> >> Regards,
> >> Andy
> >>
> >> > Maybe you can figure out why the readings are off by 4%. I suspect
> >> > that someone has set a clock divider wrong when programming the chip.
> >> > For example setting the divider for a 25Mhz clock when the clock is
> >> > actually 26Mhz would cause the error you are seeing. Or they just made
> >> > a mistake in computing the divisor. It is probably a bug in the BIOS
> >> > of your laptop.  If that's the case you could add a quirk in the
> >> > system boot code to fix the register setting.
> >
> > I figured out how windows driver compensates for the offset, and do the
> > same in my driver. I think the problem is solved.
> >
> 
> Should that be a <= or >= instead of !=?
> +       if (pll_freq != 1000)

This is how its done in windows driver. 
> 
> Programming the PLL wrong would cause the 4% error.
> 
>        hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
>        old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
> 
> +       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
> +               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
> +
> +       if (pll_freq != 1000)
> +               dev->rx_period_adjust = 4;
> +       else
> +               dev->rx_period_adjust = 2;
> +
> +
> +       ene_printk(KERN_NOTICE, "PLL freq = %d\n", pll_freq);
> +
>        if (hw_revision == 0xFF) {
> 
> 
> 
> >
> > Best regards,
> > Maxim Levitsky
> >
> >
> 
> 
> 

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Fri, 2010-07-30 at 07:51 -0400, Jon Smirl wrote:
>> On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> > On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
>> >> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
>> >> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
>> >> > <maximlevitsky@gmail.com> wrote:
>> >> > > note that error_adjustment module option is added.
>> >> > > This allows to reduce input samples by a percent.
>> >> > > This makes input on my system more correct.
>> >> > >
>> >> > > Default is 4% as it works best here.
>> >> > >
>> >> > > Note that only normal input is adjusted. I don't know
>> >> > > what adjustments to apply to fan tachometer input.
>> >> > > Maybe it is accurate already.
>> >> >
>> >> > Do you have the manual for the ENE chip in English? or do you read Chinese?
>> >>
>> >> The datasheet for a similar chip, the KB3700, is out there in English,
>> >> but it doesn't have CIR.
>> >>
>> >> You might find these links mildly interesting:
>> >>
>> >> http://www.coreboot.org/Embedded_controller
>> >> http://wiki.laptop.org/go/Embedded_controller
>> >> http://lists.laptop.org/pipermail/openec/2008-July/000108.html
>> >
>> > Nope, I have read that.
>> >>
>> >> Regards,
>> >> Andy
>> >>
>> >> > Maybe you can figure out why the readings are off by 4%. I suspect
>> >> > that someone has set a clock divider wrong when programming the chip.
>> >> > For example setting the divider for a 25Mhz clock when the clock is
>> >> > actually 26Mhz would cause the error you are seeing. Or they just made
>> >> > a mistake in computing the divisor. It is probably a bug in the BIOS
>> >> > of your laptop.  If that's the case you could add a quirk in the
>> >> > system boot code to fix the register setting.
>> >
>> > I figured out how windows driver compensates for the offset, and do the
>> > same in my driver. I think the problem is solved.
>> >
>>
>> Should that be a <= or >= instead of !=?
>> +       if (pll_freq != 1000)
>
> This is how its done in windows driver.

That doesn't mean it is bug free.

Experimenting with changing the PLL frequency register may correct the
error.  Try taking 96% of pll_freq and write it back into these
register. This would be easy to fix with a manual. The root problem is
almost certainly a bug in the way the PLLs were programmed.

I don't like putting in fudge factors like the 4% correction. What
happens if a later version of the hardware has fixed firmware? I
normal user is never going to figure out that they need to change the
fudge factor.

+       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
+


>>
>> Programming the PLL wrong would cause the 4% error.
>>
>>        hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
>>        old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
>>
>> +       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
>> +               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
>> +
>> +       if (pll_freq != 1000)
>> +               dev->rx_period_adjust = 4;
>> +       else
>> +               dev->rx_period_adjust = 2;
>> +
>> +
>> +       ene_printk(KERN_NOTICE, "PLL freq = %d\n", pll_freq);
>> +
>>        if (hw_revision == 0xFF) {
>>
>>
>>
>> >
>> > Best regards,
>> > Maxim Levitsky
>> >
>> >
>>
>>
>>
>
>
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> On Fri, 2010-07-30 at 07:51 -0400, Jon Smirl wrote:
>>> On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>>> > On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
>>> >> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
>>> >> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
>>> >> > <maximlevitsky@gmail.com> wrote:
>>> >> > > note that error_adjustment module option is added.
>>> >> > > This allows to reduce input samples by a percent.
>>> >> > > This makes input on my system more correct.
>>> >> > >
>>> >> > > Default is 4% as it works best here.
>>> >> > >
>>> >> > > Note that only normal input is adjusted. I don't know
>>> >> > > what adjustments to apply to fan tachometer input.
>>> >> > > Maybe it is accurate already.
>>> >> >
>>> >> > Do you have the manual for the ENE chip in English? or do you read Chinese?
>>> >>
>>> >> The datasheet for a similar chip, the KB3700, is out there in English,
>>> >> but it doesn't have CIR.
>>> >>
>>> >> You might find these links mildly interesting:
>>> >>
>>> >> http://www.coreboot.org/Embedded_controller
>>> >> http://wiki.laptop.org/go/Embedded_controller
>>> >> http://lists.laptop.org/pipermail/openec/2008-July/000108.html
>>> >
>>> > Nope, I have read that.
>>> >>
>>> >> Regards,
>>> >> Andy
>>> >>
>>> >> > Maybe you can figure out why the readings are off by 4%. I suspect
>>> >> > that someone has set a clock divider wrong when programming the chip.
>>> >> > For example setting the divider for a 25Mhz clock when the clock is
>>> >> > actually 26Mhz would cause the error you are seeing. Or they just made
>>> >> > a mistake in computing the divisor. It is probably a bug in the BIOS
>>> >> > of your laptop.  If that's the case you could add a quirk in the
>>> >> > system boot code to fix the register setting.
>>> >
>>> > I figured out how windows driver compensates for the offset, and do the
>>> > same in my driver. I think the problem is solved.
>>> >
>>>
>>> Should that be a <= or >= instead of !=?
>>> +       if (pll_freq != 1000)
>>
>> This is how its done in windows driver.
>
> That doesn't mean it is bug free.
>
> Experimenting with changing the PLL frequency register may correct the
> error.  Try taking 96% of pll_freq and write it back into these
> register. This would be easy to fix with a manual. The root problem is
> almost certainly a bug in the way the PLLs were programmed.
>
> I don't like putting in fudge factors like the 4% correction. What
> happens if a later version of the hardware has fixed firmware? I
> normal user is never going to figure out that they need to change the
> fudge factor.
>
> +       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
> +               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);

I can understand the shift of the high bits, but that shift of the low
bits is unlikely.  A manual would tell us if it is right.


> +
>
>
>>>
>>> Programming the PLL wrong would cause the 4% error.
>>>
>>>        hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
>>>        old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
>>>
>>> +       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
>>> +               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
>>> +
>>> +       if (pll_freq != 1000)
>>> +               dev->rx_period_adjust = 4;
>>> +       else
>>> +               dev->rx_period_adjust = 2;
>>> +
>>> +
>>> +       ene_printk(KERN_NOTICE, "PLL freq = %d\n", pll_freq);
>>> +
>>>        if (hw_revision == 0xFF) {
>>>
>>>
>>>
>>> >
>>> > Best regards,
>>> > Maxim Levitsky
>>> >
>>> >
>>>
>>>
>>>
>>
>>
>>
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Maxim Levitsky]

On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote: 
> On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> >> On Fri, 2010-07-30 at 07:51 -0400, Jon Smirl wrote:
> >>> On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> >>> > On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
> >>> >> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
> >>> >> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
> >>> >> > <maximlevitsky@gmail.com> wrote:
> >>> >> > > note that error_adjustment module option is added.
> >>> >> > > This allows to reduce input samples by a percent.
> >>> >> > > This makes input on my system more correct.
> >>> >> > >
> >>> >> > > Default is 4% as it works best here.
> >>> >> > >
> >>> >> > > Note that only normal input is adjusted. I don't know
> >>> >> > > what adjustments to apply to fan tachometer input.
> >>> >> > > Maybe it is accurate already.
> >>> >> >
> >>> >> > Do you have the manual for the ENE chip in English? or do you read Chinese?
> >>> >>
> >>> >> The datasheet for a similar chip, the KB3700, is out there in English,
> >>> >> but it doesn't have CIR.
> >>> >>
> >>> >> You might find these links mildly interesting:
> >>> >>
> >>> >> http://www.coreboot.org/Embedded_controller
> >>> >> http://wiki.laptop.org/go/Embedded_controller
> >>> >> http://lists.laptop.org/pipermail/openec/2008-July/000108.html
> >>> >
> >>> > Nope, I have read that.
> >>> >>
> >>> >> Regards,
> >>> >> Andy
> >>> >>
> >>> >> > Maybe you can figure out why the readings are off by 4%. I suspect
> >>> >> > that someone has set a clock divider wrong when programming the chip.
> >>> >> > For example setting the divider for a 25Mhz clock when the clock is
> >>> >> > actually 26Mhz would cause the error you are seeing. Or they just made
> >>> >> > a mistake in computing the divisor. It is probably a bug in the BIOS
> >>> >> > of your laptop.  If that's the case you could add a quirk in the
> >>> >> > system boot code to fix the register setting.
> >>> >
> >>> > I figured out how windows driver compensates for the offset, and do the
> >>> > same in my driver. I think the problem is solved.
> >>> >
> >>>
> >>> Should that be a <= or >= instead of !=?
> >>> +       if (pll_freq != 1000)
> >>
> >> This is how its done in windows driver.
> >
> > That doesn't mean it is bug free.

This PLL frequency is likely to be chip internal frequency.
And windows driver doesn't touch it.
Its embedded controller, so I don't want to touch things I am not sure
about.

> >
> > Experimenting with changing the PLL frequency register may correct the
> > error.  Try taking 96% of pll_freq and write it back into these
> > register. This would be easy to fix with a manual. The root problem is
> > almost certainly a bug in the way the PLLs were programmed.
> >
> > I don't like putting in fudge factors like the 4% correction. What
> > happens if a later version of the hardware has fixed firmware? I
> > normal user is never going to figure out that they need to change the
> > fudge factor.
I don't think that is a hardware bug, rather a limitation.

Lets leave it as is.
I will soon publish the driver on launchpad or something like that and
try to contact users I debugged that driver with, and then see what
ranges PLL register takes.



> >
> > +       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
> > +               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
> 


> I can understand the shift of the high bits, but that shift of the low
> bits is unlikely.  A manual would tell us if it is right.
> 
This shift is correct (according to datasheet, which contains mostly
useless info, but it does dociment this reg briefly.)


Best regards,
Maxim Levitsky

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Andy Walls]

On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote:
> On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote: 
> > On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:

> 
> > >
> > > +       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
> > > +               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
> > 
> 
> 
> > I can understand the shift of the high bits, but that shift of the low
> > bits is unlikely.  A manual would tell us if it is right.
> > 
> This shift is correct (according to datasheet, which contains mostly
> useless info, but it does dociment this reg briefly.)

The KB3700 series datasheet indicates that the value from ENE_PLLFRL
should be shifted by >> 4 bits, not by >> 2.  Of course, the KB3700
isn't the exact same chip.

Regards,
Andy

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Maxim Levitsky]

On Sat, 2010-07-31 at 09:55 -0400, Andy Walls wrote: 
> On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote:
> > On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote: 
> > > On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> 
> > 
> > > >
> > > > +       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
> > > > +               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
> > > 
> > 
> > 
> > > I can understand the shift of the high bits, but that shift of the low
> > > bits is unlikely.  A manual would tell us if it is right.
> > > 
> > This shift is correct (according to datasheet, which contains mostly
> > useless info, but it does dociment this reg briefly.)
> 
> The KB3700 series datasheet indicates that the value from ENE_PLLFRL
> should be shifted by >> 4 bits, not by >> 2.  Of course, the KB3700
> isn't the exact same chip.
You are right about that, thanks!

Best regards,
Maxim Levitsky

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Sat, Jul 31, 2010 at 10:28 AM, Maxim Levitsky
<maximlevitsky@gmail.com> wrote:
> On Sat, 2010-07-31 at 09:55 -0400, Andy Walls wrote:
>> On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote:
>> > On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote:
>> > > On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> > > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>>
>> >
>> > > >
>> > > > +       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
>> > > > +               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
>> > >
>> >
>> >
>> > > I can understand the shift of the high bits, but that shift of the low
>> > > bits is unlikely.  A manual would tell us if it is right.
>> > >
>> > This shift is correct (according to datasheet, which contains mostly
>> > useless info, but it does dociment this reg briefly.)
>>
>> The KB3700 series datasheet indicates that the value from ENE_PLLFRL
>> should be shifted by >> 4 bits, not by >> 2.  Of course, the KB3700
>> isn't the exact same chip.
> You are right about that, thanks!

I looked at KB3700 manual. It says it is trying to make a 32Mhz clock
by multiplying 32.768Khz * 1000.

32,768 * 1000 = 32.768Mhz is a 2.4% error.

When you are computing the timings of the pulses did you assume a
32Mhz clock? It looks like the clock is actuall 32.768Mhz.


>
> Best regards,
> Maxim Levitsky
>
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Sat, Jul 31, 2010 at 10:28 AM, Maxim Levitsky
<maximlevitsky@gmail.com> wrote:
> On Sat, 2010-07-31 at 09:55 -0400, Andy Walls wrote:
>> On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote:
>> > On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote:
>> > > On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> > > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>>
>> >
>> > > >
>> > > > +       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
>> > > > +               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
>> > >
>> >
>> >
>> > > I can understand the shift of the high bits, but that shift of the low
>> > > bits is unlikely.  A manual would tell us if it is right.
>> > >
>> > This shift is correct (according to datasheet, which contains mostly
>> > useless info, but it does dociment this reg briefly.)
>>
>> The KB3700 series datasheet indicates that the value from ENE_PLLFRL
>> should be shifted by >> 4 bits, not by >> 2.  Of course, the KB3700
>> isn't the exact same chip.
> You are right about that, thanks!

I looked at KB3700 manual. It says it is trying to make a 32Mhz clock
by multiplying 32.768Khz * 1000.

32,768 * 1000 = 32.768Mhz is a 2.4% error.

When you are computing the timings of the pulses did you assume a
32Mhz clock? It looks like the clock is actuall 32.768Mhz.


>
> Best regards,
> Maxim Levitsky
>
>



-- 
Jon Smirl
jonsmirl@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Maxim Levitsky]

On Sat, 2010-07-31 at 10:37 -0400, Jon Smirl wrote: 
> On Sat, Jul 31, 2010 at 10:28 AM, Maxim Levitsky
> <maximlevitsky@gmail.com> wrote:
> > On Sat, 2010-07-31 at 09:55 -0400, Andy Walls wrote:
> >> On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote:
> >> > On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote:
> >> > > On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> >> > > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> >>
> >> >
> >> > > >
> >> > > > +       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
> >> > > > +               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
> >> > >
> >> >
> >> >
> >> > > I can understand the shift of the high bits, but that shift of the low
> >> > > bits is unlikely.  A manual would tell us if it is right.
> >> > >
> >> > This shift is correct (according to datasheet, which contains mostly
> >> > useless info, but it does dociment this reg briefly.)
> >>
> >> The KB3700 series datasheet indicates that the value from ENE_PLLFRL
> >> should be shifted by >> 4 bits, not by >> 2.  Of course, the KB3700
> >> isn't the exact same chip.
> > You are right about that, thanks!
> 
> I looked at KB3700 manual. It says it is trying to make a 32Mhz clock
> by multiplying 32.768Khz * 1000.
> 
> 32,768 * 1000 = 32.768Mhz is a 2.4% error.
> 
> When you are computing the timings of the pulses did you assume a
> 32Mhz clock? It looks like the clock is actuall 32.768Mhz.
No, I just take the samples hardware give me.
Lets just leave this as is.


Best regards,
Maxim Levitsky

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Andy Walls]

On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote:
> On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote: 
> > On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:

> > >>> >
> > >>>
> > >>> Should that be a <= or >= instead of !=?
> > >>> +       if (pll_freq != 1000)
> > >>
> > >> This is how its done in windows driver.
> > >
> > > That doesn't mean it is bug free.
> 
> This PLL frequency is likely to be chip internal frequency.
> And windows driver doesn't touch it.
> Its embedded controller, so I don't want to touch things I am not sure
> about.


The KB3700 datasheet states there are 4 clock domains in the chip.

One of the clock domains is a PLL LOW domain, used to clock
miscellaneous peripherials (which probably includes CIR on similar
chips).   The defualt for this clock appears to be 32.768 kHz clock
derived from a 32.768 MHz clock from which a 32.768 kHz clock is
derived.  It seems to be set up in the EC (ACPI 2.0 Embedded Controller)
register bank of the KB3700 chip.

That 1000 (0x3e8) is the default divider value to go from 32.768 MHz to
32.768 kHz.  I suspect it could be off by one - 0x3e7 might be the right
value - but that is only a 30 ns difference in the 30 us clock period.


So the check for 1000 by the Windows driver is likely a check for the
chip being in it's default configuration.  Looking at the CLKCFG2
register, the PLL can apparently output a 25 MHz clock instead of a
32.768 MHz clock.

While I'm looking at CLKCFG2, I note the default divider value of 0x1f
(31) for 1000 ns is wrong as well:

	32 / 32.768 MHz ~= 977 ns = 0.977 us   (-2.3%)

where as

	33 / 32.768 MHz ~= 1007 ns = 1.007 us  (+0.7%)

so the CLKCFG2 register programmed with 0x20 (32) would a better divisor
for a 1 us time period, if the functions in the chip can tolerate being
a little late vs. early.

I also read that the PLL reference comes from the LPC portion of the
chip which is the PCI clock domain.  So if a 33 MHz reference is used
instead of 32.768 MHz, then the default CLKCFG2 value yields this for a
nominal 1 us:

	32 / 33.333 MHz ~= 960 ns = 0.960 us   (-4.0%)
 





> > > Experimenting with changing the PLL frequency register may correct the
> > > error.  Try taking 96% of pll_freq and write it back into these
> > > register. This would be easy to fix with a manual. The root problem is
> > > almost certainly a bug in the way the PLLs were programmed.
> > >
> > > I don't like putting in fudge factors like the 4% correction. What
> > > happens if a later version of the hardware has fixed firmware? I
> > > normal user is never going to figure out that they need to change the
> > > fudge factor.
> I don't think that is a hardware bug, rather a limitation.
> 
> Lets leave it as is.
> I will soon publish the driver on launchpad or something like that and
> try to contact users I debugged that driver with, and then see what
> ranges PLL register takes.

I think you won't be able to fix the problem conclusively either way.  A
lot of how the chip's clocks should be programmed depends on how the
GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE,
but it won't be good in every case.  The wire-up of the ENE of various
motherboards is likely something you'll have to live with as unknowns.

This is a case where looser tolerances in the in kernel decoders could
reduce this driver's complexity and/or get rid of arbitrary fudge
factors in the driver.

Regards,
Andy

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> I think you won't be able to fix the problem conclusively either way.  A
> lot of how the chip's clocks should be programmed depends on how the
> GPIOs are used and what crystal is used.
>
> I suspect many designers will use some reference design layout from ENE,
> but it won't be good in every case.  The wire-up of the ENE of various
> motherboards is likely something you'll have to live with as unknowns.
>
> This is a case where looser tolerances in the in kernel decoders could
> reduce this driver's complexity and/or get rid of arbitrary fudge
> factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses
pulses that are 4% longer than JVC. The decoders allow errors up to 2%
(50% of 4%).  The crystals used in electronics are accurate to
0.0001%+.  The 4% error in this driver is because the hardware is not
being programmed accurately. This needs to be fixed in the driver and
not in the upper layers.

How is sample period being computed, where is the complete source to
this driver?

       dev->tx_period = 32;

Where is sample_period computed?

@@ -672,13 +583,25 @@ static irqreturn_t ene_isr(int irq, void *data)
                       pulse = !(hw_value & ENE_SAMPLE_SPC_MASK);
                       hw_value &= ENE_SAMPLE_VALUE_MASK;
                       hw_sample = hw_value * sample_period;
+
+                       if (dev->rx_period_adjust) {
+                               hw_sample *= (100 - dev->rx_period_adjust);
+                               hw_sample /= 100;
+                       }
               }

I suspect sample_period is set to 32us. For 32.768Mhz the period needs
to be 30.5us. I don't see the code for how it was computed.

You have to be careful with rounding errors when doing this type of
computation. What looks like a minor error can amplify into a large
error. Sometimes I do the math in 64b ints just to keep the round off
errors from accumulating.  Instead of doing the math in calculator and
plugging in 32. Use #defines and do the math in the code.

Maybe something like
#define sample_period  (1 / (32768 * 1000))

Then don't store this constant in a variable since it will cause a
round off. Just use it directly in the computation.

>
> Regards,
> Andy
>
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> I think you won't be able to fix the problem conclusively either way.  A
> lot of how the chip's clocks should be programmed depends on how the
> GPIOs are used and what crystal is used.
>
> I suspect many designers will use some reference design layout from ENE,
> but it won't be good in every case.  The wire-up of the ENE of various
> motherboards is likely something you'll have to live with as unknowns.
>
> This is a case where looser tolerances in the in kernel decoders could
> reduce this driver's complexity and/or get rid of arbitrary fudge
> factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses
pulses that are 4% longer than JVC. The decoders allow errors up to 2%
(50% of 4%).  The crystals used in electronics are accurate to
0.0001%+.  The 4% error in this driver is because the hardware is not
being programmed accurately. This needs to be fixed in the driver and
not in the upper layers.

How is sample period being computed, where is the complete source to
this driver?

       dev->tx_period = 32;

Where is sample_period computed?

@@ -672,13 +583,25 @@ static irqreturn_t ene_isr(int irq, void *data)
                       pulse = !(hw_value & ENE_SAMPLE_SPC_MASK);
                       hw_value &= ENE_SAMPLE_VALUE_MASK;
                       hw_sample = hw_value * sample_period;
+
+                       if (dev->rx_period_adjust) {
+                               hw_sample *= (100 - dev->rx_period_adjust);
+                               hw_sample /= 100;
+                       }
               }

I suspect sample_period is set to 32us. For 32.768Mhz the period needs
to be 30.5us. I don't see the code for how it was computed.

You have to be careful with rounding errors when doing this type of
computation. What looks like a minor error can amplify into a large
error. Sometimes I do the math in 64b ints just to keep the round off
errors from accumulating.  Instead of doing the math in calculator and
plugging in 32. Use #defines and do the math in the code.

Maybe something like
#define sample_period  (1 / (32768 * 1000))

Then don't store this constant in a variable since it will cause a
round off. Just use it directly in the computation.

>
> Regards,
> Andy
>
>



-- 
Jon Smirl
jonsmirl@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Maxim Levitsky]

On Sat, 2010-07-31 at 12:25 -0400, Jon Smirl wrote: 
> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> > I think you won't be able to fix the problem conclusively either way.  A
> > lot of how the chip's clocks should be programmed depends on how the
> > GPIOs are used and what crystal is used.
> >
> > I suspect many designers will use some reference design layout from ENE,
> > but it won't be good in every case.  The wire-up of the ENE of various
> > motherboards is likely something you'll have to live with as unknowns.
> >
> > This is a case where looser tolerances in the in kernel decoders could
> > reduce this driver's complexity and/or get rid of arbitrary fudge
> > factors in the driver.
> 
> The tolerances are as loose as they can be. The NEC protocol uses
> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
> (50% of 4%).  The crystals used in electronics are accurate to
> 0.0001%+.  The 4% error in this driver is because the hardware is not
> being programmed accurately. This needs to be fixed in the driver and
> not in the upper layers.

Let me explain again.

I get samples in 4 byte buffer. each sample is a count of sample
periods.
Sample period is programmed into hardware, at 'ENE_CIR_SAMPLE_PERIOD'
(it is in us)

Default sample period is 50 us.

The error source isn't 'electronics' fault.
The device is microprocessor.
I don't read the samples 'directly' from hardware, but rather from ram
of that microprocessor.
I don't know how it samples the input.
A expiration of sample period might just cause a IRQ inside that
microprocessor, and it can't process it instantly. That is probably the
source of the delay.
Or something like that.

Best regards,
Maxim Levitsky

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Maxim Levitsky]

On Sat, 2010-07-31 at 12:25 -0400, Jon Smirl wrote: 
> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> > I think you won't be able to fix the problem conclusively either way.  A
> > lot of how the chip's clocks should be programmed depends on how the
> > GPIOs are used and what crystal is used.
> >
> > I suspect many designers will use some reference design layout from ENE,
> > but it won't be good in every case.  The wire-up of the ENE of various
> > motherboards is likely something you'll have to live with as unknowns.
> >
> > This is a case where looser tolerances in the in kernel decoders could
> > reduce this driver's complexity and/or get rid of arbitrary fudge
> > factors in the driver.
> 
> The tolerances are as loose as they can be. The NEC protocol uses
> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
> (50% of 4%).  The crystals used in electronics are accurate to
> 0.0001%+.  The 4% error in this driver is because the hardware is not
> being programmed accurately. This needs to be fixed in the driver and
> not in the upper layers.
> 
> How is sample period being computed, where is the complete source to
> this driver?
> 
>        dev->tx_period = 32;
> 
> Where is sample_period computed?
> 
> @@ -672,13 +583,25 @@ static irqreturn_t ene_isr(int irq, void *data)
>                        pulse = !(hw_value & ENE_SAMPLE_SPC_MASK);
>                        hw_value &= ENE_SAMPLE_VALUE_MASK;
>                        hw_sample = hw_value * sample_period;
> +
> +                       if (dev->rx_period_adjust) {
> +                               hw_sample *= (100 - dev->rx_period_adjust);
> +                               hw_sample /= 100;
> +                       }
>                }
> 
> I suspect sample_period is set to 32us. For 32.768Mhz the period needs
> to be 30.5us. I don't see the code for how it was computed.
> 
> You have to be careful with rounding errors when doing this type of
> computation. What looks like a minor error can amplify into a large
> error. Sometimes I do the math in 64b ints just to keep the round off
> errors from accumulating.  Instead of doing the math in calculator and
> plugging in 32. Use #defines and do the math in the
There is no reason to worry about rounding here.

hw_sample is maximum of 127 * 50, so when I muliply by 100 I get exact
result.
Then I do one divide.

Best regards,
Maxim Levitsky

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Christoph Bartelmus]

Hi Jon,

on 31 Jul 10 at 12:25, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
> wrote:
>> I think you won't be able to fix the problem conclusively either way.  A
>> lot of how the chip's clocks should be programmed depends on how the
>> GPIOs are used and what crystal is used.
>>
>> I suspect many designers will use some reference design layout from ENE,
>> but it won't be good in every case.  The wire-up of the ENE of various
>> motherboards is likely something you'll have to live with as unknowns.
>>
>> This is a case where looser tolerances in the in kernel decoders could
>> reduce this driver's complexity and/or get rid of arbitrary fudge
>> factors in the driver.

> The tolerances are as loose as they can be. The NEC protocol uses
> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
> (50% of 4%).  The crystals used in electronics are accurate to
> 0.0001%+.

But the standard IR receivers are far from being accurate enough to allow
tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of
30% / 100 us and even this is not enough sometimes.

For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
If the receiver just misses one pulse, you already have an error of 1/22
> 4%.

Christoph

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Christoph Bartelmus]

Hi Jon,

on 31 Jul 10 at 12:25, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
> wrote:
>> I think you won't be able to fix the problem conclusively either way.  A
>> lot of how the chip's clocks should be programmed depends on how the
>> GPIOs are used and what crystal is used.
>>
>> I suspect many designers will use some reference design layout from ENE,
>> but it won't be good in every case.  The wire-up of the ENE of various
>> motherboards is likely something you'll have to live with as unknowns.
>>
>> This is a case where looser tolerances in the in kernel decoders could
>> reduce this driver's complexity and/or get rid of arbitrary fudge
>> factors in the driver.

> The tolerances are as loose as they can be. The NEC protocol uses
> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
> (50% of 4%).  The crystals used in electronics are accurate to
> 0.0001%+.

But the standard IR receivers are far from being accurate enough to allow
tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of
30% / 100 us and even this is not enough sometimes.

For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
If the receiver just misses one pulse, you already have an error of 1/22
> 4%.

Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> Hi Jon,
>
> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>> wrote:
>>> I think you won't be able to fix the problem conclusively either way.  A
>>> lot of how the chip's clocks should be programmed depends on how the
>>> GPIOs are used and what crystal is used.
>>>
>>> I suspect many designers will use some reference design layout from ENE,
>>> but it won't be good in every case.  The wire-up of the ENE of various
>>> motherboards is likely something you'll have to live with as unknowns.
>>>
>>> This is a case where looser tolerances in the in kernel decoders could
>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>> factors in the driver.
>
>> The tolerances are as loose as they can be. The NEC protocol uses
>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>> (50% of 4%).  The crystals used in electronics are accurate to
>> 0.0001%+.
>
> But the standard IR receivers are far from being accurate enough to allow
> tolerance windows of only 2%.
> I'm surprised that this works for you. LIRC uses a standard tolerance of
> 30% / 100 us and even this is not enough sometimes.
>
> For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
> If the receiver just misses one pulse, you already have an error of 1/22
>> 4%.

There are different types of errors. The decoders can take large
variations in bit times. The problem is with cumulative errors. In
this case the error had accumulated up to 450us in the lead pulse.
That's just too big of an error and caused the JVC code to be
misclassified as NEC.

I think he said lirc was misclassifying it too. So we both did the same thing.


>
> Christoph
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> Hi Jon,
>
> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>> wrote:
>>> I think you won't be able to fix the problem conclusively either way.  A
>>> lot of how the chip's clocks should be programmed depends on how the
>>> GPIOs are used and what crystal is used.
>>>
>>> I suspect many designers will use some reference design layout from ENE,
>>> but it won't be good in every case.  The wire-up of the ENE of various
>>> motherboards is likely something you'll have to live with as unknowns.
>>>
>>> This is a case where looser tolerances in the in kernel decoders could
>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>> factors in the driver.
>
>> The tolerances are as loose as they can be. The NEC protocol uses
>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>> (50% of 4%).  The crystals used in electronics are accurate to
>> 0.0001%+.
>
> But the standard IR receivers are far from being accurate enough to allow
> tolerance windows of only 2%.
> I'm surprised that this works for you. LIRC uses a standard tolerance of
> 30% / 100 us and even this is not enough sometimes.
>
> For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
> If the receiver just misses one pulse, you already have an error of 1/22
>> 4%.

There are different types of errors. The decoders can take large
variations in bit times. The problem is with cumulative errors. In
this case the error had accumulated up to 450us in the lead pulse.
That's just too big of an error and caused the JVC code to be
misclassified as NEC.

I think he said lirc was misclassifying it too. So we both did the same thing.


>
> Christoph
>



-- 
Jon Smirl
jonsmirl@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Sat, Jul 31, 2010 at 2:14 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>> wrote:
>>>> I think you won't be able to fix the problem conclusively either way.  A
>>>> lot of how the chip's clocks should be programmed depends on how the
>>>> GPIOs are used and what crystal is used.
>>>>
>>>> I suspect many designers will use some reference design layout from ENE,
>>>> but it won't be good in every case.  The wire-up of the ENE of various
>>>> motherboards is likely something you'll have to live with as unknowns.
>>>>
>>>> This is a case where looser tolerances in the in kernel decoders could
>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>> factors in the driver.
>>
>>> The tolerances are as loose as they can be. The NEC protocol uses
>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>> (50% of 4%).  The crystals used in electronics are accurate to
>>> 0.0001%+.
>>
>> But the standard IR receivers are far from being accurate enough to allow
>> tolerance windows of only 2%.
>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>> 30% / 100 us and even this is not enough sometimes.
>>
>> For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
>> If the receiver just misses one pulse, you already have an error of 1/22
>>> 4%.
>
> There are different types of errors. The decoders can take large
> variations in bit times. The problem is with cumulative errors. In
> this case the error had accumulated up to 450us in the lead pulse.
> That's just too big of an error and caused the JVC code to be
> misclassified as NEC.

I only see two solutions to this problem:

1) fix the driver to semi-accurately report correct measurements. A
consistent off by 4% error is simply too much since the NEC protocol
is a 4% stretched version of the JVC protocol. If the driver is
stretching JVC by 4% it has effectively converted it into a broken NEC
message. And that's what the decoders detected.  Given that the NEC
protocol is a 4% stretched JVC the largest safe timing variance is 2%
(half of 4%).  That 2% number is nothing to do with the code, it is
caused by the definitions of the JVC and NEC protocol timings.

2) Implement a record and match mode that knows nothing about
protocols. LIRC has this in the raw protocol. That would fix this
problem, but we're treating the symptom not the disease. The disease
is the broken IR driver.

I'd rather hold off on the raw protocol and try to fix the base IR
drivers first.


>
> I think he said lirc was misclassifying it too. So we both did the same thing.
>
>
>>
>> Christoph
>>
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Andy Walls]

On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> > Hi Jon,
> >
> > on 31 Jul 10 at 12:25, Jon Smirl wrote:
> >> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
> >> wrote:
> >>> I think you won't be able to fix the problem conclusively either way.  A
> >>> lot of how the chip's clocks should be programmed depends on how the
> >>> GPIOs are used and what crystal is used.
> >>>
> >>> I suspect many designers will use some reference design layout from ENE,
> >>> but it won't be good in every case.  The wire-up of the ENE of various
> >>> motherboards is likely something you'll have to live with as unknowns.
> >>>
> >>> This is a case where looser tolerances in the in kernel decoders could
> >>> reduce this driver's complexity and/or get rid of arbitrary fudge
> >>> factors in the driver.
> >
> >> The tolerances are as loose as they can be. The NEC protocol uses
> >> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
> >> (50% of 4%).  The crystals used in electronics are accurate to
> >> 0.0001%+.
> >
> > But the standard IR receivers are far from being accurate enough to allow
> > tolerance windows of only 2%.
> > I'm surprised that this works for you. LIRC uses a standard tolerance of
> > 30% / 100 us and even this is not enough sometimes.
> >
> > For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
> > If the receiver just misses one pulse, you already have an error of 1/22
> >> 4%.
> 
> There are different types of errors. The decoders can take large
> variations in bit times. The problem is with cumulative errors. In
> this case the error had accumulated up to 450us in the lead pulse.
> That's just too big of an error 

Hi Jon,

Hmmm.  Leader marks are, by protocol design, there to give time for the
receiver's AGC to settle.  We should make it OK to miss somewhat large
portions of leader marks.  I'm not sure what the harm is in accepting
too long of a leader mark, but I'm pretty sure a leader mark that is too
long will always be due to systematic error and not noise errors.

However, if we know we have systematic errors caused by unknowns, we
should be designing and imlpementing a decoding system that reasonably
deals with those systematic errors.  Again the part of the system almost
completely out of our control is the remote controls, and we *have no
control* over systematic errors introduced by remotes.

Obviously we want to reduce or elimiinate systematic errors by
determining the unknowns and undoing their effects or by compensating
for their overall effect.  But in the case of the ENE receiver driver,
you didn't seem to like the Maxim's software compensation for the
systematic receiver errors.


> and caused the JVC code to be
> misclassified as NEC.

I still have not heard why we need protocol discrimination/classifcation
in the kernel.  Doing discrimination between two protocols with such
close timings is whose requirement again?

Since these two protocols have such close timings that systematic errors
can cause misclassifcation when using simple mark or space measurments
against fixed thresholds, it indicates that a more sophisticated
discrimation mechanism would be needed.  Perhaps one that takes multiple
successive measurments into account?

Regards,
Andy

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
>> > Hi Jon,
>> >
>> > on 31 Jul 10 at 12:25, Jon Smirl wrote:
>> >> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>> >> wrote:
>> >>> I think you won't be able to fix the problem conclusively either way.  A
>> >>> lot of how the chip's clocks should be programmed depends on how the
>> >>> GPIOs are used and what crystal is used.
>> >>>
>> >>> I suspect many designers will use some reference design layout from ENE,
>> >>> but it won't be good in every case.  The wire-up of the ENE of various
>> >>> motherboards is likely something you'll have to live with as unknowns.
>> >>>
>> >>> This is a case where looser tolerances in the in kernel decoders could
>> >>> reduce this driver's complexity and/or get rid of arbitrary fudge
>> >>> factors in the driver.
>> >
>> >> The tolerances are as loose as they can be. The NEC protocol uses
>> >> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>> >> (50% of 4%).  The crystals used in electronics are accurate to
>> >> 0.0001%+.
>> >
>> > But the standard IR receivers are far from being accurate enough to allow
>> > tolerance windows of only 2%.
>> > I'm surprised that this works for you. LIRC uses a standard tolerance of
>> > 30% / 100 us and even this is not enough sometimes.
>> >
>> > For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
>> > If the receiver just misses one pulse, you already have an error of 1/22
>> >> 4%.
>>
>> There are different types of errors. The decoders can take large
>> variations in bit times. The problem is with cumulative errors. In
>> this case the error had accumulated up to 450us in the lead pulse.
>> That's just too big of an error
>
> Hi Jon,
>
> Hmmm.  Leader marks are, by protocol design, there to give time for the
> receiver's AGC to settle.  We should make it OK to miss somewhat large
> portions of leader marks.  I'm not sure what the harm is in accepting
> too long of a leader mark, but I'm pretty sure a leader mark that is too
> long will always be due to systematic error and not noise errors.
>
> However, if we know we have systematic errors caused by unknowns, we
> should be designing and implementing a decoding system that reasonably
> deals with those systematic errors.  Again the part of the system almost
> completely out of our control is the remote controls, and we *have no
> control* over systematic errors introduced by remotes.

We haven't encountered remotes with systematic errors. If remotes had
large errors in them they wouldn't be able to reliably control their
target devices. Find a remote that won't work with the protocol
engines and a reasonably accurate receiver.

>
> Obviously we want to reduce or eliminate systematic errors by
> determining the unknowns and undoing their effects or by compensating
> for their overall effect.  But in the case of the ENE receiver driver,
> you didn't seem to like the Maxim's software compensation for the
> systematic receiver errors.

I would be happier if we could track down the source of the error
instead of sticking a bandaid on at the end of the process.

>> and caused the JVC code to be
>> misclassified as NEC.
>
> I still have not heard why we need protocol discrimination/classifcation
> in the kernel.  Doing discrimination between two protocols with such
> close timings is whose requirement again?

If we don't do protocol engines we have to revert back to raw
recording and having everyone train the system with their remotes. The
goal is to eliminate the training step. We would also have to have
large files (LIRC configs) for building the keymaps and a new API to
deal with them. With the engines the key presses are identified by
short strings.

A use case: install mythtv, add an IR receiver. Myth UI says to set
your universal remote to a Motorola DVR profile. Remote works - no
training step needed.

LIRC has protocol engines too. irrecord first tries to fit the remote
into a protocol engine. If it can't it reverts to raw mode. Let's
analyze those cases where lirc ends up in raw mode and see if we can
figure out what's going wrong.

For example I know of two things that will trip up irrecord that are
fixed in the kernel system
1) the ene driver. we know now it had a 4% error in the reported periods
2) Sony remotes - they mix protocols on a single remote.

> Since these two protocols have such close timings that systematic errors
> can cause misclassification when using simple mark or space measurements
> against fixed thresholds, it indicates that a more sophisticated
> discrimination mechanism would be needed.  Perhaps one that takes multiple
> successive measurements into account?

If we get to the point where we need more sophisticated
classifications we can build it. But are we at that point yet? I'd
prefer to initially leave everything pretty strict as a way of
flushing out driver implementation bugs.

Find some remotes and receivers that break the current system.

>
> Regards,
> Andy
>
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
>> > Hi Jon,
>> >
>> > on 31 Jul 10 at 12:25, Jon Smirl wrote:
>> >> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>> >> wrote:
>> >>> I think you won't be able to fix the problem conclusively either way.  A
>> >>> lot of how the chip's clocks should be programmed depends on how the
>> >>> GPIOs are used and what crystal is used.
>> >>>
>> >>> I suspect many designers will use some reference design layout from ENE,
>> >>> but it won't be good in every case.  The wire-up of the ENE of various
>> >>> motherboards is likely something you'll have to live with as unknowns.
>> >>>
>> >>> This is a case where looser tolerances in the in kernel decoders could
>> >>> reduce this driver's complexity and/or get rid of arbitrary fudge
>> >>> factors in the driver.
>> >
>> >> The tolerances are as loose as they can be. The NEC protocol uses
>> >> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>> >> (50% of 4%).  The crystals used in electronics are accurate to
>> >> 0.0001%+.
>> >
>> > But the standard IR receivers are far from being accurate enough to allow
>> > tolerance windows of only 2%.
>> > I'm surprised that this works for you. LIRC uses a standard tolerance of
>> > 30% / 100 us and even this is not enough sometimes.
>> >
>> > For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
>> > If the receiver just misses one pulse, you already have an error of 1/22
>> >> 4%.
>>
>> There are different types of errors. The decoders can take large
>> variations in bit times. The problem is with cumulative errors. In
>> this case the error had accumulated up to 450us in the lead pulse.
>> That's just too big of an error
>
> Hi Jon,
>
> Hmmm.  Leader marks are, by protocol design, there to give time for the
> receiver's AGC to settle.  We should make it OK to miss somewhat large
> portions of leader marks.  I'm not sure what the harm is in accepting
> too long of a leader mark, but I'm pretty sure a leader mark that is too
> long will always be due to systematic error and not noise errors.
>
> However, if we know we have systematic errors caused by unknowns, we
> should be designing and implementing a decoding system that reasonably
> deals with those systematic errors.  Again the part of the system almost
> completely out of our control is the remote controls, and we *have no
> control* over systematic errors introduced by remotes.

We haven't encountered remotes with systematic errors. If remotes had
large errors in them they wouldn't be able to reliably control their
target devices. Find a remote that won't work with the protocol
engines and a reasonably accurate receiver.

>
> Obviously we want to reduce or eliminate systematic errors by
> determining the unknowns and undoing their effects or by compensating
> for their overall effect.  But in the case of the ENE receiver driver,
> you didn't seem to like the Maxim's software compensation for the
> systematic receiver errors.

I would be happier if we could track down the source of the error
instead of sticking a bandaid on at the end of the process.

>> and caused the JVC code to be
>> misclassified as NEC.
>
> I still have not heard why we need protocol discrimination/classifcation
> in the kernel.  Doing discrimination between two protocols with such
> close timings is whose requirement again?

If we don't do protocol engines we have to revert back to raw
recording and having everyone train the system with their remotes. The
goal is to eliminate the training step. We would also have to have
large files (LIRC configs) for building the keymaps and a new API to
deal with them. With the engines the key presses are identified by
short strings.

A use case: install mythtv, add an IR receiver. Myth UI says to set
your universal remote to a Motorola DVR profile. Remote works - no
training step needed.

LIRC has protocol engines too. irrecord first tries to fit the remote
into a protocol engine. If it can't it reverts to raw mode. Let's
analyze those cases where lirc ends up in raw mode and see if we can
figure out what's going wrong.

For example I know of two things that will trip up irrecord that are
fixed in the kernel system
1) the ene driver. we know now it had a 4% error in the reported periods
2) Sony remotes - they mix protocols on a single remote.

> Since these two protocols have such close timings that systematic errors
> can cause misclassification when using simple mark or space measurements
> against fixed thresholds, it indicates that a more sophisticated
> discrimination mechanism would be needed.  Perhaps one that takes multiple
> successive measurements into account?

If we get to the point where we need more sophisticated
classifications we can build it. But are we at that point yet? I'd
prefer to initially leave everything pretty strict as a way of
flushing out driver implementation bugs.

Find some remotes and receivers that break the current system.

>
> Regards,
> Andy
>
>



-- 
Jon Smirl
jonsmirl@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Maxim Levitsky]

On Sat, 2010-07-31 at 17:53 -0400, Jon Smirl wrote: 
> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> > On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote:
> >> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> >> > Hi Jon,
> >> >
> >> > on 31 Jul 10 at 12:25, Jon Smirl wrote:
> >> >> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
> >> >> wrote:
> >> >>> I think you won't be able to fix the problem conclusively either way.  A
> >> >>> lot of how the chip's clocks should be programmed depends on how the
> >> >>> GPIOs are used and what crystal is used.
> >> >>>
> >> >>> I suspect many designers will use some reference design layout from ENE,
> >> >>> but it won't be good in every case.  The wire-up of the ENE of various
> >> >>> motherboards is likely something you'll have to live with as unknowns.
> >> >>>
> >> >>> This is a case where looser tolerances in the in kernel decoders could
> >> >>> reduce this driver's complexity and/or get rid of arbitrary fudge
> >> >>> factors in the driver.
> >> >
> >> >> The tolerances are as loose as they can be. The NEC protocol uses
> >> >> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
> >> >> (50% of 4%).  The crystals used in electronics are accurate to
> >> >> 0.0001%+.
> >> >
> >> > But the standard IR receivers are far from being accurate enough to allow
> >> > tolerance windows of only 2%.
> >> > I'm surprised that this works for you. LIRC uses a standard tolerance of
> >> > 30% / 100 us and even this is not enough sometimes.
> >> >
> >> > For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
> >> > If the receiver just misses one pulse, you already have an error of 1/22
> >> >> 4%.
> >>
> >> There are different types of errors. The decoders can take large
> >> variations in bit times. The problem is with cumulative errors. In
> >> this case the error had accumulated up to 450us in the lead pulse.
> >> That's just too big of an error
> >
> > Hi Jon,
> >
> > Hmmm.  Leader marks are, by protocol design, there to give time for the
> > receiver's AGC to settle.  We should make it OK to miss somewhat large
> > portions of leader marks.  I'm not sure what the harm is in accepting
> > too long of a leader mark, but I'm pretty sure a leader mark that is too
> > long will always be due to systematic error and not noise errors.
> >
> > However, if we know we have systematic errors caused by unknowns, we
> > should be designing and implementing a decoding system that reasonably
> > deals with those systematic errors.  Again the part of the system almost
> > completely out of our control is the remote controls, and we *have no
> > control* over systematic errors introduced by remotes.
> 
> We haven't encountered remotes with systematic errors. If remotes had
> large errors in them they wouldn't be able to reliably control their
> target devices. Find a remote that won't work with the protocol
> engines and a reasonably accurate receiver.
> 
> >
> > Obviously we want to reduce or eliminate systematic errors by
> > determining the unknowns and undoing their effects or by compensating
> > for their overall effect.  But in the case of the ENE receiver driver,
> > you didn't seem to like the Maxim's software compensation for the
> > systematic receiver errors.
> 
> I would be happier if we could track down the source of the error
> instead of sticking a bandaid on at the end of the process.
This isn't a bandaid.
Windows driver programs the period to 52 but treats it as a 50.
(I don't do that because I set period to 75 - otherwise leading pulse of
NEC/JVC is almost missing. I know the reason for that, and it isn't
important).




> 
> >> and caused the JVC code to be
> >> misclassified as NEC.
> >
> > I still have not heard why we need protocol discrimination/classifcation
> > in the kernel.  Doing discrimination between two protocols with such
> > close timings is whose requirement again?
> 
> If we don't do protocol engines we have to revert back to raw
> recording and having everyone train the system with their remotes. The
> goal is to eliminate the training step. We would also have to have
> large files (LIRC configs) for building the keymaps and a new API to
> deal with them. With the engines the key presses are identified by
> short strings.
> 
> A use case: install mythtv, add an IR receiver. Myth UI says to set
> your universal remote to a Motorola DVR profile. Remote works - no
> training step needed.
> 
> LIRC has protocol engines too. irrecord first tries to fit the remote
> into a protocol engine. If it can't it reverts to raw mode. Let's
> analyze those cases where lirc ends up in raw mode and see if we can
> figure out what's going wrong.
> 
> For example I know of two things that will trip up irrecord that are
> fixed in the kernel system
> 1) the ene driver. we know now it had a 4% error in the reported periods
No it doesn't....
It even works if leading large pulse is missing.
I would never ever think of doing the adjustments, because lircds
tolerance is much better.


I am tired of this discussion.
My ENE receiver does work now, it gives correct samples, it applies same
adjustment, and thats all.
And thanks to my patches, the in-kernel decoding actually works well
with all protocols it supports.

Besides, main target is RC5/6 and it doesn't have long pulses,
therefore, it won't have that issue.



> 2) Sony remotes - they mix protocols on a single remote.


> 
> > Since these two protocols have such close timings that systematic errors
> > can cause misclassification when using simple mark or space measurements
> > against fixed thresholds, it indicates that a more sophisticated
> > discrimination mechanism would be needed.  Perhaps one that takes multiple
> > successive measurements into account?
> 
> If we get to the point where we need more sophisticated
> classifications we can build it. But are we at that point yet? I'd
> prefer to initially leave everything pretty strict as a way of
> flushing out driver implementation bugs.
> 
> Find some remotes and receivers that break the current system.
> 
> >
> > Regards,
> > Andy
> >
> >
> 
> 
> 

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Christoph Bartelmus]

Hi Jon,

on 31 Jul 10 at 17:53, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
>> On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
>>> wrote:
>>>> Hi Jon,
>>>>
>>>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>>>> wrote:
>>>>>> I think you won't be able to fix the problem conclusively either way..
>>>>>>  A lot of how the chip's clocks should be programmed depends on how the
>>>>>> GPIOs are used and what crystal is used.
>>>>>>
>>>>>> I suspect many designers will use some reference design layout from
>>>>>> ENE, but it won't be good in every case.  The wire-up of the ENE of
>>>>>> various motherboards is likely something you'll have to live with as
>>>>>> unknowns.
>>>>>>
>>>>>> This is a case where looser tolerances in the in kernel decoders could
>>>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>>>> factors in the driver.
>>>>
>>>>> The tolerances are as loose as they can be. The NEC protocol uses
>>>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>>>> (50% of 4%).  The crystals used in electronics are accurate to
>>>>> 0.0001%+.
>>>>
>>>> But the standard IR receivers are far from being accurate enough to allow
>>>> tolerance windows of only 2%.
>>>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>>>> 30% / 100 us and even this is not enough sometimes.
>>>>
>>>> For the NEC protocol one signal consists of 22 individual pulses at
>>>> 38kHz. If the receiver just misses one pulse, you already have an error
>>>> of 1/22
>>>>> 4%.
>>>
>>> There are different types of errors. The decoders can take large
>>> variations in bit times. The problem is with cumulative errors. In
>>> this case the error had accumulated up to 450us in the lead pulse.
>>> That's just too big of an error
>>
>> Hi Jon,
>>
>> Hmmm.  Leader marks are, by protocol design, there to give time for the
>> receiver's AGC to settle.  We should make it OK to miss somewhat large
>> portions of leader marks.  I'm not sure what the harm is in accepting
>> too long of a leader mark, but I'm pretty sure a leader mark that is too
>> long will always be due to systematic error and not noise errors.
>>
>> However, if we know we have systematic errors caused by unknowns, we
>> should be designing and implementing a decoding system that reasonably
>> deals with those systematic errors.  Again the part of the system almost
>> completely out of our control is the remote controls, and we *have no
>> control* over systematic errors introduced by remotes.

> We haven't encountered remotes with systematic errors. If remotes had
> large errors in them they wouldn't be able to reliably control their
> target devices. Find a remote that won't work with the protocol
> engines and a reasonably accurate receiver.

>>
>> Obviously we want to reduce or eliminate systematic errors by
>> determining the unknowns and undoing their effects or by compensating
>> for their overall effect.  But in the case of the ENE receiver driver,
>> you didn't seem to like the Maxim's software compensation for the
>> systematic receiver errors.

> I would be happier if we could track down the source of the error
> instead of sticking a bandaid on at the end of the process.

>>> and caused the JVC code to be
>>> misclassified as NEC.
>>
>> I still have not heard why we need protocol discrimination/classifcation
>> in the kernel.  Doing discrimination between two protocols with such
>> close timings is whose requirement again?

> If we don't do protocol engines we have to revert back to raw
> recording and having everyone train the system with their remotes. The
> goal is to eliminate the training step. We would also have to have
> large files (LIRC configs) for building the keymaps and a new API to
> deal with them. With the engines the key presses are identified by
> short strings.

Only 437 of 3486 config files on lirc.org use raw mode (probably what you  
mean with large files). Many of them are recorded with an very old  
irrecord version. Current versions of irrecord wouldn't create a raw mode  
config file for these remotes.

> A use case: install mythtv, add an IR receiver. Myth UI says to set
> your universal remote to a Motorola DVR profile. Remote works - no
> training step needed.

+ Myth UI reconfigures lircd with an existing Motorola DVR config file.
Where's the difference?

> LIRC has protocol engines too. irrecord first tries to fit the remote
> into a protocol engine.

With the sublte difference to your approach that LIRC does not make any  
assumptions on any timings in contrast to hardcoded values in the kernel.

> If it can't it reverts to raw mode. Let's
> analyze those cases where lirc ends up in raw mode and see if we can
> figure out what's going wrong.
>
> For example I know of two things that will trip up irrecord that are
> fixed in the kernel system
> 1) the ene driver. we know now it had a 4% error in the reported periods

Wrong.

> 2) Sony remotes - they mix protocols on a single remote.

This is a long known issue. I didn't care to fix it because in practice it  
does not matter.

>> Since these two protocols have such close timings that systematic errors
>> can cause misclassification when using simple mark or space measurements
>> against fixed thresholds, it indicates that a more sophisticated
>> discrimination mechanism would be needed.  Perhaps one that takes multiple
>> successive measurements into account?

> If we get to the point where we need more sophisticated
> classifications we can build it. But are we at that point yet? I'd
> prefer to initially leave everything pretty strict as a way of
> flushing out driver implementation bugs.
>
> Find some remotes and receivers that break the current system.

>>
>> Regards,
>> Andy
>>
>>


Christoph

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Christoph Bartelmus]

Hi Jon,

on 31 Jul 10 at 17:53, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
>> On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
>>> wrote:
>>>> Hi Jon,
>>>>
>>>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>>>> wrote:
>>>>>> I think you won't be able to fix the problem conclusively either way..
>>>>>>  A lot of how the chip's clocks should be programmed depends on how the
>>>>>> GPIOs are used and what crystal is used.
>>>>>>
>>>>>> I suspect many designers will use some reference design layout from
>>>>>> ENE, but it won't be good in every case.  The wire-up of the ENE of
>>>>>> various motherboards is likely something you'll have to live with as
>>>>>> unknowns.
>>>>>>
>>>>>> This is a case where looser tolerances in the in kernel decoders could
>>>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>>>> factors in the driver.
>>>>
>>>>> The tolerances are as loose as they can be. The NEC protocol uses
>>>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>>>> (50% of 4%).  The crystals used in electronics are accurate to
>>>>> 0.0001%+.
>>>>
>>>> But the standard IR receivers are far from being accurate enough to allow
>>>> tolerance windows of only 2%.
>>>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>>>> 30% / 100 us and even this is not enough sometimes.
>>>>
>>>> For the NEC protocol one signal consists of 22 individual pulses at
>>>> 38kHz. If the receiver just misses one pulse, you already have an error
>>>> of 1/22
>>>>> 4%.
>>>
>>> There are different types of errors. The decoders can take large
>>> variations in bit times. The problem is with cumulative errors. In
>>> this case the error had accumulated up to 450us in the lead pulse.
>>> That's just too big of an error
>>
>> Hi Jon,
>>
>> Hmmm.  Leader marks are, by protocol design, there to give time for the
>> receiver's AGC to settle.  We should make it OK to miss somewhat large
>> portions of leader marks.  I'm not sure what the harm is in accepting
>> too long of a leader mark, but I'm pretty sure a leader mark that is too
>> long will always be due to systematic error and not noise errors.
>>
>> However, if we know we have systematic errors caused by unknowns, we
>> should be designing and implementing a decoding system that reasonably
>> deals with those systematic errors.  Again the part of the system almost
>> completely out of our control is the remote controls, and we *have no
>> control* over systematic errors introduced by remotes.

> We haven't encountered remotes with systematic errors. If remotes had
> large errors in them they wouldn't be able to reliably control their
> target devices. Find a remote that won't work with the protocol
> engines and a reasonably accurate receiver.

>>
>> Obviously we want to reduce or eliminate systematic errors by
>> determining the unknowns and undoing their effects or by compensating
>> for their overall effect.  But in the case of the ENE receiver driver,
>> you didn't seem to like the Maxim's software compensation for the
>> systematic receiver errors.

> I would be happier if we could track down the source of the error
> instead of sticking a bandaid on at the end of the process.

>>> and caused the JVC code to be
>>> misclassified as NEC.
>>
>> I still have not heard why we need protocol discrimination/classifcation
>> in the kernel.  Doing discrimination between two protocols with such
>> close timings is whose requirement again?

> If we don't do protocol engines we have to revert back to raw
> recording and having everyone train the system with their remotes. The
> goal is to eliminate the training step. We would also have to have
> large files (LIRC configs) for building the keymaps and a new API to
> deal with them. With the engines the key presses are identified by
> short strings.

Only 437 of 3486 config files on lirc.org use raw mode (probably what you  
mean with large files). Many of them are recorded with an very old  
irrecord version. Current versions of irrecord wouldn't create a raw mode  
config file for these remotes.

> A use case: install mythtv, add an IR receiver. Myth UI says to set
> your universal remote to a Motorola DVR profile. Remote works - no
> training step needed.

+ Myth UI reconfigures lircd with an existing Motorola DVR config file.
Where's the difference?

> LIRC has protocol engines too. irrecord first tries to fit the remote
> into a protocol engine.

With the sublte difference to your approach that LIRC does not make any  
assumptions on any timings in contrast to hardcoded values in the kernel.

> If it can't it reverts to raw mode. Let's
> analyze those cases where lirc ends up in raw mode and see if we can
> figure out what's going wrong.
>
> For example I know of two things that will trip up irrecord that are
> fixed in the kernel system
> 1) the ene driver. we know now it had a 4% error in the reported periods

Wrong.

> 2) Sony remotes - they mix protocols on a single remote.

This is a long known issue. I didn't care to fix it because in practice it  
does not matter.

>> Since these two protocols have such close timings that systematic errors
>> can cause misclassification when using simple mark or space measurements
>> against fixed thresholds, it indicates that a more sophisticated
>> discrimination mechanism would be needed.  Perhaps one that takes multiple
>> successive measurements into account?

> If we get to the point where we need more sophisticated
> classifications we can build it. But are we at that point yet? I'd
> prefer to initially leave everything pretty strict as a way of
> flushing out driver implementation bugs.
>
> Find some remotes and receivers that break the current system.

>>
>> Regards,
>> Andy
>>
>>


Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Remote that breaks current system (was: IR: Port ene driver...) it.

[Jarod Wilson]

On Sat, Jul 31, 2010 at 05:53:33PM -0400, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
...
> > Since these two protocols have such close timings that systematic errors
> > can cause misclassification when using simple mark or space measurements
> > against fixed thresholds, it indicates that a more sophisticated
> > discrimination mechanism would be needed.  Perhaps one that takes multiple
> > successive measurements into account?
> 
> If we get to the point where we need more sophisticated
> classifications we can build it. But are we at that point yet? I'd
> prefer to initially leave everything pretty strict as a way of
> flushing out driver implementation bugs.
> 
> Find some remotes and receivers that break the current system.

Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
ported over the weekend, but this remote just won't decode correctly w/the
in-kernel RC5 decoder.

Working:
Streamzap receiver + RC6 (MCE) remote, in-kernel decoding
Streamzap receiver + RC5 (Streamzap) remote, lirc decoding

Not working:
Streamzap receiver + RC5 (Streamzap) remote, in-kernel decoding
MCE transceiver + RC5 (Streamzap) remote, in-kernel decoding

Failure mode is identical between the two, leading me to believe my
streamzap port is good to go, we just have an issue to track down with rc5
decoding.

Said failure mode is that RC5 fails at STATE_INACTIVE (0) with the initial
space provided by both receivers, then gets rolling with (I believe) the
first pulse. It then gets all the way to STATE_FINISHED, and bails,
because it should be on a space there, but its on a pulse.

I've twiddled the decoder to proceed even if its a pulse, but the
resulting decoding is still no good, as multiple adjacent keys (which have
proper decoded values that only differ by 1, per lirc decoding) get
decoded to the same value as one another.

Still poking around trying to figure out the problem, but here's what the
(slightly modified to not bail when it gets to STATE_FINISHED with a
pulse) rc5 decoder is seeing/doing:

ir_rc5_decode: RC5(x) decode started at state 0 (4292819813us space)
ir_rc5_decode: RC5(x) decode failed at state 0 (4292819813us space)
ir_rc5_decode: RC5(x) decode started at state 0 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (7us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 3 (7us pulse)
ir_rc5_decode: RC5(x) decode started at state 3 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 4 (1031us pulse)
ir_rc5_decode: RC5 usually ends w/space, wtf?
ir_rc5_decode: RC5 scancode 0x1129 (toggle: 0)
ir_getkeycode: unknown key for scancode 0x1129

This was for the OK button on the remote, which in lircd, decodes to
scancode 0x12 in the lower 6 bits, high 8 bits are 0xa3 for all buttons.
At least, I think I'm decoding lircd.conf correctly. See here to be sure:

http://lirc.sourceforge.net/remotes/streamzap/lircd.conf.streamzap

-- 
Jarod Wilson
jarod@redhat.com

Remote that breaks current system (was: IR: Port ene driver...) it.

[Jarod Wilson]

On Sat, Jul 31, 2010 at 05:53:33PM -0400, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
...
> > Since these two protocols have such close timings that systematic errors
> > can cause misclassification when using simple mark or space measurements
> > against fixed thresholds, it indicates that a more sophisticated
> > discrimination mechanism would be needed.  Perhaps one that takes multiple
> > successive measurements into account?
> 
> If we get to the point where we need more sophisticated
> classifications we can build it. But are we at that point yet? I'd
> prefer to initially leave everything pretty strict as a way of
> flushing out driver implementation bugs.
> 
> Find some remotes and receivers that break the current system.

Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
ported over the weekend, but this remote just won't decode correctly w/the
in-kernel RC5 decoder.

Working:
Streamzap receiver + RC6 (MCE) remote, in-kernel decoding
Streamzap receiver + RC5 (Streamzap) remote, lirc decoding

Not working:
Streamzap receiver + RC5 (Streamzap) remote, in-kernel decoding
MCE transceiver + RC5 (Streamzap) remote, in-kernel decoding

Failure mode is identical between the two, leading me to believe my
streamzap port is good to go, we just have an issue to track down with rc5
decoding.

Said failure mode is that RC5 fails at STATE_INACTIVE (0) with the initial
space provided by both receivers, then gets rolling with (I believe) the
first pulse. It then gets all the way to STATE_FINISHED, and bails,
because it should be on a space there, but its on a pulse.

I've twiddled the decoder to proceed even if its a pulse, but the
resulting decoding is still no good, as multiple adjacent keys (which have
proper decoded values that only differ by 1, per lirc decoding) get
decoded to the same value as one another.

Still poking around trying to figure out the problem, but here's what the
(slightly modified to not bail when it gets to STATE_FINISHED with a
pulse) rc5 decoder is seeing/doing:

ir_rc5_decode: RC5(x) decode started at state 0 (4292819813us space)
ir_rc5_decode: RC5(x) decode failed at state 0 (4292819813us space)
ir_rc5_decode: RC5(x) decode started at state 0 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (7us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 3 (7us pulse)
ir_rc5_decode: RC5(x) decode started at state 3 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 4 (1031us pulse)
ir_rc5_decode: RC5 usually ends w/space, wtf?
ir_rc5_decode: RC5 scancode 0x1129 (toggle: 0)
ir_getkeycode: unknown key for scancode 0x1129

This was for the OK button on the remote, which in lircd, decodes to
scancode 0x12 in the lower 6 bits, high 8 bits are 0xa3 for all buttons.
At least, I think I'm decoding lircd.conf correctly. See here to be sure:

http://lirc.sourceforge.net/remotes/streamzap/lircd.conf.streamzap

-- 
Jarod Wilson
jarod@redhat.com

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Remote that breaks current system (was: IR: Port ene driver...) it.

[Jon Smirl]

On Mon, Aug 2, 2010 at 11:12 AM, Jarod Wilson <jarod@redhat.com> wrote:
> On Sat, Jul 31, 2010 at 05:53:33PM -0400, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> ...
>> > Since these two protocols have such close timings that systematic errors
>> > can cause misclassification when using simple mark or space measurements
>> > against fixed thresholds, it indicates that a more sophisticated
>> > discrimination mechanism would be needed.  Perhaps one that takes multiple
>> > successive measurements into account?
>>
>> If we get to the point where we need more sophisticated
>> classifications we can build it. But are we at that point yet? I'd
>> prefer to initially leave everything pretty strict as a way of
>> flushing out driver implementation bugs.
>>
>> Find some remotes and receivers that break the current system.
>
> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
> ported over the weekend, but this remote just won't decode correctly w/the
> in-kernel RC5 decoder.

Manchester encoding may need a decoder that waits to get 2-3 edge
changes before deciding what the first bit. As you decode the output
is always a couple bits behind the current input data.

You can build of a table of states
L0 S1 S0 L1  - emit a 1, move forward an edge
S0 S1 L0 L1 - emit a 0, move forward an edge

By doing it that way you don't have to initially figure out the bit clock.

The current decoder code may not be properly tracking the leading
zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
off by 1/2 a bit cycle.

Did you note the comment that Extended RC-5 has only a single start
bit instead of two?

>
> Working:
> Streamzap receiver + RC6 (MCE) remote, in-kernel decoding
> Streamzap receiver + RC5 (Streamzap) remote, lirc decoding
>
> Not working:
> Streamzap receiver + RC5 (Streamzap) remote, in-kernel decoding
> MCE transceiver + RC5 (Streamzap) remote, in-kernel decoding
>
> Failure mode is identical between the two, leading me to believe my
> streamzap port is good to go, we just have an issue to track down with rc5
> decoding.
>
> Said failure mode is that RC5 fails at STATE_INACTIVE (0) with the initial
> space provided by both receivers, then gets rolling with (I believe) the
> first pulse. It then gets all the way to STATE_FINISHED, and bails,
> because it should be on a space there, but its on a pulse.
>
> I've twiddled the decoder to proceed even if its a pulse, but the
> resulting decoding is still no good, as multiple adjacent keys (which have
> proper decoded values that only differ by 1, per lirc decoding) get
> decoded to the same value as one another.
>
> Still poking around trying to figure out the problem, but here's what the
> (slightly modified to not bail when it gets to STATE_FINISHED with a
> pulse) rc5 decoder is seeing/doing:
>
> ir_rc5_decode: RC5(x) decode started at state 0 (4292819813us space)
> ir_rc5_decode: RC5(x) decode failed at state 0 (4292819813us space)
> ir_rc5_decode: RC5(x) decode started at state 0 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (7us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 3 (7us pulse)
> ir_rc5_decode: RC5(x) decode started at state 3 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
> ir_rc5_decode: RC5(x) decode started at state 4 (1031us pulse)
> ir_rc5_decode: RC5 usually ends w/space, wtf?
> ir_rc5_decode: RC5 scancode 0x1129 (toggle: 0)
> ir_getkeycode: unknown key for scancode 0x1129
>
> This was for the OK button on the remote, which in lircd, decodes to
> scancode 0x12 in the lower 6 bits, high 8 bits are 0xa3 for all buttons.
> At least, I think I'm decoding lircd.conf correctly. See here to be sure:
>
> http://lirc.sourceforge.net/remotes/streamzap/lircd.conf.streamzap
>
> --
> Jarod Wilson
> jarod@redhat.com
>
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: Remote that breaks current system

[Christoph Bartelmus]

Hi!

Jon Smirl "jonsmirl@gmail.com" wrote:
[...]
>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
>> ported over the weekend, but this remote just won't decode correctly w/the
>> in-kernel RC5 decoder.

> Manchester encoding may need a decoder that waits to get 2-3 edge
> changes before deciding what the first bit. As you decode the output
> is always a couple bits behind the current input data.
>
> You can build of a table of states
> L0 S1 S0 L1  - emit a 1, move forward an edge
> S0 S1 L0 L1 - emit a 0, move forward an edge
>
> By doing it that way you don't have to initially figure out the bit clock.
>
> The current decoder code may not be properly tracking the leading
> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
> off by 1/2 a bit cycle.
>
> Did you note the comment that Extended RC-5 has only a single start
> bit instead of two?

It has nothing to do with start bits.
The Streamzap remote just sends 14 (sic!) bits instead of 13.
The decoder expects 13 bits.
Yes, the Streamzap remote does _not_ use standard RC-5.
Did I mention this already? Yes. ;-)

Christoph

Re: Remote that breaks current system

[Christoph Bartelmus]

Hi!

Jon Smirl "jonsmirl@gmail.com" wrote:
[...]
>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
>> ported over the weekend, but this remote just won't decode correctly w/the
>> in-kernel RC5 decoder.

> Manchester encoding may need a decoder that waits to get 2-3 edge
> changes before deciding what the first bit. As you decode the output
> is always a couple bits behind the current input data.
>
> You can build of a table of states
> L0 S1 S0 L1  - emit a 1, move forward an edge
> S0 S1 L0 L1 - emit a 0, move forward an edge
>
> By doing it that way you don't have to initially figure out the bit clock.
>
> The current decoder code may not be properly tracking the leading
> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
> off by 1/2 a bit cycle.
>
> Did you note the comment that Extended RC-5 has only a single start
> bit instead of two?

It has nothing to do with start bits.
The Streamzap remote just sends 14 (sic!) bits instead of 13.
The decoder expects 13 bits.
Yes, the Streamzap remote does _not_ use standard RC-5.
Did I mention this already? Yes. ;-)

Christoph

Re: Remote that breaks current system

[Jon Smirl]

On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> Hi!
>
> Jon Smirl "jonsmirl@gmail.com" wrote:
> [...]
>>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
>>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
>>> ported over the weekend, but this remote just won't decode correctly w/the
>>> in-kernel RC5 decoder.
>
>> Manchester encoding may need a decoder that waits to get 2-3 edge
>> changes before deciding what the first bit. As you decode the output
>> is always a couple bits behind the current input data.
>>
>> You can build of a table of states
>> L0 S1 S0 L1  - emit a 1, move forward an edge
>> S0 S1 L0 L1 - emit a 0, move forward an edge
>>
>> By doing it that way you don't have to initially figure out the bit clock.
>>
>> The current decoder code may not be properly tracking the leading
>> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
>> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
>> off by 1/2 a bit cycle.
>>
>> Did you note the comment that Extended RC-5 has only a single start
>> bit instead of two?
>
> It has nothing to do with start bits.
> The Streamzap remote just sends 14 (sic!) bits instead of 13.
> The decoder expects 13 bits.
> Yes, the Streamzap remote does _not_ use standard RC-5.
> Did I mention this already? Yes. ;-)

If the remote is sending a weird protocol then there are several choices:
  1) implement raw mode
  2) make a Stream-Zap protocol engine (it would be a 14b version of
RC-5). Standard RC5 engine will still reject the messages.
  3) throw away your Stream-Zap remotes

I'd vote for #3, but #2 will probably make people happier.


>
> Christoph
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: Remote that breaks current system

[Jarod Wilson]

On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> > Hi!
> >
> > Jon Smirl "jonsmirl@gmail.com" wrote:
> > [...]
> >>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
> >>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
> >>> ported over the weekend, but this remote just won't decode correctly w/the
> >>> in-kernel RC5 decoder.
> >
> >> Manchester encoding may need a decoder that waits to get 2-3 edge
> >> changes before deciding what the first bit. As you decode the output
> >> is always a couple bits behind the current input data.
> >>
> >> You can build of a table of states
> >> L0 S1 S0 L1  - emit a 1, move forward an edge
> >> S0 S1 L0 L1 - emit a 0, move forward an edge
> >>
> >> By doing it that way you don't have to initially figure out the bit clock.
> >>
> >> The current decoder code may not be properly tracking the leading
> >> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
> >> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
> >> off by 1/2 a bit cycle.
> >>
> >> Did you note the comment that Extended RC-5 has only a single start
> >> bit instead of two?
> >
> > It has nothing to do with start bits.
> > The Streamzap remote just sends 14 (sic!) bits instead of 13.
> > The decoder expects 13 bits.
> > Yes, the Streamzap remote does _not_ use standard RC-5.
> > Did I mention this already? Yes. ;-)
> 
> If the remote is sending a weird protocol then there are several choices:
>   1) implement raw mode
>   2) make a Stream-Zap protocol engine (it would be a 14b version of
> RC-5). Standard RC5 engine will still reject the messages.
>   3) throw away your Stream-Zap remotes
> 
> I'd vote for #3, but #2 will probably make people happier.

Hm. Yeah, I know a few people who are quite attached to their Streamzap
remotes. I'm not a particularly big fan of it, I only got the thing off
ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
probably not the best route. But I don't know that I'm a huge fan of #2
either. Another decoder engine just for one quirky remote seems excessive,
and there's an option #4:

4) just keep passing data out to lirc by default.

Let lircd handle the default remote in this case. If you want to use
another remote that actually uses a standard protocol, and want to use
in-kernel decoding for that, its just an ir-keytable call away.

For giggles, I may tinker with implementing another decoder engine though,
if only to force myself to actually pay more attention to protocol
specifics. For the moment, I'm inclined to go ahead with the streamzap
port as it is right now, and include either an empty or not-empty, but
not-functional key table.

-- 
Jarod Wilson
jarod@redhat.com

Re: Remote that breaks current system

[Jarod Wilson]

On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> > Hi!
> >
> > Jon Smirl "jonsmirl@gmail.com" wrote:
> > [...]
> >>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
> >>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
> >>> ported over the weekend, but this remote just won't decode correctly w/the
> >>> in-kernel RC5 decoder.
> >
> >> Manchester encoding may need a decoder that waits to get 2-3 edge
> >> changes before deciding what the first bit. As you decode the output
> >> is always a couple bits behind the current input data.
> >>
> >> You can build of a table of states
> >> L0 S1 S0 L1  - emit a 1, move forward an edge
> >> S0 S1 L0 L1 - emit a 0, move forward an edge
> >>
> >> By doing it that way you don't have to initially figure out the bit clock.
> >>
> >> The current decoder code may not be properly tracking the leading
> >> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
> >> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
> >> off by 1/2 a bit cycle.
> >>
> >> Did you note the comment that Extended RC-5 has only a single start
> >> bit instead of two?
> >
> > It has nothing to do with start bits.
> > The Streamzap remote just sends 14 (sic!) bits instead of 13.
> > The decoder expects 13 bits.
> > Yes, the Streamzap remote does _not_ use standard RC-5.
> > Did I mention this already? Yes. ;-)
> 
> If the remote is sending a weird protocol then there are several choices:
>   1) implement raw mode
>   2) make a Stream-Zap protocol engine (it would be a 14b version of
> RC-5). Standard RC5 engine will still reject the messages.
>   3) throw away your Stream-Zap remotes
> 
> I'd vote for #3, but #2 will probably make people happier.

Hm. Yeah, I know a few people who are quite attached to their Streamzap
remotes. I'm not a particularly big fan of it, I only got the thing off
ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
probably not the best route. But I don't know that I'm a huge fan of #2
either. Another decoder engine just for one quirky remote seems excessive,
and there's an option #4:

4) just keep passing data out to lirc by default.

Let lircd handle the default remote in this case. If you want to use
another remote that actually uses a standard protocol, and want to use
in-kernel decoding for that, its just an ir-keytable call away.

For giggles, I may tinker with implementing another decoder engine though,
if only to force myself to actually pay more attention to protocol
specifics. For the moment, I'm inclined to go ahead with the streamzap
port as it is right now, and include either an empty or not-empty, but
not-functional key table.

-- 
Jarod Wilson
jarod@redhat.com

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Remote that breaks current system

[Jon Smirl]

On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson <jarod@redhat.com> wrote:
> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
>> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
>> > Hi!
>> >
>> > Jon Smirl "jonsmirl@gmail.com" wrote:
>> > [...]
>> >>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
>> >>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
>> >>> ported over the weekend, but this remote just won't decode correctly w/the
>> >>> in-kernel RC5 decoder.
>> >
>> >> Manchester encoding may need a decoder that waits to get 2-3 edge
>> >> changes before deciding what the first bit. As you decode the output
>> >> is always a couple bits behind the current input data.
>> >>
>> >> You can build of a table of states
>> >> L0 S1 S0 L1  - emit a 1, move forward an edge
>> >> S0 S1 L0 L1 - emit a 0, move forward an edge
>> >>
>> >> By doing it that way you don't have to initially figure out the bit clock.
>> >>
>> >> The current decoder code may not be properly tracking the leading
>> >> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
>> >> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
>> >> off by 1/2 a bit cycle.
>> >>
>> >> Did you note the comment that Extended RC-5 has only a single start
>> >> bit instead of two?
>> >
>> > It has nothing to do with start bits.
>> > The Streamzap remote just sends 14 (sic!) bits instead of 13.
>> > The decoder expects 13 bits.
>> > Yes, the Streamzap remote does _not_ use standard RC-5.
>> > Did I mention this already? Yes. ;-)
>>
>> If the remote is sending a weird protocol then there are several choices:
>>   1) implement raw mode
>>   2) make a Stream-Zap protocol engine (it would be a 14b version of
>> RC-5). Standard RC5 engine will still reject the messages.
>>   3) throw away your Stream-Zap remotes
>>
>> I'd vote for #3, but #2 will probably make people happier.
>
> Hm. Yeah, I know a few people who are quite attached to their Streamzap
> remotes. I'm not a particularly big fan of it, I only got the thing off
> ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
> probably not the best route. But I don't know that I'm a huge fan of #2
> either. Another decoder engine just for one quirky remote seems excessive,
> and there's an option #4:
>
> 4) just keep passing data out to lirc by default.

That's a decent idea. Implement the mainstream, standard protocols in
the kernel and kick the weird stuff out to LIRC. We can avoid the
whole world of raw mode, config files, etc. Let LIRC deal with all
that. If the weird stuff gets enough users bring it in-kernel.  Maybe
StreamZap will suddenly sell a million units, you never know.

It is easy to implement a StreamZap engine. Just copy the RC5 one.
Rename everything and adjust it to require one more bit. You'll have
to modify the RC5 to wait for a bit interval (timeout) before sending
the data up. If you want to get fancy use a weak symbol in the
StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then
you can decide to wait the extra bit interval or not.

> Let lircd handle the default remote in this case. If you want to use
> another remote that actually uses a standard protocol, and want to use
> in-kernel decoding for that, its just an ir-keytable call away.
>
> For giggles, I may tinker with implementing another decoder engine though,
> if only to force myself to actually pay more attention to protocol
> specifics. For the moment, I'm inclined to go ahead with the streamzap
> port as it is right now, and include either an empty or not-empty, but
> not-functional key table.
>
> --
> Jarod Wilson
> jarod@redhat.com
>
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: Remote that breaks current system

[Jon Smirl]

On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson <jarod@redhat.com> wrote:
> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
>> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
>> > Hi!
>> >
>> > Jon Smirl "jonsmirl@gmail.com" wrote:
>> > [...]
>> >>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
>> >>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
>> >>> ported over the weekend, but this remote just won't decode correctly w/the
>> >>> in-kernel RC5 decoder.
>> >
>> >> Manchester encoding may need a decoder that waits to get 2-3 edge
>> >> changes before deciding what the first bit. As you decode the output
>> >> is always a couple bits behind the current input data.
>> >>
>> >> You can build of a table of states
>> >> L0 S1 S0 L1  - emit a 1, move forward an edge
>> >> S0 S1 L0 L1 - emit a 0, move forward an edge
>> >>
>> >> By doing it that way you don't have to initially figure out the bit clock.
>> >>
>> >> The current decoder code may not be properly tracking the leading
>> >> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
>> >> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
>> >> off by 1/2 a bit cycle.
>> >>
>> >> Did you note the comment that Extended RC-5 has only a single start
>> >> bit instead of two?
>> >
>> > It has nothing to do with start bits.
>> > The Streamzap remote just sends 14 (sic!) bits instead of 13.
>> > The decoder expects 13 bits.
>> > Yes, the Streamzap remote does _not_ use standard RC-5.
>> > Did I mention this already? Yes. ;-)
>>
>> If the remote is sending a weird protocol then there are several choices:
>>   1) implement raw mode
>>   2) make a Stream-Zap protocol engine (it would be a 14b version of
>> RC-5). Standard RC5 engine will still reject the messages.
>>   3) throw away your Stream-Zap remotes
>>
>> I'd vote for #3, but #2 will probably make people happier.
>
> Hm. Yeah, I know a few people who are quite attached to their Streamzap
> remotes. I'm not a particularly big fan of it, I only got the thing off
> ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
> probably not the best route. But I don't know that I'm a huge fan of #2
> either. Another decoder engine just for one quirky remote seems excessive,
> and there's an option #4:
>
> 4) just keep passing data out to lirc by default.

That's a decent idea. Implement the mainstream, standard protocols in
the kernel and kick the weird stuff out to LIRC. We can avoid the
whole world of raw mode, config files, etc. Let LIRC deal with all
that. If the weird stuff gets enough users bring it in-kernel.  Maybe
StreamZap will suddenly sell a million units, you never know.

It is easy to implement a StreamZap engine. Just copy the RC5 one.
Rename everything and adjust it to require one more bit. You'll have
to modify the RC5 to wait for a bit interval (timeout) before sending
the data up. If you want to get fancy use a weak symbol in the
StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then
you can decide to wait the extra bit interval or not.

> Let lircd handle the default remote in this case. If you want to use
> another remote that actually uses a standard protocol, and want to use
> in-kernel decoding for that, its just an ir-keytable call away.
>
> For giggles, I may tinker with implementing another decoder engine though,
> if only to force myself to actually pay more attention to protocol
> specifics. For the moment, I'm inclined to go ahead with the streamzap
> port as it is right now, and include either an empty or not-empty, but
> not-functional key table.
>
> --
> Jarod Wilson
> jarod@redhat.com
>
>



-- 
Jon Smirl
jonsmirl@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Remote that breaks current system

[Jarod Wilson]

On Mon, Aug 2, 2010 at 4:42 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson <jarod@redhat.com> wrote:
>> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
>>> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
...
>>> > It has nothing to do with start bits.
>>> > The Streamzap remote just sends 14 (sic!) bits instead of 13.
>>> > The decoder expects 13 bits.
>>> > Yes, the Streamzap remote does _not_ use standard RC-5.
>>> > Did I mention this already? Yes. ;-)
>>>
>>> If the remote is sending a weird protocol then there are several choices:
>>>   1) implement raw mode
>>>   2) make a Stream-Zap protocol engine (it would be a 14b version of
>>> RC-5). Standard RC5 engine will still reject the messages.
>>>   3) throw away your Stream-Zap remotes
>>>
>>> I'd vote for #3, but #2 will probably make people happier.
>>
>> Hm. Yeah, I know a few people who are quite attached to their Streamzap
>> remotes. I'm not a particularly big fan of it, I only got the thing off
>> ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
>> probably not the best route. But I don't know that I'm a huge fan of #2
>> either. Another decoder engine just for one quirky remote seems excessive,
>> and there's an option #4:
>>
>> 4) just keep passing data out to lirc by default.
>
> That's a decent idea. Implement the mainstream, standard protocols in
> the kernel and kick the weird stuff out to LIRC. We can avoid the
> whole world of raw mode, config files, etc. Let LIRC deal with all
> that. If the weird stuff gets enough users bring it in-kernel.  Maybe
> StreamZap will suddenly sell a million units, you never know.
>
> It is easy to implement a StreamZap engine. Just copy the RC5 one.
> Rename everything and adjust it to require one more bit. You'll have
> to modify the RC5 to wait for a bit interval (timeout) before sending
> the data up. If you want to get fancy use a weak symbol in the
> StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then
> you can decide to wait the extra bit interval or not.

The other thought I had was to not load the engine by default, and
only auto-load it from the streamzap driver itself.

>> Let lircd handle the default remote in this case. If you want to use
>> another remote that actually uses a standard protocol, and want to use
>> in-kernel decoding for that, its just an ir-keytable call away.
>>
>> For giggles, I may tinker with implementing another decoder engine though,
>> if only to force myself to actually pay more attention to protocol
>> specifics. For the moment, I'm inclined to go ahead with the streamzap
>> port as it is right now, and include either an empty or not-empty, but
>> not-functional key table.

So I spent a while beating on things the past few nights for giggles
(and for a sanity break from "vacation" with too many kids...). I
ended up doing a rather large amount of somewhat invasive work to the
streamzap driver itself, but the end result is functional in-kernel
decoding, and lirc userspace decode continues to behave correctly. RFC
patch here:

http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch

Core changes to streamzap.c itself:

- had to enable reporting of a long space at the conclusion of each
signal (which is what the lirc driver would do w/timeout_enabled set),
otherwise I kept having issues with key bounce and/or old data being
buffered (i.e., press up, cursor moves up. push down, cursor moves up
then down, press left, it moves down, then left, etc.). Still not
quite sure what the real problem is there, the lirc userspace decoder
has no problems with it either way.

- removed streamzap's internal delay buffer, as the ir-core kfifo
seems to provide the necessary signal buffering just fine by itself.
Can't see any significant difference in decode performance either
in-kernel or via lirc with it removed, anyway. (Christoph, can you
perhaps expand a bit on why the delay buffer was originally needed/how
to reproduce the problem it was intended to solve? Maybe I'm just not
triggering it yet.)

Other fun stuff to note:

- currently, loading up an rc5-sz decoder unconditionally, have
considered only auto-loading it from the streamzap driver itself. Its
a copy of the rc5 decoder with relatively minor tweaks to deal with
the extra bit and resulting slightly different bit layout. Might
actually be possible to merge back into the rc5 decoder itself,
haven't really looked into that yet (should be entirely doable if
there's an easy way to figure out early on if we need to grab 15
bits).

- not sure the decoder is 100% correct, but it does get to the same
scancodes as the lirc userspace now (with both a streamzap and mceusb
receiver).

-- 
Jarod Wilson
jarod@wilsonet.com

Re: Remote that breaks current system

[Jarod Wilson]

On Mon, Aug 2, 2010 at 4:42 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson <jarod@redhat.com> wrote:
>> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
>>> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
...
>>> > It has nothing to do with start bits.
>>> > The Streamzap remote just sends 14 (sic!) bits instead of 13.
>>> > The decoder expects 13 bits.
>>> > Yes, the Streamzap remote does _not_ use standard RC-5.
>>> > Did I mention this already? Yes. ;-)
>>>
>>> If the remote is sending a weird protocol then there are several choices:
>>>   1) implement raw mode
>>>   2) make a Stream-Zap protocol engine (it would be a 14b version of
>>> RC-5). Standard RC5 engine will still reject the messages.
>>>   3) throw away your Stream-Zap remotes
>>>
>>> I'd vote for #3, but #2 will probably make people happier.
>>
>> Hm. Yeah, I know a few people who are quite attached to their Streamzap
>> remotes. I'm not a particularly big fan of it, I only got the thing off
>> ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
>> probably not the best route. But I don't know that I'm a huge fan of #2
>> either. Another decoder engine just for one quirky remote seems excessive,
>> and there's an option #4:
>>
>> 4) just keep passing data out to lirc by default.
>
> That's a decent idea. Implement the mainstream, standard protocols in
> the kernel and kick the weird stuff out to LIRC. We can avoid the
> whole world of raw mode, config files, etc. Let LIRC deal with all
> that. If the weird stuff gets enough users bring it in-kernel.  Maybe
> StreamZap will suddenly sell a million units, you never know.
>
> It is easy to implement a StreamZap engine. Just copy the RC5 one.
> Rename everything and adjust it to require one more bit. You'll have
> to modify the RC5 to wait for a bit interval (timeout) before sending
> the data up. If you want to get fancy use a weak symbol in the
> StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then
> you can decide to wait the extra bit interval or not.

The other thought I had was to not load the engine by default, and
only auto-load it from the streamzap driver itself.

>> Let lircd handle the default remote in this case. If you want to use
>> another remote that actually uses a standard protocol, and want to use
>> in-kernel decoding for that, its just an ir-keytable call away.
>>
>> For giggles, I may tinker with implementing another decoder engine though,
>> if only to force myself to actually pay more attention to protocol
>> specifics. For the moment, I'm inclined to go ahead with the streamzap
>> port as it is right now, and include either an empty or not-empty, but
>> not-functional key table.

So I spent a while beating on things the past few nights for giggles
(and for a sanity break from "vacation" with too many kids...). I
ended up doing a rather large amount of somewhat invasive work to the
streamzap driver itself, but the end result is functional in-kernel
decoding, and lirc userspace decode continues to behave correctly. RFC
patch here:

http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch

Core changes to streamzap.c itself:

- had to enable reporting of a long space at the conclusion of each
signal (which is what the lirc driver would do w/timeout_enabled set),
otherwise I kept having issues with key bounce and/or old data being
buffered (i.e., press up, cursor moves up. push down, cursor moves up
then down, press left, it moves down, then left, etc.). Still not
quite sure what the real problem is there, the lirc userspace decoder
has no problems with it either way.

- removed streamzap's internal delay buffer, as the ir-core kfifo
seems to provide the necessary signal buffering just fine by itself.
Can't see any significant difference in decode performance either
in-kernel or via lirc with it removed, anyway. (Christoph, can you
perhaps expand a bit on why the delay buffer was originally needed/how
to reproduce the problem it was intended to solve? Maybe I'm just not
triggering it yet.)

Other fun stuff to note:

- currently, loading up an rc5-sz decoder unconditionally, have
considered only auto-loading it from the streamzap driver itself. Its
a copy of the rc5 decoder with relatively minor tweaks to deal with
the extra bit and resulting slightly different bit layout. Might
actually be possible to merge back into the rc5 decoder itself,
haven't really looked into that yet (should be entirely doable if
there's an easy way to figure out early on if we need to grab 15
bits).

- not sure the decoder is 100% correct, but it does get to the same
scancodes as the lirc userspace now (with both a streamzap and mceusb
receiver).

-- 
Jarod Wilson
jarod@wilsonet.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Remote that breaks current system

[Christoph Bartelmus]

Hi Jarod,

on 11 Aug 10 at 10:38, Jarod Wilson wrote:
> On Mon, Aug 2, 2010 at 4:42 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson <jarod@redhat.com> wrote:
>>> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
>>>> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de>
>>>> wrote:
> ....
>>>>> It has nothing to do with start bits.
>>>>> The Streamzap remote just sends 14 (sic!) bits instead of 13.
>>>>> The decoder expects 13 bits.
>>>>> Yes, the Streamzap remote does _not_ use standard RC-5.
>>>>> Did I mention this already? Yes. ;-)
>>>>
>>>> If the remote is sending a weird protocol then there are several choices:
>>>>   1) implement raw mode
>>>>   2) make a Stream-Zap protocol engine (it would be a 14b version of
>>>> RC-5). Standard RC5 engine will still reject the messages.
>>>>   3) throw away your Stream-Zap remotes
>>>>
>>>> I'd vote for #3, but #2 will probably make people happier.
>>>
>>> Hm. Yeah, I know a few people who are quite attached to their Streamzap
>>> remotes. I'm not a particularly big fan of it, I only got the thing off
>>> ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
>>> probably not the best route. But I don't know that I'm a huge fan of #2
>>> either. Another decoder engine just for one quirky remote seems excessive,
>>> and there's an option #4:
>>>
>>> 4) just keep passing data out to lirc by default.
>>
>> That's a decent idea. Implement the mainstream, standard protocols in
>> the kernel and kick the weird stuff out to LIRC. We can avoid the
>> whole world of raw mode, config files, etc. Let LIRC deal with all
>> that. If the weird stuff gets enough users bring it in-kernel.  Maybe
>> StreamZap will suddenly sell a million units, you never know.
>>
>> It is easy to implement a StreamZap engine. Just copy the RC5 one.
>> Rename everything and adjust it to require one more bit. You'll have
>> to modify the RC5 to wait for a bit interval (timeout) before sending
>> the data up. If you want to get fancy use a weak symbol in the
>> StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then
>> you can decide to wait the extra bit interval or not.

> The other thought I had was to not load the engine by default, and
> only auto-load it from the streamzap driver itself.

>>> Let lircd handle the default remote in this case. If you want to use
>>> another remote that actually uses a standard protocol, and want to use
>>> in-kernel decoding for that, its just an ir-keytable call away.
>>>
>>> For giggles, I may tinker with implementing another decoder engine though,
>>> if only to force myself to actually pay more attention to protocol
>>> specifics. For the moment, I'm inclined to go ahead with the streamzap
>>> port as it is right now, and include either an empty or not-empty, but
>>> not-functional key table.

> So I spent a while beating on things the past few nights for giggles
> (and for a sanity break from "vacation" with too many kids...). I
> ended up doing a rather large amount of somewhat invasive work to the
> streamzap driver itself, but the end result is functional in-kernel
> decoding, and lirc userspace decode continues to behave correctly. RFC
> patch here:
>
> http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch
>
> Core changes to streamzap.c itself:
>
> - had to enable reporting of a long space at the conclusion of each
> signal (which is what the lirc driver would do w/timeout_enabled set),
> otherwise I kept having issues with key bounce and/or old data being
> buffered (i.e., press up, cursor moves up. push down, cursor moves up
> then down, press left, it moves down, then left, etc.). Still not
> quite sure what the real problem is there, the lirc userspace decoder
> has no problems with it either way.
>
> - removed streamzap's internal delay buffer, as the ir-core kfifo
> seems to provide the necessary signal buffering just fine by itself.
> Can't see any significant difference in decode performance either
> in-kernel or via lirc with it removed, anyway. (Christoph, can you
> perhaps expand a bit on why the delay buffer was originally needed/how
> to reproduce the problem it was intended to solve? Maybe I'm just not
> triggering it yet.)

Should be fine. Current lircd with timeout support shouldn't have a  
problem with that anymore. I was already thinking of suggesting to remove  
the delay buffer.

>
> Other fun stuff to note:
>
> - currently, loading up an rc5-sz decoder unconditionally, have
> considered only auto-loading it from the streamzap driver itself. Its
> a copy of the rc5 decoder with relatively minor tweaks to deal with
> the extra bit and resulting slightly different bit layout. Might
> actually be possible to merge back into the rc5 decoder itself,
> haven't really looked into that yet (should be entirely doable if
> there's an easy way to figure out early on if we need to grab 14
> bits).

There is no way until you see the 14th bit.

> - not sure the decoder is 100% correct, but it does get to the same
> scancodes as the lirc userspace now (with both a streamzap and mceusb
> receiver).

Christoph

Re: Remote that breaks current system

[Christoph Bartelmus]

Hi Jarod,

on 11 Aug 10 at 10:38, Jarod Wilson wrote:
> On Mon, Aug 2, 2010 at 4:42 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson <jarod@redhat.com> wrote:
>>> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
>>>> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de>
>>>> wrote:
> ....
>>>>> It has nothing to do with start bits.
>>>>> The Streamzap remote just sends 14 (sic!) bits instead of 13.
>>>>> The decoder expects 13 bits.
>>>>> Yes, the Streamzap remote does _not_ use standard RC-5.
>>>>> Did I mention this already? Yes. ;-)
>>>>
>>>> If the remote is sending a weird protocol then there are several choices:
>>>>   1) implement raw mode
>>>>   2) make a Stream-Zap protocol engine (it would be a 14b version of
>>>> RC-5). Standard RC5 engine will still reject the messages.
>>>>   3) throw away your Stream-Zap remotes
>>>>
>>>> I'd vote for #3, but #2 will probably make people happier.
>>>
>>> Hm. Yeah, I know a few people who are quite attached to their Streamzap
>>> remotes. I'm not a particularly big fan of it, I only got the thing off
>>> ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
>>> probably not the best route. But I don't know that I'm a huge fan of #2
>>> either. Another decoder engine just for one quirky remote seems excessive,
>>> and there's an option #4:
>>>
>>> 4) just keep passing data out to lirc by default.
>>
>> That's a decent idea. Implement the mainstream, standard protocols in
>> the kernel and kick the weird stuff out to LIRC. We can avoid the
>> whole world of raw mode, config files, etc. Let LIRC deal with all
>> that. If the weird stuff gets enough users bring it in-kernel.  Maybe
>> StreamZap will suddenly sell a million units, you never know.
>>
>> It is easy to implement a StreamZap engine. Just copy the RC5 one.
>> Rename everything and adjust it to require one more bit. You'll have
>> to modify the RC5 to wait for a bit interval (timeout) before sending
>> the data up. If you want to get fancy use a weak symbol in the
>> StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then
>> you can decide to wait the extra bit interval or not.

> The other thought I had was to not load the engine by default, and
> only auto-load it from the streamzap driver itself.

>>> Let lircd handle the default remote in this case. If you want to use
>>> another remote that actually uses a standard protocol, and want to use
>>> in-kernel decoding for that, its just an ir-keytable call away.
>>>
>>> For giggles, I may tinker with implementing another decoder engine though,
>>> if only to force myself to actually pay more attention to protocol
>>> specifics. For the moment, I'm inclined to go ahead with the streamzap
>>> port as it is right now, and include either an empty or not-empty, but
>>> not-functional key table.

> So I spent a while beating on things the past few nights for giggles
> (and for a sanity break from "vacation" with too many kids...). I
> ended up doing a rather large amount of somewhat invasive work to the
> streamzap driver itself, but the end result is functional in-kernel
> decoding, and lirc userspace decode continues to behave correctly. RFC
> patch here:
>
> http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch
>
> Core changes to streamzap.c itself:
>
> - had to enable reporting of a long space at the conclusion of each
> signal (which is what the lirc driver would do w/timeout_enabled set),
> otherwise I kept having issues with key bounce and/or old data being
> buffered (i.e., press up, cursor moves up. push down, cursor moves up
> then down, press left, it moves down, then left, etc.). Still not
> quite sure what the real problem is there, the lirc userspace decoder
> has no problems with it either way.
>
> - removed streamzap's internal delay buffer, as the ir-core kfifo
> seems to provide the necessary signal buffering just fine by itself.
> Can't see any significant difference in decode performance either
> in-kernel or via lirc with it removed, anyway. (Christoph, can you
> perhaps expand a bit on why the delay buffer was originally needed/how
> to reproduce the problem it was intended to solve? Maybe I'm just not
> triggering it yet.)

Should be fine. Current lircd with timeout support shouldn't have a  
problem with that anymore. I was already thinking of suggesting to remove  
the delay buffer.

>
> Other fun stuff to note:
>
> - currently, loading up an rc5-sz decoder unconditionally, have
> considered only auto-loading it from the streamzap driver itself. Its
> a copy of the rc5 decoder with relatively minor tweaks to deal with
> the extra bit and resulting slightly different bit layout. Might
> actually be possible to merge back into the rc5 decoder itself,
> haven't really looked into that yet (should be entirely doable if
> there's an easy way to figure out early on if we need to grab 14
> bits).

There is no way until you see the 14th bit.

> - not sure the decoder is 100% correct, but it does get to the same
> scancodes as the lirc userspace now (with both a streamzap and mceusb
> receiver).

Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Remote that breaks current system

[Jarod Wilson]

On Thu, Aug 12, 2010 at 2:46 AM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
...
>> So I spent a while beating on things the past few nights for giggles
>> (and for a sanity break from "vacation" with too many kids...). I
>> ended up doing a rather large amount of somewhat invasive work to the
>> streamzap driver itself, but the end result is functional in-kernel
>> decoding, and lirc userspace decode continues to behave correctly. RFC
>> patch here:
>>
>> http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch
>>
>> Core changes to streamzap.c itself:
>>
>> - had to enable reporting of a long space at the conclusion of each
>> signal (which is what the lirc driver would do w/timeout_enabled set),
>> otherwise I kept having issues with key bounce and/or old data being
>> buffered (i.e., press up, cursor moves up. push down, cursor moves up
>> then down, press left, it moves down, then left, etc.). Still not
>> quite sure what the real problem is there, the lirc userspace decoder
>> has no problems with it either way.
>>
>> - removed streamzap's internal delay buffer, as the ir-core kfifo
>> seems to provide the necessary signal buffering just fine by itself.
>> Can't see any significant difference in decode performance either
>> in-kernel or via lirc with it removed, anyway. (Christoph, can you
>> perhaps expand a bit on why the delay buffer was originally needed/how
>> to reproduce the problem it was intended to solve? Maybe I'm just not
>> triggering it yet.)
>
> Should be fine. Current lircd with timeout support shouldn't have a
> problem with that anymore. I was already thinking of suggesting to remove
> the delay buffer.

Cool, sounds like a plan then, I'll go ahead with it.

>> Other fun stuff to note:
>>
>> - currently, loading up an rc5-sz decoder unconditionally, have
>> considered only auto-loading it from the streamzap driver itself. Its
>> a copy of the rc5 decoder with relatively minor tweaks to deal with
>> the extra bit and resulting slightly different bit layout. Might
>> actually be possible to merge back into the rc5 decoder itself,
>> haven't really looked into that yet (should be entirely doable if
>> there's an easy way to figure out early on if we need to grab 14
>> bits).
>
> There is no way until you see the 14th bit.

Hm. Was afraid of that. I gave it a shot to see if I could make that
work, pretty shaky results. About 2/3 of the keys get decoded as
15-bit streamzap, the other 1/3 get decoded as 14-bit RC5, and don't
match anything in the keytable (and often duplicate one another). So
it looks like at least for the time being, a separate parallel decoder
is the way to go. I'm thinking that I like the approach of only
explicitly loading it from the streamzap driver though.

-- 
Jarod Wilson
jarod@wilsonet.com

Re: Remote that breaks current system

[Maxim Levitsky]

On Mon, 2010-08-16 at 00:04 -0400, Jarod Wilson wrote: 
> On Thu, Aug 12, 2010 at 2:46 AM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> ...
> >> So I spent a while beating on things the past few nights for giggles
> >> (and for a sanity break from "vacation" with too many kids...). I
> >> ended up doing a rather large amount of somewhat invasive work to the
> >> streamzap driver itself, but the end result is functional in-kernel
> >> decoding, and lirc userspace decode continues to behave correctly. RFC
> >> patch here:
> >>
> >> http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch
> >>
> >> Core changes to streamzap.c itself:
> >>
> >> - had to enable reporting of a long space at the conclusion of each
> >> signal (which is what the lirc driver would do w/timeout_enabled set),
> >> otherwise I kept having issues with key bounce and/or old data being
> >> buffered (i.e., press up, cursor moves up. push down, cursor moves up
> >> then down, press left, it moves down, then left, etc.). Still not
> >> quite sure what the real problem is there, the lirc userspace decoder
> >> has no problems with it either way.
> >>
> >> - removed streamzap's internal delay buffer, as the ir-core kfifo
> >> seems to provide the necessary signal buffering just fine by itself.
> >> Can't see any significant difference in decode performance either
> >> in-kernel or via lirc with it removed, anyway. (Christoph, can you
> >> perhaps expand a bit on why the delay buffer was originally needed/how
> >> to reproduce the problem it was intended to solve? Maybe I'm just not
> >> triggering it yet.)
> >
> > Should be fine. Current lircd with timeout support shouldn't have a
> > problem with that anymore. I was already thinking of suggesting to remove
> > the delay buffer.
> 
> Cool, sounds like a plan then, I'll go ahead with it.
> 
> >> Other fun stuff to note:
> >>
> >> - currently, loading up an rc5-sz decoder unconditionally, have
> >> considered only auto-loading it from the streamzap driver itself. Its
> >> a copy of the rc5 decoder with relatively minor tweaks to deal with
> >> the extra bit and resulting slightly different bit layout. Might
> >> actually be possible to merge back into the rc5 decoder itself,
> >> haven't really looked into that yet (should be entirely doable if
> >> there's an easy way to figure out early on if we need to grab 14
> >> bits).
> >
> > There is no way until you see the 14th bit.
> 
> Hm. Was afraid of that. I gave it a shot to see if I could make that
> work, pretty shaky results. About 2/3 of the keys get decoded as
> 15-bit streamzap, the other 1/3 get decoded as 14-bit RC5, and don't
> match anything in the keytable (and often duplicate one another). So
> it looks like at least for the time being, a separate parallel decoder
> is the way to go. I'm thinking that I like the approach of only
> explicitly loading it from the streamzap driver though.

Just one minor nitpick.
You could 'use' the original RC5 decoder, but add a knob to it to make
it accept 15 bits instead of 14.
However, this will require some interface changes.


Best regards,
Maxim Levitsky

Re: Remote that breaks current system

[Jarod Wilson]

On Mon, Aug 16, 2010 at 4:41 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Mon, 2010-08-16 at 00:04 -0400, Jarod Wilson wrote:
>> On Thu, Aug 12, 2010 at 2:46 AM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
>> ...
>> >> So I spent a while beating on things the past few nights for giggles
>> >> (and for a sanity break from "vacation" with too many kids...). I
>> >> ended up doing a rather large amount of somewhat invasive work to the
>> >> streamzap driver itself, but the end result is functional in-kernel
>> >> decoding, and lirc userspace decode continues to behave correctly. RFC
>> >> patch here:
>> >>
>> >> http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch
>> >>
>> >> Core changes to streamzap.c itself:
>> >>
>> >> - had to enable reporting of a long space at the conclusion of each
>> >> signal (which is what the lirc driver would do w/timeout_enabled set),
>> >> otherwise I kept having issues with key bounce and/or old data being
>> >> buffered (i.e., press up, cursor moves up. push down, cursor moves up
>> >> then down, press left, it moves down, then left, etc.). Still not
>> >> quite sure what the real problem is there, the lirc userspace decoder
>> >> has no problems with it either way.
>> >>
>> >> - removed streamzap's internal delay buffer, as the ir-core kfifo
>> >> seems to provide the necessary signal buffering just fine by itself.
>> >> Can't see any significant difference in decode performance either
>> >> in-kernel or via lirc with it removed, anyway. (Christoph, can you
>> >> perhaps expand a bit on why the delay buffer was originally needed/how
>> >> to reproduce the problem it was intended to solve? Maybe I'm just not
>> >> triggering it yet.)
>> >
>> > Should be fine. Current lircd with timeout support shouldn't have a
>> > problem with that anymore. I was already thinking of suggesting to remove
>> > the delay buffer.
>>
>> Cool, sounds like a plan then, I'll go ahead with it.
>>
>> >> Other fun stuff to note:
>> >>
>> >> - currently, loading up an rc5-sz decoder unconditionally, have
>> >> considered only auto-loading it from the streamzap driver itself. Its
>> >> a copy of the rc5 decoder with relatively minor tweaks to deal with
>> >> the extra bit and resulting slightly different bit layout. Might
>> >> actually be possible to merge back into the rc5 decoder itself,
>> >> haven't really looked into that yet (should be entirely doable if
>> >> there's an easy way to figure out early on if we need to grab 14
>> >> bits).
>> >
>> > There is no way until you see the 14th bit.
>>
>> Hm. Was afraid of that. I gave it a shot to see if I could make that
>> work, pretty shaky results. About 2/3 of the keys get decoded as
>> 15-bit streamzap, the other 1/3 get decoded as 14-bit RC5, and don't
>> match anything in the keytable (and often duplicate one another). So
>> it looks like at least for the time being, a separate parallel decoder
>> is the way to go. I'm thinking that I like the approach of only
>> explicitly loading it from the streamzap driver though.
>
> Just one minor nitpick.
> You could 'use' the original RC5 decoder, but add a knob to it to make
> it accept 15 bits instead of 14.
> However, this will require some interface changes.

Well, I think that still falls down if someone, for some reason, wants
to use both an old RC5 remote and the Streamzap remote at the same
time. I think a parallel decoder is probably the best situation for
the moment, as both 14-bit RC5 and Streamzap RC5 can be decoded
simultaneously.

-- 
Jarod Wilson
jarod@wilsonet.com

Re: Remote that breaks current system

[Mauro Carvalho Chehab]

Em 16-08-2010 21:14, Jarod Wilson escreveu:

>> Just one minor nitpick.
>> You could 'use' the original RC5 decoder, but add a knob to it to make
>> it accept 15 bits instead of 14.
>> However, this will require some interface changes.
> 
> Well, I think that still falls down if someone, for some reason, wants
> to use both an old RC5 remote and the Streamzap remote at the same
> time. I think a parallel decoder is probably the best situation for
> the moment, as both 14-bit RC5 and Streamzap RC5 can be decoded
> simultaneously.

One option could be to change rc5 decoder to work with 3 different modes,
controlled by a sysfs node:
1) just 14 bits code;
2) just 15 bits code;
3) both 14 and 15 bits code.

For (3), it will need a timeout logic for a short period (like 2T), for the
15th bit. If nothing happens, it will assume it is 14 bits, producing a code
and resetting the finite-state machine.

By default, it would be working on 14-bits mode for normal RC decoders, and
on 15-bits mode for Streamzap.

Yet, IMHO, the better is to commit what you have currently. Just my 2 cents.

Cheers,
Mauro.

Re: Remote that breaks current system

[Jarod Wilson]

On Mon, Aug 16, 2010 at 11:30 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 16-08-2010 21:14, Jarod Wilson escreveu:
>
>>> Just one minor nitpick.
>>> You could 'use' the original RC5 decoder, but add a knob to it to make
>>> it accept 15 bits instead of 14.
>>> However, this will require some interface changes.
>>
>> Well, I think that still falls down if someone, for some reason, wants
>> to use both an old RC5 remote and the Streamzap remote at the same
>> time. I think a parallel decoder is probably the best situation for
>> the moment, as both 14-bit RC5 and Streamzap RC5 can be decoded
>> simultaneously.
>
> One option could be to change rc5 decoder to work with 3 different modes,
> controlled by a sysfs node:
> 1) just 14 bits code;
> 2) just 15 bits code;
> 3) both 14 and 15 bits code.
>
> For (3), it will need a timeout logic for a short period (like 2T), for the
> 15th bit. If nothing happens, it will assume it is 14 bits, producing a code
> and resetting the finite-state machine.
>
> By default, it would be working on 14-bits mode for normal RC decoders, and
> on 15-bits mode for Streamzap.
>
> Yet, IMHO, the better is to commit what you have currently. Just my 2 cents.

Yeah, I don't doubt that we *could* come up with some way to make them
coexist in the same decoder, but I think its probably not worth the
effort or added complexity over simply having a separate parallel
decoder (which is only loaded by default if the receiver bundled with
the funky remote is plugged in).

-- 
Jarod Wilson
jarod@wilsonet.com

Re: Remote that breaks current system

[Jarod Wilson]

On Mon, Aug 02, 2010 at 06:42:00PM +0200, Christoph Bartelmus wrote:
> Hi!
> 
> Jon Smirl "jonsmirl@gmail.com" wrote:
> [...]
> >> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
> >> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
> >> ported over the weekend, but this remote just won't decode correctly w/the
> >> in-kernel RC5 decoder.
> 
> > Manchester encoding may need a decoder that waits to get 2-3 edge
> > changes before deciding what the first bit. As you decode the output
> > is always a couple bits behind the current input data.
> >
> > You can build of a table of states
> > L0 S1 S0 L1  - emit a 1, move forward an edge
> > S0 S1 L0 L1 - emit a 0, move forward an edge
> >
> > By doing it that way you don't have to initially figure out the bit clock.
> >
> > The current decoder code may not be properly tracking the leading
> > zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
> > They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
> > off by 1/2 a bit cycle.
> >
> > Did you note the comment that Extended RC-5 has only a single start
> > bit instead of two?
> 
> It has nothing to do with start bits.
> The Streamzap remote just sends 14 (sic!) bits instead of 13.
> The decoder expects 13 bits.
> Yes, the Streamzap remote does _not_ use standard RC-5.
> Did I mention this already? Yes. ;-)

D'oh, yeah, sorry, completely forgot you already mentioned this. That
would certainly explain why the rc5 decoder isn't happy with it. So the
*receiver* itself is perfectly functional, its just a goofy IR protocol
sent by its default remote. Blah. So yet another reason having ongoing
lirc compatibility is a Good Thing. ;)

-- 
Jarod Wilson
jarod@redhat.com

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Christoph Bartelmus]

Hi Jon,

on 31 Jul 10 at 14:14, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>> wrote:
>>>> I think you won't be able to fix the problem conclusively either way.  A
>>>> lot of how the chip's clocks should be programmed depends on how the
>>>> GPIOs are used and what crystal is used.
>>>>
>>>> I suspect many designers will use some reference design layout from ENE,
>>>> but it won't be good in every case.  The wire-up of the ENE of various
>>>> motherboards is likely something you'll have to live with as unknowns.
>>>>
>>>> This is a case where looser tolerances in the in kernel decoders could
>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>> factors in the driver.
>>
>>> The tolerances are as loose as they can be. The NEC protocol uses
>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>> (50% of 4%).  The crystals used in electronics are accurate to
>>> 0.0001%+.
>>
>> But the standard IR receivers are far from being accurate enough to allow
>> tolerance windows of only 2%.
>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>> 30% / 100 us and even this is not enough sometimes.
>>
>> For the NEC protocol one signal consists of 22 individual pulses at 38kHz..
>> If the receiver just misses one pulse, you already have an error of 1/22
>>> 4%.

> There are different types of errors. The decoders can take large
> variations in bit times. The problem is with cumulative errors. In
> this case the error had accumulated up to 450us in the lead pulse.
> That's just too big of an error and caused the JVC code to be
> misclassified as NEC.
>
> I think he said lirc was misclassifying it too. So we both did the same
> thing.

No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse  
JVC with NEC signals?

LIRC will work if there is a 4% or 40% or 400% error. Because irrecord  
generates the config file using your receiver it will compensate for any  
timing error. It will work with pulses cut down to 50 us like IrDA  
hardware does and it will work when half of the bits are swollowed like  
the IgorPlug USB receiver does.

But of course the driver should try to generate timings as accurate as  
possible.

Christoph

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Christoph Bartelmus]

Hi Jon,

on 31 Jul 10 at 14:14, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>> wrote:
>>>> I think you won't be able to fix the problem conclusively either way.  A
>>>> lot of how the chip's clocks should be programmed depends on how the
>>>> GPIOs are used and what crystal is used.
>>>>
>>>> I suspect many designers will use some reference design layout from ENE,
>>>> but it won't be good in every case.  The wire-up of the ENE of various
>>>> motherboards is likely something you'll have to live with as unknowns.
>>>>
>>>> This is a case where looser tolerances in the in kernel decoders could
>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>> factors in the driver.
>>
>>> The tolerances are as loose as they can be. The NEC protocol uses
>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>> (50% of 4%).  The crystals used in electronics are accurate to
>>> 0.0001%+.
>>
>> But the standard IR receivers are far from being accurate enough to allow
>> tolerance windows of only 2%.
>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>> 30% / 100 us and even this is not enough sometimes.
>>
>> For the NEC protocol one signal consists of 22 individual pulses at 38kHz..
>> If the receiver just misses one pulse, you already have an error of 1/22
>>> 4%.

> There are different types of errors. The decoders can take large
> variations in bit times. The problem is with cumulative errors. In
> this case the error had accumulated up to 450us in the lead pulse.
> That's just too big of an error and caused the JVC code to be
> misclassified as NEC.
>
> I think he said lirc was misclassifying it too. So we both did the same
> thing.

No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse  
JVC with NEC signals?

LIRC will work if there is a 4% or 40% or 400% error. Because irrecord  
generates the config file using your receiver it will compensate for any  
timing error. It will work with pulses cut down to 50 us like IrDA  
hardware does and it will work when half of the bits are swollowed like  
the IgorPlug USB receiver does.

But of course the driver should try to generate timings as accurate as  
possible.

Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> Hi Jon,
>
> on 31 Jul 10 at 14:14, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
>> wrote:
>>> Hi Jon,
>>>
>>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>>> wrote:
>>>>> I think you won't be able to fix the problem conclusively either way.  A
>>>>> lot of how the chip's clocks should be programmed depends on how the
>>>>> GPIOs are used and what crystal is used.
>>>>>
>>>>> I suspect many designers will use some reference design layout from ENE,
>>>>> but it won't be good in every case.  The wire-up of the ENE of various
>>>>> motherboards is likely something you'll have to live with as unknowns.
>>>>>
>>>>> This is a case where looser tolerances in the in kernel decoders could
>>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>>> factors in the driver.
>>>
>>>> The tolerances are as loose as they can be. The NEC protocol uses
>>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>>> (50% of 4%).  The crystals used in electronics are accurate to
>>>> 0.0001%+.
>>>
>>> But the standard IR receivers are far from being accurate enough to allow
>>> tolerance windows of only 2%.
>>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>>> 30% / 100 us and even this is not enough sometimes.
>>>
>>> For the NEC protocol one signal consists of 22 individual pulses at 38kHz..
>>> If the receiver just misses one pulse, you already have an error of 1/22
>>>> 4%.
>
>> There are different types of errors. The decoders can take large
>> variations in bit times. The problem is with cumulative errors. In
>> this case the error had accumulated up to 450us in the lead pulse.
>> That's just too big of an error and caused the JVC code to be
>> misclassified as NEC.
>>
>> I think he said lirc was misclassifying it too. So we both did the same
>> thing.
>
> No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse
> JVC with NEC signals?
>
> LIRC will work if there is a 4% or 40% or 400% error. Because irrecord
> generates the config file using your receiver it will compensate for any

At the end of the process we can build a record and match raw mode if
we have to.

> timing error. It will work with pulses cut down to 50 us like IrDA
> hardware does and it will work when half of the bits are swallowed like
> the IgorPlug USB receiver does.

The code for fixing IrDA and IgorPLug should live inside their low
level device drivers.  The characteristics of the errors produced by
this hardware are known so a fix can be written to compensate.  The
IgorPlug people might find it easier to fix their firmware. You don't
have to get the timing exactly right for the protocol engines to work,
you just need to get the big systematic errors out.

Before doing raw the low level IR drivers should be fixed to provide
the most accurate data possible. I don't think it is good design for a
low level driver to be injecting systematic errors and then have the
next layer of code remove them.  The source of the systematic errors
should be characterized and fixed in the low level driver. That also
allows the fixed to be constrained to fixing data from only a single
receiver type.

I have been burnt twice in the past from fixing errors in a low level
driver higher in the stack. I have learned the hard way that it is a
bad thing to do. As the fixes accumulate in the higher layers you will
reach a point where they conflict and no solution is possible. Bugs in
the low level drivers need to be fixed in that driver.

Show me a case that can't be fixed in the low level driver and we can
explore the options.

>
> But of course the driver should try to generate timings as accurate as
> possible.
>
> Christoph
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> Hi Jon,
>
> on 31 Jul 10 at 14:14, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
>> wrote:
>>> Hi Jon,
>>>
>>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>>> wrote:
>>>>> I think you won't be able to fix the problem conclusively either way.  A
>>>>> lot of how the chip's clocks should be programmed depends on how the
>>>>> GPIOs are used and what crystal is used.
>>>>>
>>>>> I suspect many designers will use some reference design layout from ENE,
>>>>> but it won't be good in every case.  The wire-up of the ENE of various
>>>>> motherboards is likely something you'll have to live with as unknowns.
>>>>>
>>>>> This is a case where looser tolerances in the in kernel decoders could
>>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>>> factors in the driver.
>>>
>>>> The tolerances are as loose as they can be. The NEC protocol uses
>>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>>> (50% of 4%).  The crystals used in electronics are accurate to
>>>> 0.0001%+.
>>>
>>> But the standard IR receivers are far from being accurate enough to allow
>>> tolerance windows of only 2%.
>>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>>> 30% / 100 us and even this is not enough sometimes.
>>>
>>> For the NEC protocol one signal consists of 22 individual pulses at 38kHz..
>>> If the receiver just misses one pulse, you already have an error of 1/22
>>>> 4%.
>
>> There are different types of errors. The decoders can take large
>> variations in bit times. The problem is with cumulative errors. In
>> this case the error had accumulated up to 450us in the lead pulse.
>> That's just too big of an error and caused the JVC code to be
>> misclassified as NEC.
>>
>> I think he said lirc was misclassifying it too. So we both did the same
>> thing.
>
> No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse
> JVC with NEC signals?
>
> LIRC will work if there is a 4% or 40% or 400% error. Because irrecord
> generates the config file using your receiver it will compensate for any

At the end of the process we can build a record and match raw mode if
we have to.

> timing error. It will work with pulses cut down to 50 us like IrDA
> hardware does and it will work when half of the bits are swallowed like
> the IgorPlug USB receiver does.

The code for fixing IrDA and IgorPLug should live inside their low
level device drivers.  The characteristics of the errors produced by
this hardware are known so a fix can be written to compensate.  The
IgorPlug people might find it easier to fix their firmware. You don't
have to get the timing exactly right for the protocol engines to work,
you just need to get the big systematic errors out.

Before doing raw the low level IR drivers should be fixed to provide
the most accurate data possible. I don't think it is good design for a
low level driver to be injecting systematic errors and then have the
next layer of code remove them.  The source of the systematic errors
should be characterized and fixed in the low level driver. That also
allows the fixed to be constrained to fixing data from only a single
receiver type.

I have been burnt twice in the past from fixing errors in a low level
driver higher in the stack. I have learned the hard way that it is a
bad thing to do. As the fixes accumulate in the higher layers you will
reach a point where they conflict and no solution is possible. Bugs in
the low level drivers need to be fixed in that driver.

Show me a case that can't be fixed in the low level driver and we can
explore the options.

>
> But of course the driver should try to generate timings as accurate as
> possible.
>
> Christoph
>



-- 
Jon Smirl
jonsmirl@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Jon Smirl]

On Sun, Aug 1, 2010 at 10:00 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 14:14, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
>>> wrote:
>>>> Hi Jon,
>>>>
>>>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>>>> wrote:
>>>>>> I think you won't be able to fix the problem conclusively either way.  A
>>>>>> lot of how the chip's clocks should be programmed depends on how the
>>>>>> GPIOs are used and what crystal is used.
>>>>>>
>>>>>> I suspect many designers will use some reference design layout from ENE,
>>>>>> but it won't be good in every case.  The wire-up of the ENE of various
>>>>>> motherboards is likely something you'll have to live with as unknowns.
>>>>>>
>>>>>> This is a case where looser tolerances in the in kernel decoders could
>>>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>>>> factors in the driver.
>>>>
>>>>> The tolerances are as loose as they can be. The NEC protocol uses
>>>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>>>> (50% of 4%).  The crystals used in electronics are accurate to
>>>>> 0.0001%+.
>>>>
>>>> But the standard IR receivers are far from being accurate enough to allow
>>>> tolerance windows of only 2%.
>>>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>>>> 30% / 100 us and even this is not enough sometimes.
>>>>
>>>> For the NEC protocol one signal consists of 22 individual pulses at 38kHz..
>>>> If the receiver just misses one pulse, you already have an error of 1/22
>>>>> 4%.
>>
>>> There are different types of errors. The decoders can take large
>>> variations in bit times. The problem is with cumulative errors. In
>>> this case the error had accumulated up to 450us in the lead pulse.
>>> That's just too big of an error and caused the JVC code to be
>>> misclassified as NEC.
>>>
>>> I think he said lirc was misclassifying it too. So we both did the same
>>> thing.
>>
>> No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse
>> JVC with NEC signals?
>>
>> LIRC will work if there is a 4% or 40% or 400% error. Because irrecord
>> generates the config file using your receiver it will compensate for any
>
> At the end of the process we can build a record and match raw mode if
> we have to.
>
>> timing error. It will work with pulses cut down to 50 us like IrDA
>> hardware does and it will work when half of the bits are swallowed like
>> the IgorPlug USB receiver does.
>
> The code for fixing IrDA and IgorPLug should live inside their low
> level device drivers.  The characteristics of the errors produced by
> this hardware are known so a fix can be written to compensate.  The
> IgorPlug people might find it easier to fix their firmware. You don't
> have to get the timing exactly right for the protocol engines to work,
> you just need to get the big systematic errors out.

There is a real benefit to strict protocol engines. If the IgorPlus
people had strict protocol engines to test against they would have
discovered their firmware bugs during the initial development process.

>
> Before doing raw the low level IR drivers should be fixed to provide
> the most accurate data possible. I don't think it is good design for a
> low level driver to be injecting systematic errors and then have the
> next layer of code remove them.  The source of the systematic errors
> should be characterized and fixed in the low level driver. That also
> allows the fixed to be constrained to fixing data from only a single
> receiver type.
>
> I have been burnt twice in the past from fixing errors in a low level
> driver higher in the stack. I have learned the hard way that it is a
> bad thing to do. As the fixes accumulate in the higher layers you will
> reach a point where they conflict and no solution is possible. Bugs in
> the low level drivers need to be fixed in that driver.
>
> Show me a case that can't be fixed in the low level driver and we can
> explore the options.
>
>>
>> But of course the driver should try to generate timings as accurate as
>> possible.
>>
>> Christoph
>>
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Christoph Bartelmus]

Hi!

Jon Smirl "jonsmirl@gmail.com" wrote:

> On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus <lirc@bartelmus.de>
> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 14:14, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
>>> wrote:
>>>> Hi Jon,
>>>>
>>>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>>>> wrote:
>>>>>> I think you won't be able to fix the problem conclusively either way.
>>>>>>  A lot of how the chip's clocks should be programmed depends on how the
>>>>>> GPIOs are used and what crystal is used.
>>>>>>
>>>>>> I suspect many designers will use some reference design layout from
>>>>>> ENE, but it won't be good in every case.  The wire-up of the ENE of
>>>>>> various motherboards is likely something you'll have to live with as
>>>>>> unknowns.
>>>>>>
>>>>>> This is a case where looser tolerances in the in kernel decoders could
>>>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>>>> factors in the driver.
>>>>
>>>>> The tolerances are as loose as they can be. The NEC protocol uses
>>>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>>>> (50% of 4%).  The crystals used in electronics are accurate to
>>>>> 0.0001%+.
>>>>
>>>> But the standard IR receivers are far from being accurate enough to allow
>>>> tolerance windows of only 2%.
>>>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>>>> 30% / 100 us and even this is not enough sometimes.
>>>>
>>>> For the NEC protocol one signal consists of 22 individual pulses at
>>>> 38kHz.. If the receiver just misses one pulse, you already have an error
>>>> of 1/22
>>>>> 4%.
>>
>>> There are different types of errors. The decoders can take large
>>> variations in bit times. The problem is with cumulative errors. In
>>> this case the error had accumulated up to 450us in the lead pulse.
>>> That's just too big of an error and caused the JVC code to be
>>> misclassified as NEC.
>>>
>>> I think he said lirc was misclassifying it too. So we both did the same
>>> thing.
>>
>> No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse
>> JVC with NEC signals?
>>
>> LIRC will work if there is a 4% or 40% or 400% error. Because irrecord
>> generates the config file using your receiver it will compensate for any

> At the end of the process we can build a record and match raw mode if
> we have to.

I'm not talking about raw mode here. lircd will happily decode the signals  
despite of any timing error as long it's consistent.

I'm still interested how JVC can be confused with NEC codes.

>> timing error. It will work with pulses cut down to 50 us like IrDA
>> hardware does and it will work when half of the bits are swallowed like
>> the IgorPlug USB receiver does.

> The code for fixing IrDA and IgorPLug should live inside their low
> level device drivers.  The characteristics of the errors produced by
> this hardware are known so a fix can be written to compensate.

The function f(x) = 50 is not bijective. No way to compensate.

Missing bits cannot be magically regenerated by the driver.

> The
> IgorPlug people might find it easier to fix their firmware.

There is a firmware patch available? Do you have a pointer?

Christoph

Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Christoph Bartelmus]

Hi!

Jon Smirl "jonsmirl@gmail.com" wrote:

> On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus <lirc@bartelmus.de>
> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 14:14, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
>>> wrote:
>>>> Hi Jon,
>>>>
>>>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>>>> wrote:
>>>>>> I think you won't be able to fix the problem conclusively either way.
>>>>>>  A lot of how the chip's clocks should be programmed depends on how the
>>>>>> GPIOs are used and what crystal is used.
>>>>>>
>>>>>> I suspect many designers will use some reference design layout from
>>>>>> ENE, but it won't be good in every case.  The wire-up of the ENE of
>>>>>> various motherboards is likely something you'll have to live with as
>>>>>> unknowns.
>>>>>>
>>>>>> This is a case where looser tolerances in the in kernel decoders could
>>>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>>>> factors in the driver.
>>>>
>>>>> The tolerances are as loose as they can be. The NEC protocol uses
>>>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>>>> (50% of 4%).  The crystals used in electronics are accurate to
>>>>> 0.0001%+.
>>>>
>>>> But the standard IR receivers are far from being accurate enough to allow
>>>> tolerance windows of only 2%.
>>>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>>>> 30% / 100 us and even this is not enough sometimes.
>>>>
>>>> For the NEC protocol one signal consists of 22 individual pulses at
>>>> 38kHz.. If the receiver just misses one pulse, you already have an error
>>>> of 1/22
>>>>> 4%.
>>
>>> There are different types of errors. The decoders can take large
>>> variations in bit times. The problem is with cumulative errors. In
>>> this case the error had accumulated up to 450us in the lead pulse.
>>> That's just too big of an error and caused the JVC code to be
>>> misclassified as NEC.
>>>
>>> I think he said lirc was misclassifying it too. So we both did the same
>>> thing.
>>
>> No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse
>> JVC with NEC signals?
>>
>> LIRC will work if there is a 4% or 40% or 400% error. Because irrecord
>> generates the config file using your receiver it will compensate for any

> At the end of the process we can build a record and match raw mode if
> we have to.

I'm not talking about raw mode here. lircd will happily decode the signals  
despite of any timing error as long it's consistent.

I'm still interested how JVC can be confused with NEC codes.

>> timing error. It will work with pulses cut down to 50 us like IrDA
>> hardware does and it will work when half of the bits are swallowed like
>> the IgorPlug USB receiver does.

> The code for fixing IrDA and IgorPLug should live inside their low
> level device drivers.  The characteristics of the errors produced by
> this hardware are known so a fix can be written to compensate.

The function f(x) = 50 is not bijective. No way to compensate.

Missing bits cannot be magically regenerated by the driver.

> The
> IgorPlug people might find it easier to fix their firmware.

There is a firmware patch available? Do you have a pointer?

Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html