[MPC52xx]Latency issue with DMA on FEC
Scott Wood
scottwood at freescale.com
Thu Dec 2 08:16:12 EST 2010
On Wed, 1 Dec 2010 15:09:54 +0000
David Laight <David.Laight at ACULAB.COM> wrote:
> The in_le32() not only contains the unwanted 'sync', but also
> a 'twi' (trap immediate - NFI exactly what this does) and 'isync'.
It turns a data dependency into a flow dependency. It's basically equivalent to:
lwz rX, ...
cmpw rX, rX
bne 1f
1: isync
> The 'isync' is particularly horrid and unnecessary (aborts
> the instruction queue and refeches the opcode bytes)
The isync makes sure that the twi has completed before proceeding.
Note that the guarded, cache-inhibited load itself can be pretty
painful -- the core can't restart it, so it must complete before you
can take an interrupt.
> The very slow in_le32() might be there to give semi-synchronous
> traps on address fault - but unless the hardware is being probed
> that really isn't necessary.
There are times when you really want to be sure that the I/O is
finished before proceeding with something that isn't a load/store and
thus can't be serialized with normal barriers.
E.g. you're about to execute instructions in a physical address window
that you just set up (or even just create a non-guarded mapping to it
-- could get speculative accesses any time), or you just masked an
interrupt at the PIC (with a readback to flush) and are about to enable
MSR[EE].
Most of the time, though, it's overkill. It should probably be an
alternate accessor form, or maybe a wait_for_io() wrapper -- if it can
be shown to make a real performance difference.
-Scott
More information about the Linuxppc-dev
mailing list