aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
diff options
context:
space:
mode:
authorholger@muscate-magnussen.de <holger@muscate-magnussen.de>2007-05-01 08:25:56 -0400
committerMauro Carvalho Chehab <mchehab@infradead.org>2007-05-09 09:12:35 -0400
commit4d8451700171d6bbc254191880f86bfdeec2f74f (patch)
tree4b08ddedcb6717f189668e66e6f35e496ae318ff /drivers
parentba70d59bb987110c4394e896b299f9726609aa33 (diff)
V4L/DVB (5578): Workaround for bad hardare/firmware on some pluto2 devices
pluto2_driver: Workaround for pluto2 card reporting wrong number of received packets and flooding system with interrupts. This patch constitutes a workaround for a hardware/firmware problem of the pluto2-based card (e.g., Satelco EasyWatch). It can happen in rare cases that the card gets into a mode where it always reports back a number of received packets (nbpackets) which is larger than the maximum permissible number of packets (TS_DMA_PACKETS). The workaround that is already in the driver in function pluto_dma_end reports back zero received packets. In spite of the (in reality) zero received packets the card continues to generate interrupts at a very high rate, which can effectively stall the system. The patch resets the TS logic, which puts the card back into normal operations. Signed-off-by: Holger Magnussen <holger@muscate-magnussen.de> Signed-off-by: Andreas Oberritter <obi@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/media/dvb/pluto2/pluto2.c8
1 files changed, 8 insertions, 0 deletions
diff --git a/drivers/media/dvb/pluto2/pluto2.c b/drivers/media/dvb/pluto2/pluto2.c
index 058df5c10034..08a2599ed74a 100644
--- a/drivers/media/dvb/pluto2/pluto2.c
+++ b/drivers/media/dvb/pluto2/pluto2.c
@@ -293,12 +293,20 @@ static void pluto_dma_end(struct pluto *pluto, unsigned int nbpackets)
293 * but no packets have been transfered. 293 * but no packets have been transfered.
294 * [2] Sometimes (actually very often) NBPACKETS stays at zero 294 * [2] Sometimes (actually very often) NBPACKETS stays at zero
295 * although one packet has been transfered. 295 * although one packet has been transfered.
296 * [3] Sometimes (actually rarely), the card gets into an erroneous
297 * mode where it continuously generates interrupts, claiming it
298 * has recieved nbpackets>TS_DMA_PACKETS packets, but no packet
299 * has been transfered. Only a reset seems to solve this
296 */ 300 */
297 if ((nbpackets == 0) || (nbpackets > TS_DMA_PACKETS)) { 301 if ((nbpackets == 0) || (nbpackets > TS_DMA_PACKETS)) {
298 unsigned int i = 0; 302 unsigned int i = 0;
299 while (pluto->dma_buf[i] == 0x47) 303 while (pluto->dma_buf[i] == 0x47)
300 i += 188; 304 i += 188;
301 nbpackets = i / 188; 305 nbpackets = i / 188;
306 if (i == 0) {
307 pluto_reset_ts(pluto, 1);
308 dev_printk(KERN_DEBUG, &pluto->pdev->dev, "resetting TS because of invalid packet counter\n");
309 }
302 } 310 }
303 311
304 dvb_dmx_swfilter_packets(&pluto->demux, pluto->dma_buf, nbpackets); 312 dvb_dmx_swfilter_packets(&pluto->demux, pluto->dma_buf, nbpackets);