[RESEND: GIT PATCHES FOR 2.6.36] cx23885, cx25840, v4l2_subdev: I/O pin config and CX23885 chip IR Rx
Mauro, This is a resend of my previous pull request, because I have added 4 new patches. Please pull these changes for 2.6.36. They are based off of the v4l-dvb/other branch from a few weeks ago, IIRC. These changes implement CX23885 chip IR Rx support, which different people seem to bug me about once a month or so. IR support for the CX23885 chip, which is not used in new designs, will never get better unless it is in the hands of the masses. I have also converted these v4l2_subdevices to use struct ir_raw_event as their native record type to pass information in and out, reducing a data conversion. This also sets up the possibility of modifying struct ir_raw_event so these subdevices can provide more events in band to the decoders than just space and mark time measurement events. These changes are also a necessary step for CX23887 and CX231xx IR Tx/Rx and CX2388[58] IR Tx. Regards, Andy The following changes since commit f6242ad1007df90691fd5b70f0808320fe7aee07: V4L/DVB: xc5000: Fix a few warnings (2010-07-05 18:38:46 -0300) are available in the git repository at: ssh://linuxtv.org/git/awalls/v4l-dvb.git cx-ir Andy Walls (19): cx25840: Make cx25840 i2c register read transactions atomic cx23885: Add correct detection of the HVR-1250 model 79501 cx23885: Add a VIDIOC_LOG_STATUS ioctl function for analog video devices v4l2_subdev: Add s_io_pin_config to v4l2_subdev_core_ops cx25840: Add s_io_pin_config core subdev ops for the CX2388[578] v4l2_subdev, cx23885: Differentiate IR carrier sense and I/O pin inversion cx23885: For CX23888 IR, configure the IO pin mux IR pins explcitly v4l2_subdev: Move interrupt_service_routine ptr to v4l2_subdev_core_ops cx25840: Add support for CX2388[57] A/V core integrated IR controllers cx23885: Add a v4l2_subdev group id for the CX2388[578] integrated AV core cx23885: Add preliminary IR Rx support for the HVR-1250 and TeVii S470 cx23885: Protect PCI interrupt mask manipulations with a spinlock cx23885: Move AV Core irq handling to a work handler cx23885: Require user to explicitly enable CX2388[57] IR via module param cx23885: Change Kconfig dependencies to new IR_CORE functions cx23885, cx25840: Report IR max pulse width regardless of mod/demod use cx23885, cx25840: Report the actual length of an IR Rx timeout event cx23885, cx25840: Change IR measurment records to use struct ir_raw_event v4l2_subdev: Get rid of now unused IR pulse width defines Jean Delvare (3): cx23885: Return -ENXIO on slave nack cx23885: Check for slave nack on all transactions cx23885: i2c_wait_done returns 0 or 1, don't check for < 0 return value drivers/media/video/cx23885/Kconfig |2 +- drivers/media/video/cx23885/Makefile|5 +- drivers/media/video/cx23885/cx23885-av.c| 35 + drivers/media/video/cx23885/cx23885-av.h| 27 + drivers/media/video/cx23885/cx23885-cards.c | 114 +++- drivers/media/video/cx23885/cx23885-core.c | 124 +++- drivers/media/video/cx23885/cx23885-i2c.c | 27 +- drivers/media/video/cx23885/cx23885-input.c | 72 +- drivers/media/video/cx23885/cx23885-ir.c| 24 +- drivers/media/video/cx23885/cx23885-reg.h |1 + drivers/media/video/cx23885/cx23885-vbi.c |2 +- drivers/media/video/cx23885/cx23885-video.c | 23 +- drivers/media/video/cx23885/cx23885.h |9 +- drivers/media/video/cx23885/cx23888-ir.c| 142 ++-- drivers/media/video/cx25840/Makefile|2 +- drivers/media/video/cx25840/cx25840-core.c | 339 +++- drivers/media/video/cx25840/cx25840-core.h | 28 + drivers/media/video/cx25840/cx25840-ir.c| 1279 +++ include/media/cx25840.h | 75 ++ include/media/v4l2-subdev.h | 51 +- 20 files changed, insertions(+), 159 deletions(-) create mode 100644 drivers/media/video/cx23885/cx23885-av.c create mode 100644 drivers/media/video/cx23885/cx23885-av.h create mode 100644 drivers/media/video/cx25840/cx25840-ir.c -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] Port dvb-usb to ir-core
This patch series starts the proccess of moving dvb-usb drivers to use the new Remote Controller core. It adds support for rc-core at dvb-usb core, while keeping support for the legacy mode. One driver (dib0700) were ported to the new rc-core mode, as an example for the low-level driver maintainers to port their drivers. There are still some space for improvements on this port, like breaking the dib0700 table into smaller ones, implementing protocol switch via rc-core API, etc. Ah, the first patch on this series fixes a problem caused on a previous commit. Mauro Carvalho Chehab (7): V4L/DVB: Partially revert commit da7251dd0bca6c17571be2bd4434b9779dea72d8 V4L/DVB: dvb-usb: get rid of struct dvb_usb_rc_key V4L/DVB: dvb-usb: prepare drivers for using rc-core V4L/DVB: dvb-usb: add support for rc-core mode V4L/DVB: Add a keymap file with dib0700 table V4L/DVB: Port dib0700 to rc-core V4L/DVB: dib0700: avoid bad repeat drivers/media/IR/ir-sysfs.c | 155 - drivers/media/IR/keymaps/Makefile |1 + drivers/media/IR/keymaps/rc-dib0700-big.c | 314 + drivers/media/dvb/dvb-usb/a800.c| 12 +- drivers/media/dvb/dvb-usb/af9005-remote.c |4 +- drivers/media/dvb/dvb-usb/af9005.c | 16 +- drivers/media/dvb/dvb-usb/af9005.h |2 +- drivers/media/dvb/dvb-usb/af9015.c | 34 ++- drivers/media/dvb/dvb-usb/af9015.h | 18 +- drivers/media/dvb/dvb-usb/anysee.c | 18 +- drivers/media/dvb/dvb-usb/az6027.c | 13 +- drivers/media/dvb/dvb-usb/cinergyT2-core.c | 12 +- drivers/media/dvb/dvb-usb/cxusb.c | 128 --- drivers/media/dvb/dvb-usb/dib0700_core.c| 87 + drivers/media/dvb/dvb-usb/dib0700_devices.c | 485 ++- drivers/media/dvb/dvb-usb/dibusb-common.c |2 +- drivers/media/dvb/dvb-usb/dibusb-mb.c | 40 ++- drivers/media/dvb/dvb-usb/dibusb-mc.c | 10 +- drivers/media/dvb/dvb-usb/dibusb.h |2 +- drivers/media/dvb/dvb-usb/digitv.c | 20 +- drivers/media/dvb/dvb-usb/dtt200u.c | 42 ++- drivers/media/dvb/dvb-usb/dvb-usb-remote.c | 198 drivers/media/dvb/dvb-usb/dvb-usb.h | 90 -- drivers/media/dvb/dvb-usb/dw2102.c | 67 ++-- drivers/media/dvb/dvb-usb/m920x.c | 44 ++- drivers/media/dvb/dvb-usb/nova-t-usb2.c | 14 +- drivers/media/dvb/dvb-usb/opera1.c | 16 +- drivers/media/dvb/dvb-usb/vp702x.c | 14 +- drivers/media/dvb/dvb-usb/vp7045.c | 14 +- include/media/rc-map.h |4 + 30 files changed, 1026 insertions(+), 850 deletions(-) create mode 100644 drivers/media/IR/keymaps/rc-dib0700-big.c -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] V4L/DVB: dib0700: avoid bad repeat
a 250ms delay is too low for this device. It ends by producing false repeat events. Increase the delay time to 500 ms to avoid troubles. Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c b/drivers/media/dvb/dvb-usb/dib0700_core.c index 164fa9c..a05d955 100644 --- a/drivers/media/dvb/dvb-usb/dib0700_core.c +++ b/drivers/media/dvb/dvb-usb/dib0700_core.c @@ -648,6 +648,9 @@ static int dib0700_probe(struct usb_interface *intf, else dev->props.rc.core.bulk_mode = false; + /* Need a higher delay, to avoid wrong repeat */ + dev->rc_input_dev->rep[REP_DELAY] = 500; + dib0700_rc_setup(dev); return 0; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] V4L/DVB: Port dib0700 to rc-core
Use the new rc-core handler at dvb-usb-remote for dib0700 driver.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 527b1e6..164fa9c 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -491,14 +491,11 @@ struct dib0700_rc_response {
static void dib0700_rc_urb_completion(struct urb *purb)
{
struct dvb_usb_device *d = purb->context;
- struct ir_scancode *keymap;
struct dib0700_state *st;
struct dib0700_rc_response poll_reply;
u8 *buf;
- int found = 0;
- u32 event;
- int state;
- int i;
+ u32 keycode;
+ u8 toggle;
deb_info("%s()\n", __func__);
if (d == NULL)
@@ -510,7 +507,6 @@ static void dib0700_rc_urb_completion(struct urb *purb)
return;
}
- keymap = d->props.rc.legacy.rc_key_map;
st = d->priv;
buf = (u8 *)purb->transfer_buffer;
@@ -525,21 +521,17 @@ static void dib0700_rc_urb_completion(struct urb *purb)
goto resubmit;
}
- /* Set initial results in case we exit the function early */
- event = 0;
- state = REMOTE_NO_KEY_PRESSED;
-
deb_data("IR raw %02X %02X %02X %02X %02X %02X (len %d)\n", buf[0],
buf[1], buf[2], buf[3], buf[4], buf[5], purb->actual_length);
switch (dvb_usb_dib0700_ir_proto) {
case 0:
/* NEC Protocol */
- poll_reply.report_id = 0;
- poll_reply.data_state = 1;
+ poll_reply.data_state = 0;
poll_reply.system = buf[2];
poll_reply.data = buf[4];
poll_reply.not_data = buf[5];
+ toggle = 0;
/* NEC protocol sends repeat code as 0 0 0 FF */
if ((poll_reply.system == 0x00) && (poll_reply.data == 0x00)
@@ -547,6 +539,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
poll_reply.data_state = 2;
break;
}
+
break;
default:
/* RC5 Protocol */
@@ -555,6 +548,9 @@ static void dib0700_rc_urb_completion(struct urb *purb)
poll_reply.system = (buf[2] << 8) | buf[3];
poll_reply.data = buf[4];
poll_reply.not_data = buf[5];
+
+ toggle = poll_reply.report_id;
+
break;
}
@@ -570,59 +566,8 @@ static void dib0700_rc_urb_completion(struct urb *purb)
poll_reply.report_id, poll_reply.data_state,
poll_reply.system, poll_reply.data, poll_reply.not_data);
- /* Find the key in the map */
- for (i = 0; i < d->props.rc.legacy.rc_key_map_size; i++) {
- if (rc5_custom(&keymap[i]) == (poll_reply.system & 0xff) &&
- rc5_data(&keymap[i]) == poll_reply.data) {
- event = keymap[i].keycode;
- found = 1;
- break;
- }
- }
-
- if (found == 0) {
- err("Unknown remote controller key: %04x %02x %02x",
- poll_reply.system, poll_reply.data, poll_reply.not_data);
- d->last_event = 0;
- goto resubmit;
- }
-
- if (poll_reply.data_state == 1) {
- /* New key hit */
- st->rc_counter = 0;
- event = keymap[i].keycode;
- state = REMOTE_KEY_PRESSED;
- d->last_event = keymap[i].keycode;
- } else if (poll_reply.data_state == 2) {
- /* Key repeated */
- st->rc_counter++;
-
- /* prevents unwanted double hits */
- if (st->rc_counter > RC_REPEAT_DELAY_V1_20) {
- event = d->last_event;
- state = REMOTE_KEY_PRESSED;
- st->rc_counter = RC_REPEAT_DELAY_V1_20;
- }
- } else {
- err("Unknown data state [%d]", poll_reply.data_state);
- }
-
- switch (state) {
- case REMOTE_NO_KEY_PRESSED:
- break;
- case REMOTE_KEY_PRESSED:
- deb_info("key pressed\n");
- d->last_event = event;
- case REMOTE_KEY_REPEAT:
- deb_info("key repeated\n");
- input_event(d->rc_input_dev, EV_KEY, event, 1);
- input_sync(d->rc_input_dev);
- input_event(d->rc_input_dev, EV_KEY, d->last_event, 0);
- input_sync(d->rc_input_dev);
- break;
- default:
- break;
- }
+ keycode = poll_reply.system << 8 | poll_reply.data;
+ ir_keydown(d->rc_input_dev, keycode, toggle);
resubmit:
/* Clean the buffer before we requeue */
@@ -640,9 +585,6 @@ int dib0700_rc_setup(struct dvb_usb_device *d)
[PATCH 5/7] V4L/DVB: Add a keymap file with dib0700 table
Signed-off-by: Mauro Carvalho Chehab
create mode 100644 drivers/media/IR/keymaps/rc-dib0700-big.c
diff --git a/drivers/media/IR/keymaps/Makefile
b/drivers/media/IR/keymaps/Makefile
index 86d3d1f..85330d1 100644
--- a/drivers/media/IR/keymaps/Makefile
+++ b/drivers/media/IR/keymaps/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-budget-ci-old.o \
rc-cinergy-1400.o \
rc-cinergy.o \
+ rc-dib0700-big.o \
rc-dm1105-nec.o \
rc-dntv-live-dvb-t.o \
rc-dntv-live-dvbt-pro.o \
diff --git a/drivers/media/IR/keymaps/rc-dib0700-big.c
b/drivers/media/IR/keymaps/rc-dib0700-big.c
new file mode 100644
index 000..2e83820
--- /dev/null
+++ b/drivers/media/IR/keymaps/rc-dib0700-big.c
@@ -0,0 +1,314 @@
+/* rc-dvb0700-big.c - Keytable for devices in dvb0700
+ *
+ * Copyright (c) 2010 by Mauro Carvalho Chehab
+ *
+ * TODO: This table is a real mess, as it merges RC codes from several
+ * devices into a big table. It also has both RC-5 and NEC codes inside.
+ * It should be broken into small tables, and the protocols should properly
+ * be indentificated.
+ *
+ * The table were imported from dib0700_devices.c.
+ *
+ * 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
+
+static struct ir_scancode dib0700_table[] = {
+ /* Key codes for the tiny Pinnacle remote*/
+ { 0x0700, KEY_MUTE },
+ { 0x0701, KEY_MENU }, /* Pinnacle logo */
+ { 0x0739, KEY_POWER },
+ { 0x0703, KEY_VOLUMEUP },
+ { 0x0709, KEY_VOLUMEDOWN },
+ { 0x0706, KEY_CHANNELUP },
+ { 0x070c, KEY_CHANNELDOWN },
+ { 0x070f, KEY_1 },
+ { 0x0715, KEY_2 },
+ { 0x0710, KEY_3 },
+ { 0x0718, KEY_4 },
+ { 0x071b, KEY_5 },
+ { 0x071e, KEY_6 },
+ { 0x0711, KEY_7 },
+ { 0x0721, KEY_8 },
+ { 0x0712, KEY_9 },
+ { 0x0727, KEY_0 },
+ { 0x0724, KEY_SCREEN }, /* 'Square' key */
+ { 0x072a, KEY_TEXT }, /* 'T' key */
+ { 0x072d, KEY_REWIND },
+ { 0x0730, KEY_PLAY },
+ { 0x0733, KEY_FASTFORWARD },
+ { 0x0736, KEY_RECORD },
+ { 0x073c, KEY_STOP },
+ { 0x073f, KEY_CANCEL }, /* '?' key */
+ /* Key codes for the Terratec Cinergy DT XS Diversity, similar to
cinergyT2.c */
+ { 0xeb01, KEY_POWER },
+ { 0xeb02, KEY_1 },
+ { 0xeb03, KEY_2 },
+ { 0xeb04, KEY_3 },
+ { 0xeb05, KEY_4 },
+ { 0xeb06, KEY_5 },
+ { 0xeb07, KEY_6 },
+ { 0xeb08, KEY_7 },
+ { 0xeb09, KEY_8 },
+ { 0xeb0a, KEY_9 },
+ { 0xeb0b, KEY_VIDEO },
+ { 0xeb0c, KEY_0 },
+ { 0xeb0d, KEY_REFRESH },
+ { 0xeb0f, KEY_EPG },
+ { 0xeb10, KEY_UP },
+ { 0xeb11, KEY_LEFT },
+ { 0xeb12, KEY_OK },
+ { 0xeb13, KEY_RIGHT },
+ { 0xeb14, KEY_DOWN },
+ { 0xeb16, KEY_INFO },
+ { 0xeb17, KEY_RED },
+ { 0xeb18, KEY_GREEN },
+ { 0xeb19, KEY_YELLOW },
+ { 0xeb1a, KEY_BLUE },
+ { 0xeb1b, KEY_CHANNELUP },
+ { 0xeb1c, KEY_VOLUMEUP },
+ { 0xeb1d, KEY_MUTE },
+ { 0xeb1e, KEY_VOLUMEDOWN },
+ { 0xeb1f, KEY_CHANNELDOWN },
+ { 0xeb40, KEY_PAUSE },
+ { 0xeb41, KEY_HOME },
+ { 0xeb42, KEY_MENU }, /* DVD Menu */
+ { 0xeb43, KEY_SUBTITLE },
+ { 0xeb44, KEY_TEXT }, /* Teletext */
+ { 0xeb45, KEY_DELETE },
+ { 0xeb46, KEY_TV },
+ { 0xeb47, KEY_DVD },
+ { 0xeb48, KEY_STOP },
+ { 0xeb49, KEY_VIDEO },
+ { 0xeb4a, KEY_AUDIO }, /* Music */
+ { 0xeb4b, KEY_SCREEN }, /* Pic */
+ { 0xeb4c, KEY_PLAY },
+ { 0xeb4d, KEY_BACK },
+ { 0xeb4e, KEY_REWIND },
+ { 0xeb4f, KEY_FASTFORWARD },
+ { 0xeb54, KEY_PREVIOUS },
+ { 0xeb58, KEY_RECORD },
+ { 0xeb5c, KEY_NEXT },
+
+ /* Key codes for the Haupauge WinTV Nova-TD, copied from nova-t-usb2.c
(Nova-T USB2) */
+ { 0x1e00, KEY_0 },
+ { 0x1e01, KEY_1 },
+ { 0x1e02, KEY_2 },
+ { 0x1e03, KEY_3 },
+ { 0x1e04, KEY_4 },
+ { 0x1e05, KEY_5 },
+ { 0x1e06, KEY_6 },
+ { 0x1e07, KEY_7 },
+ { 0x1e08, KEY_8 },
+ { 0x1e09, KEY_9 },
+ { 0x1e0a, KEY_KPASTERISK },
+ { 0x1e0b, KEY_RED },
+ { 0x1e0c, KEY_RADIO },
+ { 0x1e0d, KEY_MENU },
+ { 0x1e0e, KEY_GRAVE }, /* # */
+ { 0x1e0f, KEY_MUTE },
+ { 0x1e10, KEY_VOLUMEUP },
+ { 0x1e11, KEY_VOLUMEDOWN },
+ { 0x1e12, KEY_CHANNEL },
+ { 0x1e14, KEY_UP },
+ { 0x1e15, KEY_DOWN },
+ { 0x1e16, KEY_LEFT },
+ { 0x1e17, KEY_RIGHT },
+ { 0x1e18, KEY_VIDEO },
+ { 0x1e19, KEY_AUDIO },
+ { 0x1e1a, KEY_MEDIA },
+
[PATCH 4/7] V4L/DVB: dvb-usb: add support for rc-core mode
Allows dvb-usb drivers to use rc-core, instead of the legacy
implementation.
No driver were ported yet to rc-core, so, some small adjustments
may be needed, when starting to migrate the drivers.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
b/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
index 7951076..b579fed 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
@@ -8,7 +8,7 @@
#include "dvb-usb-common.h"
#include
-static int dvb_usb_getkeycode(struct input_dev *dev,
+static int legacy_dvb_usb_getkeycode(struct input_dev *dev,
unsigned int scancode, unsigned int *keycode)
{
struct dvb_usb_device *d = input_get_drvdata(dev);
@@ -25,7 +25,7 @@ static int dvb_usb_getkeycode(struct input_dev *dev,
/*
* If is there extra space, returns KEY_RESERVED,
-* otherwise, input core won't let dvb_usb_setkeycode
+* otherwise, input core won't let legacy_dvb_usb_setkeycode
* to work
*/
for (i = 0; i < d->props.rc.legacy.rc_key_map_size; i++)
@@ -38,7 +38,7 @@ static int dvb_usb_getkeycode(struct input_dev *dev,
return -EINVAL;
}
-static int dvb_usb_setkeycode(struct input_dev *dev,
+static int legacy_dvb_usb_setkeycode(struct input_dev *dev,
unsigned int scancode, unsigned int keycode)
{
struct dvb_usb_device *d = input_get_drvdata(dev);
@@ -78,7 +78,7 @@ static int dvb_usb_setkeycode(struct input_dev *dev,
*
* TODO: Fix the repeat rate of the input device.
*/
-static void dvb_usb_read_remote_control(struct work_struct *work)
+static void legacy_dvb_usb_read_remote_control(struct work_struct *work)
{
struct dvb_usb_device *d =
container_of(work, struct dvb_usb_device, rc_query_work.work);
@@ -154,15 +154,114 @@ schedule:
schedule_delayed_work(&d->rc_query_work,msecs_to_jiffies(d->props.rc.legacy.rc_interval));
}
+static int legacy_dvb_usb_remote_init(struct dvb_usb_device *d,
+ struct input_dev *input_dev)
+{
+ int i, err, rc_interval;
+
+ input_dev->getkeycode = legacy_dvb_usb_getkeycode;
+ input_dev->setkeycode = legacy_dvb_usb_setkeycode;
+
+ /* set the bits for the keys */
+ deb_rc("key map size: %d\n", d->props.rc.legacy.rc_key_map_size);
+ for (i = 0; i < d->props.rc.legacy.rc_key_map_size; i++) {
+ deb_rc("setting bit for event %d item %d\n",
+ d->props.rc.legacy.rc_key_map[i].keycode, i);
+ set_bit(d->props.rc.legacy.rc_key_map[i].keycode,
input_dev->keybit);
+ }
+
+ /* setting these two values to non-zero, we have to manage key repeats
*/
+ input_dev->rep[REP_PERIOD] = d->props.rc.legacy.rc_interval;
+ input_dev->rep[REP_DELAY] = d->props.rc.legacy.rc_interval + 150;
+
+ input_set_drvdata(input_dev, d);
+
+ err = input_register_device(input_dev);
+ if (err)
+ input_free_device(input_dev);
+
+ rc_interval = d->props.rc.legacy.rc_interval;
+
+ INIT_DELAYED_WORK(&d->rc_query_work,
legacy_dvb_usb_read_remote_control);
+
+ info("schedule remote query interval to %d msecs.", rc_interval);
+ schedule_delayed_work(&d->rc_query_work,
+ msecs_to_jiffies(rc_interval));
+
+ d->state |= DVB_USB_STATE_REMOTE;
+
+ return err;
+}
+
+/* Remote-control poll function - called every dib->rc_query_interval ms to see
+ * whether the remote control has received anything.
+ *
+ * TODO: Fix the repeat rate of the input device.
+ */
+static void dvb_usb_read_remote_control(struct work_struct *work)
+{
+ struct dvb_usb_device *d =
+ container_of(work, struct dvb_usb_device, rc_query_work.work);
+ int err;
+
+ /* TODO: need a lock here. We can simply skip checking for the remote
control
+ if we're busy. */
+
+ /* when the parameter has been set to 1 via sysfs while the
+* driver was running, or when bulk mode is enabled after IR init
+*/
+ if (dvb_usb_disable_rc_polling || d->props.rc.core.bulk_mode)
+ return;
+
+ err = d->props.rc.core.rc_query(d);
+ if (err)
+ err("error %d while querying for an remote control event.",
err);
+
+ schedule_delayed_work(&d->rc_query_work,
+ msecs_to_jiffies(d->props.rc.core.rc_interval));
+}
+
+static int rc_core_dvb_usb_remote_init(struct dvb_usb_device *d,
+ struct input_dev *input_dev)
+{
+ int err, rc_interval;
+
+ d->props.rc.core.rc_props.priv = d;
+ err = ir_input_register(input_dev,
+d->props.rc.core.rc_codes,
+&d->props.rc.core.rc_props,
+d->props.rc.core.module_name);
[PATCH 3/7] V4L/DVB: dvb-usb: prepare drivers for using rc-core
This is a big patch, yet trivial. It just move the RC properties
to a separate struct, in order to prepare the dvb-usb drivers to
use rc-core. There's no change on the behavior of the drivers.
With this change, it is possible to have both legacy and rc-core
based code inside the dvb-usb-remote, allowing a gradual migration
to rc-core, driver per driver.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb/dvb-usb/a800.c b/drivers/media/dvb/dvb-usb/a800.c
index 5580383..a5c3637 100644
--- a/drivers/media/dvb/dvb-usb/a800.c
+++ b/drivers/media/dvb/dvb-usb/a800.c
@@ -146,10 +146,12 @@ static struct dvb_usb_device_properties a800_properties =
{
.power_ctrl = a800_power_ctrl,
.identify_state = a800_identify_state,
- .rc_interval = DEFAULT_RC_INTERVAL,
- .rc_key_map = ir_codes_a800_table,
- .rc_key_map_size = ARRAY_SIZE(ir_codes_a800_table),
- .rc_query = a800_rc_query,
+ .rc.legacy = {
+ .rc_interval = DEFAULT_RC_INTERVAL,
+ .rc_key_map = ir_codes_a800_table,
+ .rc_key_map_size = ARRAY_SIZE(ir_codes_a800_table),
+ .rc_query = a800_rc_query,
+ },
.i2c_algo = &dibusb_i2c_algo,
diff --git a/drivers/media/dvb/dvb-usb/af9005.c
b/drivers/media/dvb/dvb-usb/af9005.c
index 9856463..8ecba88 100644
--- a/drivers/media/dvb/dvb-usb/af9005.c
+++ b/drivers/media/dvb/dvb-usb/af9005.c
@@ -1025,10 +1025,12 @@ static struct dvb_usb_device_properties
af9005_properties = {
.i2c_algo = &af9005_i2c_algo,
- .rc_interval = 200,
- .rc_key_map = NULL,
- .rc_key_map_size = 0,
- .rc_query = af9005_rc_query,
+ .rc.legacy = {
+ .rc_interval = 200,
+ .rc_key_map = NULL,
+ .rc_key_map_size = 0,
+ .rc_query = af9005_rc_query,
+ },
.generic_bulk_ctrl_endpoint = 2,
.generic_bulk_ctrl_endpoint_response = 1,
@@ -1072,10 +1074,10 @@ static int __init af9005_usb_module_init(void)
rc_keys_size = symbol_request(ir_codes_af9005_table_size);
if (rc_decode == NULL || rc_keys == NULL || rc_keys_size == NULL) {
err("af9005_rc_decode function not found, disabling remote");
- af9005_properties.rc_query = NULL;
+ af9005_properties.rc.legacy.rc_query = NULL;
} else {
- af9005_properties.rc_key_map = rc_keys;
- af9005_properties.rc_key_map_size = *rc_keys_size;
+ af9005_properties.rc.legacy.rc_key_map = rc_keys;
+ af9005_properties.rc.legacy.rc_key_map_size = *rc_keys_size;
}
return 0;
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index c63134c..ea1ed3b 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -847,8 +847,8 @@ static void af9015_set_remote_config(struct usb_device
*udev,
}
if (table) {
- props->rc_key_map = table->rc_key_map;
- props->rc_key_map_size = table->rc_key_map_size;
+ props->rc.legacy.rc_key_map = table->rc_key_map;
+ props->rc.legacy.rc_key_map_size = table->rc_key_map_size;
af9015_config.ir_table = table->ir_table;
af9015_config.ir_table_size = table->ir_table_size;
}
@@ -878,8 +878,8 @@ static int af9015_read_config(struct usb_device *udev)
deb_info("%s: IR mode:%d\n", __func__, val);
for (i = 0; i < af9015_properties_count; i++) {
if (val == AF9015_IR_MODE_DISABLED) {
- af9015_properties[i].rc_key_map = NULL;
- af9015_properties[i].rc_key_map_size = 0;
+ af9015_properties[i].rc.legacy.rc_key_map = NULL;
+ af9015_properties[i].rc.legacy.rc_key_map_size = 0;
} else
af9015_set_remote_config(udev, &af9015_properties[i]);
}
@@ -1063,7 +1063,7 @@ static int af9015_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
{
u8 buf[8];
struct req_t req = {GET_IR_CODE, 0, 0, 0, 0, sizeof(buf), buf};
- struct ir_scancode *keymap = d->props.rc_key_map;
+ struct ir_scancode *keymap = d->props.rc.legacy.rc_key_map;
int i, ret;
memset(buf, 0, sizeof(buf));
@@ -1075,7 +1075,7 @@ static int af9015_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
*event = 0;
*state = REMOTE_NO_KEY_PRESSED;
- for (i = 0; i < d->props.rc_key_map_size; i++) {
+ for (i = 0; i < d->props.rc.legacy.rc_key_map_size; i++) {
if (!buf[1] && rc5_custom(&keymap[i]) == buf[0] &&
rc5_data(&keymap[i]) == buf[2]) {
*event = keymap[i].keycode;
@@ -1354,8 +1354,10 @@ static struct dvb_usb_device_properties
af9015_prope
[PATCH 2/7] V4L/DVB: dvb-usb: get rid of struct dvb_usb_rc_key
dvb-usb has its own IR handle code. Now that we have a Remote
Controller subsystem, we should start using it. So, remove this
struct, in favor of the similar struct defined at the RC subsystem.
This is a big, but trivial patch. It is a 3 line delect, plus
lots of rename on several dvb-usb files.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb/dvb-usb/a800.c b/drivers/media/dvb/dvb-usb/a800.c
index b6cbb1d..5580383 100644
--- a/drivers/media/dvb/dvb-usb/a800.c
+++ b/drivers/media/dvb/dvb-usb/a800.c
@@ -37,7 +37,7 @@ static int a800_identify_state(struct usb_device *udev,
struct dvb_usb_device_pr
return 0;
}
-static struct dvb_usb_rc_key ir_codes_a800_table[] = {
+static struct ir_scancode ir_codes_a800_table[] = {
{ 0x0201, KEY_PROG1 }, /* SOURCE */
{ 0x0200, KEY_POWER }, /* POWER */
{ 0x0205, KEY_1 }, /* 1 */
diff --git a/drivers/media/dvb/dvb-usb/af9005-remote.c
b/drivers/media/dvb/dvb-usb/af9005-remote.c
index b41fa87..696207f 100644
--- a/drivers/media/dvb/dvb-usb/af9005-remote.c
+++ b/drivers/media/dvb/dvb-usb/af9005-remote.c
@@ -33,7 +33,7 @@ MODULE_PARM_DESC(debug,
#define deb_decode(args...) dprintk(dvb_usb_af9005_remote_debug,0x01,args)
-struct dvb_usb_rc_key ir_codes_af9005_table[] = {
+struct ir_scancode ir_codes_af9005_table[] = {
{0x01b7, KEY_POWER},
{0x01a7, KEY_VOLUMEUP},
@@ -133,7 +133,7 @@ int af9005_rc_decode(struct dvb_usb_device *d, u8 * data,
int len, u32 * event,
for (i = 0; i < ir_codes_af9005_table_size; i++) {
if (rc5_custom(&ir_codes_af9005_table[i]) ==
cust
&& rc5_data(&ir_codes_af9005_table[i]) ==
dat) {
- *event = ir_codes_af9005_table[i].event;
+ *event =
ir_codes_af9005_table[i].keycode;
*state = REMOTE_KEY_PRESSED;
deb_decode
("key pressed, event %x\n", *event);
diff --git a/drivers/media/dvb/dvb-usb/af9005.h
b/drivers/media/dvb/dvb-usb/af9005.h
index 088e708..3c1fbd1 100644
--- a/drivers/media/dvb/dvb-usb/af9005.h
+++ b/drivers/media/dvb/dvb-usb/af9005.h
@@ -3490,7 +3490,7 @@ extern u8 regmask[8];
/* remote control decoder */
extern int af9005_rc_decode(struct dvb_usb_device *d, u8 * data, int len,
u32 * event, int *state);
-extern struct dvb_usb_rc_key ir_codes_af9005_table[];
+extern struct ir_scancode ir_codes_af9005_table[];
extern int ir_codes_af9005_table_size;
#endif
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index 2fb24c3..c63134c 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -735,7 +735,7 @@ error:
struct af9015_setup {
unsigned int id;
- struct dvb_usb_rc_key *rc_key_map;
+ struct ir_scancode *rc_key_map;
unsigned int rc_key_map_size;
u8 *ir_table;
unsigned int ir_table_size;
@@ -1063,7 +1063,7 @@ static int af9015_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
{
u8 buf[8];
struct req_t req = {GET_IR_CODE, 0, 0, 0, 0, sizeof(buf), buf};
- struct dvb_usb_rc_key *keymap = d->props.rc_key_map;
+ struct ir_scancode *keymap = d->props.rc_key_map;
int i, ret;
memset(buf, 0, sizeof(buf));
@@ -1078,7 +1078,7 @@ static int af9015_rc_query(struct dvb_usb_device *d, u32
*event, int *state)
for (i = 0; i < d->props.rc_key_map_size; i++) {
if (!buf[1] && rc5_custom(&keymap[i]) == buf[0] &&
rc5_data(&keymap[i]) == buf[2]) {
- *event = keymap[i].event;
+ *event = keymap[i].keycode;
*state = REMOTE_KEY_PRESSED;
break;
}
diff --git a/drivers/media/dvb/dvb-usb/af9015.h
b/drivers/media/dvb/dvb-usb/af9015.h
index 63b2a49..c8e9349 100644
--- a/drivers/media/dvb/dvb-usb/af9015.h
+++ b/drivers/media/dvb/dvb-usb/af9015.h
@@ -123,7 +123,7 @@ enum af9015_remote {
/* LeadTek - Y04G0051 */
/* Leadtek WinFast DTV Dongle Gold */
-static struct dvb_usb_rc_key ir_codes_af9015_table_leadtek[] = {
+static struct ir_scancode ir_codes_af9015_table_leadtek[] = {
{ 0x001e, KEY_1 },
{ 0x001f, KEY_2 },
{ 0x0020, KEY_3 },
@@ -227,7 +227,7 @@ static u8 af9015_ir_table_leadtek[] = {
};
/* TwinHan AzureWave AD-TU700(704J) */
-static struct dvb_usb_rc_key ir_codes_af9015_table_twinhan[] = {
+static struct ir_scancode ir_codes_af9015_table_twinhan[] = {
{ 0x053f, KEY_POWER },
{ 0x0019, KEY_FAVORITES },/* Favorite List */
{ 0x0004, KEY_TEXT }, /* Teletext */
@@ -338,7 +338,7 @@ static u8 af9015_ir_table_twinhan[] = {
};
/* A-Link DTU(m) */
-static struct dvb_usb_rc_k
[PATCH 1/7] V4L/DVB: Partially revert commit da7251dd0bca6c17571be2bd4434b9779dea72d8
By mistake, changeset da7251dd0bca6c17571be2bd4434b9779dea72d8
reverted the following commits:
commit 6795f9a1ac9e85deb96a49e46b29c809214bf5ea
commit d69861a25a54ef1cd6ee92f5ceb6ff2c01d84803
commit 1ba30538e2d125ce821622ac1f5e7ef31d856077
This patch partially reverts the original commit, to return the
code to its original state.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index a841e51..c533d8b 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -33,6 +33,21 @@ static struct class ir_input_class = {
.devnode= ir_devnode,
};
+static struct {
+ u64 type;
+ char*name;
+} proto_names[] = {
+ { IR_TYPE_UNKNOWN, "unknown" },
+ { IR_TYPE_RC5, "rc-5" },
+ { IR_TYPE_NEC, "nec" },
+ { IR_TYPE_RC6, "rc-6" },
+ { IR_TYPE_JVC, "jvc" },
+ { IR_TYPE_SONY, "sony" },
+ { IR_TYPE_LIRC, "lirc" },
+};
+
+#define PROTO_NONE "none"
+
/**
* show_protocols() - shows the current IR protocol(s)
* @d: the device descriptor
@@ -50,6 +65,7 @@ static ssize_t show_protocols(struct device *d,
struct ir_input_dev *ir_dev = dev_get_drvdata(d);
u64 allowed, enabled;
char *tmp = buf;
+ int i;
if (ir_dev->props->driver_type == RC_DRIVER_SCANCODE) {
enabled = ir_dev->rc_tab.ir_type;
@@ -63,35 +79,12 @@ static ssize_t show_protocols(struct device *d,
(long long)allowed,
(long long)enabled);
- if (allowed & enabled & IR_TYPE_UNKNOWN)
- tmp += sprintf(tmp, "[unknown] ");
- else if (allowed & IR_TYPE_UNKNOWN)
- tmp += sprintf(tmp, "unknown ");
-
- if (allowed & enabled & IR_TYPE_RC5)
- tmp += sprintf(tmp, "[rc5] ");
- else if (allowed & IR_TYPE_RC5)
- tmp += sprintf(tmp, "rc5 ");
-
- if (allowed & enabled & IR_TYPE_NEC)
- tmp += sprintf(tmp, "[nec] ");
- else if (allowed & IR_TYPE_NEC)
- tmp += sprintf(tmp, "nec ");
-
- if (allowed & enabled & IR_TYPE_RC6)
- tmp += sprintf(tmp, "[rc6] ");
- else if (allowed & IR_TYPE_RC6)
- tmp += sprintf(tmp, "rc6 ");
-
- if (allowed & enabled & IR_TYPE_JVC)
- tmp += sprintf(tmp, "[jvc] ");
- else if (allowed & IR_TYPE_JVC)
- tmp += sprintf(tmp, "jvc ");
-
- if (allowed & enabled & IR_TYPE_SONY)
- tmp += sprintf(tmp, "[sony] ");
- else if (allowed & IR_TYPE_SONY)
- tmp += sprintf(tmp, "sony ");
+ for (i = 0; i < ARRAY_SIZE(proto_names); i++) {
+ if (allowed & enabled & proto_names[i].type)
+ tmp += sprintf(tmp, "[%s] ", proto_names[i].name);
+ else if (allowed & proto_names[i].type)
+ tmp += sprintf(tmp, "%s ", proto_names[i].name);
+ }
if (allowed & enabled & IR_TYPE_LIRC)
tmp += sprintf(tmp, "[lirc] ");
@@ -116,6 +109,7 @@ static ssize_t show_protocols(struct device *d,
* Writing "+proto" will add a protocol to the list of enabled protocols.
* Writing "-proto" will remove a protocol from the list of enabled protocols.
* Writing "proto" will enable only "proto".
+ * Writing "none" will disable all protocols.
* Returns -EINVAL if an invalid protocol combination or unknown protocol name
* is used, otherwise @len.
*/
@@ -129,67 +123,62 @@ static ssize_t store_protocols(struct device *d,
const char *tmp;
u64 type;
u64 mask;
- int rc;
+ int rc, i, count = 0;
unsigned long flags;
- tmp = skip_spaces(data);
-
- if (*tmp == '+') {
- enable = true;
- disable = false;
- tmp++;
- } else if (*tmp == '-') {
- enable = false;
- disable = true;
- tmp++;
- } else {
- enable = false;
- disable = false;
- }
-
- if (!strncasecmp(tmp, "unknown", 7)) {
- tmp += 7;
- mask = IR_TYPE_UNKNOWN;
- } else if (!strncasecmp(tmp, "rc5", 3)) {
- tmp += 3;
- mask = IR_TYPE_RC5;
- } else if (!strncasecmp(tmp, "nec", 3)) {
- tmp += 3;
- mask = IR_TYPE_NEC;
- } else if (!strncasecmp(tmp, "rc6", 3)) {
- tmp += 3;
- mask = IR_TYPE_RC6;
- } else if (!strncasecmp(tmp, "jvc", 3)) {
- tmp += 3;
- mask = IR_TYPE_JVC;
- } else if (!strncasecmp(tmp, "sony", 4)) {
- tmp += 4;
- mask = IR_TYPE_SONY;
- } else if (!strncasecmp(tmp, "lirc", 4)) {
- tmp += 4;
- mask
Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.
On Sat, 2010-07-31 at 17:53 -0400, Jon Smirl wrote: > On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls wrote: > > On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote: > >> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus > >> wrote: > >> > Hi Jon, > >> > > >> > on 31 Jul 10 at 12:25, Jon Smirl wrote: > >> >> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls > >> >> 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
Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.
On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls wrote: > On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote: >> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus >> wrote: >> > Hi Jon, >> > >> > on 31 Jul 10 at 12:25, Jon Smirl wrote: >> >> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls >> >> 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
Re: [PATCH 06/20] mt9m111: changed MAX_{HEIGHT,WIDTH} values to silicon pixelcount
Michael Grzeschik writes: > Signed-off-by: Philipp Wiesner > Signed-off-by: Michael Grzeschik > --- > drivers/media/video/mt9m111.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c > index 5f0c55e..2080615 100644 > --- a/drivers/media/video/mt9m111.c > +++ b/drivers/media/video/mt9m111.c > @@ -131,8 +131,8 @@ > > #define MT9M111_MIN_DARK_ROWS8 > #define MT9M111_MIN_DARK_COLS24 > -#define MT9M111_MAX_HEIGHT 1024 > -#define MT9M111_MAX_WIDTH1280 > +#define MT9M111_MAX_HEIGHT 1032 > +#define MT9M111_MAX_WIDTH1288 If we're going down that path, my specification says in chapter "Pixel Data Format/Pixel Array Structure" that there are : - 1289 optical active pixels in width - 1033 optical active pixels in height So why don't we use the real values here ? Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/20] mt9m111: added new bit offset defines
Michael Grzeschik writes: > Signed-off-by: Philipp Wiesner > Signed-off-by: Michael Grzeschik OK for me. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~stoth/saa7164-v4l
Mauro, Analog Encoder and VBI support in the SAA7164 tree, for the HVR2200 and HVR2250 cards. Please pull from http://www.kernellabs.com/hg/~stoth/saa7164-v4l - saa7164: basic definitions for -encoder.c - saa7164: Add some encoder firmwares message types and structs - saa7164: convert buffering structs to be more generic - saa7164: add various encoder message functions - saa7164: Implement encoder irq handling in a deferred work queue. - saa7164: command dequeue fixup to clean the bus after error. - saa7164: allow the encoder GOP structure to be configured - saa7164: generate a fixed kernel warning if the irq is 'late' - saa7164: add support for encoder CBR and VBR optionally. - saa7164: allow the IBP reference distance to be configurable - saa7164: implement encoder peak bitrate feature - saa7164: allow encoder output format to be user configurable - saa7164: allow variable length GOP sizes and switch encoder default to CBR - saa7164: patches to monitor TS payload for inconsistencies - saa7164: allow the number of encoder buffers to be user configurable - saa7164: measure via histograms various irq and queue latencies - saa7164: add guard bytes around critical buffers to detect failure. - saa7164: buffer crc checks and ensure we use the correct PCIe IO memcpy func - saa7164: adjust the PS pack size handling to fill buffers 100% - saa7164: Implement resolution control firmware command - saa7164: mundane buffer debugging changes to track issues - saa7164: irqhandler cleanup and helper function added - saa7164: code cleanup - saa7164: allow DMA engin buffers to vary in size between analog and digital - saa7164: New firmware changes, new size, new filename - saa7164: Avoid spurious error after firmware starts - saa7164: rename a structure for readability - saa7164: add NTSC VBI support - saa7164: add firmware debug message collection and procfs changes - saa7164: VBI irq cleanup and V4L VBI raw pitch adjustments - saa7164: Monitor the command bus and check for inconsistencies - saa7164: enforce the march 10th firmware is used. - saa7164: collect/show the firmware debugging via a thread - saa7164: monitor the RISC cpu load via a thread - saa7164: video_is_registered() func change - saa7164: change debug to saa_debug - saa7164: Add missing saa7164-vbi.c file. - saa7164: fix vbi compiler warnings - saa7164: if 0/1 cleanups b/linux/drivers/media/video/saa7164/saa7164-encoder.c | 23 b/linux/drivers/media/video/saa7164/saa7164-vbi.c | 1459 ++ linux/drivers/media/video/saa7164/Makefile|4 linux/drivers/media/video/saa7164/saa7164-api.c | 1143 - linux/drivers/media/video/saa7164/saa7164-buffer.c| 204 linux/drivers/media/video/saa7164/saa7164-bus.c | 231 - linux/drivers/media/video/saa7164/saa7164-cards.c | 56 linux/drivers/media/video/saa7164/saa7164-cmd.c | 21 linux/drivers/media/video/saa7164/saa7164-core.c | 2103 ++ linux/drivers/media/video/saa7164/saa7164-dvb.c | 109 linux/drivers/media/video/saa7164/saa7164-encoder.c | 1872 linux/drivers/media/video/saa7164/saa7164-fw.c| 35 linux/drivers/media/video/saa7164/saa7164-i2c.c |2 linux/drivers/media/video/saa7164/saa7164-reg.h | 70 linux/drivers/media/video/saa7164/saa7164-types.h | 183 linux/drivers/media/video/saa7164/saa7164-vbi.c | 53 linux/drivers/media/video/saa7164/saa7164.h | 328 + 17 files changed, 6421 insertions(+), 1475 deletions(-) Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/20] mt9m111: register cleanup hex to dec bitoffset
Michael Grzeschik writes: > Signed-off-by: Philipp Wiesner > Signed-off-by: Michael Grzeschik OK for me (the formal ack will be once we finish the review). Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/20] mt9m111: init chip after read CHIP_VERSION
Guennadi Liakhovetski writes: > On Fri, 30 Jul 2010, Michael Grzeschik wrote: > >> Moved mt9m111_init after the chip version detection passage: I >> don't like the idea of writing on a device we haven't identified >> yet. > > In principle it's correct, but what do you do, if a chip cannot be probed, > before it is initialised / enabled? Actually, this shouldn't be the case, > devices should be available for probing without any initialisation. So, we > have to ask the original author, whether this really was necessary, > Robert? Michael is right I think. According to the specification, even before the reset, the control registers can be read, and they'll return their current values, which can be weird before reset, excepting the CHIP_VERSION which is hard coded. Therefore I think Michael is right by reading chip version before doing the reset, and I ack this patch. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/20] mt9m111: Added indication that MT9M131 is supported by this driver
Guennadi Liakhovetski writes: >> Why this one ? It signals a sensor was successfully detected. Maybe a >> replacement from MT9M11x to MT9M1xx would be better ? Or if your real >> intention >> is to remove the message, then transform it to dev_dbg(), and say why you >> did it >> in the commit message. > > Robert, the message is not removed, it is moved into two chip ID switch > cases. Damn, you're right. I have no other comments on that one, looks good to me. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/20] mt9m111: added default row/col/width/height values
On Fri, 30 Jul 2010, Michael Grzeschik wrote:
> Signed-off-by: Philipp Wiesner
> Signed-off-by: Michael Grzeschik
> ---
> drivers/media/video/mt9m111.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
> index aeb2241..5f0c55e 100644
> --- a/drivers/media/video/mt9m111.c
> +++ b/drivers/media/video/mt9m111.c
> @@ -133,6 +133,10 @@
> #define MT9M111_MIN_DARK_COLS24
> #define MT9M111_MAX_HEIGHT 1024
> #define MT9M111_MAX_WIDTH1280
> +#define MT9M111_DEF_DARK_ROWS12
> +#define MT9M111_DEF_DARK_COLS30
> +#define MT9M111_DEF_HEIGHT 1024
> +#define MT9M111_DEF_WIDTH1280
Don't think this split makes sense. Please, call them "DEFAUL": "DEF" is
too ambiguous, and unite with patch 08/20. In general, you're exaggerating
splitting og patches. Many of them make little sense with this kind of a
split and have to be merged.
>
> /* MT9M111 has only one fixed colorspace per pixelcode */
> struct mt9m111_datafmt {
> --
> 1.7.1
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/20] mt9m111: Added indication that MT9M131 is supported by this driver
On Sat, 31 Jul 2010, Robert Jarzmik wrote: > Michael Grzeschik writes: > > > From: Philipp Wiesner > > > > Added this info to Kconfig and mt9m111.c, some comment cleanup, > > replaced 'mt9m11x'-statements by clarifications or driver name. > > Driver is fully compatible to mt9m131 which has only additional functions > > compared to mt9m111. Those aren't used anyway at the moment. > > > > > > - dev_info(&client->dev, "Detected a MT9M11x chip ID %x\n", data); > > - > > Why this one ? It signals a sensor was successfully detected. Maybe a > replacement from MT9M11x to MT9M1xx would be better ? Or if your real > intention > is to remove the message, then transform it to dev_dbg(), and say why you did > it > in the commit message. Robert, the message is not removed, it is moved into two chip ID switch cases. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/20] mt9m111: Added indication that MT9M131 is supported by this driver
Michael Grzeschik writes: > From: Philipp Wiesner > > Added this info to Kconfig and mt9m111.c, some comment cleanup, > replaced 'mt9m11x'-statements by clarifications or driver name. > Driver is fully compatible to mt9m131 which has only additional functions > compared to mt9m111. Those aren't used anyway at the moment. > > - dev_info(&client->dev, "Detected a MT9M11x chip ID %x\n", data); > - Why this one ? It signals a sensor was successfully detected. Maybe a replacement from MT9M11x to MT9M1xx would be better ? Or if your real intention is to remove the message, then transform it to dev_dbg(), and say why you did it in the commit message. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/20] mt9m111: init chip after read CHIP_VERSION
On Fri, 30 Jul 2010, Michael Grzeschik wrote:
> Moved mt9m111_init after the chip version detection passage: I
> don't like the idea of writing on a device we haven't identified
> yet.
In principle it's correct, but what do you do, if a chip cannot be probed,
before it is initialised / enabled? Actually, this shouldn't be the case,
devices should be available for probing without any initialisation. So, we
have to ask the original author, whether this really was necessary,
Robert?
Thanks
Guennadi
>
> Signed-off-by: Philipp Wiesner
> Signed-off-by: Michael Grzeschik
> ---
> drivers/media/video/mt9m111.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
> index e934559..39dff7c 100644
> --- a/drivers/media/video/mt9m111.c
> +++ b/drivers/media/video/mt9m111.c
> @@ -969,10 +969,6 @@ static int mt9m111_video_probe(struct soc_camera_device
> *icd,
> mt9m111->swap_rgb_even_odd = 1;
> mt9m111->swap_rgb_red_blue = 1;
>
> - ret = mt9m111_init(client);
> - if (ret)
> - goto ei2c;
> -
> data = reg_read(CHIP_VERSION);
>
> switch (data) {
> @@ -994,6 +990,8 @@ static int mt9m111_video_probe(struct soc_camera_device
> *icd,
> goto ei2c;
> }
>
> + ret = mt9m111_init(client);
> +
> ei2c:
> return ret;
> }
> --
> 1.7.1
>
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/20] mt9m111: Added indication that MT9M131 is supported by this driver
On Fri, 30 Jul 2010, Michael Grzeschik wrote:
> From: Philipp Wiesner
>
> Added this info to Kconfig and mt9m111.c, some comment cleanup,
> replaced 'mt9m11x'-statements by clarifications or driver name.
> Driver is fully compatible to mt9m131 which has only additional functions
> compared to mt9m111. Those aren't used anyway at the moment.
>
> Signed-off-by: Philipp Wiesner
> ---
> drivers/media/video/Kconfig |5 +++--
> drivers/media/video/mt9m111.c | 37 +++--
> 2 files changed, 26 insertions(+), 16 deletions(-)
>
[snip]
> diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
> index d35f536..e934559 100644
> --- a/drivers/media/video/mt9m111.c
> +++ b/drivers/media/video/mt9m111.c
[snip]
> @@ -970,21 +976,24 @@ static int mt9m111_video_probe(struct soc_camera_device
> *icd,
> data = reg_read(CHIP_VERSION);
>
> switch (data) {
> - case 0x143a: /* MT9M111 */
> + case 0x143a: /* MT9M111 or MT9M131 */
> mt9m111->model = V4L2_IDENT_MT9M111;
> + dev_info(&client->dev,
> + "Detected a MT9M111/MT9M131 chip ID %x\n", data);
> break;
> case 0x148c: /* MT9M112 */
> mt9m111->model = V4L2_IDENT_MT9M112;
> + dev_info(&client->dev, "Detected a MT9M112 chip ID %x\n", data);
> break;
> default:
> ret = -ENODEV;
> dev_err(&client->dev,
> - "No MT9M11x chip detected, register read %x\n", data);
> + "No MT9M111/MT9M112/MT9M131 chip detected, "
> + "register read %x\n",
Please, join the strings onto one line. Don't worry about > 80 characters.
> + data);
> goto ei2c;
> }
>
> - dev_info(&client->dev, "Detected a MT9M11x chip ID %x\n", data);
> -
> ei2c:
> return ret;
> }
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Jul 31 19:00:17 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@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.
On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote: > On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus > wrote: > > Hi Jon, > > > > on 31 Jul 10 at 12:25, Jon Smirl wrote: > >> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@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.
On Sat, Jul 31, 2010 at 2:14 PM, Jon Smirl wrote: > On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus > wrote: >> Hi Jon, >> >> on 31 Jul 10 at 12:25, Jon Smirl wrote: >>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls >>> 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 > jonsm...@gmail.com > -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~stoth/cx23885-mpx
On Sat, 2010-07-31 at 12:31 -0400, Steven Toth wrote: > Mauro, > > Please pull from http://www.kernellabs.com/hg/~stoth/cx23885-mpx > >- cx23885: prepare the cx23885 makefile for alsa support >- cx23885: merge mijhail's header changes for alsa >- cx23885: ALSA support >- cx23885: core changes requireed for ALSA >- cx23885: add definitions for HVR1500 to support audio >- cx23885: correct the contrast, saturation and hue controls >- cx23885: hooks the alsa changes into the video subsystem >- cx23885: convert call clients into subdevices >- cx23885: replaced spinlock with mutex >- cx23885: minor function renaming to ensure uniformity >- cx23885: setup the dma mapping for raw audio support >- cx23885: mute the audio during channel change >- cx23885: add two additional defines to simplify VBI register > bitmap handling >- cx23885: initial support for VBI with the cx23885 >- cx23885: initialize VBI support in the core, add IRQ support, > register vbi device >- cx23885: minor printk cleanups and device registration >- cx25840: enable raw cc processing only for the cx23885 hardware >- cx23885: vbi line window adjustments >- cx23885: add vbi buffer formatting, window changes and video core > changes >- cx23885: Ensure the VBI pixel format is established correctly. >- cx23885: convert from snd_card_new() to snd_card_create() >- cx23885: ensure video is streaming before allowing vbi to stream >- cx23885: vbi related codingstyle cleanups >- cx23885: removal of VBI and earlier VBI printk debugging >- cx23885: removal of redundant code, this is no longer required. >- cx23885: remove channel dump diagnostics when a vbi buffer times out. >- cx23885: Ensure VBI buffers timeout quickly - bugfix for vbi > hangs during streaming. >- cx23885: coding style violation cleanups >- cx23885: Convert a mutex back to a spinlock >- cx23885: Name an internal i2c part and declare a bitfield by name >- cx25840: Enable support for non-tuner LR1/LR2 audio inputs >- cx23885: Allow the audio mux config to be specified on a per input > basis. >- cx23885: remove a line of debug >- cx23885: Enable audio line in support from the back panel >- cx25840: Ensure AUDIO6 and AUDIO7 trigger line-in baseband use. >- cx23885: Initial support for the MPX-885 mini-card >- cx23885: fixes related to maximum number of inputs and range checking >- cx23885: add generic functions for dealing with audio input selection >- cx23885: hook the audio selection functions into the main driver >- cx23885: v4l2 api compliance, set the audioset field correctly >- cx23885: Removed a spurious function cx23885_set_scale(). >- cx23885: Avoid stopping the risc engine during buffer timeout. >- cx23885: Avoid incorrect error handling and reporting >- cx23885: Stop the risc video fifo before reconfiguring it. > > b/linux/drivers/media/video/cx23885/cx23885-alsa.c | 542 + > linux/Documentation/video4linux/CARDLIST.cx23885 |1 > linux/drivers/media/video/cx23885/Makefile |2 > linux/drivers/media/video/cx23885/cx23885-alsa.c | 28 > linux/drivers/media/video/cx23885/cx23885-cards.c | 53 > linux/drivers/media/video/cx23885/cx23885-core.c | 127 +- > linux/drivers/media/video/cx23885/cx23885-i2c.c|1 > linux/drivers/media/video/cx23885/cx23885-reg.h|3 > linux/drivers/media/video/cx23885/cx23885-vbi.c| 96 + > linux/drivers/media/video/cx23885/cx23885-video.c | 556 ++ > linux/drivers/media/video/cx23885/cx23885.h| 65 + > linux/drivers/media/video/cx25840/cx25840-audio.c |9 > linux/drivers/media/video/cx25840/cx25840-core.c | 21 > 13 files changed, 1257 insertions(+), 247 deletions(-) > > A pretty large patch set which adds a number of important features to > the cx23885 driver. I have a few cx25840 related comments: 1. Please don't abuse CX25840_AUDIOn and make it mean something other than its current usage of specifying which input the SIF audio is coming in on. The cx25840 module has enough confusion in it already. Let's not overload the current enumerations. Also the current cx25840 keys off of CX25840_AUDIOn vs CX25840_AUDIO_SERIAL to set up a number of things: sample rate convertors and the Baseband Path 1 routing for the CX23885 family at least. It would be better to add new enumaerated values for CX23885_AUDIO_LR1, or whatever, to achieve your desired audio input configuration tasks. 2. The raw VBI startup you added in the cx25840 module is not going to serve you well. It is true that it is harmless to existing non-CX2388[578] boards. However, any app action that causes cx25840_std_setup() to be called will change register 0x474 to probably something you are not expecting. It would be better for you, in the long run, to fix up cx25840_std_setup() and
Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.
On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus wrote: > Hi Jon, > > on 31 Jul 10 at 12:25, Jon Smirl wrote: >> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls >> 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 jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@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.
Hi Jon, on 31 Jul 10 at 12:25, Jon Smirl wrote: > On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls > 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-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] IR keymap: Add print button for HP OEM version of MCE remote
This patch adds a defintion for the "Print" button found on HP OEM
versions of the MCE remote. All of the other keys found on the HP OEM
version of the remote match the other keys as already defined.
Because, who doesn't need "remote printing", while one is sitting on the
couch across from one's PC? ;)
Signed-off-by: Andy Walls
diff --git a/drivers/media/IR/keymaps/rc-rc6-mce.c b/drivers/media/IR/keymaps/rc
index c6726a8..3edda53 100644
--- a/drivers/media/IR/keymaps/rc-rc6-mce.c
+++ b/drivers/media/IR/keymaps/rc-rc6-mce.c
@@ -74,6 +74,8 @@ static struct ir_scancode rc6_mce[] = {
{ 0x800f045a, KEY_SUBTITLE }, /* Caption/Teletext */
{ 0x800f044d, KEY_TITLE },
+ { 0x800f044e, KEY_PRINT }, /* Print - HP OEM version of remote */
+
{ 0x800f040c, KEY_POWER },
{ 0x800f040d, KEY_PROG1 }, /* Windows MCE button */
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@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.
On Sat, 2010-07-31 at 12:25 -0400, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@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.
On Sat, 2010-07-31 at 12:25 -0400, Jon Smirl wrote: > On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.kernellabs.com/hg/~stoth/cx23885-mpx
Mauro, Please pull from http://www.kernellabs.com/hg/~stoth/cx23885-mpx - cx23885: prepare the cx23885 makefile for alsa support - cx23885: merge mijhail's header changes for alsa - cx23885: ALSA support - cx23885: core changes requireed for ALSA - cx23885: add definitions for HVR1500 to support audio - cx23885: correct the contrast, saturation and hue controls - cx23885: hooks the alsa changes into the video subsystem - cx23885: convert call clients into subdevices - cx23885: replaced spinlock with mutex - cx23885: minor function renaming to ensure uniformity - cx23885: setup the dma mapping for raw audio support - cx23885: mute the audio during channel change - cx23885: add two additional defines to simplify VBI register bitmap handling - cx23885: initial support for VBI with the cx23885 - cx23885: initialize VBI support in the core, add IRQ support, register vbi device - cx23885: minor printk cleanups and device registration - cx25840: enable raw cc processing only for the cx23885 hardware - cx23885: vbi line window adjustments - cx23885: add vbi buffer formatting, window changes and video core changes - cx23885: Ensure the VBI pixel format is established correctly. - cx23885: convert from snd_card_new() to snd_card_create() - cx23885: ensure video is streaming before allowing vbi to stream - cx23885: vbi related codingstyle cleanups - cx23885: removal of VBI and earlier VBI printk debugging - cx23885: removal of redundant code, this is no longer required. - cx23885: remove channel dump diagnostics when a vbi buffer times out. - cx23885: Ensure VBI buffers timeout quickly - bugfix for vbi hangs during streaming. - cx23885: coding style violation cleanups - cx23885: Convert a mutex back to a spinlock - cx23885: Name an internal i2c part and declare a bitfield by name - cx25840: Enable support for non-tuner LR1/LR2 audio inputs - cx23885: Allow the audio mux config to be specified on a per input basis. - cx23885: remove a line of debug - cx23885: Enable audio line in support from the back panel - cx25840: Ensure AUDIO6 and AUDIO7 trigger line-in baseband use. - cx23885: Initial support for the MPX-885 mini-card - cx23885: fixes related to maximum number of inputs and range checking - cx23885: add generic functions for dealing with audio input selection - cx23885: hook the audio selection functions into the main driver - cx23885: v4l2 api compliance, set the audioset field correctly - cx23885: Removed a spurious function cx23885_set_scale(). - cx23885: Avoid stopping the risc engine during buffer timeout. - cx23885: Avoid incorrect error handling and reporting - cx23885: Stop the risc video fifo before reconfiguring it. b/linux/drivers/media/video/cx23885/cx23885-alsa.c | 542 + linux/Documentation/video4linux/CARDLIST.cx23885 |1 linux/drivers/media/video/cx23885/Makefile |2 linux/drivers/media/video/cx23885/cx23885-alsa.c | 28 linux/drivers/media/video/cx23885/cx23885-cards.c | 53 linux/drivers/media/video/cx23885/cx23885-core.c | 127 +- linux/drivers/media/video/cx23885/cx23885-i2c.c|1 linux/drivers/media/video/cx23885/cx23885-reg.h|3 linux/drivers/media/video/cx23885/cx23885-vbi.c| 96 + linux/drivers/media/video/cx23885/cx23885-video.c | 556 ++ linux/drivers/media/video/cx23885/cx23885.h| 65 + linux/drivers/media/video/cx25840/cx25840-audio.c |9 linux/drivers/media/video/cx25840/cx25840-core.c | 21 13 files changed, 1257 insertions(+), 247 deletions(-) A pretty large patch set which adds a number of important features to the cx23885 driver. Some early patches for the HVR1500 with add support for analog audio (very rough, much rework on these). The University of California sponsored work for the HVR1800 and HVR1850 and raw video and raw audio and VBI support. The Belac Group sponsored changes related to the MPX cx23885 8 input design, adding raw video and audio support. Mencoder now works correctly with the raw video and audio portions of the driver. GStreamer now works correctly using the v4l interfaces from the driver, live video and audio viewing are now possible. NTSC-ZZ-VBI now works correctly for RAW VBI decoding (although TVTime still refuses to work correctly - tvtime bug) Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@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.
On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls 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
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix module dependency selection for Mantis driver
On Fri, Jun 11, 2010 at 8:11 PM, VDR User wrote: > This patch adds missing module dependencies to the Mantis Kconfig file > so that they are selected automatically when the user enables Mantis. > > Signed-off-by: Derek Kelly > -- > > --- v4l-dvb.orig/linux/drivers/media/dvb/mantis/Kconfig 2010-06-11 > 14:28:26.0 -0700 > +++ v4l-dvb/linux/drivers/media/dvb/mantis/Kconfig 2010-06-11 > 14:32:44.0 -0700 > @@ -10,6 +10,8 @@ config MANTIS_CORE > config DVB_MANTIS > tristate "MANTIS based cards" > depends on MANTIS_CORE && DVB_CORE && PCI && I2C > + select DVB_STB0899 > + select DVB_STB6100 > select DVB_MB86A16 > select DVB_ZL10353 > select DVB_STV0299 > Any reason this was ignored? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@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.
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/13] IR: Allow not to compile keymaps in.
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
Acked-by: Jarod Wilson
---
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 502d477..be68172 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -126,7 +126,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..000
--- 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
- *
- * 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
-
-/* 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 ");
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_
[PATCH 09/13] IR: add helper function for hardware with small o/b buffer.
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
Acked-by: Jarod Wilson
---
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 be68172..8053e3b 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 d0c18db..43094e7 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -140,6 +140,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_
[PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.
Signed-off-by: Maxim Levitsky
---
MAINTAINERS |6 +
drivers/media/IR/Kconfig | 14 +
drivers/media/IR/Makefile |1 +
drivers/media/IR/ene_ir.c | 595 +
drivers/media/IR/ene_ir.h | 51 ++---
5 files changed, 265 insertions(+), 402 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
+S: Maintained
+F: drivers/media/IR/ene_ir.c
+F: drivers/media/IR/ene_ir.h
+
EPSON 1355 FRAMEBUFFER DRIVER
M: Christopher Hoover
M: Christopher Hoover
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..5447750 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
*
@@ -25,20 +25,20 @@
#include
#include
#include
-#include
-#include "lirc_ene0100.h"
+#include
+#include
+#include
+#include
+#include "ene_ir.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)
@@ -85,6 +85,7 @@ static int ene_hw_detect(struct ene_device *dev)
u8 hw_revision, old_ver;
u8 tmp;
u8 fw_capabilities;
+ int pll_freq;
tmp = ene_hw_read_reg(dev, ENE_HW_UNK);
ene_hw_write_reg(dev, ENE_HW_UNK, tmp & ~ENE_HW_UNK_CLR);
@@ -96,6 +97,17 @@ static int ene_hw_detect(struct ene_device *dev)
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) >> 4);
+
+ 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) {
ene_printk(KERN_WARNING, "device seems to be disabled\n");
@@ -160,7 +172,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 +180,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 +198,7 @@ static void ene_enable_fan_recieve
[PATCH 10/13] IR: extend interfaces to support more device settings
LIRC: add new IOCTL that enables learning mode (wide band receiver)
Still missing features: carrier report & timeout reports.
Will need to pack these into ir_raw_event
Signed-off-by: Maxim Levitsky
---
.../DocBook/v4l/lirc_device_interface.xml | 16 +++
drivers/media/IR/ir-core-priv.h|1 +
drivers/media/IR/ir-lirc-codec.c | 112
include/media/ir-core.h| 12 ++-
include/media/lirc.h |5 +-
5 files changed, 125 insertions(+), 21 deletions(-)
diff --git a/Documentation/DocBook/v4l/lirc_device_interface.xml
b/Documentation/DocBook/v4l/lirc_device_interface.xml
index 0413234..68134c0 100644
--- a/Documentation/DocBook/v4l/lirc_device_interface.xml
+++ b/Documentation/DocBook/v4l/lirc_device_interface.xml
@@ -229,6 +229,22 @@ on working with the default settings initially.
and LIRC_SETUP_END. Drivers can also choose to ignore these
ioctls.
+
+LIRC_SET_WIDEBAND_RECEIVER
+
+ Some receivers are equipped with special wide band receiver which
is intended
+ to be used to learn output of existing remote.
+ Calling that ioctl with (1) will enable it, and with (0) disable it.
+ This might be useful of receivers that have otherwise narrow band
receiver
+ that prevents them to be used with some remotes.
+ Wide band receiver might also be more precise
+ On the other hand its disadvantage it usually reduced range of reception.
+ Note: wide band receiver might be implictly enabled if you enable
+ carrier reports. In that case it will be disabled as soon as you disable
+ carrier reports. Trying to disable wide band receiver while carrier
+ reports are active will do nothing.
+
+
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 8053e3b..a85a8c7 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -79,6 +79,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..77b5946 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 -ENO
[PATCH 11/13] IR: report unknown scancodes the in-kernel decoders found.
This way it is possible to use evtest to create keymap for unknown remote.
Signed-off-by: Maxim Levitsky
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/13] IR: NECX: support repeat
This adds support for repeat detecting for NECX variant
Tested with uneversal remote
Signed-off-by: Maxim Levitsky
---
drivers/media/IR/ir-core-priv.h |2 ++
drivers/media/IR/ir-nec-decoder.c | 23 +--
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 84c7a9a..502d477 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -45,6 +45,8 @@ struct ir_raw_event_ctrl {
int state;
unsigned count;
u32 bits;
+ bool is_nec_x;
+ bool necx_repeat;
} 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..d597421 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)
#defineNEC_TRAILER_PULSE (1 * NEC_UNIT)
#defineNEC_TRAILER_SPACE (10 * NEC_UNIT) /* even longer in
reality */
+#define NECX_REPEAT_BITS 1
enum nec_state {
STATE_INACTIVE,
@@ -67,8 +68,12 @@ 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;
+ data->necx_repeat = 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 +110,17 @@ static int ir_nec_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
if (ev.pulse)
break;
+ if (data->necx_repeat && data->count == NECX_REPEAT_BITS &&
+ geq_margin(ev.duration,
+ NEC_TRAILER_SPACE, NEC_UNIT / 2)) {
+ IR_dprintk(1, "Repeat last key\n");
+ ir_repeat(input_dev);
+ data->state = STATE_INACTIVE;
+ return 0;
+
+ } else if (data->count > NECX_REPEAT_BITS)
+ data->necx_repeat = false;
+
data->bits <<= 1;
if (eq_margin(ev.duration, NEC_BIT_1_SPACE, NEC_UNIT / 2))
data->bits |= 1;
@@ -159,6 +175,9 @@ static int ir_nec_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
IR_dprintk(1, "NEC scancode 0x%04x\n", scancode);
}
+ if (data->is_nec_x)
+ data->necx_repeat = true;
+
ir_keydown(input_dev, scancode, 0);
data->state = STATE_INACTIVE;
return 0;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/13] IR: nec decoder: fix repeat.
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 Reviewed-by: Andy Walls --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/13] IR: JVC: make repeat work
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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/13] IR: replace spinlock with mutex.
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
---
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
-#include
+#include
#include
#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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/13] IR: replace workqueue with kthread
It is perfectly possible to have ir_raw_event_work
running concurently on two cpus, thus we must protect
it from that situation.
This stems from the fact that if hardware sends short packets of samples
we might end up queueing the work item more times that nessesary.
Such job isn't well suited for a workqueue, so use a kernel thread.
Signed-off-by: Maxim Levitsky
---
drivers/media/IR/ir-core-priv.h |2 +-
drivers/media/IR/ir-raw-event.c | 42 --
2 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index dc26e2b..84c7a9a 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -32,7 +32,7 @@ struct ir_raw_handler {
struct ir_raw_event_ctrl {
struct list_headlist; /* to keep track of raw
clients */
- struct work_struct rx_work;/* for the rx decoding
workqueue */
+ struct task_struct *thread;
struct kfifokfifo; /* fifo for the
pulse/space durations */
ktime_t last_event; /* when last event
occurred */
enum raw_event_type last_type; /* last event type */
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index 9d5c029..d0c18db 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -12,9 +12,10 @@
* GNU General Public License for more details.
*/
-#include
+#include
#include
#include
+#include
#include "ir-core-priv.h"
/* Define the max number of pulse/space transitions to buffer */
@@ -33,20 +34,30 @@ static u64 available_protocols;
static struct work_struct wq_load;
#endif
-static void ir_raw_event_work(struct work_struct *work)
+static int ir_raw_event_thread(void *data)
{
struct ir_raw_event ev;
struct ir_raw_handler *handler;
- struct ir_raw_event_ctrl *raw =
- container_of(work, struct ir_raw_event_ctrl, rx_work);
+ struct ir_raw_event_ctrl *raw = (struct ir_raw_event_ctrl *)data;
+
+ while (!kthread_should_stop()) {
+ try_to_freeze();
- 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);
+
+ while (kfifo_out(&raw->kfifo, &ev, sizeof(ev)) == sizeof(ev)) {
+ list_for_each_entry(handler, &ir_raw_handler_list, list)
+ handler->decode(raw->input_dev, ev);
+ raw->prev_ev = ev;
+ }
+
mutex_unlock(&ir_raw_handler_lock);
- raw->prev_ev = ev;
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule();
}
+
+ return 0;
}
/**
@@ -141,7 +152,7 @@ void ir_raw_event_handle(struct input_dev *input_dev)
if (!ir->raw)
return;
- schedule_work(&ir->raw->rx_work);
+ wake_up_process(ir->raw->thread);
}
EXPORT_SYMBOL_GPL(ir_raw_event_handle);
@@ -170,7 +181,7 @@ int ir_raw_event_register(struct input_dev *input_dev)
return -ENOMEM;
ir->raw->input_dev = input_dev;
- INIT_WORK(&ir->raw->rx_work, ir_raw_event_work);
+
ir->raw->enabled_protocols = ~0;
rc = kfifo_alloc(&ir->raw->kfifo, sizeof(s64) * MAX_IR_EVENT_SIZE,
GFP_KERNEL);
@@ -180,6 +191,15 @@ int ir_raw_event_register(struct input_dev *input_dev)
return rc;
}
+ ir->raw->thread = kthread_run(ir_raw_event_thread, ir->raw,
+ "rc%u", (unsigned int)ir->devno);
+
+ if (IS_ERR(ir->raw->thread)) {
+ kfree(ir->raw);
+ ir->raw = NULL;
+ return PTR_ERR(ir->raw->thread);
+ }
+
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)
@@ -198,7 +218,7 @@ void ir_raw_event_unregister(struct input_dev *input_dev)
if (!ir->raw)
return;
- cancel_work_sync(&ir->raw->rx_work);
+ kthread_stop(ir->raw->thread);
mutex_lock(&ir_raw_handler_lock);
list_del(&ir->raw->list);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/13] IR: minor fixes:
* 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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/13] IR: Kconfig fixes
Move IR drives below separate menu. This allows to disable them. Also correct a typo. Signed-off-by: Maxim Levitsky --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9 v4] IR: few fixes, additions and ENE driver
Hi, 4th revision of my patches below: Changes: * more carefull repeat support in NECX protocol * added documentation for wide band mode ioctl * fix for 64 bit divide * updated summary of patches, and preserved few * Acked/Reviewed by tags you gave me. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@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.
On Sat, 2010-07-31 at 10:37 -0400, Jon Smirl wrote: > On Sat, Jul 31, 2010 at 10:28 AM, Maxim Levitsky > 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 wrote: > >> > > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky > >> > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@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.
On Sat, Jul 31, 2010 at 10:28 AM, Maxim Levitsky 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 wrote: >> > > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky >> > > > 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 jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Nova-S-Plus audio line input
Hi everyone,
This patch adds audio DMA capture and ALSA mixer elements for the line
input jack of the Hauppauge Nova-S-plus DVB-S PCI card.
I'm using a Hauppauge Nova-S-plus PCI card to watch sat TV and it's been
very robust - thanks to everyone here. I have one minor niggle - when I
use it with composite video input from an external STB I can't connect
the audio to the line input jack on the card. So I developed this
patch, originally in late 2008 with lots of feedback and input from
Darron Broad.
The Nova-S-plus has a WM8775 ADC that is currently not detected. This
patch enables this chip and exports elements for ALSA mixer controls.
I've used this patch with kernels from 2.6.24 to 2.6.35-rc6 and I'm just
a little tired of tweaking it every time a new kernel comes out so I'm
hoping that it can be permanently included.
Signed-off by Lawrence Rust
diff --git a/drivers/media/video/cx88/cx88-alsa.c
b/drivers/media/video/cx88/cx88-alsa.c
index 33082c9..044516b 100644
--- a/drivers/media/video/cx88/cx88-alsa.c
+++ b/drivers/media/video/cx88/cx88-alsa.c
@@ -588,6 +588,30 @@ static int snd_cx88_volume_put(struct snd_kcontrol
*kcontrol,
int changed = 0;
u32 old;
+/* If a WM8775 is used for audio input utilise the audio controls */
+if ( core->board.audio_chip && core->board.audio_chip ==
V4L2_IDENT_WM8775) {
+struct v4l2_control client_ctl;
+
+if ( value->value.integer.value[0] >= value->value.integer.value[1]) {
+v = value->value.integer.value[0] << 10;
+b = value->value.integer.value[0] ?
+ (0x8000 * value->value.integer.value[1]) /
value->value.integer.value[0] :
+ 0x8000;
+} else {
+v = value->value.integer.value[1] << 10;
+b = value->value.integer.value[1] ?
+ 0x - (0x8000 * value->value.integer.value[0]) /
value->value.integer.value[1] :
+ 0x8000;
+}
+client_ctl.value = v;
+client_ctl.id = V4L2_CID_AUDIO_VOLUME;
+call_all(core, core, s_ctrl, &client_ctl);
+
+client_ctl.value = b;
+client_ctl.id = V4L2_CID_AUDIO_BALANCE;
+call_all(core, core, s_ctrl, &client_ctl);
+}
+
left = value->value.integer.value[0] & 0x3f;
right = value->value.integer.value[1] & 0x3f;
b = right - left;
@@ -601,10 +625,10 @@ static int snd_cx88_volume_put(struct snd_kcontrol
*kcontrol,
spin_lock_irq(&chip->reg_lock);
old = cx_read(AUD_VOL_CTL);
if (v != (old & 0x3f)) {
- cx_write(AUD_VOL_CTL, (old & ~0x3f) | v);
+cx_swrite(SHADOW_AUD_VOL_CTL, AUD_VOL_CTL, (old & ~0x3f) | v);
changed = 1;
}
- if (cx_read(AUD_BAL_CTL) != b) {
+if ((cx_read(AUD_BAL_CTL) & 0x7f) != b) {
cx_write(AUD_BAL_CTL, b);
changed = 1;
}
@@ -619,7 +643,7 @@ static struct snd_kcontrol_new snd_cx88_volume = {
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
.access = SNDRV_CTL_ELEM_ACCESS_READWRITE |
SNDRV_CTL_ELEM_ACCESS_TLV_READ,
- .name = "Playback Volume",
+ .name = "Tuner Volume",
.info = snd_cx88_volume_info,
.get = snd_cx88_volume_get,
.put = snd_cx88_volume_put,
@@ -650,7 +674,14 @@ static int snd_cx88_switch_put(struct snd_kcontrol
*kcontrol,
vol = cx_read(AUD_VOL_CTL);
if (value->value.integer.value[0] != !(vol & bit)) {
vol ^= bit;
- cx_write(AUD_VOL_CTL, vol);
+cx_swrite(SHADOW_AUD_VOL_CTL, AUD_VOL_CTL, vol);
+/* If a WM8775 is used for audio input utilise the audio controls */
+if ( (1<<6) == bit && core->board.audio_chip && core->board.audio_chip
== V4L2_IDENT_WM8775) {
+struct v4l2_control client_ctl;
+client_ctl.value = 0 == value->value.integer.value[0];
+client_ctl.id = V4L2_CID_AUDIO_MUTE;
+call_all(core, core, s_ctrl, &client_ctl);
+}
ret = 1;
}
spin_unlock_irq(&chip->reg_lock);
@@ -659,7 +690,7 @@ static int snd_cx88_switch_put(struct snd_kcontrol
*kcontrol,
static struct snd_kcontrol_new snd_cx88_dac_switch = {
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
- .name = "Playback Switch",
+ .name = "Audio Out Switch",
.info = snd_ctl_boolean_mono_info,
.get = snd_cx88_switch_get,
.put = snd_cx88_switch_put,
@@ -668,7 +699,7 @@ static struct snd_kcontrol_new snd_cx88_dac_switch = {
static struct snd_kcontrol_new snd_cx88_source_switch = {
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
- .name = "Capture Switch",
+ .name = "Tuner Switch",
.info = snd_ctl_boolean_mono_info,
.get = snd_cx88_switch_get,
.put = snd_cx88_switch_put,
diff --git a/drivers/media/video/cx88/cx88-cards.c
b/drivers/media/video/cx88/cx88-cards.c
index 2918a6e..c7ac0fe 100644
--- a/drivers/media/video/cx88/cx88-cards.c
+++ b/drivers/media/vide
Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.
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 wrote: > > > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] soc-camera, sh-vou, v4l2 for 2.6.36
Hi Mauro On Fri, 30 Jul 2010, Mauro Carvalho Chehab wrote: > Em 29-07-2010 06:31, Guennadi Liakhovetski escreveu: > > Hi Mauro > > > > The following changes since commit c57fd88318988f17731e446fe1d8498f506fdd44: > > > > V4L/DVB: uvcvideo: Add support for Manta MM-353 Plako (2010-07-05 > > 19:47:16 -0300) > > > > are available in the git repository at: > > git://linuxtv.org/gliakhovetski/v4l-dvb.git for-2.6.36 > > > > Guennadi Liakhovetski (8): > > mediabus: fix ambiguous pixel code names > > V4L2: avoid name conflicts in macros > > This patch is incomplete, as other macros use sd without declaring it > as an argument, like: > > #define v4l2_device_call_all(v4l2_dev, grpid, o, f, args...)\ > __v4l2_device_call_subdevs(v4l2_dev,\ > !(grpid) || sd->grp_id == (grpid), o, f , ##args) > > To make things even worse, some drivers have their own opinion about it, like: > > #define cx18_call_hw(cx, hw, o, f, args...) \ > __v4l2_device_call_subdevs(&(cx)->v4l2_dev, \ >!(hw) || (sd->grp_id & (hw)), o, f , > ##args) > > The result is that this patch breaks the compilation on several drivers. > > It is not your patch's fault. the problem is that those macros have something > to hide. If sd is a parameter of the macro, they should have being declaring > sd into their lists of arguments. nice... > Please provide a version that will properly address those problems. > > As the other patches don't seem to need this change (at least, all compiled > fine here), I'll drop this patch and apply the remaining ones. Thanks, that's a perfect solution for now! I'll think, if I can solve this probelm(s) properly. I'm on a holiday for the next 2 weeks, so, don't know when I'll be able to provide a new version. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@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.
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 wrote: > > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Handling of large keycodes
Hi Dmitry, Em 31-07-2010 06:19, Dmitry Torokhov escreveu: > Hi Mauro, > > I finally got a chance to review the patches adding handling of large > scancodes to input core and there are a few things with this approach > that I do not like. Thanks for the review! > First of all I do not think that we should be working with scancode via > a pointer as it requires additional compat handling when running 32-bit > userspace on 64-bit kernel. We can use a static buffer of sufficient > size (lets say 32 bytes) to move scancode around and simply increase its > size if we come upon device that uses even bigger scancodes. As long as > buffer is at the end we can handle this in a compatible way. Yes, this is the downside of using a pointer. I'm not aware of a Remote Controller protocol using more than 256 bits for scancode, so 32 bits should be ok. > The other issue is that interface is notsymmetrical, setting is done by > scancode but retrieval is done by index. I think we should be able to > use both scancode and index in both operations. Yes, this also bothered me. I was thinking to do something similar to your approach of having a bool to select between them. This change is welcome. > The usefulnes of reserved data elements in the structure is doubtful, > since we do not seem to require them being set to a particular value and > so we'll be unable to distinguish betwee legacy and newer users. David proposed some parameters that we rejected on our discussions. As we might need to add something similar, I decided to keep it on my approach, since a set of reserved fields wouldn't hurt (and removing it on our discussions would be easy), but I'm ok on removing them. > I also concerned about the code very messy with regard to using old/new > style interfaces instea dof converting old ones to use new > insfrastructure, Good cleanup at the code! > I below is something that addresses these issues and seems to be working > for me. It is on top of your patches and it also depends on a few > changes in my tree that I have not publushed yet but plan on doing that > tomorrow. I am also attaching patches converting sparse keymap and hid > to the new style of getkeycode and setkeycode as examples. > > Please take a look and let me know if I missed something important. It seems to work for me. After you add the patches on your git tree, I'll work on porting the RC core to the new approach, and change the ir-keycode userspace program to work with, in order to be 100% sure that it will work, but I can't foresee any missing part on it. Currently, I'm not using my input patches, as I was waiting for your review. I just patched the userspace application, in order to test the legacy mode. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Handling of large keycodes
Stefan Richter wrote: > - I take it from your description that scan codes are fundamentally > variable-length data. How about defining it as __u8 scancode[0]? Forget this; that would make it difficult to extend the ABI later by adding more struct members. -- Stefan Richter -=-==-=- -=== = http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Handling of large keycodes
Dmitry Torokhov wrote:
> --- a/include/linux/input.h
> +++ b/include/linux/input.h
> @@ -56,22 +56,35 @@ struct input_absinfo {
> __s32 resolution;
> };
>
> -struct keycode_table_entry {
> - __u32 keycode; /* e.g. KEY_A */
> - __u32 index;/* Index for the given scan/key table, on
> EVIOCGKEYCODEBIG */
> - __u32 len; /* Length of the scancode */
> - __u32 reserved[2]; /* Reserved for future usage */
> - char *scancode; /* scancode, in machine-endian */
> +/**
> + * struct keymap_entry - used by EVIOCGKEYCODE/EVIOCSKEYCODE ioctls
> + * @scancode: scancode represented in machine-endian form.
> + * @len: length of the scancode that resides in @scancode buffer.
> + * @index: index in the keymap, may be used instead of scancode
> + * @by_index: boolean value indicating that kernel should perform
> + * lookup in keymap by @index instead of @scancode
> + * @keycode: key code assigned to this scancode
> + *
> + * The structure is used to retrieve and modify keymap data. Users have
> + * of performing lookup either by @scancode itself or by @index in
> + * keymap entry. EVIOCGKEYCODE will also return scancode or index
> + * (depending on which element was used to perform lookup).
> + */
> +struct keymap_entry {
> + __u8 len;
> + __u8 by_index;
> + __u16 index;
> + __u32 keycode;
> + __u8 scancode[32];
> };
I agree with Dimitry; don't put a pointer typed member into a userspace
ABI struct.
Two remarks:
- Presently, defines three structs named input_... for
userspace, two structs named input_... for kernelspace, and a few
structs named ff_... specially for force-feedback stuff. How about
calling struct keymap_entry perhaps struct input_keymap_entry
instead, to keep namespaces tidy?
- I take it from your description that scan codes are fundamentally
variable-length data. How about defining it as __u8 scancode[0]?
--
Stefan Richter
-=-==-=- -=== =
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/20] MT9M111/MT9M131
Guennadi Liakhovetski writes: > Hi Michael > > Thanks for the patches, and for taking care about my holiday - now I will > definitely not have to be bored, while lying around on tropical beaches of > Denmark;) Same thing in here, if my wife lets me play with my computer :) I'll review them as soon as possible. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/13] IR: extend interfaces to support more device settings LIRC: add new IOCTL that enables learning mode (wide band receiver)
On Sat, 2010-07-31 at 10:10 +0200, Christoph Bartelmus wrote:
> Hi Maxim,
>
> on 31 Jul 10 at 01:01, Maxim Levitsky wrote:
> > On Fri, 2010-07-30 at 23:22 +0200, Christoph Bartelmus wrote:
> [...]
> >>> +#define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, __u32)
> >>
> >> If you really want this new ioctl, then it should be clarified how it
> >> behaves in relation to LIRC_SET_MEASURE_CARRIER_MODE.
>
> > In my opinion, I won't need the LIRC_SET_MEASURE_CARRIER_MODE,
> > I would just optionally turn that on in learning mode.
> > You disagree, and since that is not important (besides TX and learning
> > features are present only at fraction of ENE devices. The only user I
> > did the debugging with, doesn't seem to want to help debug that code
> > anymore...)
> >
> > But anyway, in current state I want these features to be independent.
> > Driver will enable learning mode if it have to.
>
> Please avoid the term "learning mode" as to you it probably means
> something different than to me.
>
> >
> > I'll add the documentation.
>
> >>
> >> Do you have to enable the wide-band receiver explicitly before you can
> >> enable carrier reports or does enabling carrier reports implicitly switch
> >> to the wide-band receiver?
> > I would implicitly switch the learning mode on, untill user turns off
> > the carrier reports.
>
> You mean that you'll implicitly switch on the wide-band receiver. Ok.
>
> >>
> >> What happens if carrier mode is enabled and you explicitly turn off the
> >> wide-band receiver?
> > Wouldn't it be better to have one ioctl for both after all?
>
> There may be hardware that allows carrier measurement but does not have a
> wide-band receiver. And there may be hardware that does have a wide-band
> receiver but does not allow carrier measurement. irrecord needs to be able
> to distinguish these cases, so we need separate ioctls.
>
> I'd say: carrier reports may switch on the wide-band reciever implicitly.
> In that case the wide-band receiver cannot be switched off explicitly
> until carrier reports are disabled again. It just needs to be documented.
No problem.
Best regards,
Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Handling of large keycodes
Hi Mauro,
I finally got a chance to review the patches adding handling of large
scancodes to input core and there are a few things with this approach
that I do not like.
First of all I do not think that we should be working with scancode via
a pointer as it requires additional compat handling when running 32-bit
userspace on 64-bit kernel. We can use a static buffer of sufficient
size (lets say 32 bytes) to move scancode around and simply increase its
size if we come upon device that uses even bigger scancodes. As long as
buffer is at the end we can handle this in a compatible way.
The other issue is that interface is notsymmetrical, setting is done by
scancode but retrieval is done by index. I think we should be able to
use both scancode and index in both operations.
The usefulnes of reserved data elements in the structure is doubtful,
since we do not seem to require them being set to a particular value and
so we'll be unable to distinguish betwee legacy and newer users.
I also concerned about the code very messy with regard to using old/new
style interfaces instea dof converting old ones to use new
insfrastructure,
I below is something that addresses these issues and seems to be working
for me. It is on top of your patches and it also depends on a few
changes in my tree that I have not publushed yet but plan on doing that
tomorrow. I am also attaching patches converting sparse keymap and hid
to the new style of getkeycode and setkeycode as examples.
Please take a look and let me know if I missed something important.
Thank you.
--
Dmitry
Signed-off-by: Dmitry Torokhov
---
drivers/char/keyboard.c | 31 +++-
drivers/input/evdev.c | 139 +++
drivers/input/input.c | 351 +++
include/linux/input.h | 72 +-
4 files changed, 255 insertions(+), 338 deletions(-)
diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index 54109dc..4dd9fb0 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -175,8 +175,7 @@ EXPORT_SYMBOL_GPL(unregister_keyboard_notifier);
*/
struct getset_keycode_data {
- unsigned int scancode;
- unsigned int keycode;
+ struct keymap_entry ke;
int error;
};
@@ -184,32 +183,50 @@ static int getkeycode_helper(struct input_handle *handle,
void *data)
{
struct getset_keycode_data *d = data;
- d->error = input_get_keycode(handle->dev, d->scancode, &d->keycode);
+ d->error = input_get_keycode(handle->dev, &d->ke);
return d->error == 0; /* stop as soon as we successfully get one */
}
int getkeycode(unsigned int scancode)
{
- struct getset_keycode_data d = { scancode, 0, -ENODEV };
+ struct getset_keycode_data d = {
+ .ke = {
+ .by_index = false,
+ .len= sizeof(scancode),
+ .keycode= 0,
+ },
+ .error = -ENODEV,
+ };
+
+ memcpy(d.ke.scancode, &scancode, sizeof(scancode));
input_handler_for_each_handle(&kbd_handler, &d, getkeycode_helper);
- return d.error ?: d.keycode;
+ return d.error ?: d.ke.keycode;
}
static int setkeycode_helper(struct input_handle *handle, void *data)
{
struct getset_keycode_data *d = data;
- d->error = input_set_keycode(handle->dev, d->scancode, d->keycode);
+ d->error = input_set_keycode(handle->dev, &d->ke);
return d->error == 0; /* stop as soon as we successfully set one */
}
int setkeycode(unsigned int scancode, unsigned int keycode)
{
- struct getset_keycode_data d = { scancode, keycode, -ENODEV };
+ struct getset_keycode_data d = {
+ .ke = {
+ .by_index = false,
+ .len= sizeof(scancode),
+ .keycode= keycode,
+ },
+ .error = -ENODEV,
+ };
+
+ memcpy(d.ke.scancode, &scancode, sizeof(scancode));
input_handler_for_each_handle(&kbd_handler, &d, setkeycode_helper);
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 783cdd3..9c7a97b 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -534,6 +534,80 @@ static int handle_eviocgbit(struct input_dev *dev,
}
#undef OLD_KEY_MAX
+static int evdev_handle_get_keycode(struct input_dev *dev,
+ void __user *p, size_t size)
+{
+ struct keymap_entry ke;
+ int error;
+
+ memset(&ke, 0, sizeof(ke));
+
+ if (size == sizeof(unsigned int[2])) {
+ /* legacy case */
+ int __user *ip = (int __user *)p;
+
+ if (copy_from_user(ke.scancode, p, sizeof(unsigned int)))
+ return -EFAULT;
+
+ ke.len = sizeof(unsigned int);
+ ke.by_index = false;
+
+ error = input_get_keycode(dev, &ke)
Re: [PATCH 10/13] IR: extend interfaces to support more device settings LIRC: add new IOCTL that enables learning mode (wide band receiver)
Hi Maxim,
on 31 Jul 10 at 01:01, Maxim Levitsky wrote:
> On Fri, 2010-07-30 at 23:22 +0200, Christoph Bartelmus wrote:
[...]
>>> +#define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, __u32)
>>
>> If you really want this new ioctl, then it should be clarified how it
>> behaves in relation to LIRC_SET_MEASURE_CARRIER_MODE.
> In my opinion, I won't need the LIRC_SET_MEASURE_CARRIER_MODE,
> I would just optionally turn that on in learning mode.
> You disagree, and since that is not important (besides TX and learning
> features are present only at fraction of ENE devices. The only user I
> did the debugging with, doesn't seem to want to help debug that code
> anymore...)
>
> But anyway, in current state I want these features to be independent.
> Driver will enable learning mode if it have to.
Please avoid the term "learning mode" as to you it probably means
something different than to me.
>
> I'll add the documentation.
>>
>> Do you have to enable the wide-band receiver explicitly before you can
>> enable carrier reports or does enabling carrier reports implicitly switch
>> to the wide-band receiver?
> I would implicitly switch the learning mode on, untill user turns off
> the carrier reports.
You mean that you'll implicitly switch on the wide-band receiver. Ok.
>>
>> What happens if carrier mode is enabled and you explicitly turn off the
>> wide-band receiver?
> Wouldn't it be better to have one ioctl for both after all?
There may be hardware that allows carrier measurement but does not have a
wide-band receiver. And there may be hardware that does have a wide-band
receiver but does not allow carrier measurement. irrecord needs to be able
to distinguish these cases, so we need separate ioctls.
I'd say: carrier reports may switch on the wide-band reciever implicitly.
In that case the wide-band receiver cannot be switched off explicitly
until carrier reports are disabled again. It just needs to be documented.
>>
>> And while we're at interface stuff:
>> Do we really need LIRC_SETUP_START and LIRC_SETUP_END? It is only used
>> once in lircd during startup.
> I don't think so.
>
Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
