diff options
author | David Härdeman <david@hardeman.nu> | 2007-02-13 07:39:58 -0500 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@infradead.org> | 2007-02-21 10:35:32 -0500 |
commit | 59327a4897a0395d6f0358574dbb113102b63769 (patch) | |
tree | 081274844ce88110376a0052a09bb98816b67bcc | |
parent | 89e4d59f2c082be9472c4de4dafb832e01bfbe01 (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>
-rw-r--r-- | drivers/media/dvb/ttpci/budget-ci.c | 26 |
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 | ||