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.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
