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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
