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=/