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 <[e-mail]>
Signed-off-by: Andreas Oberritter <[e-mail]>
Signed-off-by: Mauro Carvalho Chehab <[e-mail]>

drivers/media/dvb/pluto2/pluto2.c

···
 	 *     but no packets have been transfered.
 	 * [2] Sometimes (actually very often) NBPACKETS stays at zero
 	 *     although one packet has been transfered.
+	 * [3] Sometimes (actually rarely), the card gets into an erroneous
+	 *     mode where it continuously generates interrupts, claiming it
+	 *     has recieved nbpackets>TS_DMA_PACKETS packets, but no packet
+	 *     has been transfered. Only a reset seems to solve this
 	 */
 	if ((nbpackets == 0) || (nbpackets > TS_DMA_PACKETS)) {
 		unsigned int i = 0;
 		while (pluto->dma_buf[i] == 0x47)
 			i += 188;
 		nbpackets = i / 188;
+		if (i == 0) {
+			pluto_reset_ts(pluto, 1);
+			dev_printk(KERN_DEBUG, &pluto->pdev->dev, "resetting TS because of invalid packet counter\n");
+		}
 	}
 
 	dvb_dmx_swfilter_packets(&pluto->demux, pluto->dma_buf, nbpackets);