summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorOliver Endriss <o.endriss@gmx.de>2007-02-13 13:39:58 +0100
committerOliver Endriss <o.endriss@gmx.de>2007-02-13 13:39:58 +0100
commit0e9bb1fbb3ec45410ffcea8ffe3f883f7a5b5f0d (patch)
treec4ddf0e39dd83daee79198602535863796065bf9
parentcd02f1c774cfec232d5db61834ddf960bcac0713 (diff)
downloadmediapointer-dvb-s2-0e9bb1fbb3ec45410ffcea8ffe3f883f7a5b5f0d.tar.gz
mediapointer-dvb-s2-0e9bb1fbb3ec45410ffcea8ffe3f883f7a5b5f0d.tar.bz2
budget-ci: IR handling fixups
From: David Härdeman <david@hardeman.nu> Changeset 6562d27de0d7 by Oliver Endriss changed the budget-ci driver to use interrupt mode for i2c transfers. This also meant that a new bunch of IR bytes that were previously lost are now received, which allowed me to better understand how the MSP430 chip works. Unfortunately it also means that the current driver gets some assumptions wrong and might generate double keypresses for one IR command. The attached patch fixes this by throwing away the repeat bytes and by associating the correct command and device bytes. Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Oliver Endriss <o.endriss@gmx.de>
-rw-r--r--linux/drivers/media/dvb/ttpci/budget-ci.c26
1 files changed, 20 insertions, 6 deletions
diff --git a/linux/drivers/media/dvb/ttpci/budget-ci.c b/linux/drivers/media/dvb/ttpci/budget-ci.c
index f86ba0010..7cb60e37b 100644
--- a/linux/drivers/media/dvb/ttpci/budget-ci.c
+++ b/linux/drivers/media/dvb/ttpci/budget-ci.c
@@ -130,6 +130,7 @@ static void msp430_ir_interrupt(unsigned long data)
int toggle;
static int prev_toggle = -1;
static u32 ir_key;
+ static int state = 0;
u32 command = ttpci_budget_debiread(&budget_ci->budget, DEBINOSWAP, DEBIADDR_IR, 2, 1, 0) >> 8;
/*
@@ -138,21 +139,34 @@ static void msp430_ir_interrupt(unsigned long data)
* type1: X1CCCCCC, C = command bits (0 - 63)
* type2: X0TDDDDD, D = device bits (0 - 31), T = RC5 toggle bit
*
- * More than one command byte may be generated before the device byte
- * Only when we have both, a correct keypress is generated
+ * Each signal from the remote control can generate one or more command
+ * bytes and one or more device bytes. For the repeated bytes, the
+ * highest bit (X) is set. The first command byte is always generated
+ * before the first device byte. Other than that, no specific order
+ * seems to apply.
+ *
+ * Only when we have a command and device byte, a keypress is
+ * generated.
*/
+ if (ir_debug)
+ printk("budget_ci: received byte 0x%02x\n", command);
+
+ /* Is this a repeated byte? */
+ if (command & 0x80)
+ return;
+
/* Is this a RC5 command byte? */
if (command & 0x40) {
- if (ir_debug)
- printk("budget_ci: received command byte 0x%02x\n", command);
+ state = 1;
ir_key = command & 0x3f;
return;
}
/* It's a RC5 device byte */
- if (ir_debug)
- printk("budget_ci: received device byte 0x%02x\n", command);
+ if (!state)
+ return;
+ state = 0;
device = command & 0x1f;
toggle = command & 0x20;