cx18: "missing audio" for analog recordings

On 15/03/10 07:51 AM, Andy Walls wrote:
> On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
>> On 03/02/10 07:40, Andy Walls wrote:
..
>> after updating to the tip of the v4l2-dvb git tree last week,
>> I've been hitting the "no audio" on analog recordings bug much more often.
>>
>> Digging through google, it appears this problem has been around as long
>> as the cx18 driver has existed, with no clear resolution.  Lots of people
>> have reported it to you before, and nobody has found a silver bullet fix.
..
> Here are all the potential problem areas I can think of:
>
> 1. A/V digitizer/decoder audio detection firmware load and init.  (I've
> added firmware readback verification to try and head this off.)
>
> 2. A/V digitizer decoder audio microcontroller hard reset and "soft"
> reset sequencing.  (I think the cx18 driver has this wrong ATM.)
>
> 3. APU load and init.  (The double load is to fix a DTV TS stream bug on
> every other APU&  CPU firmware load sequence.  The APU_AI_RESET is to
> fix the audio bitrate problem on first capture after a double firmware
> load.)
>
> 4. AI1 Mux setting failing when switching between the internal A/V
> decoder's I2S output and the external I2S inputs.  (I thought I had this
> fixed, but I don't have detailed register specs for that register - so
> maybe not.)
>
> 5. A/V decoder audio clock PLL stops operating due to being programmed
> out of range.  (This was a problem for 32 ksps audio a while ago, but
> I'm pretty confident I have it fixed.)
>
> 6. A/V decoder analog frontend setup for SIF wrong?.  (I fixed this due
> to a problen Helen Buus reported with cable TV.)
>
> I think #2 is the real problem.  I just started to disassmble the
> digitizer firmware 2 nights ago to see if I could get some insight as to
> how to properly reset it.
>
> I've got a first WAG at fixing the resets of the audio microcontroller's
> resets at:
>
> 	http://linuxtv.org/hg/~awalls/cx18-audio
>
> If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
> from 0x810 to 0x9cc, although that may not work either.
..
> Thanks for the troubleshooting and reporting.
..

Back at this again today, after a month away from it -- getting tired
of watching "Survivor" with closed-captioning instead of audio.  :)

I pulled your (Andy) repository today, and merged the cx18 audio reset
changes from it into today's tip from v4l-dvb.  Patch attached for reference.

So far, so good.  I'll keep tabs on it over time, and see if the audio
is stable, or if it still fails once in a while.

Cheers
  

On Sat, 2010-04-10 at 18:28 -0400, Mark Lord wrote:
> On 15/03/10 07:51 AM, Andy Walls wrote:
> > On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> >> On 03/02/10 07:40, Andy Walls wrote:
> ..
> >> after updating to the tip of the v4l2-dvb git tree last week,
> >> I've been hitting the "no audio" on analog recordings bug much more often.
> >>
> >> Digging through google, it appears this problem has been around as long
> >> as the cx18 driver has existed, with no clear resolution.  Lots of people
> >> have reported it to you before, and nobody has found a silver bullet fix.
> ..
> > Here are all the potential problem areas I can think of:
> >
> > 1. A/V digitizer/decoder audio detection firmware load and init.  (I've
> > added firmware readback verification to try and head this off.)
> >
> > 2. A/V digitizer decoder audio microcontroller hard reset and "soft"
> > reset sequencing.  (I think the cx18 driver has this wrong ATM.)
> >
> > 3. APU load and init.  (The double load is to fix a DTV TS stream bug on
> > every other APU&  CPU firmware load sequence.  The APU_AI_RESET is to
> > fix the audio bitrate problem on first capture after a double firmware
> > load.)
> >
> > 4. AI1 Mux setting failing when switching between the internal A/V
> > decoder's I2S output and the external I2S inputs.  (I thought I had this
> > fixed, but I don't have detailed register specs for that register - so
> > maybe not.)
> >
> > 5. A/V decoder audio clock PLL stops operating due to being programmed
> > out of range.  (This was a problem for 32 ksps audio a while ago, but
> > I'm pretty confident I have it fixed.)
> >
> > 6. A/V decoder analog frontend setup for SIF wrong?.  (I fixed this due
> > to a problen Helen Buus reported with cable TV.)
> >
> > I think #2 is the real problem.  I just started to disassmble the
> > digitizer firmware 2 nights ago to see if I could get some insight as to
> > how to properly reset it.
> >
> > I've got a first WAG at fixing the resets of the audio microcontroller's
> > resets at:
> >
> > 	http://linuxtv.org/hg/~awalls/cx18-audio
> >
> > If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
> > from 0x810 to 0x9cc, although that may not work either.
> ..
> > Thanks for the troubleshooting and reporting.
> ..
> 
> Back at this again today, after a month away from it -- getting tired
> of watching "Survivor" with closed-captioning instead of audio.  :)
> 
> I pulled your (Andy) repository today, and merged the cx18 audio reset
> changes from it into today's tip from v4l-dvb.  Patch attached for reference.
> 
> So far, so good.  I'll keep tabs on it over time, and see if the audio
> is stable, or if it still fails once in a while.

Hmmm.  Darren's having problems (loss of video/black screen) with my
patches under my cx18-audio repo, but I'm not quite convinced he doesn't
have some other PCI bus problem either.

Anyway, my plan now is this:

1. on cx18-av-core.c:input_change()
	a. set register 0x808 for audio autodetection
	b. restart the format detection loop
	c. set or reset a 1.5 second timeout

2. after the timer expires, if no audio standard was detected, 
	a. force the audio standard by programming register 0x808
		(e.g. BTSC for NTSC-M)
	b. restart the format detection loop so the micrcontroller will 
		do the unmute when it detects audio



Darren is in NTSC-M/BTSC land.  What TV standard are you dealing with?

Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Sat, 2010-04-10 at 18:54 -0400, Andy Walls wrote:
> On Sat, 2010-04-10 at 18:28 -0400, Mark Lord wrote:
> > On 15/03/10 07:51 AM, Andy Walls wrote:
> > > On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> > >> On 03/02/10 07:40, Andy Walls wrote:
> > ..
> > >> after updating to the tip of the v4l2-dvb git tree last week,
> > >> I've been hitting the "no audio" on analog recordings bug much more often.
> > >>
> > >> Digging through google, it appears this problem has been around as long
> > >> as the cx18 driver has existed, with no clear resolution.  Lots of people
> > >> have reported it to you before, and nobody has found a silver bullet fix.
> > ..
> > > Here are all the potential problem areas I can think of:
> > >
> > > 1. A/V digitizer/decoder audio detection firmware load and init.  (I've
> > > added firmware readback verification to try and head this off.)
> > >
> > > 2. A/V digitizer decoder audio microcontroller hard reset and "soft"
> > > reset sequencing.  (I think the cx18 driver has this wrong ATM.)
> > >
> > > 3. APU load and init.  (The double load is to fix a DTV TS stream bug on
> > > every other APU&  CPU firmware load sequence.  The APU_AI_RESET is to
> > > fix the audio bitrate problem on first capture after a double firmware
> > > load.)
> > >
> > > 4. AI1 Mux setting failing when switching between the internal A/V
> > > decoder's I2S output and the external I2S inputs.  (I thought I had this
> > > fixed, but I don't have detailed register specs for that register - so
> > > maybe not.)
> > >
> > > 5. A/V decoder audio clock PLL stops operating due to being programmed
> > > out of range.  (This was a problem for 32 ksps audio a while ago, but
> > > I'm pretty confident I have it fixed.)
> > >
> > > 6. A/V decoder analog frontend setup for SIF wrong?.  (I fixed this due
> > > to a problen Helen Buus reported with cable TV.)
> > >
> > > I think #2 is the real problem.  I just started to disassmble the
> > > digitizer firmware 2 nights ago to see if I could get some insight as to
> > > how to properly reset it.
> > >
> > > I've got a first WAG at fixing the resets of the audio microcontroller's
> > > resets at:
> > >
> > > 	http://linuxtv.org/hg/~awalls/cx18-audio
> > >
> > > If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
> > > from 0x810 to 0x9cc, although that may not work either.
> > ..
> > > Thanks for the troubleshooting and reporting.
> > ..
> > 
> > Back at this again today, after a month away from it -- getting tired
> > of watching "Survivor" with closed-captioning instead of audio.  :)
> > 
> > I pulled your (Andy) repository today, and merged the cx18 audio reset
> > changes from it into today's tip from v4l-dvb.  Patch attached for reference.
> > 
> > So far, so good.  I'll keep tabs on it over time, and see if the audio
> > is stable, or if it still fails once in a while.
> 
> Hmmm.  Darren's having problems (loss of video/black screen) with my
> patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> have some other PCI bus problem either.
> 
> Anyway, my plan now is this:
> 
> 1. on cx18-av-core.c:input_change()
> 	a. set register 0x808 for audio autodetection
> 	b. restart the format detection loop
> 	c. set or reset a 1.5 second timeout
> 
> 2. after the timer expires, if no audio standard was detected, 
> 	a. force the audio standard by programming register 0x808
> 		(e.g. BTSC for NTSC-M)
> 	b. restart the format detection loop so the micrcontroller will 
> 		do the unmute when it detects audio
> 
> 
> 
> Darren is in NTSC-M/BTSC land.  What TV standard are you dealing with?

Hey, I just found an OTA analog broadcast on channel 23!  I even can
reproduce the problem of the audio microcontroller not detecting the
audio standard (shoot it just kicked in and figured it out).

Anyway this will help me turn around something.

Regards,
Andy


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 10/04/10 06:54 PM, Andy Walls wrote:
>
> Hmmm.  Darren's having problems (loss of video/black screen) with my
> patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> have some other PCI bus problem either.
>
> Anyway, my plan now is this:
>
> 1. on cx18-av-core.c:input_change()
> 	a. set register 0x808 for audio autodetection
> 	b. restart the format detection loop
> 	c. set or reset a 1.5 second timeout
>
> 2. after the timer expires, if no audio standard was detected,
> 	a. force the audio standard by programming register 0x808
> 		(e.g. BTSC for NTSC-M)
> 	b. restart the format detection loop so the micrcontroller will
> 		do the unmute when it detects audio
>
> Darren is in NTSC-M/BTSC land.  What TV standard are you dealing with?
..

I'm in Canada, using the tuner for over-the-air NTSC broadcasts.

Cheers!
  

On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
> On 10/04/10 06:54 PM, Andy Walls wrote:
> >
> > Hmmm.  Darren's having problems (loss of video/black screen) with my
> > patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> > have some other PCI bus problem either.
> >
> > Anyway, my plan now is this:
> >
> > 1. on cx18-av-core.c:input_change()
> > 	a. set register 0x808 for audio autodetection
> > 	b. restart the format detection loop
> > 	c. set or reset a 1.5 second timeout
> >
> > 2. after the timer expires, if no audio standard was detected,
> > 	a. force the audio standard by programming register 0x808
> > 		(e.g. BTSC for NTSC-M)
> > 	b. restart the format detection loop so the micrcontroller will
> > 		do the unmute when it detects audio
> >
> > Darren is in NTSC-M/BTSC land.  What TV standard are you dealing with?
> ..
> 
> I'm in Canada, using the tuner for over-the-air NTSC broadcasts.


Try this:

	http://linuxtv.org/hg/~awalls/cx18-audio2

this waits 1.5 seconds after an input/channel change to see if the audio
standard micrcontroller can detect the standard.  If it can't, the
driver tells it to try a fallback detection.  Right now, only the NTSC-M
fallback detection is set to force a mode (i.e. BTSC), all the others
"fall back" to their same auto-detection.

Some annoyances with the fallback to a forced audio standard, mode, and
format:

1. Static gets unmuted on stations with no signal. :(

2. I can't seem to force mode "MONO2 (LANGUAGE B)".  I'm guessing the
microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
+R channel for BTSC, EIAJ, A2)"  Feel free to experiment with the LSB of
the fallback setting magic number (0x1101) in
cx18-av-core.c:input_change().


Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
> On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
> > On 10/04/10 06:54 PM, Andy Walls wrote:
> > >
> > > Hmmm.  Darren's having problems (loss of video/black screen) with my
> > > patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> > > have some other PCI bus problem either.
> > >
> > > Anyway, my plan now is this:
> > >
> > > 1. on cx18-av-core.c:input_change()
> > > 	a. set register 0x808 for audio autodetection
> > > 	b. restart the format detection loop
> > > 	c. set or reset a 1.5 second timeout
> > >
> > > 2. after the timer expires, if no audio standard was detected,
> > > 	a. force the audio standard by programming register 0x808
> > > 		(e.g. BTSC for NTSC-M)
> > > 	b. restart the format detection loop so the micrcontroller will
> > > 		do the unmute when it detects audio
> > >
> > > Darren is in NTSC-M/BTSC land.  What TV standard are you dealing with?
> > ..
> > 
> > I'm in Canada, using the tuner for over-the-air NTSC broadcasts.
> 
> 
> Try this:
> 
> 	http://linuxtv.org/hg/~awalls/cx18-audio2
> 
> this waits 1.5 seconds after an input/channel change to see if the audio
> standard micrcontroller can detect the standard.  If it can't, the
> driver tells it to try a fallback detection.  Right now, only the NTSC-M
> fallback detection is set to force a mode (i.e. BTSC), all the others
> "fall back" to their same auto-detection.
> 
> Some annoyances with the fallback to a forced audio standard, mode, and
> format:
> 
> 1. Static gets unmuted on stations with no signal. :(
> 
> 2. I can't seem to force mode "MONO2 (LANGUAGE B)".  I'm guessing the
> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
> +R channel for BTSC, EIAJ, A2)"  Feel free to experiment with the LSB of
                                                                    ^^^

Bah, wrong byte.  That should have been the LSN of the MSB of the 0x1101
number.  I'm too tired. 

Regards,
Andy

> the fallback setting magic number (0x1101) in
> cx18-av-core.c:input_change().
> 
> 
> Regards,
> Andy
> 
> 
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
> On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
> > On 10/04/10 06:54 PM, Andy Walls wrote:
> > >
> > > Hmmm.  Darren's having problems (loss of video/black screen) with my
> > > patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> > > have some other PCI bus problem either.
> > >
> > > Anyway, my plan now is this:
> > >
> > > 1. on cx18-av-core.c:input_change()
> > > 	a. set register 0x808 for audio autodetection
> > > 	b. restart the format detection loop
> > > 	c. set or reset a 1.5 second timeout
> > >
> > > 2. after the timer expires, if no audio standard was detected,
> > > 	a. force the audio standard by programming register 0x808
> > > 		(e.g. BTSC for NTSC-M)
> > > 	b. restart the format detection loop so the micrcontroller will
> > > 		do the unmute when it detects audio
> > >
> > > Darren is in NTSC-M/BTSC land.  What TV standard are you dealing with?
> > ..
> > 
> > I'm in Canada, using the tuner for over-the-air NTSC broadcasts.
> 
> 
> Try this:
> 
> 	http://linuxtv.org/hg/~awalls/cx18-audio2
> 
> this waits 1.5 seconds after an input/channel change to see if the audio
> standard micrcontroller can detect the standard.  If it can't, the
> driver tells it to try a fallback detection.  Right now, only the NTSC-M
> fallback detection is set to force a mode (i.e. BTSC), all the others
> "fall back" to their same auto-detection.
> 
> Some annoyances with the fallback to a forced audio standard, mode, and
> format:
> 
> 1. Static gets unmuted on stations with no signal. :(
> 
> 2. I can't seem to force mode "MONO2 (LANGUAGE B)".  I'm guessing the
> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
> +R channel for BTSC, EIAJ, A2)"  Feel free to experiment with the LSB of
> the fallback setting magic number (0x1101) in
> cx18-av-core.c:input_change().

I fixed #2.  I had a bug so the first patch didn't properly set the
fallback audio mode.

I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take
into consideration that we might be using a forced audio mode vs. auto
detection.  However, that is not essential for testing; this should be
good enough for testing.

Regards,
Andy


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 11/04/10 07:47 AM, Andy Walls wrote:
> On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
>> Try this:
>>
>> 	http://linuxtv.org/hg/~awalls/cx18-audio2
>>
>> this waits 1.5 seconds after an input/channel change to see if the audio
>> standard micrcontroller can detect the standard.  If it can't, the
>> driver tells it to try a fallback detection.  Right now, only the NTSC-M
>> fallback detection is set to force a mode (i.e. BTSC), all the others
>> "fall back" to their same auto-detection.
>>
>> Some annoyances with the fallback to a forced audio standard, mode, and
>> format:
>>
>> 1. Static gets unmuted on stations with no signal. :(
>>
>> 2. I can't seem to force mode "MONO2 (LANGUAGE B)".  I'm guessing the
>> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
>> +R channel for BTSC, EIAJ, A2)"  Feel free to experiment with the LSB of
>> the fallback setting magic number (0x1101) in
>> cx18-av-core.c:input_change().
>
> I fixed #2.  I had a bug so the first patch didn't properly set the
> fallback audio mode.
>
> I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take
> into consideration that we might be using a forced audio mode vs. auto
> detection.  However, that is not essential for testing; this should be
> good enough for testing.
..

Those new patches don't want to coexist with the earlier hard/soft reset
changes.  There's always a chance that *both* things might be needed,
and the reset stuff didn't look obviously "bad".  Why dropped?

Thanks
  

On Sun, 2010-04-11 at 09:24 -0400, Mark Lord wrote:
> On 11/04/10 07:47 AM, Andy Walls wrote:
> > On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
> >> Try this:
> >>
> >> 	http://linuxtv.org/hg/~awalls/cx18-audio2
> >>
> >> this waits 1.5 seconds after an input/channel change to see if the audio
> >> standard micrcontroller can detect the standard.  If it can't, the
> >> driver tells it to try a fallback detection.  Right now, only the NTSC-M
> >> fallback detection is set to force a mode (i.e. BTSC), all the others
> >> "fall back" to their same auto-detection.
> >>
> >> Some annoyances with the fallback to a forced audio standard, mode, and
> >> format:
> >>
> >> 1. Static gets unmuted on stations with no signal. :(
> >>
> >> 2. I can't seem to force mode "MONO2 (LANGUAGE B)".  I'm guessing the
> >> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
> >> +R channel for BTSC, EIAJ, A2)"  Feel free to experiment with the LSB of
> >> the fallback setting magic number (0x1101) in
> >> cx18-av-core.c:input_change().
> >
> > I fixed #2.  I had a bug so the first patch didn't properly set the
> > fallback audio mode.
> >
> > I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take
> > into consideration that we might be using a forced audio mode vs. auto
> > detection.  However, that is not essential for testing; this should be
> > good enough for testing.
> ..
> 
> Those new patches don't want to coexist with the earlier hard/soft reset
> changes.  There's always a chance that *both* things might be needed,
> and the reset stuff didn't look obviously "bad".  Why dropped?

Because...

1. Darren had problems with a black video screen with them and so did I
(once I found an analog OTA station).

2.  I also suspect those previous patches were not performing the format
detection loop reset properly.

3. One could possibly reset the microcontroller all day long without
auto-detection ever working.  Also autodetection will auto-mute, and
restart the detection loop, if it thinks the audio carrier went away.

4. Falling back to a known used audio standard, format, and mode is
guaranteed to work.  I guess it can be a problem in some region for some
video stanadrd where one just can't know what each broadcaster is using.
For NTSC-M this is not the case: BTSC at 4.5 MHz is always used.

5. I don't understand the exact failure mode of why the microcontroller
is failing to detect the audio standard, so any other fix that doesn't
explicitly set a standard will likely be unreliable.  I'm tired of audio
detection fixes with unpredictable outcomes based on variations in cable
and OTA signal sources.  Forcing the microcontroller to a particular
standard, after autodetection fails, gives a deterministic outcome.

(BTW, we really do need the microcontroller to do some work for us.  No
documentation accessable to me has enough detail to allow one to fully
program the audio decoder portion of the A/V core.  We have to rely on
the microntroller firmware to set up some of the undocumented or
unexplained registers.)


I can always throw the other reset patches back in I guess, but this
latest patch set should dominate the behavior of the microcontroller (if
I didn't miss something because I was tired).

I would be interested in hearing how frequent these patches show "forced
audio standard" for you:
        
        [  389.388200] cx18-0 843: Detected format:           NTSC-M
        [  389.388204] cx18-0 843: Specified standard:        NTSC-M
        [  389.388208] cx18-0 843: Specified video input:     Composite 7
        [  389.388212] cx18-0 843: Specified audioclock freq: 48000 Hz
        [  389.388232] cx18-0 843: Detected audio mode:       forced mode
        [  389.388237] cx18-0 843: Detected audio standard:   forced audio standard
        [  389.388241] cx18-0 843: Audio muted:               no
        [  389.388245] cx18-0 843: Audio microcontroller:     running
        [  389.388249] cx18-0 843: Configured audio standard: BTSC
        [  389.388253] cx18-0 843: Configured audio mode:     MONO2 (LANGUAGE B)
        [  389.388257] cx18-0 843: Specified audio input:     Tuner (In8)
        [  389.388261] cx18-0 843: Preferred audio mode:      stereo

meaning that the fallback audio settings were used because auto
detection failed.

Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

Andy Walls wrote:
> On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
>   
>> On 10/04/10 06:54 PM, Andy Walls wrote:
>>     
>>> Hmmm.  Darren's having problems (loss of video/black screen) with my
>>> patches under my cx18-audio repo, but I'm not quite convinced he doesn't
>>> have some other PCI bus problem either.
>>>
>>> Anyway, my plan now is this:
>>>
>>> 1. on cx18-av-core.c:input_change()
>>> 	a. set register 0x808 for audio autodetection
>>> 	b. restart the format detection loop
>>> 	c. set or reset a 1.5 second timeout
>>>
>>> 2. after the timer expires, if no audio standard was detected,
>>> 	a. force the audio standard by programming register 0x808
>>> 		(e.g. BTSC for NTSC-M)
>>> 	b. restart the format detection loop so the micrcontroller will
>>> 		do the unmute when it detects audio
>>>
>>> Darren is in NTSC-M/BTSC land.  What TV standard are you dealing with?
>>>       
>> ..
>>
>> I'm in Canada, using the tuner for over-the-air NTSC broadcasts.
>>     
>
>
> Try this:
>
> 	http://linuxtv.org/hg/~awalls/cx18-audio2
>
> this waits 1.5 seconds after an input/channel change to see if the audio
> standard micrcontroller can detect the standard.  If it can't, the
> driver tells it to try a fallback detection.  Right now, only the NTSC-M
> fallback detection is set to force a mode (i.e. BTSC), all the others
> "fall back" to their same auto-detection.
>
> Some annoyances with the fallback to a forced audio standard, mode, and
> format:
>
> 1. Static gets unmuted on stations with no signal. :(
>
> 2. I can't seem to force mode "MONO2 (LANGUAGE B)".  I'm guessing the
> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
> +R channel for BTSC, EIAJ, A2)"  Feel free to experiment with the LSB of
> the fallback setting magic number (0x1101) in
> cx18-av-core.c:input_change().
>
>
> Regards,
> Andy
>
>   
So far, it seems fine, no black screens, and audio seems to be fine.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 11/04/10 03:01 PM, Andy Walls wrote:
..
> I can always throw the other reset patches back in I guess, but this
> latest patch set should dominate the behavior of the microcontroller (if
> I didn't miss something because I was tired).
>
> I would be interested in hearing how frequent these patches show "forced
> audio standard" for you:
..

Thanks.  Will do.

I've added a printk() to the fallback path, so that it will show up in
the syslog whenever the fallback is used.

So far, no problem.  But prior to now, the HVR-1600 regularly failed about
once every 2-3 days according to the script I have which tests for the issue.

On a similar note, while checking the logs last evening, I discovered that
the muted episode of "Survivor Heros & Villians" (two weeks ago) was actually
recorded on the _PVR-250_ card.  With no audio.   This has happened before,
though rarely -- perhaps once every 3-6 months or so.

I wonder if a similar fix/workaround could be appropriate for that card as well?
In the mean while, I guess I'll update my scripts to test/report for that
one as well as the cx18/hvr1600.

Cheers
  

On 11/04/10 03:01 PM, Andy Walls wrote:
>
> I would be interested in hearing how frequent these patches show "forced
> audio standard" for you:
..

The MythTV box here has many tuners, most of which are not used every power-up.
But mythbackend _always_ initializes all tuners, and pre-tunes them to their startup channel
each time the system boots up to record/play something.

So.. in the logs from the other night, there are some "fallback" messages.
But since the HVR1600 was not actually used to record anything,
I don't know for sure if the audio fallback actually "worked",
other than that v4l-ctl reported non-muted audio afterwards.

The abridged syslog is below.
Something I find interesting, is that it reported having to
fallback twice on this boot (once during the initial anti-stutter tune,
and again when mythbackend started up).

I wonder if this means that once the audio bug is present,
it remains present until the next time the driver is loaded/unloaded.

Which matches previous observations.
The fallback (hopefully) works around this, but there's still a bug
somewhere that is preventing the audio from working without the fallback.

Cheers

Mark Lord

* * * *

Apr 12 03:56:55 duke kernel: cx18:  Start initialization, version 1.4.0
Apr 12 03:56:55 duke kernel: cx18-0: Initializing card 0
Apr 12 03:56:55 duke kernel: cx18-0: Autodetected Hauppauge card
Apr 12 03:56:55 duke kernel: cx18 0000:05:03.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Apr 12 03:56:55 duke kernel: cx18-0: Unreasonably low latency timer, setting to 64 (was 2)
Apr 12 03:56:55 duke kernel: cx18-0: cx23418 revision 01010000 (B)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: MAC address is 00:0d:fe:1a:be:03
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: has radio
Apr 12 03:56:55 duke kernel: cx18-0: Autodetected Hauppauge HVR-1600
Apr 12 03:56:55 duke kernel: cx18-0: Simultaneous Digital and Analog TV capture supported
Apr 12 03:56:55 duke kernel: IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
Apr 12 03:56:55 duke kernel: tuner 2-0043: chip found @ 0x86 (cx18 i2c driver #0-1)
Apr 12 03:56:55 duke kernel: tda9887 2-0043: creating new instance
Apr 12 03:56:55 duke kernel: tda9887 2-0043: tda988[5/6/7] found
Apr 12 03:56:55 duke kernel: tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
Apr 12 03:56:55 duke kernel: cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
Apr 12 03:56:55 duke kernel: tuner-simple 2-0061: creating new instance
Apr 12 03:56:55 duke kernel: tuner-simple 2-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
Apr 12 03:56:55 duke kernel: cx18-0: Registered device video1 for encoder MPEG (64 x 32.00 kB)
Apr 12 03:56:55 duke kernel: DVB: registering new adapter (cx18)
Apr 12 03:56:55 duke kernel: MXL5005S: Attached at address 0x63
Apr 12 03:56:55 duke kernel: DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)...
Apr 12 03:56:55 duke kernel: cx18-0: DVB Frontend registered
Apr 12 03:56:55 duke kernel: cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
Apr 12 03:56:55 duke kernel: cx18-0: Registered device video33 for encoder YUV (20 x 101.25 kB)
Apr 12 03:56:55 duke kernel: cx18-0: Registered device vbi1 for encoder VBI (20 x 51984 bytes)
Apr 12 03:56:55 duke kernel: cx18-0: Registered device video25 for encoder PCM audio (256 x 4.00 kB)
Apr 12 03:56:55 duke kernel: cx18-0: Registered device radio1 for encoder radio
Apr 12 03:56:55 duke kernel: cx18-0: Initialized card: Hauppauge HVR-1600
Apr 12 03:56:55 duke kernel: cx18:  End initialization

Apr 12 03:56:58 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-cpu.fw
Apr 12 03:56:58 duke kernel: cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
Apr 12 03:56:58 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-apu.fw
Apr 12 03:56:58 duke kernel: cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
Apr 12 03:56:58 duke kernel: cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
Apr 12 03:56:58 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-cpu.fw
Apr 12 03:56:59 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-apu.fw
Apr 12 03:56:59 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-dig.fw
Apr 12 03:56:59 duke kernel: cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
Apr 12 03:56:59 duke kernel: cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes)

Apr 12 03:57:00 duke kernel: ivtv 0000:05:02.0: firmware: requesting v4l-cx2341x-enc.fw
Apr 12 03:57:00 duke kernel: ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
Apr 12 03:57:00 duke kernel: ivtv0: Encoder revision: 0x02060039

Apr 12 03:57:01 duke logger: /usr/local/bin/enable_hauppauge_remote.sh: reconfiguring driver
Apr 12 03:57:01 duke kernel: cx18_av_aud_detect_work: cx18/hvr1600 audio bug: doing fallback detection      <-------------------
Apr 12 03:57:01 duke kernel: input: i2c IR (Hauppauge) as /class/input/input5
Apr 12 03:57:01 duke kernel: irrcv0: i2c IR (Hauppauge) as /class/irrcv/irrcv0
Apr 12 03:57:01 duke kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c driver #0]
Apr 12 03:57:01 duke logger: /usr/local/bin/enable_hauppauge_remote.sh: waiting for device(s)

Apr 12 03:57:02 duke logger[4238]: /usr/bin/input-kbd -f /usr/local/bin/hauppauge_remote.conf 5
Apr 12 03:57:02 duke logger: /dev/video1: fix_hvr1600_audio.sh: Pre-initializing

Apr 12 03:57:04 duke logger: /dev/video1: fix_hvr1600_audio.sh: HVR1600/cx18 audio ok.
Apr 12 03:57:04 duke nanny.mythbackend[4263]: mythbackend[4265] started

Apr 12 03:57:20 duke /usr/local/bin/antenna_switcher[4828]: Selecting '2C' (hvr1600)
Apr 12 03:57:20 duke /usr/local/bin/antenna_switcher[4828]: writing 0x08 [- - - - 1 - - -]

Apr 12 03:57:22 duke logger: channel_change: /dev/video1: cx18/hvr1600 audio ok.
Apr 12 03:57:22 duke kernel: cx18_av_aud_detect_work: cx18/hvr1600 audio bug: doing fallback detection      <-------------------
Apr 12 03:57:22 duke /usr/local/bin/antenna_switcher[4858]: Selecting '1D' (pvr250)
Apr 12 03:57:22 duke /usr/local/bin/antenna_switcher[4858]: writing 0x0b [- - - - 1 - 1 1]
Apr 12 03:57:23 duke logger: channel_change: /dev/video0: ivtv/pvr250 audio ok.

Apr 12 03:59:31 duke /usr/local/bin/antenna_switcher[5603]: Selecting '1C' (pvr250)
Apr 12 03:59:31 duke /usr/local/bin/antenna_switcher[5603]: writing 0x0a [- - - - 1 - 1 -]
Apr 12 03:59:32 duke logger: channel_change: /dev/video0: ivtv/pvr250 audio ok.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Mon, 2010-04-12 at 16:08 -0400, Mark Lord wrote:
> On 11/04/10 03:01 PM, Andy Walls wrote:
> >
> > I would be interested in hearing how frequent these patches show "forced
> > audio standard" for you:
> ..
> 
> The MythTV box here has many tuners, most of which are not used every power-up.
> But mythbackend _always_ initializes all tuners, and pre-tunes them to their startup channel
> each time the system boots up to record/play something.
> 
> So.. in the logs from the other night, there are some "fallback" messages.
> But since the HVR1600 was not actually used to record anything,
> I don't know for sure if the audio fallback actually "worked",
> other than that v4l-ctl reported non-muted audio afterwards.

Forcing BTSC for NTSC-M will always work.  You should hear something.


> The abridged syslog is below.
> Something I find interesting, is that it reported having to
> fallback twice on this boot (once during the initial anti-stutter tune,

BTW you shouldn't need to do that anymore.  The audio "stutter" was a
CX23418 APU and CPU firmware state problem about audio sampling rate
that the newer versions of the driver handle by loading those firmwares
twice and calling the APU firmware's APU_RESET_AI call.  The first
analog capture should never "stutter" anymore.

> and again when mythbackend started up).

Whenever cx18_av_core.c:input_change() is called, the audio
microcontroller audio standard autodetection is restarted.  This
function gets called at least once for each of these ioctl()s:

	VIDIOC_S_STD
	VIDIOC_S_FREQUENCY
	VIDIOC_S_INPUT

and probably for some other ioctl()s as well.  VIDIOC_S_FREQUENCY is
called for every channel tuning operation.  Your logs are probably
showing the effects of calls to S_INPUT and S_FREQUENCY.  You can 

	modprobe cx18 debug=0x10

to log cx18 ioctl calls if you are interested.


> I wonder if this means that once the audio bug is present,
> it remains present until the next time the driver is loaded/unloaded.

If we're talking about audio standard auto detection not working, I'll
guess "no".  Too much really depends on the input signal quality.

Auto detection working requires the analog tuner assembly to output a
stable SIF signal (from the broadcaster) upon which the CX23418 A/V
decoder will operate.

The TV channels needs to have an audio signal.  If you tune to a channel
with no signal, audio autodetection will always fail and fallback to the
forced mode.  The cx18 driver defaults to channel 4 on startup.



> Which matches previous observations.
> The fallback (hopefully) works around this, but there's still a bug
> somewhere that is preventing the audio from working without the fallback.

A way to test your hypothesis is to run a script that repeatedly tunes
among known analog stations, perhaps with ivtv-tune, and then check the
results of audio detection, perhaps with v4l2-ctl, after a few seconds.
You could also save a short segment of PCM audio from /dev/video24 (or
whatever) that you can check later with your own ear.
	


My hypothesis is that once BTSC is forced once, autodetection of BTSC
will more likely work well for a good number of channel changes
thereafter.

I do not have enough analog stations to run a test.

Regards,
Andy

> Cheers
> 
> Mark Lord


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 12/04/10 05:17 PM, Andy Walls wrote:
> On Mon, 2010-04-12 at 16:08 -0400, Mark Lord wrote:
..
>> I wonder if this means that once the audio bug is present,
>> it remains present until the next time the driver is loaded/unloaded.
>
>> Which matches previous observations.
>> The fallback (hopefully) works around this, but there's still a bug
>> somewhere that is preventing the audio from working without the fallback.
..

Okay, the "fallback" works -- recordings made with it do have good audio.

And.. my hypothesis appears to be true thus far:  once the audio fails,
requiring the fallback, it stays failed until the driver is reloaded.

Every subsequent recording made (after a "fallback") also experiences the fallback.
This is with a good channel, with good audio.  Subsequent recordings using the
exact same channel.

Weird, eh.  I wonder how to discover the real cause?

Good workaround, though!  Thanks.
  

On 12/04/10 10:22 PM, Mark Lord wrote:
..
> Okay, the "fallback" works -- recordings made with it do have good audio.
>
> And.. my hypothesis appears to be true thus far: once the audio fails,
> requiring the fallback, it stays failed until the driver is reloaded.
>
> Every subsequent recording made (after a "fallback") also experiences the fallback.
> This is with a good channel, with good audio. Subsequent recordings
> using the exact same channel.
..

Mmm.. further to that:  the problem went away as soon as I told
it to tune to a different channel.  No more fallbacks (for now).
It can now even retune the original channel without fallbacks.

So.. tuning to a new channel appears to fix whatever the bad state was
that was triggering the fallbacks.  Based on my sample of one, anyway. ;)

Now that it is behaving again, I cannot poke further until the next time
I'm lucky enough to be around when it fails.

> Weird, eh. I wonder how to discover the real cause?
> Good workaround, though! Thanks.

Cheers
  

On 12/04/10 10:30 PM, Mark Lord wrote:
..
> Mmm.. further to that: the problem went away as soon as I told
> it to tune to a different channel. No more fallbacks (for now).
> It can now even retune the original channel without fallbacks.
>
> So.. tuning to a new channel appears to fix whatever the bad state was
> that was triggering the fallbacks. Based on my sample of one, anyway. ;)
..

Nope.. what that second email should have said, was
Changing channels in LiveTV, no fallbacks required
because the audio is already working from the initial fallback.

As soon as I quit from LiveTV, the next recording still needed
a new fallback.  So the chip is still in some weird state where
auto-audio will continue to fail until I reload the module.

Cheers
  

On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote:
> On 12/04/10 10:30 PM, Mark Lord wrote:
> ..
> > Mmm.. further to that: the problem went away as soon as I told
> > it to tune to a different channel. No more fallbacks (for now).
> > It can now even retune the original channel without fallbacks.
> >
> > So.. tuning to a new channel appears to fix whatever the bad state was
> > that was triggering the fallbacks. Based on my sample of one, anyway. ;)
> ..
> 
> Nope.. what that second email should have said, was
> Changing channels in LiveTV, no fallbacks required
> because the audio is already working from the initial fallback.
> 
> As soon as I quit from LiveTV, the next recording still needed
> a new fallback.  So the chip is still in some weird state where
> auto-audio will continue to fail until I reload the module.


Thansk you for all the testing and feedback.

At this point I'm going to brush up the fixes by properly incorporating
support for the cx18_av_g_tuner()/cx18_av_s_tuner() calls so that user
space can still influence the audio mode (mono, stereo, Lang1, lang2,
etc.) even when audio standard and format are forced.  I'll have time on
Friday for this.



The *only* other thing I can think of, that I have control over, is the
PLL charge pump current in the analog tuner.  Right now it is set to low
current to minimize phase noise when tuned to a channel.  Perhaps
setting the PLL charge pump to high current while chaning the channel to
get a faster lock, and low current after a short time, will help get a
good SIF output from the analog tuner assembly sooner.  Perhaps when I
have time....

Regards,
Andy


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 13/04/10 06:35 AM, Andy Walls wrote:
> On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote:
..
>> As soon as I quit from LiveTV, the next recording still needed
>> a new fallback.  So the chip is still in some weird state where
>> auto-audio will continue to fail until I reload the module.
..
> The *only* other thing I can think of, that I have control over, is the
> PLL charge pump current in the analog tuner.  Right now it is set to low
> current to minimize phase noise when tuned to a channel.  Perhaps
> setting the PLL charge pump to high current while chaning the channel to
> get a faster lock, and low current after a short time, will help get a
> good SIF output from the analog tuner assembly sooner.  Perhaps when I
> have time....
..

What's weird, is that things work most of the time.
But as soon as one fallback is needed, the chip then fails
continuously afterward, requiring fallback after fallback.
Until the driver is reloaded.

So to me, that suggests that perhaps some register has gotten corrupted,
or some part of the chip has gone wanky.

Perhaps if the driver could re-init more of the chip when tuning,
which might correct whatever bits/state happen to need fixing?

I might have a look later, and see if there are any obvious registers
that perhaps I could have it dump out prior to doing the fallback,
and then compare that state with a "good" tuning state.  Or something.

Cheers
  

On Tue, 2010-04-13 at 08:42 -0400, Mark Lord wrote:
> On 13/04/10 06:35 AM, Andy Walls wrote:
> > On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote:
> ..
> >> As soon as I quit from LiveTV, the next recording still needed
> >> a new fallback.  So the chip is still in some weird state where
> >> auto-audio will continue to fail until I reload the module.
> ..
> > The *only* other thing I can think of, that I have control over, is the
> > PLL charge pump current in the analog tuner.  Right now it is set to low
> > current to minimize phase noise when tuned to a channel.  Perhaps
> > setting the PLL charge pump to high current while chaning the channel to
> > get a faster lock, and low current after a short time, will help get a
> > good SIF output from the analog tuner assembly sooner.  Perhaps when I
> > have time....
> ..
> 
> What's weird, is that things work most of the time.
> But as soon as one fallback is needed, the chip then fails
> continuously afterward, requiring fallback after fallback.
> Until the driver is reloaded.

Hmmm.  Interesting observation. 

> So to me, that suggests that perhaps some register has gotten corrupted,
> or some part of the chip has gone wanky.
>
> Perhaps if the driver could re-init more of the chip when tuning,
> which might correct whatever bits/state happen to need fixing?

If needed, once we're in a forced mode, we could stop the
microcontroller, reload all of the microcontroller firmware, and restart
it.  Kind of heavy handed, but it may work.


> I might have a look later, and see if there are any obvious registers
> that perhaps I could have it dump out prior to doing the fallback,
> and then compare that state with a "good" tuning state.  Or something.


# v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff

Keep in mind that some of these registers aren't settable and only read
out the state of various hardware blocks and functions.


Dumping the state of the microcontroller memory could also be done, but
I'd have to modify the driver to do it.
cx18-av-firmware.c:cx18_av_verifyfw() has code that's really close to
doing that.

Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 13/04/10 09:45 PM, Andy Walls wrote:
..
> # v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff
>
> Keep in mind that some of these registers aren't settable and only read
> out the state of various hardware blocks and functions.
>
>
> Dumping the state of the microcontroller memory could also be done, but
> I'd have to modify the driver to do it.
> cx18-av-firmware.c:cx18_av_verifyfw() has code that's really close to
> doing that.
..

Thanks.  I'll have a go at that some night.

Meanwhile, tonight, audio failed.

The syslog shows the usual "fallback" messages,
but the audio consisted of very loud static, the kind
of noise one gets when the sample bits are all reversed.

While it was failing, I tried retuning, stopping/starting
the recording, etc..  nothing mattered.  It wanted a reload
of the cx18 driver to cure it.

> If needed, once we're in a forced mode, we could stop the
> microcontroller, reload all of the microcontroller firmware, and restart
> it.  Kind of heavy handed, but it may work.
..

Perhaps that's what is needed here.

Cheers
  

On 14/04/10 12:32 AM, Mark Lord wrote:
..
> Thanks. I'll have a go at that some night.
>
> Meanwhile, tonight, audio failed.
..

Oh, I forgot to include this:

Apr 13 22:00:05 duke kernel: cx18-0: =================  START STATUS CARD #0  =================
Apr 13 22:00:05 duke kernel: cx18-0: Version: 1.4.0  Card: Hauppauge HVR-1600
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: MAC address is 00:0d:fe:1a:be:03
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43)
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38)
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31)
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: has radio
Apr 13 22:00:05 duke kernel: cx18-0 843: Video signal:              present
Apr 13 22:00:05 duke kernel: cx18-0 843: Detected format:           NTSC-M
Apr 13 22:00:05 duke kernel: cx18-0 843: Specified standard:        NTSC-M
Apr 13 22:00:05 duke kernel: cx18-0 843: Specified video input:     Composite 7
Apr 13 22:00:05 duke kernel: cx18-0 843: Specified audioclock freq: 48000 Hz
Apr 13 22:00:05 duke kernel: cx18-0 843: Detected audio mode:       forced mode
Apr 13 22:00:05 duke kernel: cx18-0 843: Detected audio standard:   forced audio standard
Apr 13 22:00:05 duke kernel: cx18-0 843: Audio muted:               no
Apr 13 22:00:05 duke kernel: cx18-0 843: Audio microcontroller:     running
Apr 13 22:00:05 duke kernel: cx18-0 843: Configured audio standard: BTSC
Apr 13 22:00:05 duke kernel: cx18-0 843: Configured audio mode:     MONO2 (LANGUAGE B)
Apr 13 22:00:05 duke kernel: cx18-0 843: Specified audio input:     Tuner (In8)
Apr 13 22:00:05 duke kernel: cx18-0 843: Preferred audio mode:      stereo
Apr 13 22:00:05 duke kernel: cx18-0 gpio-reset-ctrl: GPIO:  direction 0x00003001, value 0x00003001
Apr 13 22:00:05 duke kernel: tda9887 2-0043: Data bytes: b=0x14 c=0x30 e=0x44
Apr 13 22:00:05 duke kernel: tuner 2-0061: Tuner mode:      analog TV
Apr 13 22:00:05 duke kernel: tuner 2-0061: Frequency:       531.25 MHz
Apr 13 22:00:05 duke kernel: tuner 2-0061: Standard:        0x0000b000
Apr 13 22:00:05 duke kernel: cs5345 1-004c: Input:  1
Apr 13 22:00:05 duke kernel: cs5345 1-004c: Volume: 0 dB
Apr 13 22:00:05 duke kernel: cx18-0: Video Input: Tuner 1
Apr 13 22:00:05 duke kernel: cx18-0: Audio Input: Tuner 1
Apr 13 22:00:05 duke kernel: cx18-0: GPIO:  direction 0x00003001, value 0x00003001
Apr 13 22:00:05 duke kernel: cx18-0: Tuner: TV
Apr 13 22:00:05 duke kernel: cx18-0: Stream: MPEG-2 Program Stream
Apr 13 22:00:05 duke kernel: cx18-0: VBI Format: Private packet, IVTV format
Apr 13 22:00:05 duke kernel: cx18-0: Video:  720x480, 30 fps
Apr 13 22:00:05 duke kernel: cx18-0: Video:  MPEG-2, 4x3, Variable Bitrate, 12000000, Peak 14500000
Apr 13 22:00:05 duke kernel: cx18-0: Video:  GOP Size 15, 2 B-Frames, GOP Closure
Apr 13 22:00:05 duke kernel: cx18-0: Audio:  48 kHz, MPEG-1/2 Layer II, 224 kbps, Stereo, No Emphasis, No CRC
Apr 13 22:00:05 duke kernel: cx18-0: Spatial Filter:  Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0
Apr 13 22:00:05 duke kernel: cx18-0: Temporal Filter: Manual, 8
Apr 13 22:00:05 duke kernel: cx18-0: Median Filter:   Off, Luma [0, 255], Chroma [0, 255]
Apr 13 22:00:05 duke kernel: cx18-0: Status flags: 0x00200001
Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder MPEG: status 0x0118, 0% of 2048 KiB (64 buffers) in use
Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder YUV: status 0x0000, 0% of 2025 KiB (20 buffers) in use
Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder VBI: status 0x0038, 5% of 1015 KiB (20 buffers) in use
Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder PCM audio: status 0x0000, 0% of 1024 KiB (256 buffers) in use
Apr 13 22:00:05 duke kernel: cx18-0: Read MPEG/VBI: 190420992/476784 bytes
Apr 13 22:00:05 duke kernel: cx18-0: ==================  END STATUS CARD #0  ==================
  

On 14/04/10 12:32 AM, Mark Lord wrote:
..
> The syslog shows the usual "fallback" messages,
> but the audio consisted of very loud static, the kind
> of noise one gets when the sample bits are all reversed.
>
> While it was failing, I tried retuning, stopping/starting
> the recording, etc.. nothing mattered. It wanted a reload
> of the cx18 driver to cure it.
..

Since all of this happens rather randomly,
I'm beginning to more strongly suspect a race condition
somewhere in the driver.

Now, it's a rather large driver -- lots of complexity in that chip
-- so it will take me a while to sort through things.

But at first blush, I don't see any obvious locking around
the various read-modify-write sequences for the audio registers.

And a quick "grep spin *.[ch]" shows a few spin_lock/spin_unlock
calls in cx18-queue.c and cx18-stream.c (as well as the alsa code,
which shouldn't be in play in this scenario).

Oddly, none of those spinlocks use _irq or _irq_save/restore,
which means they aren't providing any sort of mutual exclusion
against the interrupt handler.

But like I said, I'm only just beginning to look more closely now.
  

On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote:
> On 14/04/10 12:32 AM, Mark Lord wrote:
> ..
> > The syslog shows the usual "fallback" messages,
> > but the audio consisted of very loud static, the kind
> > of noise one gets when the sample bits are all reversed.
> >
> > While it was failing, I tried retuning, stopping/starting
> > the recording, etc.. nothing mattered. It wanted a reload
> > of the cx18 driver to cure it.
> ..
> 
> Since all of this happens rather randomly,
> I'm beginning to more strongly suspect a race condition
> somewhere in the driver.
> 
> Now, it's a rather large driver -- lots of complexity in that chip
> -- so it will take me a while to sort through things.

You can at least logically break it into components:

cx18-av-*      : the integrated A/V decoder subdevice (very much like a CX25843)

cx18-gpio*     : logical subdevices for functions controlled by GPIO
cx18-alsa*     : the ALSA interface presented to userspace
cx18-fileops*, cx18-ioctl*, cx18-contorls* : The V4L2 interface
cx18-dvb*      : The DTV interface
cx18-streams*  : main streams management, and empty DMA buffer handover
cx18-queue*    : queue routines used for all queues for all streams
cx18-mailbox*, cx18-scb* : driver-firmware API, main body of hard irq handler for incoming DMA, and workhandler for incoming DMA
cx18-io*       : Insanity to handle CX23418 PCI MMIO quirks
cx18-irq*      : The hard irq handler
cx18-driver*   : main driver probe and shutdown
cx18-cards*    : specifics on each supported card
cx18-firmware* : Bridge and MPEG encoder firmware load and init, but not A/V core firmware
cx18-i2c*      : I2C master setup, bus driving, and device registration
cx18-audio*    : Top level audio routing functions
cx18-video*    : Top level video routing functions
cx18-vbi*      : VBI data extraction


> But at first blush, I don't see any obvious locking around
> the various read-modify-write sequences for the audio registers.

The ioctl handling in the driver does it:

$ grep serialize_lock *

The serialize_lock is a bit overloaded, but it's frequent operational
use is ioctl() serialization.  The A/V core is almost exclusively
manipulated by ioctl()s.  The timer I added for fallback is an
exception.


> And a quick "grep spin *.[ch]" shows a few spin_lock/spin_unlock
> calls in cx18-queue.c and cx18-stream.c (as well as the alsa code,
> which shouldn't be in play in this scenario).

Correct.

What is involved are the three "reset" processes in the cx18-av-* files:

1. Stopping and restarting the microcontroller via register 803
2. Soft reset (of what exactly?) via register 0x810
3. Format detection loop restart via register 0x9cc

I have no idea if 2 & 3 above reset hardware and registers, or simply
set a flag for the microcontroller firmware to notice, or both.

So I've wondered about the exact sequencing of stopping the
microcontoller, peforming the other 2 resets, and restarting the
microcontroller.


> Oddly, none of those spinlocks use _irq or _irq_save/restore,
> which means they aren't providing any sort of mutual exclusion
> against the interrupt handler.

There is no need.  The hard irq handler only really deals with firmware
mailbox ack and firmware mailbox ready notifications.  It sucks off the
mailbox contents and shoves it over to the cx18-NN-in workhandler via
work orders placed on a workqueue.  The work handler does grab the
spinlocks, but it is from a non-irq context.


> But like I said, I'm only just beginning to look more closely now.

Look at the publicly available CX25843 datasheet:

	http://dl.ivtvdriver.org/

pages 107-116 and Section 5.7.  In figure 3.30 we've got SIF coming in
from the analog tuner and the microcontoller is represented by the "Auto
Std/Mode Detection" block.  In figure 3-38 the output of the "source
select" block is what then gets fed to the baseband processing chain as
digital audio from the tuner.



For reference, you may want to also grab FCC docment OET60 (Rev A from
1996?), which technically describes the BTSC audio subcarriers.  Then
Google for a nice pciture of the MTS/BTSC spectrum.

This app note has a good picture in figure 1:
	http://assets.fluke.com/appnotes/it_products/Anbtsc.pdf
although it is missing the "PRO" channel that is above SAP at 6fh IIRC.

I don't know what part of the BTSC spectrum the Conexant microcontroller
is keying off of, but I guessing the pilot for sure is part of the
decision process.

Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 15/04/10 12:46 AM, Andy Walls wrote:
> On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote:
..
>> Oddly, none of those spinlocks use _irq or _irq_save/restore,
>> which means they aren't providing any sort of mutual exclusion
>> against the interrupt handler.
>
> There is no need.  The hard irq handler only really deals with firmware
> mailbox ack and firmware mailbox ready notifications.  It sucks off the
> mailbox contents and shoves it over to the cx18-NN-in workhandler via
> work orders placed on a workqueue.  The work handler does grab the
> spinlocks, but it is from a non-irq context.
..

Mmmm.. but it does do read-modify-write on several registers inside the IRQ handling.
I suppose those might be "safe" groups, written to _only_ by the IRQ handler,
but maybe not.

 From what I can see, (nearly?) all registers are read/written as full 32-bit units.
So when code wants to modify an 8-bit "register", this is converted into a read-
modify-write of the corresponding 32-bit register.

So if two threads, or any thread and the irq handler, want to modify parts
of the same 32-bit register, then there's a race.  The code _appears_ to mostly
not have such a problem, but it would conveniently explain the sporadic failures.  :)

So, for now, I've added lower level spinlock protection onto all register writes,
as well as to routines that themselves do a higher level read-modify-write:
eg. the routines to enable/disable specific IRQ sources.

This was easy enough to do, and it'll give us confidence that the r-m-w sequences
are not the issue.  Or perhaps it'll cure some problems.  Time will tell.

I'll run with that patch on top of yours for the next couple of days,
or until I see a "fallback" log again.  None so far, though.

Cheers
  

On 15/04/10 01:16 AM, Mark Lord wrote:
>
> for now, I've added lower level spinlock protection onto all
> register writes,
..

As you expected, this doesn't seem to have cured anything obvious.  :)

I had Mythtv wakeup/record/powerdown several times overnight,
and it still required "fallbacks" for about half of those.

And.. one of the "fallback" recordings still had muted audio.
Even though my script which checks for that reported "audio ok".

Enough for now.. I'll hack some more on the weekend.

cheers
  

On Thu, 2010-04-15 at 01:16 -0400, Mark Lord wrote:
> On 15/04/10 12:46 AM, Andy Walls wrote:
> > On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote:
> .
> 
> Mmmm.. but it does do read-modify-write on several registers inside the IRQ handling.
> I suppose those might be "safe" groups, written to _only_ by the IRQ handler,
> but maybe not.

In the linux driver, the registers in CX23418 address range:

	0x2c40000-0x2c409ff

are only written to by the files named cx18-av-*[ch], which is mostly
ioctl() call driven.  (Those registers are logically mapped by the linux
driver code to 0x000-0x9ff to make the integrated A/V decoder look like
a CX25843 chip for convenience.)

Accesses to those are orthognal to the rest of the cx18 driver,
including the IRQ handler.  (I agree, its hard to follow things in the
driver; it's very large.)

Do note, however, that the audio standard detection microcontroller
*does* write to the registers in 0x800-0x9ff *independent* of the linux
cx18 driver.

Locking with respect to the microcontroller would mean halting and
restarting the microcontroller.  I don't know if that causes it to reset
or not, and I do not know how it affects it's internal timers.

Regards,
Andy



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Wed, 2010-04-14 at 00:32 -0400, Mark Lord wrote:
> On 13/04/10 09:45 PM, Andy Walls wrote:

> The syslog shows the usual "fallback" messages,
> but the audio consisted of very loud static, the kind
> of noise one gets when the sample bits are all reversed.

When in forced audio mode, the microcontroller will unmute.  What you
hear is what the decoder is decoding for BTSC.  And that makes your
observation *very* interesting.

The sample rate conversion for SIF is fixed at about 62.937 ksps.  That
is 4 times the NTSC line rate of 15.734 kHz.  Also note, that for
anything other than simple monaural L+R audio, the BTSC subcarrier pilot
and subcarrier center frequencies are based on multiples of Fh = 15.734
kHz.

So if you hear something that sounds like sampling being performed at
the wrong rate, I think we have one of two other problems:

a. The horizontal sync tracking loop in the A/V decoder is way off
(unlikely if you can see video properly)

or

b. the SIF signal from the analog tuner is off center.



> While it was failing, I tried retuning, stopping/starting
> the recording, etc..  nothing mattered.  It wanted a reload
> of the cx18 driver to cure it.


Since you have a unit with FM radio, for a simple test, when you notice
the fallback happen:

1. stop your TV capture
2. perform a short FM radio capture with ivtv-radio (it doesn't have to
find a station, it shouldn't matter)
3. retry your TV capture.

I'm hoping that this reconfiguration of the analog tuner's IF
demodulator chip will correct any problem with the SIF output from the
analog tuner.


Regards,
Andy

BTW, that's for all your testing.  It's really helpful.

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Fri, 2010-04-16 at 09:15 -0400, Andy Walls wrote:

> 
> Regards,
> Andy
> 
> BTW, that's for all your testing.  It's really helpful.
       ^^^^^^

That should be "thanks".

-Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Thu, 2010-04-15 at 10:15 -0400, Mark Lord wrote:

> And.. one of the "fallback" recordings still had muted audio.
> Even though my script which checks for that reported "audio ok".
> 
> Enough for now.. I'll hack some more on the weekend.

I had to disassemble and study some of the microcontorller firmware, and
then reread some documents, to figure out how all the audio detection
"resets" must work.

I've just pushed some microcontroller reset related changes to the
cx18-audio2 repo.  Please test and see if things are better or worse.  

The analog stations I had last weekend I can't seem to pick up anymore.

Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 17/04/10 12:43 AM, Andy Walls wrote:
> I had to disassemble and study some of the microcontorller firmware, and
> then reread some documents, to figure out how all the audio detection
> "resets" must work.
>
> I've just pushed some microcontroller reset related changes to the
> cx18-audio2 repo.  Please test and see if things are better or worse.
..

Mmm.. something is not right -- the audio is failing constantly with that change.
Perhaps if I could dump out the registers, we might see what is wrong.

I also tried:
      v4l2-dbg -d /dev/video1 -c type=host,chip=1 --list-registers=min=0x800,max=0x9ff
but that fails to read any of the registers (ioctl: VIDIOC_DBG_G_REGISTER failed for 0xXXX).

I think I'll patch the driver to dump them for us.

Thank-you for your work on this.  There are many of us here  hoping
that we can figure out and fix whatever is wrong with our cards.

Cheers
  

On 16/04/10 08:59 AM, Andy Walls wrote:
..
> Accesses to those are orthognal to the rest of the cx18 driver,
> including the IRQ handler.  (I agree, its hard to follow things in the
> driver; it's very large.)
>
> Do note, however, that the audio standard detection microcontroller
> *does* write to the registers in 0x800-0x9ff *independent* of the linux
> cx18 driver.
>
> Locking with respect to the microcontroller would mean halting and
> restarting the microcontroller.  I don't know if that causes it to reset
> or not, and I do not know how it affects it's internal timers.
..

Since the problem really does behave like a "race condition" would behave,
I wonder if it could have something to do with how/when we modify any of
those registers which are shared with the microcontroller?

The cx18 driver *always* does read-modify-write (RMW) of 32-bits at at time,
even when just an "8-bit" register is being modified.

If the microcontroller is using/updating the other 24-bits of any of those
registers, then the cx18 driver's RMW will destroy values that the microcontroller
has written.

Is it possible to write only 8-bits, rather than having to do the RMW on 32-bits ?

Cheers
  

On 17/04/10 08:09 AM, Mark Lord wrote:
..
> Mmm.. something is not right -- the audio is failing constantly with that change.
> Perhaps if I could dump out the registers, we might see what is wrong.
..

When the microcontroller is reset, does it put all settings back to defaults?
I wonder if this causes it to select a different audio input, as part of the reset?

If so, then we'll need to reselect the tuner-audio afterward.
Anything else?


??
  

On Sat, 2010-04-17 at 08:09 -0400, Mark Lord wrote:
> On 17/04/10 12:43 AM, Andy Walls wrote:
> > I had to disassemble and study some of the microcontorller firmware, and
> > then reread some documents, to figure out how all the audio detection
> > "resets" must work.
> >
> > I've just pushed some microcontroller reset related changes to the
> > cx18-audio2 repo.  Please test and see if things are better or worse.
> ..
> 
> Mmm.. something is not right -- the audio is failing constantly with that change.

Crud.  I added an additional soft reset using register 0x810 with that
change; maybe that needs to be taken out.


> Perhaps if I could dump out the registers, we might see what is wrong.




> I also tried:
>       v4l2-dbg -d /dev/video1 -c type=host,chip=1 --list-registers=min=0x800,max=0x9ff
> but that fails to read any of the registers (ioctl: VIDIOC_DBG_G_REGISTER failed for 0xXXX).
> 
> I think I'll patch the driver to dump them for us.

Whatever's easiest.  As root, this should work:

# v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff
ioctl: VIDIOC_DBG_G_REGISTER

                00       04       08       0C       10       14       18       1C
00000800: 13248000 0000fefe 01010411 20000000 80ff0200 20140905 000031c0 478005d1 
00000820: 80002800 e084e044 007e54a8 240107f2 0186a020 00000000 24010800 0186a020 
00000840: 00000000 00801c00 00000020 00000000 00a14f72 00000030 00000000 00007800 
[...]
000009c0: 80007ffc 00000000 0000c000 00000001 02000200 00000000 00000000 00000000 
000009e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Or equivalently with the actual register addresses (vs. the logical remapping using host1):

#  v4l2-dbg -d /dev/video0  --list-registers=min=0x2c40800,max=0x2c409ff
ioctl: VIDIOC_DBG_G_REGISTER

                00       04       08       0C       10       14       18       1C
02c40800: 137d8000 0000fefe 01010411 20000000 80ff0200 20140905 000031c0 478005d1 
02c40820: 80002800 e084e044 007e54a8 240107f2 0186a020 00000000 24010800 0186a020 
02c40840: 00000000 00801c00 00000020 00000000 00a14f72 00000030 00000000 00007800 
[...]
02c409c0: 7ffc27cc 00000000 0000c000 00000001 02000200 00000000 00000000 00000000 
02c409e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

Dumps of registers might help me figure out something.


> Thank-you for your work on this.  There are many of us here  hoping
> that we can figure out and fix whatever is wrong with our cards.

No problem.  Sorry for all the shots in the dark so far.  Without a
BTSC/MTS signal source I'm just trying to guess what might be wrong.
(Most VCR's, set top boxes, and RF modulators only seem to put out the
monaural L+R sound signal and not an MTS BTSC signal with the pilot tone
and stereo L-R as well).

Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Sat, 2010-04-17 at 09:01 -0400, Mark Lord wrote:
> On 17/04/10 08:09 AM, Mark Lord wrote:
> ..
> > Mmm.. something is not right -- the audio is failing constantly with that change.
> > Perhaps if I could dump out the registers, we might see what is wrong.
> ..
> 
> When the microcontroller is reset, does it put all settings back to defaults?

The microcontroller reset via register 0x803 causes the 8051 hardware to
go to reset state and jump back to execute at address 0x0000 of the
loaded v4l-cx23418-dig.fw firmware image.

> I wonder if this causes it to select a different audio input, as part of the reset?

The microcontroller doesn't control much in the way of routing except
what outputs of the SIF decoding (L+R, L-R, SAP, dbx, NICAM) to route to
the dematrix and the baseband audio processing path.


> If so, then we'll need to reselect the tuner-audio afterward.
> Anything else?

I think the extra soft reset I added might be doing something bad.
Based on what I can tell:

1. Register 0x803 start/stop of the microcontroller is for sure a
microcontroller hardware reset and likely nothing else

2. Register 0x9cc bit 1 is almost certainly only a software flag to the
microcontroller program.  It doesn't appear to affect hardware.

3. Soft reset via register 0x810 must affect hardware units and
registers and not the micrcontroller itself.

So perhaps you could try removing the extra soft rest I added in my
changes to cx18-av-core.c


I also added a mute of baseband processing path 1 to the firmware load
and init in cx18-av-firmware.c.  The microcontroller should be unmuting
things when it detects a broadcast standard, so I didn't think it was a
problem.  Maybe it is.


Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On Sat, 2010-04-17 at 08:18 -0400, Mark Lord wrote:
> On 16/04/10 08:59 AM, Andy Walls wrote:
> ..
> > Accesses to those are orthognal to the rest of the cx18 driver,
> > including the IRQ handler.  (I agree, its hard to follow things in the
> > driver; it's very large.)
> >
> > Do note, however, that the audio standard detection microcontroller
> > *does* write to the registers in 0x800-0x9ff *independent* of the linux
> > cx18 driver.
> >
> > Locking with respect to the microcontroller would mean halting and
> > restarting the microcontroller.  I don't know if that causes it to reset
> > or not, and I do not know how it affects it's internal timers.
> ..
> 
> Since the problem really does behave like a "race condition" would behave,
> I wonder if it could have something to do with how/when we modify any of
> those registers which are shared with the microcontroller?

It certainly could.  The changes where we set our preferences in
registers 0x808-0x80b need to be protected.  We then need to notify the
microcontroller properly that we have set things.

Currently tmy latest changes do this:

1. halt the microcontroller by holding it in reset via register 0x803
(This is our lock out of the microcontroller from modifying registers)
2. assert the soft reset via register 0x810
3. set our preferences in register 0x808-0x80b
4. deassert soft reset via register 0x810
5. restart the microcontroller via register 0x803
6. Pulse the format detection reset flag via register 0x9cc
7. Schedule a 1.5 second delay to come back and check if the
microcontroller found something.


So I'm unsure about 

a. the exact sequencing of the current steps 2-4 (and if steps 2 & 4 are
needed at all)

b. if we're pulsing the bit in 0x9cc too rapidly in step 6

c. if we should wait a little longer than 1.5 seconds in step 7.




> The cx18 driver *always* does read-modify-write (RMW) of 32-bits at at time,
> even when just an "8-bit" register is being modified.
> 
> If the microcontroller is using/updating the other 24-bits of any of those
> registers, then the cx18 driver's RMW will destroy values that the microcontroller
> has written.

The micrcontroller should only read registers 0x808-0x80b and never
write them.

I suspect the micrcontroller does check and modify the soft reset bit in
register 0x810 itself at times.  (I do not know what hardware units that
bit resets, if any.)

Register 0x9cc only ever appears to be read by the microcontroller.

> 
> Is it possible to write only 8-bits, rather than having to do the RMW on 32-bits ?

Yes it should be possible.  PCI read of bytes are possible PCI bus
transactions.  I've never tried it, and there are no routines in
cx18-io.[ch] presently to assist with the occasional failure to write a
CX23418 register.

You're welcome to check to se if it makes a difference, but please make
sure you don't modify the firmware loading process, it's pretty touchy.

Regards,
Andy


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html