aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/media
diff options
context:
space:
mode:
authorDavid Härdeman <david@hardeman.nu>2007-02-13 07:39:58 -0500
committerMauro Carvalho Chehab <mchehab@infradead.org>2007-02-21 10:35:32 -0500
commit59327a4897a0395d6f0358574dbb113102b63769 (patch)
tree081274844ce88110376a0052a09bb98816b67bcc /drivers/media
parent89e4d59f2c082be9472c4de4dafb832e01bfbe01 (diff)
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 154cc2de8113..464feaf1a9ad 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)
130 int toggle; 130 int toggle;
131 static int prev_toggle = -1; 131 static int prev_toggle = -1;
132 static u32 ir_key; 132 static u32 ir_key;
133 static int state = 0;
133 u32 command = ttpci_budget_debiread(&budget_ci->budget, DEBINOSWAP, DEBIADDR_IR, 2, 1, 0) >> 8; 134 u32 command = ttpci_budget_debiread(&budget_ci->budget, DEBINOSWAP, DEBIADDR_IR, 2, 1, 0) >> 8;
134 135
135 /* 136 /*
@@ -138,21 +139,34 @@ static void msp430_ir_interrupt(unsigned long data)
138 * type1: X1CCCCCC, C = command bits (0 - 63) 139 * type1: X1CCCCCC, C = command bits (0 - 63)
139 * type2: X0TDDDDD, D = device bits (0 - 31), T = RC5 toggle bit 140 * type2: X0TDDDDD, D = device bits (0 - 31), T = RC5 toggle bit
140 * 141 *
141 * More than one command byte may be generated before the device byte 142 * Each signal from the remote control can generate one or more command
142 * Only when we have both, a correct keypress is generated 143 * bytes and one or more device bytes. For the repeated bytes, the
144 * highest bit (X) is set. The first command byte is always generated
145 * before the first device byte. Other than that, no specific order
146 * seems to apply.
147 *
148 * Only when we have a command and device byte, a keypress is
149 * generated.
143 */ 150 */
144 151
152 if (ir_debug)
153 printk("budget_ci: received byte 0x%02x\n", command);
154
155 /* Is this a repeated byte? */
156 if (command & 0x80)
157 return;
158
145 /* Is this a RC5 command byte? */ 159 /* Is this a RC5 command byte? */
146 if (command & 0x40) { 160 if (command & 0x40) {
147 if (ir_debug) 161 state = 1;
148 printk("budget_ci: received command byte 0x%02x\n", command);
149 ir_key = command & 0x3f; 162 ir_key = command & 0x3f;
150 return; 163 return;
151 } 164 }
152 165
153 /* It's a RC5 device byte */ 166 /* It's a RC5 device byte */
154 if (ir_debug) 167 if (!state)
155 printk("budget_ci: received device byte 0x%02x\n", command); 168 return;
169 state = 0;
156 device = command & 0x1f; 170 device = command & 0x1f;
157 toggle = command & 0x20; 171 toggle = command & 0x20;
158 172