On Wed, 23 Jan 2008 14:18:38 +0100
Marc Pignat <marc.pignat@hevs.ch> wrote:

quoted text
> On Wednesday 23 January 2008, Haavard Skinnemoen wrote:
> > Ok, but then any power of two larger than the cache line size should be
> > fine, assuming kmalloc() returns a properly aligned buffer.
> Yes. The memory should be allocated using GFP_KERNEL | GFP_DMA flags, but this
> is probably a nop on at91 and avr32.

GFP_DMA doesn't have anything to do with alignment, AFAIK.

quoted text
> I prepare a patch using the generic dma api (allocation + dma mapping in one
> call = simpler code).

No, please don't. If you're thinking of dma_alloc_coherent(), it means
that the cache will be bypassed when accessing the buffer (slower), and
that the size will be rounded up to the next multiple of the page size
(larger). If the sole purpose of doing that is to get properly aligned
buffers, we might as well use the page allocator directly.

kmalloc() does return cache-aligned buffers on AVR32, so a patch like
that would have only downsides. I'm not sure about ARM though.

quoted text
> > Other than that, I can't see any reason why a platform with 64 byte
> > cache lines should need larger buffers than one with 32 byte cache
> > lines.
> If the memory at the end of the cacheline is used by the cpu, it will be
> corrupted while you call dma_sync_single_for_cpu(..., DMA_FROM_DEVICE);

True, but if that happens, the right fix is to provide a suitable
definition of ARCH_KMALLOC_MINALIGN on ARM.

Haavard
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/