[PATCH 1/2] media/rc/imon.c: make send_packet() delay configurable

From: Kevin Baradon
Date: Sun Feb 24 2013 - 15:46:37 EST

Some imon devices (like 15c2:0036) need a higher delay between send_packet calls.
Default value is still 5ms to avoid regressions on already working hardware.

Also use interruptible wait to avoid load average going too high (and let caller handle signals).

Signed-off-by: Kevin Baradon <kevin.baradon@xxxxxxxxx>
drivers/media/rc/imon.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 78d109b..a3e66a0 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -347,6 +347,11 @@ module_param(pad_stabilize, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(pad_stabilize, "Apply stabilization algorithm to iMON PAD "
"presses in arrow key mode. 0=disable, 1=enable (default).");

+static unsigned int send_packet_delay = 5;
+module_param(send_packet_delay, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(send_packet_delay, "Minimum delay between send_packet() calls "
+ "(default 5ms)");
* In certain use cases, mouse mode isn't really helpful, and could actually
* cause confusion, so allow disabling it when the IR device is open.
@@ -535,12 +540,15 @@ static int send_packet(struct imon_context *ictx)

- * Induce a mandatory 5ms delay before returning, as otherwise,
+ * Induce a mandatory delay before returning, as otherwise,
* send_packet can get called so rapidly as to overwhelm the device,
* particularly on faster systems and/or those with quirky usb.
+ * Do not use TASK_UNINTERRUPTIBLE as this routine is called quite often
+ * and doing so will increase load average slightly. Caller will handle
+ * signals itself.
- timeout = msecs_to_jiffies(5);
- set_current_state(TASK_UNINTERRUPTIBLE);
+ timeout = msecs_to_jiffies(send_packet_delay);
+ set_current_state(TASK_INTERRUPTIBLE);

return retval;

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/