Re: [RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Sat, Apr 16, 2011 at 09:01:26PM +0800, Haojian Zhuang wrote:
> On Fri, Apr 15, 2011 at 9:06 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > This is work in progress.
> >
> > We have two SoCs using SRAM, both with their own allocation systems,
> > and both with their own ways of copying functions into the SRAM.
> >
> > Let's unify this before we have additional SoCs re-implementing this
> > obviously common functionality themselves.
> >
> > Unfortunately, we end up with code growth through doing this, but that
> > will become a win when we have another SoC using this (which I know
> > there's at least one in the pipeline).
> >
> > One of the considerations here is that we can easily convert sram-pool.c
> > to hook into device tree stuff, which can tell the sram allocator:
> >        - physical address of sram
> >        - size of sram
> >        - allocation granularity
> > and then we just need to ensure that it is appropriately mapped.
> >
> > 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.
> >
> > 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)
> >
> > 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.
> >
> > Lastly, uio_pruss should probably take the SRAM pool pointer via
> > platform data so that it doesn't have to include Davinci specific
> > includes.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> This common sram driver is good for us. It can benefit us on DMA usage.
> I just have one question on SRAM for storing instruction. We still need to
> copy code into SRAM and flush cache & TLB with this SRAM driver.

There is the fncpy API for copying code to other regions of memory,
including SRAM.  The fncpy API is explicitly designed to cope with
Thumb 2 and provide an appropriate function pointer for such code.

Such code needs to be position independent to cope with multiple SRAM
users, and also possible variability of SRAM mapping which may (eventually)
exist when DT comes along.

> TCM driver can allocate code into SRAM section in link stage. It needs to
> update link file and virtual memory layout. Is it worth to make SRAM driver
> support this behavior? The case of using SRAM as memory for instruction
> is switching frequency or entering/exiting low power mode in PXA silicons.

This is more or less the same scenario which OMAP is using its SRAM
for, although that's explicitly SRAM and not TCM.

I don't think we need position dependent code requiring fixup for
these applications as such things tend to be fairly easily coded in a
position independent way.

Also note that C functions can't be copied because C produces position
dependent code, and we have no way of extracting the relocation
dependencies from such code.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html