Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2006-04-20 at 20:57 +0200, Gerhard Pircher wrote:

> 1. The AmigaOne is similar to the PREP platform, i.e. DMA can only be
> performed in the first 16MB for ISA devices (there's only a VIA southbridge,
> no other SuperI/O IC with 32bit capable DMA controller). I guess the first
> 16MB cannot be reserved for not coherent DMA operation, because this memory
> area is occupied by kernel data? (not to talk about the performance loss, if
> the kernel data area would be excluded from the BAT mapping).

Yeah that would suck. Are you sure you need ISA DMA ? You can do pseudo
DMA like pegasos for the floppy. Anything else should be able to do 32
bits DMA unless you have a very broken chipset.

> 2. I'm not sure how to allocate memory for DMA operation. I think
> alloc_pages() will not do the job for me, as the page tables for not
> coherent DMA are reserved (SetPageReserved()) and removed from the available
> lowmem.

alloc_pages() ? How so ? No, you want to allocate from your reserved
pool, you'll have to implement your own allocator. Easiest is a running
bitmap, look at ppc64 iommu code for an example.

>  Also memory fragmentation may be a problem, if a lot DMA operations
> with different buffer sizes are performed. Therefore a system could quickly
> run out of memory for not coherent DMA operation, right?
> Is there a way to minimize fragmentation?

Best you can do is have separate pools for small and big allocations I
suppose.

> 3. How are DMA buffers used outside the kernel? Do user programs get a
> pointer to the DMA buffer (in theory) from the device driver or is the data
> copied to another buffer allocated by an user program?

There are cases where some drivers try that but you should ignore it for
the moment. Won't happen in most cases.

Ben.