From: Maxim L. <max...@gm...> - 2009-08-13 19:31:37
|
This is a patch against git tree of my driver. It is the CVS version + my latest bugfix patch + usual support for kernel (Kconfig, Makefile) Also I have found and fixed a bug in this tree, without this bugfix, my and probably other drivers won't unload properly. Best regards, Maxim Levitsky |
From: Maxim L. <max...@gm...> - 2009-08-13 19:32:57
|
>From 82aa04ede187551f11f74b4e4199014c0a4d9b39 Mon Sep 17 00:00:00 2001 From: Maxim Levitsky <max...@gm...> Date: Thu, 13 Aug 2009 22:19:58 +0300 Subject: [PATCH] Fix problem with allocating dynamic minors New allocated minor wasn't saved, thus it wasn't possible to deallocate a lirc driver Signed-off-by: Maxim Levitsky <max...@gm...> --- drivers/input/lirc/lirc_dev.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/input/lirc/lirc_dev.c b/drivers/input/lirc/lirc_dev.c index 0510b4e..d7317c0 100644 --- a/drivers/input/lirc/lirc_dev.c +++ b/drivers/input/lirc/lirc_dev.c @@ -296,6 +296,7 @@ int lirc_register_driver(struct lirc_driver *d) } init_irctl(ir); irctls[minor] = ir; + d->minor = minor; if (d->sample_rate) { ir->jiffies_to_wait = HZ / d->sample_rate; @@ -377,8 +378,8 @@ int lirc_unregister_driver(int minor) if (minor < 0 || minor >= MAX_IRCTL_DEVICES) { printk(KERN_ERR "lirc_dev: lirc_unregister_driver: " - "\"minor\" must be between 0 and %d!\n", - MAX_IRCTL_DEVICES-1); + "\"minor(%d)\" must be between 0 and %d!\n", + minor, MAX_IRCTL_DEVICES-1); return -EBADRQC; } -- 1.6.0.4 |
From: Maxim L. <max...@gm...> - 2009-08-13 19:34:23
|
>From 73ed61a286f8e6d26725388a23400f28b5eba588 Mon Sep 17 00:00:00 2001 From: Maxim Levitsky <max...@gm...> Date: Thu, 13 Aug 2009 22:19:59 +0300 Subject: [PATCH] Add driver for ENE KB3924 This a driver for cir port inside embedded controller found on some aspire notebooks Signed-off-by: Maxim Levitsky <max...@gm...> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_ene0100.c | 450 +++++++++++++++++++++++++++++++++++++ drivers/input/lirc/lirc_ene0100.h | 100 ++++++++ 4 files changed, 558 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_ene0100.c create mode 100644 drivers/input/lirc/lirc_ene0100.h diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 6ef8622..bd9caf0 100644 --- a/drivers/input/lirc/Kconfig +++ b/drivers/input/lirc/Kconfig @@ -109,4 +109,11 @@ config LIRC_ZILOG Driver for the Zilog/Hauppauge IR Transmitter, found on PVR-150/500, HVR-1200/1250/1700/1800, HD-PVR and other cards +config LIRC_ENE0100 + tristate "ENE KB3924/ENE0100 CIR Port Reciever" + depends on LIRC_DEV + help + This is a driver for CIR port handled by ENE KB3924 embedded + controller found on some acer aspire notebooks. + It appears on PNP list as ENE0100. endif diff --git a/drivers/input/lirc/Makefile b/drivers/input/lirc/Makefile index 7b1386e..9814dc5 100644 --- a/drivers/input/lirc/Makefile +++ b/drivers/input/lirc/Makefile @@ -18,3 +18,4 @@ obj-$(CONFIG_LIRC_SIR) += lirc_sir.o obj-$(CONFIG_LIRC_STREAMZAP) += lirc_streamzap.o obj-$(CONFIG_LIRC_TTUSBIR) += lirc_ttusbir.o obj-$(CONFIG_LIRC_ZILOG) += lirc_zilog.o +obj-$(CONFIG_LIRC_ENE0100) += lirc_ene0100.o diff --git a/drivers/input/lirc/lirc_ene0100.c b/drivers/input/lirc/lirc_ene0100.c new file mode 100644 index 0000000..e6f1617 --- /dev/null +++ b/drivers/input/lirc/lirc_ene0100.c @@ -0,0 +1,450 @@ +/* + * driver for ENE KB3924 CIR (also known as ENE0100) + * + * Copyright (C) 2009 Maxim Levitsky <max...@gm...> + * + * 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 "lirc_ene0100.h" + + +static int sample_period = 50; +static int enable_idle = 1; + +static void ene_set_idle(struct ene_device *dev, int idle); + +/* 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); +} + + +/* which half of hardware buffer we read now ?*/ +static int hw_get_buf_pointer(struct ene_device *dev) +{ + return 4 * (ene_hw_read_reg(dev, ENE_FW_BUFFER_POINTER) + & ENE_FW_BUFFER_POINTER_HIGH); +} + + +/* read irq status and ack it */ +static int ene_hw_irq_status(struct ene_device *dev) +{ + u8 irq_status = ene_hw_read_reg(dev, ENE_IRQ_STATUS); + + if (!irq_status & ENE_IRQ_STATUS_IR) + return 0; + + ene_hw_write_reg(dev, ENE_IRQ_STATUS, irq_status & ~ENE_IRQ_STATUS_IR); + return 1; +} + + +/* hardware initialization */ +static int ene_hw_init(void *data) +{ + struct ene_device *dev = (struct ene_device *)data; + dev->in_use = 1; + + ene_hw_write_reg(dev, ENE_IRQ, dev->irq << 1); + ene_hw_write_reg(dev, ENE_ADC_UNK2, 0x00); + ene_hw_write_reg(dev, ENE_ADC_SAMPLE_PERIOD, sample_period); + ene_hw_write_reg(dev, ENE_ADC_UNK1, 0x07); + ene_hw_write_reg(dev, ENE_UNK1, 0x01); + ene_hw_write_reg_mask(dev, ENE_FW_SETTINGS, ENE_FW_ENABLE | ENE_FW_IRQ, + ENE_FW_ENABLE | ENE_FW_IRQ); + + /* ack any pending irqs - just in case */ + ene_hw_irq_status(dev); + + /* enter idle mode */ + ene_set_idle(dev, 1); + + /* clear stats */ + dev->sample = 0; + return 0; +} + +/* deinitialization */ +static void ene_hw_deinit(void *data) +{ + struct ene_device *dev = (struct ene_device *)data; + + /* disable hardware IRQ and firmware flag */ + ene_hw_write_reg_mask(dev, ENE_FW_SETTINGS, 0, + ENE_FW_ENABLE | ENE_FW_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; + + ene_hw_write_reg_mask(dev, ENE_ADC_SAMPLE_PERIOD, + idle & enable_idle ? 0 : ENE_ADC_SAMPLE_OVERFLOW, + ENE_ADC_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_address; + u8 hw_value; + int i, hw_sample; + int space; + + struct ene_device *dev = (struct ene_device *)data; + + if (!ene_hw_irq_status(dev)) + return IRQ_NONE; + + hw_address = ENE_SAMPLE_BUFFER + hw_get_buf_pointer(dev); + + for (i = 0 ; i < ENE_SAMPLES_SIZE ; i++) { + + hw_value = ene_hw_read_reg(dev, hw_address + i); + space = hw_value & ENE_SAMPLE_LOW_MASK; + hw_value &= ~ENE_SAMPLE_LOW_MASK; + + /* no more data */ + if (!(hw_value)) + break; + + /* calculate hw sample */ + hw_sample = hw_value * sample_period; + + if (space) + hw_sample *= -1; + + /* overflow sample recieved, handle it */ + if (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->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 resource *res; + 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); + + error = -EINVAL; + if (sample_period < 5) { + + printk(KERN_ERR ENE_DRIVER_NAME ": sample period must be at " + "least 5 ms, (at least 30 recommended)\n"); + + goto err1; + } + + /* validate and read resources */ + error = -ENODEV; + res = pnp_get_resource(pnp_dev, IORESOURCE_IO, 0); + if (!pnp_resource_valid(res)) + goto err2; + + dev->hw_io = res->start; + + if (pnp_resource_len(res) < ENE_MAX_IO) + goto err2; + + + res = pnp_get_resource(pnp_dev, IORESOURCE_IRQ, 0); + if (!pnp_resource_valid(res)) + goto err2; + + dev->irq = res->start; + + /* 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; + + /* 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; + + + /* check firmware version */ + error = -ENODEV; + if (ene_hw_read_reg(dev, ENE_FW_VERSION) != ENE_FW_VER_SUPP) { + printk(KERN_WARNING ENE_DRIVER_NAME ": " + "unsupported firmware found, aborting\n"); + goto err8; + } + + printk(KERN_NOTICE ENE_DRIVER_NAME ": " + "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 +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_FW_SETTINGS, ENE_FW_WAKE, ENE_FW_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_FW_SETTINGS, 0, ENE_FW_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) +{ + 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, +"Allow hardware to signal when IR pulse starts, disable if your remote" +"doesn't send a sync pulse"); + + +MODULE_DEVICE_TABLE(pnp, ene_ids); +MODULE_DESCRIPTION("LIRC driver for KB3924/ENE0100 CIR port"); +MODULE_AUTHOR("Maxim Levitsky"); +MODULE_LICENSE("GPL"); + +module_init(ene_init); +module_exit(ene_exit); diff --git a/drivers/input/lirc/lirc_ene0100.h b/drivers/input/lirc/lirc_ene0100.h new file mode 100644 index 0000000..a31be90 --- /dev/null +++ b/drivers/input/lirc/lirc_ene0100.h @@ -0,0 +1,100 @@ +/* + * driver for ENE KB3924 CIR (also known as ENE0100) + * + * Copyright (C) 2009 Maxim Levitsky <max...@gm...> + * + * 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 "lirc.h" +#include "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 3 + + +/* 8 bytes of samples, divided in 2 halfs*/ +#define ENE_SAMPLE_BUFFER 0xF8F0 +#define ENE_SAMPLE_LOW_MASK (1 << 7) +#define ENE_SAMPLE_VALUE_MASK 0x7F +#define ENE_SAMPLE_OVERFLOW 0x7F +#define ENE_SAMPLES_SIZE 4 + + +/* firmware settings */ +#define ENE_FW_SETTINGS 0xF8F8 +#define ENE_FW_ENABLE (1 << 0) /* enable fw processing */ +#define ENE_FW_WAKE (1 << 6) /* enable wake from S3 */ +#define ENE_FW_IRQ (1 << 7) /* enable interrupt */ + + +/* buffer pointer, tells which half of ENE_SAMPLE_BUFFER to read */ +#define ENE_FW_BUFFER_POINTER 0xF8F9 +#define ENE_FW_BUFFER_POINTER_HIGH (1 << 0) + + +/* IRQ registers block */ +#define ENE_IRQ 0xFD09 /* IRQ number */ +#define ENE_UNK1 0xFD17 /* unknown setting = 1 */ +#define ENE_IRQ_STATUS 0xFD80 /* irq status */ +#define ENE_IRQ_STATUS_IR (1 << 5) /* IR irq */ + + +/* ADC settings */ +#define ENE_ADC_UNK1 0xFEC0 /* unknown setting = 7 */ +#define ENE_ADC_UNK2 0xFEC1 /* unknown setting = 0 */ +#define ENE_ADC_SAMPLE_PERIOD 0xFEC8 /* sample period in us */ +#define ENE_ADC_SAMPLE_OVERFLOW (1 << 7) /* interrupt on + overflows if set */ + +/* fimware version */ +#define ENE_FW_VERSION 0xFF00 +#define ENE_FW_VER_SUPP 0xC0 + + +#define same_sign(a, b) ((((a) > 0) && (b) > 0) || ((a) < 0 && (b) < 0)) + +#define ENE_DRIVER_NAME "enecir" + +#define ENE_MAXGAP 5000000 /* this is amount of + time we wait before + turning the + sampler, chosen + arbitry */ + +#define space(len) (-(len)) /* add a space */ + + +struct ene_device { + struct pnp_dev *pnp_dev; + struct lirc_driver *lirc_driver; + + /* hw settings */ + unsigned long hw_io; + int irq; + + /* device data */ + int idle; + int sample; + int in_use; + + struct timeval gap_start; +}; + -- 1.6.0.4 |
From: Giuseppe B. <giu...@gm...> - 2009-08-17 09:37:00
|
Hello all, sorry for coming in late in the discussion. I'm catching up the backlogs for this mailing list and I'm very interested in this particular patch because I have an HP laptop that sports this ENE receiver. I haven't tested the patch yet, but I've been reading it and I have a couple of comments. On Thursday 13 August 2009 21:34, Maxim Levitsky wrote: >>From 73ed61a286f8e6d26725388a23400f28b5eba588 Mon Sep 17 00:00:00 2001 > From: Maxim Levitsky <max...@gm...> > Date: Thu, 13 Aug 2009 22:19:59 +0300 > Subject: [PATCH] Add driver for ENE KB3924 > > This a driver for cir port inside embedded controller > found on some aspire notebooks The controller is also found in some HP Pavilion models. You may want to mention this in the commit message, and more importantly in the Kconfig. > > +config LIRC_ENE0100 > + tristate "ENE KB3924/ENE0100 CIR Port Reciever" > + depends on LIRC_DEV > + help > + This is a driver for CIR port handled by ENE KB3924 embedded > + controller found on some acer aspire notebooks. > + It appears on PNP list as ENE0100. Aside from adding the HP Pavilion here, you may want to upcase Acer Aspire here. It is also possible that the receiver is found in other laptop models, so not listing any of them (just mentioning 'some notebooks') or having a more complete list might be better. > + if (pnp_resource_len(res) < ENE_MAX_IO) [snip] > + if (!request_region(dev->hw_io, ENE_MAX_IO, ENE_DRIVER_NAME)) [snip] > + release_region(dev->hw_io, ENE_MAX_IO); [snip] > + release_region(dev->hw_io, ENE_MAX_IO); [snip] > +/* 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 */ whitespace nitpick: you probaply want one less tab on the above line, to get proper alignment. > +#define ENE_MAX_IO 3 I have absolutely no knowledge when it comes to this low level of programming, but this one got me wondering: given the use of ENE_MAX_IO in the code, shouldn't it rather be set to 4 (and maybe renamed to ENE_IO_NUM or something like that)? Best regards and thanks a lot for this driver (I still have to test it, but I'll do it briefly), -- Giuseppe "Oblomov" Bilotta |
From: Giuseppe B. <giu...@gm...> - 2009-08-18 08:40:04
|
On Tue, Aug 18, 2009 at 8:40 AM, Maxim Levitsky<max...@gm...> wrote: > And I must say that there are many differences. > I have downloaded the windows driver and examined it. > It is very different, but I try to add support for it. I've been working on the same thing myself, looking at the Windows driver to see what's going on there. This is how I gathered most of the information I gave you in my previous email. By the way, if you want you can find me on the Freenode IRC network, on channel #lirc, and we can exchange notes on the topic in real-time (assuming we have overlapping timezones, of course ;-)) > now you don't need to use enable_idle=0, probably it won't help at all > anyway. Indeed. Looking at the Windows init code, it seems that the 3926C I'm using is VERY different from anything else, and has its own special init sequence. > Can you tell me exact model of your notebook? The exact model is an HP Pavilion dv5t (i.e. the Intel based one). However, this is not so important for the firmware init, as far as I can see: aside from the pnp ID, what really tells the various chips apart is the embedded ChipID and hardware version (btw, you mark it as firmware version, but according to the KB3700 pdf it's the actual _hardware_ version). -- Giuseppe "Oblomov" Bilotta |
From: Maxim L. <max...@gm...> - 2009-08-17 10:08:32
|
On Mon, 2009-08-17 at 11:36 +0200, Giuseppe Bilotta wrote: > Hello all, > > sorry for coming in late in the discussion. I'm catching up the backlogs > for this mailing list and I'm very interested in this particular patch > because I have an HP laptop that sports this ENE receiver. I haven't > tested the patch yet, but I've been reading it and I have a couple of > comments. > > > On Thursday 13 August 2009 21:34, Maxim Levitsky wrote: > > >>From 73ed61a286f8e6d26725388a23400f28b5eba588 Mon Sep 17 00:00:00 2001 > > From: Maxim Levitsky <max...@gm...> > > Date: Thu, 13 Aug 2009 22:19:59 +0300 > > Subject: [PATCH] Add driver for ENE KB3924 > > > > This a driver for cir port inside embedded controller > > found on some aspire notebooks > > The controller is also found in some HP Pavilion models. You may want to > mention this in the commit message, and more importantly in the Kconfig. I'll do so as soon as I get confirmation that it works. Who knows, the driver talks to firmware, interface might be different. > > > > > +config LIRC_ENE0100 > > + tristate "ENE KB3924/ENE0100 CIR Port Reciever" > > + depends on LIRC_DEV > > + help > > + This is a driver for CIR port handled by ENE KB3924 embedded > > + controller found on some acer aspire notebooks. > > + It appears on PNP list as ENE0100. > > Aside from adding the HP Pavilion here, you may want to upcase Acer > Aspire here. It is also possible that the receiver is found in other > laptop models, so not listing any of them (just mentioning 'some > notebooks') or having a more complete list might be better. I didn't knew it is found on other notebooks, so it is a good idea. > > > + if (pnp_resource_len(res) < ENE_MAX_IO) > > [snip] > > > + if (!request_region(dev->hw_io, ENE_MAX_IO, ENE_DRIVER_NAME)) > > [snip] > > > + release_region(dev->hw_io, ENE_MAX_IO); > > [snip] > > > + release_region(dev->hw_io, ENE_MAX_IO); > > [snip] > > > +/* 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 */ > > whitespace nitpick: you probaply want one less tab on the above line, to > get proper alignment. > > > +#define ENE_MAX_IO 3 > > I have absolutely no knowledge when it comes to this low level of > programming, but this one got me wondering: given the use of ENE_MAX_IO > in the code, shouldn't it rather be set to 4 (and maybe renamed to > ENE_IO_NUM or something like that)? You are right here! when I wrote it, I probably thought of ENE_IO as a maximum offset from start, not as a port count. Typical off by one error... > > Best regards and thanks a lot for this driver (I still have to test it, > but I'll do it briefly), > When you do, grab lirc cvs. http://www.lirc.org/cvs.html Mine driver is already included in CVS, but please apply patch, titled 'PATCH v4] Few fixes to ENE0100 driver' on top of it Driver should work without above patch as well, but it fixes few real bugs in this code. This driver won't work with stable version of lirc (although it is easy to port, as it seems that ioctl numbers have changed, but I don't want to clutter the code with compat code) And, you need a relatively new kernel, probably 2.6.29 (this is what Christoph Bartelmus, told me). I test currently only against 2.6.31-rc5, but I expend this as time permits. Best regards, Maxim Levitsky |
From: Giuseppe B. <giu...@gm...> - 2009-08-17 10:57:37
|
On Mon, Aug 17, 2009 at 12:08 PM, Maxim Levitsky<max...@gm...> wrote: > On Mon, 2009-08-17 at 11:36 +0200, Giuseppe Bilotta wrote: >> The controller is also found in some HP Pavilion models. You may want to >> mention this in the commit message, and more importantly in the Kconfig. > I'll do so as soon as I get confirmation that it works. > Who knows, the driver talks to firmware, interface might be different. Good point. >> Best regards and thanks a lot for this driver (I still have to test it, >> but I'll do it briefly), >> > > When you do, grab lirc cvs. > http://www.lirc.org/cvs.html > > Mine driver is already included in CVS, but please apply patch, titled > 'PATCH v4] Few fixes to ENE0100 driver' on top of it > > Driver should work without above patch as well, but it fixes few real > bugs in this code. Ok, so I grabbed the last lirc from CVS, and applied your patch on top. I followed the build instructions on the lirc webside. I'm running a Debian unstable with distro kernel 2.6.30-1-amd64. I can modprobe lirc_ene0100 and I get [684810.850718] lirc_dev: IR Remote Control driver registered, major 61 [684810.851059] lirc_dev: lirc_register_driver: sample_rate: 0 [684810.851130] enecir: driver has been succesfully loaded in the dmesg. A /dev/lirc0 entry gets created, too, with crw-rw--- permissino and root:video ownership (this is udev at work, I think). So far so good. However, when I run irrecord -d /dev/lirc0 remotes/generic/RC-6.conf (the remote avertizes itself as an RC6) I never receives any signal. I've also tried a brute 'cat /dev/lirc0' and no activity is registered, but I don't know if this is normal or not. -- Giuseppe "Oblomov" Bilotta |
From: Giuseppe B. <giu...@gm...> - 2009-08-17 14:00:52
|
On Mon, Aug 17, 2009 at 12:57 PM, Giuseppe Bilotta<giu...@gm...> wrote: > > Ok, so I grabbed the last lirc from CVS, and applied your patch on > top. I followed the build instructions on the lirc webside. I'm > running a Debian unstable with distro kernel 2.6.30-1-amd64. > > I can modprobe lirc_ene0100 and I get > > [684810.850718] lirc_dev: IR Remote Control driver registered, major 61 > [684810.851059] lirc_dev: lirc_register_driver: sample_rate: 0 > [684810.851130] enecir: driver has been succesfully loaded > > in the dmesg. A /dev/lirc0 entry gets created, too, with crw-rw--- > permissino and root:video ownership (this is udev at work, I think). > So far so good. > > However, when I run irrecord -d /dev/lirc0 remotes/generic/RC-6.conf > (the remote avertizes itself as an RC6) I never receives any signal. > I've also tried a brute 'cat /dev/lirc0' and no activity is > registered, but I don't know if this is normal or not. Some more information. The kernel is actually 2.6.30-6 in Debian unstable. The rc works (in Vista everything is fine). If I reboot the computer (i.e. on a fresh hardware init) and I cat /dev/lirc0, then pressing a key (e.g. the DVD key) I get oblomov@oblomov:~$ cat /dev/lirc0 | xxd 0000000: bc05 5e00 d70a 0001 8403 0000 c201 0001 ..^............. After that, nothing else comes out. I can reboot, and get the stuff again, and then again nothing. If I use irrecord instead of cat, on the first press it says that something is wrong, and after that it says that nothing is received. Let me know if there is anything I can do to help you debug this issue. -- Giuseppe "Oblomov" Bilotta |
From: Giuseppe B. <giu...@gm...> - 2009-08-17 14:02:21
|
On Mon, Aug 17, 2009 at 4:00 PM, Giuseppe Bilotta<giu...@gm...> wrote: > > Some more information. The kernel is actually 2.6.30-6 in Debian > unstable. The rc works (in Vista everything is fine). If I reboot the > computer (i.e. on a fresh hardware init) and I cat /dev/lirc0, then > pressing a key (e.g. the DVD key) I get > > oblomov@oblomov:~$ cat /dev/lirc0 | xxd > 0000000: bc05 5e00 d70a 0001 8403 0000 c201 0001 ..^............. > > After that, nothing else comes out. I can reboot, and get the stuff > again, and then again nothing. Doh, sorry for replying to myself so often and for spamming like this, but one more information: after the first key press on the remote, I get nothing else. A reboot is _necessary_. Just unloading and then reloading the lirc_ene0100 (and related) modules is not enough. -- Giuseppe "Oblomov" Bilotta |
From: Jarod W. <ja...@wi...> - 2009-08-17 15:27:38
|
On Aug 13, 2009, at 3:31 PM, Maxim Levitsky wrote: > This is a patch against git tree of my driver. > It is the CVS version + my latest bugfix patch + usual support for > kernel (Kconfig, Makefile) > > > Also I have found and fixed a bug in this tree, without this bugfix, > my > and probably other drivers won't unload properly. Okay, its finally been added to my git tree, with minor whitespace fixups and sorting the Kconfig and Makefile bits alphabetically with the rest of the device drivers. -- Jarod Wilson ja...@wi... |
From: Maxim L. <max...@gm...> - 2009-08-20 07:55:00
|
On Mon, 2009-08-17 at 11:27 -0400, Jarod Wilson wrote: > On Aug 13, 2009, at 3:31 PM, Maxim Levitsky wrote: > > > This is a patch against git tree of my driver. > > It is the CVS version + my latest bugfix patch + usual support for > > kernel (Kconfig, Makefile) > > > > > > Also I have found and fixed a bug in this tree, without this bugfix, > > my > > and probably other drivers won't unload properly. > > > Okay, its finally been added to my git tree, with minor whitespace > fixups and sorting the Kconfig and Makefile bits alphabetically with > the rest of the device drivers. > Thanks! I was really busy few days implementing, support for newer ENE devices. Best regards, Maxim Levitsky |
From: Maxim L. <max...@gm...> - 2009-08-17 23:53:57
|
On Mon, 2009-08-17 at 16:01 +0200, Giuseppe Bilotta wrote: > On Mon, Aug 17, 2009 at 4:00 PM, Giuseppe > Bilotta<giu...@gm...> wrote: > > > > Some more information. The kernel is actually 2.6.30-6 in Debian > > unstable. The rc works (in Vista everything is fine). If I reboot the > > computer (i.e. on a fresh hardware init) and I cat /dev/lirc0, then > > pressing a key (e.g. the DVD key) I get > > > > oblomov@oblomov:~$ cat /dev/lirc0 | xxd > > 0000000: bc05 5e00 d70a 0001 8403 0000 c201 0001 ..^............. > > > > After that, nothing else comes out. I can reboot, and get the stuff > > again, and then again nothing. > > Doh, sorry for replying to myself so often and for spamming like this, > but one more information: after the first key press on the remote, I > get nothing else. A reboot is _necessary_. Just unloading and then > reloading the lirc_ene0100 (and related) modules is not enough. > I knew that there were hardware differences :-( Try to load the driver (after a reboot) (You probably need first to unload it) modprobe -r lirc_ene0100 modprobe lirc_ene0100 enable_idle=0 sample_period=200 and then, please run mode2 -m -d /dev/lirc0 and send me the output also, when there is no output, take a look at /proc/interrupts does entry enecir increase ? What exactly notebook you have? Best regards, Maxim Levitsky |
From: Giuseppe B. <giu...@gm...> - 2009-08-18 01:05:00
|
On Tue, Aug 18, 2009 at 1:53 AM, Maxim Levitsky<max...@gm...> wrote: > On Mon, 2009-08-17 at 16:01 +0200, Giuseppe Bilotta wrote: >> On Mon, Aug 17, 2009 at 4:00 PM, Giuseppe >> Bilotta<giu...@gm...> wrote: >> > >> > Some more information. The kernel is actually 2.6.30-6 in Debian >> > unstable. The rc works (in Vista everything is fine). If I reboot the >> > computer (i.e. on a fresh hardware init) and I cat /dev/lirc0, then >> > pressing a key (e.g. the DVD key) I get >> > >> > oblomov@oblomov:~$ cat /dev/lirc0 | xxd >> > 0000000: bc05 5e00 d70a 0001 8403 0000 c201 0001 ..^............. >> > >> > After that, nothing else comes out. I can reboot, and get the stuff >> > again, and then again nothing. >> >> Doh, sorry for replying to myself so often and for spamming like this, >> but one more information: after the first key press on the remote, I >> get nothing else. A reboot is _necessary_. Just unloading and then >> reloading the lirc_ene0100 (and related) modules is not enough. >> > > I knew that there were hardware differences :-( > > Try to load the driver (after a reboot) > (You probably need first to unload it) > > modprobe -r lirc_ene0100 > modprobe lirc_ene0100 enable_idle=0 sample_period=200 > > and then, please run > > mode2 -m -d /dev/lirc0 > > and send me the output I will look into this, but I suspect the problem does not lie there. I think the buffer pointer is stored elsewhere in my chip, see below. > also, when there is no output, take a look at /proc/interrupts > does entry enecir increase ? No, only 1 interrupt gets called. > What exactly notebook you have? I have an HP Pavilion dv5. However, more important than the notebook I think is the actual chip ID. You can get the chip ID value by peeking at FF1E (hi) and FF1F (lo), which in my case return 3926 (since you mention a KB3924, I assume FF1F will hold 0x24 in your case). For my chip, F8F9 does not hold the buffer pointer but another configuration word, which I think refers to the IR _transmitter_ provided by this chip (a feature which is probably disabled here anyway). I'll try providing more information as soon as I discover it. By the way, did you manage to contact the ENE rep for the embedded controllers? I wrote him an email some time ago but they never replied ... maybe if enough people ask they will provide datasheets ... -- Giuseppe "Oblomov" Bilotta |
From: Maxim L. <max...@gm...> - 2009-08-18 05:28:35
|
On Tue, 2009-08-18 at 03:04 +0200, Giuseppe Bilotta wrote: > On Tue, Aug 18, 2009 at 1:53 AM, Maxim Levitsky<max...@gm...> wrote: > > On Mon, 2009-08-17 at 16:01 +0200, Giuseppe Bilotta wrote: > >> On Mon, Aug 17, 2009 at 4:00 PM, Giuseppe > >> Bilotta<giu...@gm...> wrote: > >> > > >> > Some more information. The kernel is actually 2.6.30-6 in Debian > >> > unstable. The rc works (in Vista everything is fine). If I reboot the > >> > computer (i.e. on a fresh hardware init) and I cat /dev/lirc0, then > >> > pressing a key (e.g. the DVD key) I get > >> > > >> > oblomov@oblomov:~$ cat /dev/lirc0 | xxd > >> > 0000000: bc05 5e00 d70a 0001 8403 0000 c201 0001 ..^............. > >> > > >> > After that, nothing else comes out. I can reboot, and get the stuff > >> > again, and then again nothing. > >> > >> Doh, sorry for replying to myself so often and for spamming like this, > >> but one more information: after the first key press on the remote, I > >> get nothing else. A reboot is _necessary_. Just unloading and then > >> reloading the lirc_ene0100 (and related) modules is not enough. > >> > > > > I knew that there were hardware differences :-( > > > > Try to load the driver (after a reboot) > > (You probably need first to unload it) > > > > modprobe -r lirc_ene0100 > > c sample_period=200 > > > > and then, please run > > > > mode2 -m -d /dev/lirc0 > > > > and send me the output > > I will look into this, but I suspect the problem does not lie there. I > think the buffer pointer is stored elsewhere in my chip, see below. > > > also, when there is no output, take a look at /proc/interrupts > > does entry enecir increase ? > > No, only 1 interrupt gets called. This is the most interesting part.... Which means that interrupt ACK that works here, doesn't work on your system. Still, try to use enable_idle=0 > > > What exactly notebook you have? > > I have an HP Pavilion dv5. However, more important than the notebook I > think is the actual chip ID. > > You can get the chip ID value by peeking at FF1E (hi) and FF1F (lo), > which in my case return 3926 (since you mention a KB3924, I assume > FF1F will hold 0x24 in your case) Mine actually returns 3909. The fact I have 3924 I concluded from bios dumps and changelog of it. > . For my chip, F8F9 does not hold the > buffer pointer but another configuration word, which I think refers to > the IR _transmitter_ provided by this chip (a feature which is > probably disabled here anyway). I'll try providing more information as > soon as I discover it. F8F9 can contain anything. its only the lowest bit that I check. could you see if contents of F8F0-F8F7 stop changing after initial packet? And, are these contents always the same? Or in other words is the firmware buffer there. Just a wild guess, maybe they have switched to store each sample in a word?, then firmware pointer might be further away. Anyway, hardware really seems to be different. F400h~FBFF are the device ram, thus onlu range that depends on firmware used, but you probably have a slightly different hardware too. These clowns, change hardware, and keep the same PNP ID.... And also, it would be great to see interrupt status, FD80, before and after first and only interrupt, to see if another bit is used there. > > By the way, did you manage to contact the ENE rep for the embedded > controllers? I wrote him an email some time ago but they never replied > ... maybe if enough people ask they will provide datasheets ... > I didn't try, but, since OLPC devs have worked quite hard to get KB3700 datasheets, I guess these folks won't give me anything unless I sign an NDA or so, and I won't do that for any price. Best regards, Maxim Levitsky |
From: Maxim L. <max...@gm...> - 2009-08-18 06:41:00
|
On Tue, 2009-08-18 at 08:28 +0300, Maxim Levitsky wrote: > On Tue, 2009-08-18 at 03:04 +0200, Giuseppe Bilotta wrote: > > On Tue, Aug 18, 2009 at 1:53 AM, Maxim Levitsky<max...@gm...> wrote: > > > On Mon, 2009-08-17 at 16:01 +0200, Giuseppe Bilotta wrote: > > >> On Mon, Aug 17, 2009 at 4:00 PM, Giuseppe > > >> Bilotta<giu...@gm...> wrote: > > >> > > > >> > Some more information. The kernel is actually 2.6.30-6 in Debian > > >> > unstable. The rc works (in Vista everything is fine). If I reboot the > > >> > computer (i.e. on a fresh hardware init) and I cat /dev/lirc0, then > > >> > pressing a key (e.g. the DVD key) I get > > >> > > > >> > oblomov@oblomov:~$ cat /dev/lirc0 | xxd > > >> > 0000000: bc05 5e00 d70a 0001 8403 0000 c201 0001 ..^............. > > >> > > > >> > After that, nothing else comes out. I can reboot, and get the stuff > > >> > again, and then again nothing. > > >> > > >> Doh, sorry for replying to myself so often and for spamming like this, > > >> but one more information: after the first key press on the remote, I > > >> get nothing else. A reboot is _necessary_. Just unloading and then > > >> reloading the lirc_ene0100 (and related) modules is not enough. > > >> > > > > > > I knew that there were hardware differences :-( And I must say that there are many differences. I have downloaded the windows driver and examined it. It is very different, but I try to add support for it. now you don't need to use enable_idle=0, probably it won't help at all anyway. Can you tell me exact model of your notebook? Best regards, Maxim Levitsky |
From: Maxim L. <max...@gm...> - 2009-08-18 09:45:15
|
On Tue, 2009-08-18 at 10:39 +0200, Giuseppe Bilotta wrote: > On Tue, Aug 18, 2009 at 8:40 AM, Maxim Levitsky<max...@gm...> wrote: > > And I must say that there are many differences. > > I have downloaded the windows driver and examined it. > > It is very different, but I try to add support for it. > > I've been working on the same thing myself, looking at the Windows > driver to see what's going on there. This is how I gathered most of > the information I gave you in my previous email. By the way, if you > want you can find me on the Freenode IRC network, on channel #lirc, > and we can exchange notes on the topic in real-time (assuming we have > overlapping timezones, of course ;-)) Sure, I now am there too. > > > now you don't need to use enable_idle=0, probably it won't help at all > > anyway. > > Indeed. Looking at the Windows init code, it seems that the 3926C I'm > using is VERY different from anything else, and has its own special > init sequence. > > > Can you tell me exact model of your notebook? > > The exact model is an HP Pavilion dv5t (i.e. the Intel based one). > However, this is not so important for the firmware init, as far as I > can see: aside from the pnp ID, what really tells the various chips > apart is the embedded ChipID and hardware version (btw, you mark it as > firmware version, but according to the KB3700 pdf it's the actual > _hardware_ version). Best regards, Maxim Levitsky |
From: xyzyx <re...@po...> - 2009-08-19 17:02:15
|
Hello Maxim, Just noticed that someone made a driver for this ENE0100 CIR. I've the same CIR receiver on my Compal laptop JFL92 and trying to make it work with rc6 remote control for a while. As soon as I saw this driver, I thought to gave it a try. I've compiled lirc with your driver suport (last CVS), and... unfortunately it doesn't work. Maybe there is something different on my laptop and thats why I would like you to look into this or/and make your driver to work also with my hardware. My CIR module is conected via isa port. Here is what I get after lspnp 00:02 ENE0100 (unknown) state = active io 0x700-0x703 irq 4 Should your driver work normaly in this configuration? If you need anything else to investigate (logs etc) just tell me. Thanks in advance Mario Maxim Levitsky wrote: > > On Tue, 2009-08-18 at 10:39 +0200, Giuseppe Bilotta wrote: >> On Tue, Aug 18, 2009 at 8:40 AM, Maxim Levitsky<max...@gm...> >> wrote: >> > And I must say that there are many differences. >> > I have downloaded the windows driver and examined it. >> > It is very different, but I try to add support for it. >> >> I've been working on the same thing myself, looking at the Windows >> driver to see what's going on there. This is how I gathered most of >> the information I gave you in my previous email. By the way, if you >> want you can find me on the Freenode IRC network, on channel #lirc, >> and we can exchange notes on the topic in real-time (assuming we have >> overlapping timezones, of course ;-)) > Sure, I now am there too. > >> >> > now you don't need to use enable_idle=0, probably it won't help at all >> > anyway. >> >> Indeed. Looking at the Windows init code, it seems that the 3926C I'm >> using is VERY different from anything else, and has its own special >> init sequence. > > >> >> > Can you tell me exact model of your notebook? >> >> The exact model is an HP Pavilion dv5t (i.e. the Intel based one). >> However, this is not so important for the firmware init, as far as I >> can see: aside from the pnp ID, what really tells the various chips >> apart is the embedded ChipID and hardware version (btw, you mark it as >> firmware version, but according to the KB3700 pdf it's the actual >> _hardware_ version). > > Best regards, > Maxim Levitsky > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > -- View this message in context: http://www.nabble.com/-PATCH-v4--ENE-lirc-driver-tp24960987p25048137.html Sent from the LIRC mailing list archive at Nabble.com. |
From: Maxim L. <max...@gm...> - 2009-08-20 07:44:09
|
On Wed, 2009-08-19 at 10:02 -0700, xyzyx wrote: > Hello Maxim, > > Just noticed that someone made a driver for this ENE0100 CIR. I've the same > CIR receiver on my Compal laptop JFL92 and trying to make it work with rc6 > remote control for a while. > As soon as I saw this driver, I thought to gave it a try. I've compiled lirc > with your driver suport (last CVS), and... unfortunately it doesn't work. > Maybe there is something different on my laptop and thats why I would like > you to look into this or/and make your driver to work also with my hardware. > My CIR module is conected via isa port. Here is what I get after lspnp > > 00:02 ENE0100 (unknown) > state = active > io 0x700-0x703 > irq 4 > > Should your driver work normaly in this configuration? > If you need anything else to investigate (logs etc) just tell me. First of all the windows ene driver that you gave me for your notebook is byte perfectly same, as mine. Thus original driver I have wrote will work if we manage to enable the device. Secondary, as this io range returns 0xFF (you can try to inb 0x701 , inb 0x702, etc... to be sure), the hardware seems to be disabled. This is what I thing about possible reasons: 1) this notebook was shipped with XP. XP doesn't have a Microsoft-ridden CIR subsystem, thus windows driver won't work. On the other hand the device in question, is an embedded controller, and thus serves as a keyboard controller. It is known that firmware running inside this device, _can_ decode the ir signal itself, and present it to system as if it was originated from keyboard. This is so called compatibility mode. The catch is that it will only decode signals of remote that was shipped with the notebook. But this doesn't matter to windows users, as anyway nether the windows driver will work with any remote, as it works with only MS certificated RC6 remotes (I did say it was Microsoft ridden didn't I... they sell lots of mouses keyboards, and now remotes...) It is possible, that since laptop is shipped with XP, they have just disabled the window to this embedded controller. In this case you can try to update the bios, although updating bios is always very dangerous. 2) It is disabled in bios settings. look carefully there for signs of IR, or CIR. 3) There is some 'magic' driver shipped among their windows drivers, that opens the access window. While possible this is unlikely. While it might seem to be tempting to install windows vista on this system to test, it won't help. Why? because first of all anyway as I explained, windows will work only with shipped remote that you don't have. And even if you had it, you couldn't distinguish between windows driver working, and compat mode (I want to remind again that compat mode doesn't need nether drivers not access window open) 4) ACPI tables on your system somehow detect linux, think its XP, and disable the device. This is highly unlikely, but send me the output of 'acpidump' to be sure. 5) There is a bug in ACPI/PnP code that makes it show incorrect io address for the device. Again highly unlikely, but send me the 'acpidump' output (you need to run is as root of course) to be sure. Thats all, I hope this explains everything. Best regards, Maxim Levitsky |
From: Maxim L. <max...@gm...> - 2009-08-20 21:17:43
|
On Thu, 2009-08-20 at 10:43 +0300, Maxim Levitsky wrote: > On Wed, 2009-08-19 at 10:02 -0700, xyzyx wrote: > > Hello Maxim, > > > > Just noticed that someone made a driver for this ENE0100 CIR. I've the same > > CIR receiver on my Compal laptop JFL92 and trying to make it work with rc6 > > remote control for a while. > > As soon as I saw this driver, I thought to gave it a try. I've compiled lirc > > with your driver suport (last CVS), and... unfortunately it doesn't work. > > Maybe there is something different on my laptop and thats why I would like > > you to look into this or/and make your driver to work also with my hardware. > > My CIR module is conected via isa port. Here is what I get after lspnp > > > > 00:02 ENE0100 (unknown) > > state = active > > io 0x700-0x703 > > irq 4 > > > > Should your driver work normaly in this configuration? > > If you need anything else to investigate (logs etc) just tell me. > > First of all the windows ene driver that you gave me for your notebook > is byte perfectly same, as mine. Thus original driver I have wrote will > work if we manage to enable the device. > > Secondary, as this io range returns 0xFF (you can try to inb 0x701 , inb > 0x702, etc... to be sure), the hardware seems to be disabled. > > This is what I thing about possible reasons: > > > 1) this notebook was shipped with XP. XP doesn't have a Microsoft-ridden > CIR subsystem, thus windows driver won't work. > > On the other hand the device in question, is an embedded controller, and > thus serves as a keyboard controller. It is known that firmware running > inside this device, _can_ decode the ir signal itself, and present it to > system as if it was originated from keyboard. > > This is so called compatibility mode. The catch is that it will only > decode signals of remote that was shipped with the notebook. > > But this doesn't matter to windows users, as anyway nether the windows > driver will work with any remote, as it works with only MS certificated > RC6 remotes > (I did say it was Microsoft ridden didn't I... they sell lots of mouses > keyboards, and now remotes...) > > It is possible, that since laptop is shipped with XP, they have just > disabled the window to this embedded controller. > In this case you can try to update the bios, although updating bios is > always very dangerous. > > > > 2) It is disabled in bios settings. look carefully there for signs of > IR, or CIR. > > > 3) There is some 'magic' driver shipped among their windows drivers, > that opens the access window. While possible this is unlikely. > While it might seem to be tempting to install windows vista on this > system to test, it won't help. > > Why? because first of all anyway as I explained, windows will work only > with shipped remote that you don't have. > > And even if you had it, you couldn't distinguish between windows driver > working, and compat mode (I want to remind again that compat mode > doesn't need nether drivers not access window open) > > > 4) ACPI tables on your system somehow detect linux, think its XP, and > disable the device. > This is highly unlikely, but send me the output of 'acpidump' to be > sure. Well, sometimes the highly unlikely things happen.... This was the cause of this problem. and strangely acpi_osi="Windows 2006" didn't help. For the reference, the ugly hack (works only on this laptop only!) is to do: sudo setpci -s 00:1f.0 0x88.W=0x701 this enables a I/O window to EC in LPC controller. look at ICH8 datasheet for more information. This command is very system specific, and can damage another system. If used. Best regards, Maxim Levitsky > > > 5) There is a bug in ACPI/PnP code that makes it show incorrect io > address for the device. Again highly unlikely, but send me the > 'acpidump' output (you need to run is as root of course) to be sure. > > > Thats all, I hope this explains everything. > > Best regards, > Maxim Levitsky > |