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 -- Mark Lord Real-Time Remedies Inc. mlord@xxxxxxxxx -- 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
