On Sat, 31 May 2008 01:12:08 +0400
Evgeniy Polyakov [off-list ref] wrote:

On Fri, May 30, 2008 at 03:48:20PM -0500, Kim Phillips (kim.phillips@freescale.com) wrote:

quoted

sorry, by ISR I meant interrupt status registers.  but I can't tell
where the suspected simultaneous accesses are.  Evgeniy, can you point
out the register accesses you're talking about?

priv->status is accessed from tasklets, although readonly, but that rises
a red flag... Also callback invocation tasklet drops the lock around

ok, I see what you are saying now; if a channel gets done during
talitos_done processing, it'll trigger an interrupt and reset
priv->status, leaving the tasklet in the dark as to which channel has
done status, depending on how many channel dones it has already
processed.  I think the only solution here is to call flush_channel on
each channel, regardless of the bits in the interrupt status - I'll
send out a patch shortly.

callback, during that time cached status and priv itself (and tail like
in two simultaneous flushes) could change (or not?)

I think you're talking about a different 'status' here; flush_channel's
local 'status' doesn't resemble priv->status bits in any way, it looks
at the descriptor header writeback bits for done status, on a per
descriptor basis.  It forwards this descriptor done vs. error status to
the callback.

priv itself won't change; it's uniquely associated to the device.

Kim