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)
?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
