Hi.

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

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.

Out of curiosity, what is number of channels? I had simialar issue with
HIFN crypto driver and limited number of descriptor to 80 iirc, since
with that number HIFN traversal did not show perfromance degradataion on
Ghz x86.

quoted

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.

I meant descriptor hdr value accessed via it - can it be checked in
tasklet under the lock and in submit path without? Can they correlate
somehow?

-- 
	Evgeniy Polyakov