[ivtv-users] CX18 audio interference

[faginbagin]

Hi Andy,

> OK.  I wasn't sure if it would.  That narrows the problem to the '843
> core in the CX23418 (I think).
> 
> Could you provide the output of 
> 
> # v4l2-dbg -d /dev/video0 -c host0 --log-status -l
> 
> for when you are tuned to a channel with good sound and one with
> consistent static (but good video).

Good sound: See attached dbg-after-mplayer-chan4.txt & dbg-tune-chan2.txt
dbg-after-mplayer-chan4.txt was captured after starting mplayer, default channel appears to be 4.
dbg-tune-chan2.txt was captured after tuning to channel 2.

Static but good video; See attached dbg-tune-chan41.txt
Channel 41 is one of the noisier channels.

> BTW are using the firmware available from 
> 
> http://dl.ivtvdriver.org/ivtv/firmware/cx18-firmware.tar.gz

Yes. The correct files are provided by the mythbuntu jaunty distro. I double checked it by downloading the above and cmp'ing each .fw file against the distro files.

>> I see only one such message:
>> [10899.263227] cx18-0: cx18_writel failed to write 0x00000b05 to addr 0x02c72014
>>
>> And I believe it's to be expected, because it occurred when I called:
>> v4l2-dbg -c host0 -s 0x2c72014 0xb05
>> and the value that's read back is 0x305, right?
> 
> Yup.  The v4l2-dbg command can't tell the driver what value to expect to
> read back.  If that's the only message like that, then the driver is
> setting all the registers as it intended .

And during this latest test, there were no 'failed to write' messages in dmesg.

>> FWIW, a while back, you asked Terry whether APU & CPU firmware were loaded twice.
>> What I see are two pairs of requests to load them. Only the first pair of requests
>> are followed with "loaded" messages.
> 
> Yes, that's by design.  Without debugging enabled, we only log when
> we're done loading the firmwares (twice).  We load them twice to
> overcome a firmware bug related to the digital TV TS not working every
> other time the cx18 module is reloaded.

Are there any other debug flags I should enable besides CONFIG_VIDEO_ADV_DEBUG? I was going to attach my .config file, but it caused thie email to exceed a 40K limit.

> OK.  So it looks like everything is happening as the cx18 driver
> intended.  This means simply, that the cx18 driver is likely doing
> *something* wrong that doesn't matter for many boards, but appears to
> matter for yours.  It is likely related to the setup of the '843 core in
> the CX23418 front end.  Hopefully differential analysis of the register
> dumps will provide some insight.
> 
> BTW, could you check if inhibiting the load of lirc_i2c makes things
> better?

This time, I made sure to stop the lircd daemon and to rmmod lirc_i2c and lirc_dev before modprobing cx18. I made sure the lirc modules didn't automagically reappear after modprobing or after running mplayer. So I think it's safe to say they've got nothing to do with my problem. Although, to be certain, I could do a scan of all channels.

I also have a dmesg.txt that covers the time from when I unloaded & reloaded modules to when I stopped mplayer. I'm not attaching it as it would put this message over 40K. If you want it, and/or my .config file, perhaps I should send them to you off-list?

Regards,
Helen

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dbg-after-mplayer-chan4.txt
Url: http://ivtvdriver.org/pipermail/ivtv-users/attachments/20090501/22048a3e/attachment-0003.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dbg-tune-chan2.txt
Url: http://ivtvdriver.org/pipermail/ivtv-users/attachments/20090501/22048a3e/attachment-0004.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dbg-tune-chan41.txt
Url: http://ivtvdriver.org/pipermail/ivtv-users/attachments/20090501/22048a3e/attachment-0005.txt