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
--
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
