On Fri, Apr 15, 2011 at 9:26 AM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Fri, Apr 15, 2011 at 04:40:00PM +0200, Arnd Bergmann wrote: >> On Friday 15 April 2011 15:39:55 Rob Herring wrote: >> >> > On 04/15/2011 08:06 AM, Russell King - ARM Linux 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. >> > >> > It's more than that. Several i.MX chips use plat-mxc/iram_alloc.c. >> >> There are also non-ARM systems doing something like that, >> arch/blackfin/mm/sram-alloc.c comes to mind. On powerpc, the >> ppc7410 also has this feature in hardware, but I believe it was >> never supported in mainline Linux. > > Yes, but there's some horrible bits out there. PPC is one of them > which looks like it doesn't lend itself to consolidating with this > kind of implementation. > >> How about putting sram-pool.c into the top-level mm/ directory >> and sram-pool.h into include/linux? They seem to be completely >> generic to me, aside from the dependency on asm/fncpy.h which >> should probably remain arch specific. > > I've thought about lib - but first lets see whether other architectures > want to use it first. I've asked the sh folk off-list about this and > waiting for a reply. > > Blackfin and PPC look horrible to sort out though, so they can come at > a later date if they so wish. Yes, once the infrastructure is in place, powerpc can do its own migration to the new code. I vote for putting it in lib at the outset. g. -- 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
