Any restrictions on DMA address boundry?

Matt Porter mporter at kernel.crashing.org
Fri Sep 26 05:56:53 EST 2003


On Thu, Sep 25, 2003 at 01:15:15PM -0500, Bret Indrelee wrote:
> I've read through the old thread about short DMAs, but still there are
> things that aren't clear to me.
>
> What exactly is the issue?

The issue is confined to processors which do not support hardware
snooping of the external bus.  In this case, management of the
caches is performed in software.  Software cache management is
has a granularity of the processor's cache line size.  When a
buffer is allocated using the allowed methods (as defined in
DMA-mapping.txt) to obtain memory for use in DMA, there is
no guarantee that the buffer is cacheline aligned.  Imagine
one buffer allocated for internal driver management and another
buffer allocated for inbound DMA transactions from a bus
master.  They can share the same cacheline.  Inbound DMA
read transaction occurs, the usual streaming DMA API call is
made, and the platform-specific implementation invalidates the
entire cacheline.  This could corrupt the contents of the
allocated management buffer that is being accessed by the CPU
only.

> As I understand it, if there is a DMA to the same cache line as something
> that the CPU is referencing, you've got a cache problem.

On a certain type of processors, yes.

> Does it matter what type of transfer the PCI device is doing? If it
> always does 32-bit burst memory write transfers instead of memory
> write & invalidate does that make a difference?
>
> Right now, I'm interested in the PPC and x86 compatible (Pentium,
> Pentium 4, Geode) systems, trying to understand the differences and
> requirements of each.

Which PPCs?  Classic PPC != PPC8xx != PPC40x != Book E PPC. :)

PPC8xx and PPC4xx require software cache coherency.  If you want
your products to work on PPC44x (I hope you do, they are targetted
at markets where qlogic storage controllers are used) ensuring that
your DMA buffers are cacheline aligned at the head/tail is
important.

-Matt

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





More information about the Linuxppc-embedded mailing list