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);
On Tue, Feb 01, 2005 at 08:19:17PM -0500, Eric Lammerts wrote:
>
> 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.
Thanks, merged (and fixed a simliar issue in saa7134-video.c along the
way ;).
> 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.
It has shown up before already (long ago), thats why the two-buffer
thingy exists in the first place. Looks like 2.6 really makes a better
job on low-latency than 2.4 did, otherwise that would have been noticed
earlier...
Gerd