On Sat, 2009-08-29 at 01:04 -0500, Chris Kennedy wrote:
> On Fri, Aug 28, 2009 at 09:00:58PM -0400, Andy Walls wrote:
> > On Fri, 2009-08-28 at 16:49 -0500, Chris Kennedy wrote:
> > > On Fri, Aug 28, 2009 at 04:31:13PM -0500, Chris Kennedy wrote:
> > > > On Fri, Aug 28, 2009 at 03:40:07PM -0400, Andy Walls wrote:
> > > > > On Fri, 2009-08-28 at 12:01 -0500, Chris Kennedy wrote:
> > > > >
> > > > >
> > > > > If you can reproduce again, maybe use v4l2-dbg to dump the registers
> > > > > of
> > > > > the cx25840 and compare the good and the bad cases. I suspect
> > > > > registers
> > > > > in the 0x800-0x8ff range will jump out as being very different. It
> > > > > won't explain the failure mode however...
> > > >
> > > > I've got a script that I am running which checks for the
> > > > oddity in audio subchannels and resets the audio input to
> > > > 0 when not just mono. I put into that a v4l2-dbg command to
> > > > dump the registers, so I should be able to catch the state
> > > > of the registers to my log file when this happens.
> > >
> > > Right away after running my catch script, it happens to
> > > have caught this happening almost always on driver
> > > load. Actually not always, out of the 4 inputs usually
> > > 3 or so will have this odd mono lang2 state. I'm guessing
> > > this may be the natural state before audio detection,
> > > so when this happens the chip just wasn't able to detect
> > > audio standards correctly or something like that (and seems
> > > calling the audio input set command makes it try again and
> > > usually works that time).
> >
> > Hmmm. Another guess, maybe with the newer kernel version, perhaps
> > cx25840 firmware load worker thread is completing faster than initial
> > tuner setup in ivtv-driver.c (I'm assuming it wasn't with the old
> > kernel), so the SIF is not stable when the CX25843 firmware is loaded
> > and set running.
> >
> > Just another guess really.
> >
> >
> > > So here's the main diffs between the registers, from 2 different
> > > inputs to help. I'll see if it ever does this outside a restart,
> > > and will see if I can find a time when it does this and truly
> > > messes up audio (in these cases it's probably not fully
> > > initialized or detecting audio yet, I'm guessing, but interesting
> > > that this is exactly the same subchannels it shows when the
> > > audio is messed up).
> >
> > I suspect you're right about the default state.
> >
> > I'll take a look at these diffs tomorrow.
> >
> > Regards,
> > Andy
> >
> > > These are diffs of bad vs. good, so - is from bad state
> > > and + is when back into good state.
> > >
> > > -00000120: 00 00 01 10 87 b6 30 50 f8 93 11 a0 ff 5f 20 11
> > > +00000120: 00 00 01 10 87 b6 b0 50 f8 93 11 a0 ff 5f 20 11
^^
GPIO inputs are floating around.
> > > -00000400: 01 e0 04 00 31 25 10 00 00 80 00 00 00 91 00 00
> > > +00000400: 01 e0 04 00 31 25 10 00 00 80 00 00 00 81 35 00
^^ ^^
Odd vs. Even field (don't care)
Video present, VGA locked, Vertical lock, Horizontal lock - big difference
> > > -00000410: bf 01 ff 7f 00 80 00 00 00 00 00 00 00 00 08 00
> > > +00000410: bf 07 ff 7f 00 80 00 00 00 00 00 00 00 00 08 00
^^
Macrovision detect changed, Vid Present changed
> > > -00000480: 26 00 00 00 00 00 00 42 1b 97 05 f8 dc 40 10 00
> > > +00000480: 5b 00 00 00 00 00 60 42 17 d3 07 f8 dc 40 10 00
^^ ^^ ^^^^^^^^
Field count and test register (don't care)
Variable Gain amplifier gain and AGC is different - no surprise given
the above
> > > -00000800: fe 3f 02 13 fe ff 8d 00 f6 04 01 00 00 00 1c 60
> > > +00000800: fe 3f f8 13 fe ff 8d 00 f6 04 11 00 00 00 1c e0
^^ ^^ ^^
DL Port - con't care when not in memory map mode
Video present (in the line with a +), but in both cases the
microcontroller claims to know the video format!
> > > -00000810: 00 01 ff 80 05 09 14 20 c0 31 00 00 50 00 53 47
> > > +00000810: 00 01 ff 80 05 09 14 20 c0 31 00 00 50 00 80 47
^^
> > > -00000820: 16 4a ce 1b 85 e0 05 8a a0 01 00 00 e9 01 ed 03
> > > +00000820: 53 44 ce 1b 05 e0 05 8a a0 01 00 00 e9 01 ed 03
^^^^^ ^^
> > > -00000840: 00 00 00 40 00 00 ed 03 10 80 84 1e 00 00 00 40
> > > +00000840: 00 00 00 40 00 00 ed 03 10 80 00 00 00 00 00 00
^^ ^^ ^^
> > > -00000850: 55 5f a1 00 30 00 00 00 00 00 00 00 3e 70 00 80
> > > +00000850: bc 42 42 01 31 00 00 00 2d 0d 00 80 00 78 00 00
^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
> > > -00000860: b8 01 ca 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > +00000860: 55 1b 04 00 00 04 00 00 00 00 33 46 10 30 05 00
^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
> > > -00000870: 00 00 00 00 00 00 00 00 7e 05 7e 05 88 45 a2 06
> > > +00000870: 28 18 04 00 04 06 00 00 41 02 41 02 ec 45 87 07
^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
> > > -00000880: da 07 3c 0b e1 ca 03 40 30 70 30 70 f4 01 7f 00
> > > +00000880: 71 0a 80 0c e1 ca 03 40 30 70 30 70 31 00 16 00
^^ ^^ ^^ ^^ ^^ ^^ ^^
> > > -00000890: 24 f4 03 40 30 70 30 70 fb 0c 2d 02 58 01 7b 05
> > > +00000890: 24 f4 03 40 30 70 30 70 e7 10 e3 00 00 00 63 00
^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^
Not publicly documented registers that indicate different
"detections" or, in the + case, that the microcontroller or hardware is
not done with calculations.
> > > -000008c0: 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 0f
> > > +000008c0: 00 00 00 00 00 00 00 00 00 00 01 00 22 00 08 0f
^^ ^^
DBX to channel 2, channel 1 phase delayed, 2 samples of delay (in the '+'
case)
Dematrix BTSC force mono (vs unset in the '-' case)
Those look really odd. I'm not up on Dolby stereo though.
> > > -00000940: 00 00 00 00 00 00 00 00 00 2e 3f 4a 00 33 64 54
> > > -00000950: 00 00 00 ff 03 10 40 07 00 08 02 ff 00 00 00 00
> > > +00000940: 00 00 00 00 00 00 00 00 00 2e 3f 4a 00 33 64 3d
> > > +00000950: 00 00 00 d2 01 10 40 07 00 08 02 ff 00 00 00 00
> > >
> > > -00000990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > -000009a0: 00 00 00 00 00 00 00 00 00 00 00 00 21 06 00 00
> > > +00000990: 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00
> > > +000009a0: 00 00 00 00 00 00 00 00 11 00 00 00 06 f4 00 80
(Skipping the 0x900's for now).
>From what I can tell, what may be going on at initialization is that the
audio microcontroller may be claiming to understand the video standard
before there is actually a video signal present and proceeeding to look
for the audio and configure for it. It is conceivable that once video
locks in, the configuration made by the audio controller may be wrong.
> > > -- SECOND CARD --
> > >
> > > -00000120: 00 00 01 10 87 b6 30 50 f8 93 11 a0 ff 5f 20 11
> > > +00000120: 00 00 01 10 87 b6 b0 50 f8 93 11 a0 ff 5f 20 11
> > >
> > > -00000400: 01 e0 04 00 31 25 10 00 00 80 00 00 00 81 01 00
> > > -00000410: bb 01 ff ff 00 80 00 00 00 00 00 00 00 00 08 00
> > > +00000400: 01 e0 04 00 31 25 10 00 00 80 00 00 00 91 15 00
> > > +00000410: bb 03 ff ff 00 80 00 00 00 00 00 00 00 00 08 00
> > >
> > > -00000480: 26 00 00 00 00 00 10 40 10 59 24 f8 dc 40 10 00
> > > +00000480: 5b 00 00 00 00 00 64 42 17 5c 28 f8 dc 40 10 00
> > >
> > > -00000800: fe 3f 03 13 fe ff 8d 00 f6 04 01 00 00 00 00 20
> > > -00000810: 00 02 ff 80 05 09 14 20 c0 31 00 00 50 00 6b 53
> > > -00000820: 02 55 ce 1b 84 e0 04 e0 a0 01 00 00 e9 01 ed 03
> > > +00000800: fe 3f 03 13 fe ff 8d 00 f6 04 11 00 00 00 00 a0
> > > +00000810: 00 02 ff 80 05 09 14 20 c0 31 00 00 50 00 80 47
> > > +00000820: 53 44 ce 1b 04 e0 04 e0 a0 01 00 00 e9 01 ed 03
> > >
> > > -00000840: 00 00 00 00 00 00 ed 03 10 80 84 1e 00 00 00 00
> > > -00000850: 55 5f a1 00 30 00 00 00 00 00 00 00 3e 70 00 80
> > > -00000860: b8 01 ca 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > -00000870: 00 00 00 00 00 00 00 00 c0 16 c0 16 88 45 a2 06
> > > -00000880: da 07 3c 0b bd 83 71 41 23 a4 23 a4 cd 05 dc 04
> > > -00000890: a9 9b 03 40 59 ae 59 ae c3 0c 52 01 87 06 58 0e
> > > +00000840: 00 00 00 00 00 00 ed 03 10 80 00 00 00 00 00 00
> > > +00000850: bc 42 42 01 31 00 00 00 b5 12 00 80 00 78 00 00
> > > +00000860: 55 1b 04 18 00 04 00 00 00 00 33 46 10 30 05 00
> > > +00000870: 28 18 04 00 04 06 00 00 07 08 07 08 ec 45 87 07
> > > +00000880: 71 0a 80 0c bd 83 71 41 23 a4 23 a4 16 00 05 00
> > > +00000890: a9 9b 03 40 59 ae 59 ae f8 08 80 00 00 00 db 03
> > >
> > > -000008c0: 00 00 00 00 00 00 00 00 1f 06 01 00 00 00 00 0f
> > > +000008c0: 00 00 00 00 00 00 00 00 00 00 01 00 22 00 08 0f
> > >
> > > -000008f0: fc 0a 00 88 88 88 55 55 7c 86 01 08 7c 86 01 08
> > > +000008f0: fc 0a 52 bb 88 88 55 55 7c 86 01 08 7c 86 01 08
> > >
> > > -00000940: 00 00 00 00 00 00 00 00 00 2e 3f 4a 00 33 64 a0
> > > -00000950: 00 00 00 ff 03 10 40 07 00 08 02 ff 00 00 00 00
> > > +00000940: 00 00 00 00 00 00 00 00 00 2e 3f 4a 00 33 64 47
> > > +00000950: 00 00 00 b0 02 10 40 07 00 08 02 ff 00 00 00 00
> > >
> > > -000009a0: 00 00 00 00 00 00 00 00 00 00 00 00 e7 06 00 00
> > > +000009a0: 00 00 00 00 00 00 00 00 11 00 00 00 0a f4 00 80
>
> And here it is after running a few hours, seems it can go into
> that state during capture too...
>
> 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
> -00000800: fe 3f 90 13 00 0f 8d 20 f6 04 11 00 00 00 1c e0
> +00000800: fe 3f f9 13 00 0f 8d 00 f6 04 11 00 00 00 1c e0
^^ ^^
| |
uController DL port-+ + Doesn't matter
Neither of these should matter. I'm not sure the behavior of the DL
port register when not in memory map mode - as it is now.
> 00000810: 00 01 ff 8e 05 09 14 20 c0 31 00 00 d1 05 80 47
> -00000820: 00 28 00 80 44 e5 84 e5 a8 5c 72 00 f2 07 01 24
> +00000820: 00 28 00 80 44 e0 84 e0 a8 5c 72 00 f2 07 01 24
^^ ^^
It makes sense that these would get set similarly. These might be a
clue as to why the audio sounds bad. (If it were unmuted - see
below.)
> -00000830: 21 a0 86 01 d6 10 00 c0 00 08 01 24 21 a0 86 01
> +00000830: 21 a0 86 01 00 00 00 40 00 08 01 24 21 a0 86 01
^^^^^^^^^^^
> -00000840: d7 6e 00 c0 00 1b 00 01 31 00 00 00 a6 02 00 80
> +00000840: 00 00 00 40 00 1b 00 01 31 00 00 00 00 00 00 00
^^^^^^^^^^^ ^^^^^^^^^^^
These register differences don't matter unless the first 3 bytes in each
stay 0 for a long time. By the time the audio controller decides to
unmute, I suspect these should be non-zero.
> -00000850: bc 42 42 01 31 00 00 00 d2 37 00 80 00 78 00 00
> +00000850: 53 44 42 01 31 00 00 00 cb 0e 00 80 00 78 00 00
^^^^^ ^^^^^
The input waveform changed by about 2.4% - or it didn't, but the audio
microcontroller thought it did, or is converging onto some solution..
> 00000860: 55 1b 04 00 00 04 00 00 00 00 33 46 10 30 05 00
> 00000870: 28 18 04 00 04 06 00 00 41 02 41 02 ec 45 87 07
> -00000880: 71 0a 80 0c e1 ca 03 40 30 70 30 70 00 00 00 00
> +00000880: 71 0a 80 0c e1 ca 03 40 30 70 30 70 00 00 04 00
^^
> -00000890: 24 f4 03 40 30 70 30 70 1c 11 f9 00 00 00 7b 00
> +00000890: 24 f4 03 40 30 70 30 70 22 11 ed 00 00 00 36 00
^^ ^^ ^^
These indicate some difference in advanced decoding of the audio. I'm
not sure they inidcate much.
> 000008a0: 78 06 d6 12 87 51 00 00 de 53 03 00 b1 01 00 00
> 000008b0: d0 f3 00 00 00 00 00 00 c8 00 ff 0f 1f 00 0f 00
> 000008c0: 00 00 00 00 00 00 00 00 00 00 01 00 22 00 08 0f
> -000008d0: 70 38 06 01 24 00 ff 7f 00 18 18 18 a3 33 ff 7f
> +000008d0: 70 38 06 1f 24 00 ff 7f 00 18 18 18 a3 33 ff 7f
^^
PATH1 Mute control is set to mute everything. This indicates the audio
microcontroller hasn't finished it's work yet at the time of this
snapshot, as it hasn't unmuted things.
> Figure this is interesting in comparison the the previous
> when starting up, looks yet a little different in the audio
> register regions.
Well it is interesting in that you caught the audio controller in the
midst of a change, before it finished some computations and before it
decided to unmute the audio.
I'm trying to think of what actions can be taken on the Linux driver end
to ensure the integrity of the microcontroller code and operation, and
the integrity of the SIF signal from the tuner.
a) I have code in the cx18 driver that verifies the microcontroller code
load by reading it back and comparing. I can port that back to the
cx25840 driver to give a log indication that the download to the
microcontoller was OK or not.
b) if the board is wired up so that the IRQ_N pin of the CX25843 goes to
the CX23416 where it can detect and interrupt line, then could detect
the audio microcontroller events indicated in register 0x813 and take
action on some of them:
RDS interrupt asserted (asserted in dump above)
NICAM bit error rate too high interrupt asserted
NICAM lost lock interrupt asserted
IF signal lost interrupt asserted
Format detection loop complete interrupt asserted (asserted in dump above)
Audio format change interrupt asserted (asserted in dump above)
Audio mode change interrupt asserted (asserted in dump above)
AC97 interrupt asserted
we could also do the same for the Video interrupts in registers
0x410-0x411 and reset the audio microcontroller when we see video the
format, present, and/or lock status change. That way the audio
autodetection would work on a stable signal.
c) Maybe experiment with the audio automatic gain control settings in
registers 0x814-0x817.
I have no idea what about the new kernel has caused symptoms to appear,
so b) and c) are really work-arounds for something else.
I'm trying to reproduce the issue with a DTV STB feeding my PVR-150MCE
on Channel 3 with a 2.6.27.30-170.2.82.fc10.x86_64 kernel. So far, no
luck.
Any ideas?
Regards,
Andy
> Thanks,
> Chris
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
