On Wed, 23 Jan 2008 14:18:38 +0100 Marc Pignat <[EMAIL PROTECTED]> wrote:
> 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. > 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
