ARM: support for cache coherent allocations
PATCH 1/1 ARM: support for cache coherent allocations
This is a draft implementation of cache coherent memory allocator. This simple implementation just reserves memory area below malloc space and leave it uncached even if data cache is enabled. Allocations are even simpler: code just verifies that we have enough space and increments the offset counter. No deallocations supported for now. In future versions we could probably use dlmalloc allocator to get space out of coherent pool.
--- arch/arm/include/asm/dma-mapping.h | 4 ++++ arch/arm/include/asm/global_data.h | 4 ++++ arch/arm/lib/Makefile | 1 + arch/arm/lib/board.c | 8 ++++++++ arch/arm/lib/cache-cp15.c | 5 +++++ arch/arm/lib/dma-coherent.c | 37 ++++++++++++++++++++++++++++++++++++ 6 files changed, 59 insertions(+) create mode 100644 arch/arm/lib/dma-coherent.c
arch/arm/include/asm/dma-mapping.h +4 -0
@@ -30,11 +30,15 @@ enum dma_data_direction { DMA_FROM_DEVICE = 2, }; +#ifndef CONFIG_DMA_COHERENT static void *dma_alloc_coherent (size_t len,unsigned long *handle) { *handle = (unsigned long )malloc (len);return (void *)*handle; } +#else +void *dma_alloc_coherent (size_t len,unsigned long *handle); +#endif static inline unsigned long dma_map_single (volatile void *vaddr,size_t len,enum dma_data_direction dir)
arch/arm/include/asm/global_data.h +4 -0
@@ -76,6 +76,10 @@ typedef struct global_data {#if !(defined(CONFIG_SYS_ICACHE_OFF ) && defined(CONFIG_SYS_DCACHE_OFF ))unsigned long tlb_addr;#endif +#ifdef CONFIG_DMA_COHERENT +unsigned long coherent_base;/* Start address of coherent space */ +unsigned long coherent_size;/* Size of coherent space */ +#endif const void *fdt_blob;/* Our device tree, NULL if none */ void **jt;/* jump table */ char env_buf[32 ];/* buffer for getenv() before reloc. */
arch/arm/lib/Makefile +1 -0
@@ -40,6 +40,7 @@ GLCOBJS += div0.o COBJS-y += board.o COBJS-y += bootm.o COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o +COBJS-$(CONFIG_DMA_COHERENT) += dma-coherent.o COBJS-y += interrupts.o COBJS-y += reset.o SOBJS-$(CONFIG_USE_ARCH_MEMSET) += memset.o
arch/arm/lib/board.c +8 -0
@@ -400,6 +400,14 @@ void board_init_f(ulong bootflag)debug ("Reserving %zu Bytes for Global Data at: %08lx\n" ,sizeof (gd_t), addr_sp); +#ifdef CONFIG_DMA_COHERENT +/* reserve space for cache coherent allocations */ + gd->coherent_size =ALIGN (CONFIG_DMA_COHERENT_SIZE ,1 <<20 ); + addr_sp &= ~((1 <<20 ) -1 ); + addr_sp -= gd->coherent_size; + gd->coherent_base = addr_sp; +#endif +/* setup stackpointer for exeptions */ gd->irq_sp = addr_sp;#ifdef CONFIG_USE_IRQ
arch/arm/lib/cache-cp15.c +5 -0
@@ -60,6 +60,11 @@ static inline void dram_bank_mmu_setup(int bank)for (i = bd->bi_dram[bank].start >>20 ; i < (bd->bi_dram[bank].start + bd->bi_dram[bank].size) >>20 ; i++) { +#ifdef CONFIG_DMA_COHERENT +if ((i >= gd->coherent_base >>20 ) && + (i < (gd->coherent_base + gd->coherent_size) >>20 )) +continue ; +#endif page_table[i] = i <<20 | (3 <<10 ) |CACHE_SETUP ; } }
arch/arm/lib/dma-coherent.c new file +37 -0
@@ -0,0 +1,37 @@ +/* +* (C) Copyright 2012 +* Ilya Yanok, [email protected] +* +* See file CREDITS for list of people who contributed to this +* project. +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License as +* published by the Free Software Foundation; either version 2 of +* the License, or (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +*/ + +#include <common.h> + +DECLARE_GLOBAL_DATA_PTR ; + +size_t offset; + +void *dma_alloc_coherent (size_t size,unsigned long *handle) +{ +if (size + offset > gd->coherent_size) +return NULL ; + + *handle = gd->coherent_base + offset; + offset += size; + +return (void *)(*handle); +}
Signature · 1 line
1.7.9.5
PATCH 1/1 ARM: support for cache coherent allocations
Hi All,
Quoted 8 lines · Ilya Yanok
This is a draft implementation of cache coherent memory allocator. This simple implementation just reserves memory area below malloc space and leave it uncached even if data cache is enabled. Allocations are even simpler: code just verifies that we have enough space and increments the offset counter. No deallocations supported for now. In future versions we could probably use dlmalloc allocator to get space out of coherent pool.
Any comments on this?
Regards, Ilya.
PATCH 1/1 ARM: support for cache coherent allocations
Quoted 14 lines · Ilya Yanok
Hi All,
Quoted 8 lines · Ilya Yanok
This is a draft implementation of cache coherent memory allocator. This simple implementation just reserves memory area below malloc space and leave it uncached even if data cache is enabled. Allocations are even simpler: code just verifies that we have enough space and increments the offset counter. No deallocations supported for now. In future versions we could probably use dlmalloc allocator to get space out of coherent pool.
Quoted 1 line
Any comments on this?
Albert?
Signature · 1 line
Tom
PATCH 1/1 ARM: support for cache coherent allocations
In reply to Ilya YanokDear Ilya Yanok,
Quoted 9 lines
This is a draft implementation of cache coherent memory allocator. This simple implementation just reserves memory area below malloc space and leave it uncached even if data cache is enabled. Allocations are even simpler: code just verifies that we have enough space and increments the offset counter. No deallocations supported for now. In future versions we could probably use dlmalloc allocator to get space out of coherent pool.
Signed-off-by Ilya Yanok <[email protected]>
Hm, can't we just punch a hole in the MMU table at runtime instead of preallocating it like this?
Also, what is this for? Can we not simply flush/invalidate the caches?
Best regards,
Marek Vasut
PATCH 1/1 ARM: support for cache coherent allocations
Hi Marek,
[sorry for copying, forget to CC the list]
Quoted 3 lines · Marek Vasut
Hm, can't we just punch a hole in the MMU table at runtime instead of preallocating it like this?
It's allocated at runtime now, do you mean allocate it on demand? Good
point, Probably we can malloc big enough block and make it uncached directly from dma_alloc_coherent(). Is it what you suggest?
Also, what is this for? Can we not simply flush/invalidate the caches?
Quoted 1 line
flush/invalidate can be racy for some hardware. Sometimes we need to write
some field to DMA descriptor and then read another one. And because one cannot flush/invalidate individual bytes write/flush can destroy the field updated by hardware. (Well, we can invalidate/read before write/flush but that introduces a race).
Regards, Ilya.
PATCH 1/1 ARM: support for cache coherent allocations
Dear Ilya Yanok,
Quoted 11 lines
Hi Marek,
[sorry for copying, forget to CC the list]
Quoted 2 lines · Marek Vasut
Hm, can't we just punch a hole in the MMU table at runtime instead of preallocating it like this?
It's allocated at runtime now, do you mean allocate it on demand? Good
point, Probably we can malloc big enough block and make it uncached directly fromdma_alloc_coherent(). Is it what you suggest?
Kind of ... I mean rather insert an entry into MMU table at runtime that says "this region is uncached". But that'd need some hack in the mallocator now that I think about it. It might not be as simple as I thought at first.
On the other hand, most MMUs allow you to allocate stuff with 4k density, which should be ok.
Quoted 8 lines
Also, what is this for? Can we not simply flush/invalidate the caches?
flush/invalidate can be racy for some hardware. Sometimes we need to write
some field to DMA descriptor and then read another one. And because one cannot flush/invalidate individual bytes write/flush can destroy the field updated by hardware. (Well, we can invalidate/read before write/flush but that introduces a race).
But that's shitty hardware. Do you really need to do it? Where? I fixed similar issue in fec_mxc.c recently.
Quoted 2 lines
Regards, Ilya.
Best regards,
Marek Vasut
PATCH 1/1 ARM: support for cache coherent allocations
Hi Marek,
Quoted 7 lines · Marek Vasut
Kind of ... I mean rather insert an entry into MMU table at runtime that says
"this region is uncached". But that'd need some hack in the mallocator now that
I think about it. It might not be as simple as I thought at first.
Hm. I don't quite understand. Do you mean patch malloc code to handle turning caching off for the region? I doubt that's a good approach. I would make the malloc calling code to handle caching.
How about something like this (pseudocode):
if (/* have enough room in space allocated previously*/ )
/* update existing allocation data and return */
newp = malloc_align(ALIGN(size, min_size), min_size);
/* Allocate both size and offset aligned block.
* min_size is minimal block size for which cache can be turned off, on ARM
currently it's 1MB
* malloc_align will return block starting on aligned address, I don't
think current allocator has some support for this so effectively we will have to allocate ALIGN(size, min_size) + min_size - 1 bytes
*/
/* Patch pagetable (on ARM) or do whatever needed to make allocated block uncached */
/* Save data about unused space in the block (in case we allocated more than was requested) */
return newp;
Existing allocation data could be as simple pair of static variables. This is not optimal in some scenarios but very simple.
On the other hand, most MMUs allow you to allocate stuff with 4k density,
Quoted 3 lines
which
should be ok.
Hm, I don't really feel like rebuilding page tables on the fly in U-Boot is a good idea. Currently U-Boot ARM uses page table with 1MB granularity.
Quoted 7 lines
Quoted 4 lines
Also, what is this for? Can we not simply flush/invalidate the caches?
flush/invalidate can be racy for some hardware. Sometimes we need to
write
Quoted 2 lines
some field to DMA descriptor and then read another one. And because one cannot flush/invalidate individual bytes write/flush can destroy the
Quoted 8 lines
field
Quoted 2 lines
updated by hardware. (Well, we can invalidate/read before write/flush but that introduces a race).
But that's shitty hardware. Do you really need to do it? Where? I fixed similar
issue infec_mxc.crecently.
CPSW switch on TI AM33x. Here is the code:
/* not the first packet - enqueue at the tail */
prev = chan->tail;
desc_write(prev, hw_next, desc);
chan->tail = desc;
/* next check if EOQ has been triggered already */
if (desc_read(prev, hw_mode) & CPDMA_DESC_EOQ)
chan_write(chan, hdp, desc);desc_{read/write} are just readl/writel on fields of desc structure. Note that one have to flush for desc_write() to reach the hardware but as fields of the DMA descriptor are going to be in the same cache line this flush will harm other fields that are probably updated by the hardware. Well, I have to say I never seen a manifestation of this problem in the wild and probably hardware somehow takes care of this situation but we can't be sure.
Regards, Ilya.