summaryrefslogtreecommitdiffstats
path: root/drivers/media
diff options
context:
space:
mode:
authorDavid Härdeman <david@hardeman.nu>2007-02-13 09:39:58 -0300
committerMauro Carvalho Chehab <mchehab@infradead.org>2007-02-21 13:35:32 -0200
commit59327a4897a0395d6f0358574dbb113102b63769 (patch)
tree081274844ce88110376a0052a09bb98816b67bcc /drivers/media
parent89e4d59f2c082be9472c4de4dafb832e01bfbe01 (diff)
downloadop-kernel-dev-59327a4897a0395d6f0358574dbb113102b63769.zip
op-kernel-dev-59327a4897a0395d6f0358574dbb113102b63769.tar.gz
V4L/DVB (5246): Budget-ci: IR handling fixups
Commit 00c4cc67512ada1d195b8bf3ef1db1d6b3951605 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> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Diffstat (limited to 'drivers/media')
-rw-r--r--drivers/media/dvb/ttpci/budget-ci.c26
1 files changed, 20 insertions, 6 deletions
diff --git a/drivers/media/dvb/ttpci/budget-ci.c b/drivers/media/dvb/ttpci/budget-ci.c
index 154cc2d..464feaf 100644
--- a/drivers/media/dvb/ttpci/budget-ci.c
+++ b/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;
OpenPOWER on IntegriCloud