DC10+ woes

Martin Samuelsson <[email protected]> Fri, 25 Jul 2008 09:28:39 +0200
Newsgroups gmane.comp.video.mjpeg.devel
Message-ID <[email protected]>
As some of you are aware of, I'm loopking into why my DC10+ fails to play more than 66 frames of video through the onboard connector, while a Buz in the same machine play the whole file without any problem.

After a day of experiments yesterday, I've established that the DC10+'s behavior would be explained if a) the buffer data arrives late and b) DATERR in zr36060 register 0x007 (ZR060_IMR) is set. That would signal an underrun error that would lock playback until the ZR060_ISR register is read.

However, as far as I'm able to check out, DATERR is never set, and that would invalidate the whole theory. I am not pleased.

The whole thing boils down to


	if (!wait_event_interruptible_timeout(zr->jpg_capq,
			(zr->jpg_que_tail != zr->jpg_dma_tail ||
			 zr->jpg_dma_tail == zr->jpg_dma_head),
			10*HZ)) {

in jpg_sync() in zoran_driver.c failing. It continues to fail until 

		zr->codec->control(zr->codec, CODEC_G_STATUS,
					   sizeof(isr), &isr);

is executed. After that, the numbers line up correctly again.

While playing, jpg_dma_head, jpg_dma_tail and jpg_que_tail follow this pattern in the Buz:

Jul 24 17:43:36 klon kernel: Buz[1]: jpg_sync() - pre-wait:  39 35 35
Jul 24 17:43:36 klon kernel: Buz[1]: jpg_sync() - post-wait: 40 36 35
Jul 24 17:43:36 klon kernel: Buz[1]: jpg_sync() - pre-wait:  40 36 36
Jul 24 17:43:36 klon kernel: Buz[1]: jpg_sync() - post-wait: 41 37 36
Jul 24 17:43:36 klon kernel: Buz[1]: jpg_sync() - pre-wait:  41 37 37
Jul 24 17:43:36 klon kernel: Buz[1]: jpg_sync() - post-wait: 42 38 37

While the DC10+ fail:

Jul 24 17:42:45 klon kernel: DC10plus[0]: jpg_sync() - pre-wait:  39 35 35
Jul 24 17:42:45 klon kernel: DC10plus[0]: jpg_sync() - post-wait: 40 36 35
Jul 24 17:42:45 klon kernel: DC10plus[0]: jpg_sync() - pre-wait:  40 36 36
Jul 24 17:42:46 klon kernel: DC10plus[0]: jpg_sync() - timeout: codec isr=0x07
Jul 24 17:42:46 klon kernel: DC10plus[0]: jpg_sync() - jpg_dma_head: 41
Jul 24 17:42:46 klon kernel: DC10plus[0]: jpg_sync() - jpg_dma_tail: 37
Jul 24 17:42:46 klon kernel: DC10plus[0]: jpg_sync() - jpg_que_tail: 36

CODEC_G_STATUS is done before the "timeout:" line, and fixes the numbers until the following lines are written.

(Another curiosity: CODEC_G_STATUS reads ZR060_CFSR (0x0001). I can't find any notes in the zr36060 data sheet that reading that register would affect anything like this.)

If I comment out 

		btand(~ZR36057_JMC_Go_en, ZR36057_JMC);
and
		return -ETIME;

in the error handling, playback continues after the 10 second timeout, until the next lockup, where the cycle repeat itself until the end of the file is reached.

I do, however, think a) is true.

If I give s0 to lavplay before the lockup, and then step frame by frame with +, nothing bad happens.

I'm currently at a loss here. It's the same code in both cases, with the same register settings, as far as I know, and yet the DC10+ locks up while the Buz doesn't. Every time.

Any ideas?

/Sam

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/