Re: [RFC PATCH] Consolidate SRAM support

[Detlef Vollmann <dv@vollmann.ch>]

On 04/15/11 15:06, Russell King - ARM Linux wrote:
> This is work in progress.
Thanks, very useful.

> This uses the physical address, and unlike Davinci's dma address usage,
> it always wants to have the physical address, and will always return
> the corresponding physical address when passed that pointer.
Good.

> OMAP could probably do with some more work to make the omapfb and other
> allocations use the sram allocator, rather than hooking in before the
> sram allocator is initialized - and then further cleanups so that we
> have an initialization function which just does
>
> sram_create(phys, size)
> 	virt = map sram(phys, size)
> 	create sram pool(virt, phys, size, min_alloc_order)
I'd love to have the mapping inside the create pool, but that might
not be possible in general.

> Another question is whether we should allow multiple SRAM pools or not -
> this code does allow multiple pools, but so far we only have one pool
> per SoC.  Overdesign?  Maybe, but it prevents SoCs wanting to duplicate
> it if they want to partition the SRAM, or have peripheral-local SRAMs.
Having the option to partition the SRAM is probably useful.
What I'm missing is sram_pool_add: on AT91SAM9G20 you have two banks
of SRAM, and you might want to combine them into a single pool.

>   arch/arm/common/sram-pool.c                 |   69 +++++++++++++++++++++++++++
>   arch/arm/include/asm/sram-pool.h            |   20 ++++++++
Waht is ARM specific about this code?
Why not put it into lib/ and include/linux, respectively?

   Detlef