[PATCH] Fix SAA7134 transport stream errors

[Eric Lammerts]

Hi,
I had a lot of problems with the transport stream input on the
SAA7134. Even the slighest bit of other system activity caused data
corruption. This patch corrects the switching of the two DMA
buffers.

Without the patch, the driver updates the buffer that is just about to
be used by the chip. It still works, but only if no new TS packet
comes in before the registers are updated (in my case there's
typically ~500us between TS packets).

FYI, the problems only occur on Transmeta TM5800/TM5400 Crusoe boards
(1GHz/533MHz). When I move the SAA7134 board to a 400MHz Celeron, no
problems at all. I measured the interrupt latency of the SAA7134
interrupt on the Crusoe, and that peaks to >1000us when power
management is enabled and other activity (IDE DMA) is taking place!!
That may explain why other people haven't seen this problem.

Question for lkml: are interrupt latencies supposed to be like that on
Crusoe systems, or is there something wrong with my boards? Booting
with no-hlt acpi=off apm=off, setting the cpufreq governor to
performance, or running a reniced "while :; do :; done" in the
background all seem to help quite a bit, but it doesn't eliminate the
problem completely.

Eric

--- video4linux/saa7134-ts.c.orig	2004-12-10 08:07:00.000000000 -0500
+++ video4linux/saa7134-ts.c	2005-02-01 18:58:50.000000000 -0500
@@ -221,10 +221,10 @@
 	if (dev->ts_q.curr) {
 		field = dev->ts_q.curr->vb.field;
 		if (field == V4L2_FIELD_TOP) {
-			if ((status & 0x100000) != 0x100000)
+			if ((status & 0x100000) == 0x100000)
 				goto done;
 		} else {
-			if ((status & 0x100000) != 0x000000)
+			if ((status & 0x100000) == 0x000000)
 				goto done;
 		}
 		saa7134_buffer_finish(dev,&dev->ts_q,STATE_DONE);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/