[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 05:20:45PM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 15, 2011 at 04:18:23PM +0000, Nguyen Dinh-R00091 wrote:
> > >Hmm, that's nice - except for one issue.  According to my grep of
> > >arch/arm/ and drivers/, nothing uses iram_alloc().  So, does anything in
> > >the MX stuff use iram_alloc.c, or is it dead code left over from a
> > >previous experiment?
> > 
> > This function will be used for suspend code in the mx5x series. I just
> > got done submitting a series of patches to Sascha for a simple suspend
> > that does not need running code out of IRAM yet. The next set of suspend
> > patches will be using these iram functions.
> 
> Okay, so does iram_alloc() need to return a dma_addr_t or a phys_addr_t ?
> Are you dealing with physical addresses for it or DMA addresses?

And another question: why does iram_alloc() return a void __iomem * for
the virtual address, and the physical address via a pointer argument.
However, iram_free() take an unsigned long for the address.

It seems rather inconsistent that the parameter for free is returned via
a pointer argument.

If I convert this to sram-pool, can we change this to:

static inline void *iram_alloc(size_t size, phys_addr_t *phys_addr)
{
	return sram_pool_alloc(iram_pool, size, phys_addr);
}

static void iram_free(void *addr, size_t size)
{
	sram_pool_free(iram_pool, addr, size);
}

and:

int __init iram_init(unsigned long base, unsigned long size)

becomes:

int __init iram_init(phys_addr_t base, size_t size)

?