[RFC PATCH] Consolidate SRAM support

[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

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>
---
 arch/arm/Kconfig                            |    2 +
 arch/arm/common/Kconfig                     |    4 ++
 arch/arm/common/Makefile                    |    1 +
 arch/arm/common/sram-pool.c                 |   69 +++++++++++++++++++++++++++
 arch/arm/include/asm/sram-pool.h            |   20 ++++++++
 arch/arm/mach-davinci/da850.c               |    2 +-
 arch/arm/mach-davinci/dm355.c               |    2 +-
 arch/arm/mach-davinci/dm365.c               |    2 +-
 arch/arm/mach-davinci/dm644x.c              |    2 +-
 arch/arm/mach-davinci/dm646x.c              |    2 +-
 arch/arm/mach-davinci/include/mach/common.h |    2 +-
 arch/arm/mach-davinci/include/mach/sram.h   |   13 +----
 arch/arm/mach-davinci/pm.c                  |   12 +----
 arch/arm/mach-davinci/sram.c                |   42 +++--------------
 arch/arm/plat-omap/include/plat/sram.h      |   17 ++++---
 arch/arm/plat-omap/sram.c                   |   34 +++++---------
 drivers/uio/uio_pruss.c                     |    8 ++-
 17 files changed, 141 insertions(+), 93 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b9f78b..5c3401c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -850,6 +850,7 @@ config ARCH_DAVINCI
 	bool "TI DaVinci"
 	select GENERIC_CLOCKEVENTS
 	select ARCH_REQUIRE_GPIOLIB
+	select ARM_SRAM_POOL
 	select ZONE_DMA
 	select HAVE_IDE
 	select CLKDEV_LOOKUP
@@ -863,6 +864,7 @@ config ARCH_OMAP
 	select HAVE_CLK
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_CPUFREQ
+	select ARM_SRAM_POOL
 	select GENERIC_CLOCKEVENTS
 	select HAVE_SCHED_CLOCK
 	select ARCH_HAS_HOLES_MEMORYMODEL
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index ea5ee4d..ddbd20b 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -39,3 +39,7 @@ config SHARP_PARAM
 
 config SHARP_SCOOP
 	bool
+
+config ARM_SRAM_POOL
+	bool
+	select GENERIC_ALLOCATOR
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e7521bca..b79ad68 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_ARCH_IXP23XX)	+= uengine.o
 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
 obj-$(CONFIG_COMMON_CLKDEV)	+= clkdev.o
 obj-$(CONFIG_ARM_TIMER_SP804)	+= timer-sp.o
+obj-$(CONFIG_ARM_SRAM_POOL)	+= sram-pool.o
diff --git a/arch/arm/common/sram-pool.c b/arch/arm/common/sram-pool.c
new file mode 100644
index 0000000..9ff1466
--- /dev/null
+++ b/arch/arm/common/sram-pool.c
@@ -0,0 +1,69 @@
+/*
+ * Unified SRAM allocator, based on mach-davinci/sram.c, which was
+ * Copyright (C) 2009 David Brownell.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/dma-mapping.h>
+#include <linux/genalloc.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+
+#include <asm/sram-pool.h>
+
+struct sram_pool {
+	struct gen_pool *genpool;
+	void *cpu_base;
+	phys_addr_t phys_base;
+};
+
+void *sram_pool_alloc(struct sram_pool *pool, size_t len, phys_addr_t *phys)
+{
+	void *addr = (void *)gen_pool_alloc(pool->genpool, len);
+
+	if (phys)
+		*phys = addr ? (pool->phys_base + (addr - pool->cpu_base)) :
+			 (phys_addr_t)-1ULL;
+
+	return addr;
+}
+EXPORT_SYMBOL_GPL(sram_pool_alloc);
+
+void sram_pool_free(struct sram_pool *pool, void *addr, size_t len)
+{
+	gen_pool_free(pool->genpool, (unsigned long)addr, len);
+}
+EXPORT_SYMBOL_GPL(sram_pool_free);
+
+struct sram_pool *sram_pool_create(void *addr, phys_addr_t phys, size_t len,
+	int min_alloc_order)
+{
+	struct sram_pool *pool = kzalloc(sizeof(struct sram_pool), GFP_KERNEL);
+
+	if (pool) {
+		pool->cpu_base = addr;
+		pool->phys_base = phys;
+		pool->genpool = gen_pool_create(min_alloc_order, -1);
+		if (!pool->genpool) {
+			kfree(pool);
+			pool = NULL;
+		} else {
+			WARN_ON(gen_pool_add(pool->genpool, (unsigned long)addr,
+						len, -1) < 0);
+		}
+	}
+
+	return pool;
+}
+EXPORT_SYMBOL_GPL(sram_pool_create);
+
+void sram_pool_destroy(struct sram_pool *pool)
+{
+	gen_pool_destroy(pool->genpool);
+	kfree(pool);
+}
+EXPORT_SYMBOL_GPL(sram_pool_destroy);
diff --git a/arch/arm/include/asm/sram-pool.h b/arch/arm/include/asm/sram-pool.h
new file mode 100644
index 0000000..b7ae871
--- /dev/null
+++ b/arch/arm/include/asm/sram-pool.h
@@ -0,0 +1,20 @@
+#ifndef __ASMARM_SRAM_POOL_H
+#define __ASMARM_SRAM_POOL_H
+
+#include <asm/fncpy.h>
+
+struct sram_pool;
+
+void *sram_pool_alloc(struct sram_pool *, size_t, phys_addr_t *);
+void sram_pool_free(struct sram_pool *, void *, size_t);
+struct sram_pool *sram_pool_create(void *, phys_addr_t, size_t, int);
+void sram_pool_destroy(struct sram_pool *);
+
+/* Macro to copy a function into SRAM, using the fncpy API */
+#define sram_pool_fncpy(pool, funcp, size) ({			\
+	size_t _sz = size;					\
+	void *_sram = sram_pool_alloc(pool, _sz, NULL);		\
+	(_sram ? fncpy(_sram, &(funcp), _sz) : NULL);		\
+})
+
+#endif
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 68fe4c2..5eca128 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
-	.sram_dma		= DA8XX_ARM_RAM_BASE,
+	.sram_phys		= DA8XX_ARM_RAM_BASE,
 	.sram_len		= SZ_8K,
 	.reset_device		= &da8xx_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 76364d1..3df8730 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
 	.serial_dev		= &dm355_serial_device,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 4604e72..d306034 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
 	.serial_dev		= &dm365_serial_device,
 	.emac_pdata		= &dm365_emac_pdata,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..4ca7295 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -764,7 +764,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.gpio_irq		= IRQ_GPIOBNK0,
 	.serial_dev		= &dm644x_serial_device,
 	.emac_pdata		= &dm644x_emac_pdata,
-	.sram_dma		= 0x00008000,
+	.sram_phys		= 0x00008000,
 	.sram_len		= SZ_16K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 1e0f809..a4365f7 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -848,7 +848,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
 	.serial_dev		= &dm646x_serial_device,
 	.emac_pdata		= &dm646x_emac_pdata,
-	.sram_dma		= 0x10010000,
+	.sram_phys		= 0x10010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index a57cba2..665d049 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -75,7 +75,7 @@ struct davinci_soc_info {
 	int				gpio_ctlrs_num;
 	struct platform_device		*serial_dev;
 	struct emac_platform_data	*emac_pdata;
-	dma_addr_t			sram_dma;
+	phys_addr_t			sram_phys;
 	unsigned			sram_len;
 	struct platform_device		*reset_device;
 	void				(*reset)(struct platform_device *);
diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h
index 111f7cc..7d77e85 100644
--- a/arch/arm/mach-davinci/include/mach/sram.h
+++ b/arch/arm/mach-davinci/include/mach/sram.h
@@ -10,18 +10,11 @@
 #ifndef __MACH_SRAM_H
 #define __MACH_SRAM_H
 
+#include <asm/sram-pool.h>
+
 /* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
 #define SRAM_GRANULARITY	512
 
-/*
- * SRAM allocations return a CPU virtual address, or NULL on error.
- * If a DMA address is requested and the SRAM supports DMA, its
- * mapped address is also returned.
- *
- * Errors include SRAM memory not being available, and requesting
- * DMA mapped SRAM on systems which don't allow that.
- */
-extern void *sram_alloc(size_t len, dma_addr_t *dma);
-extern void sram_free(void *addr, size_t len);
+extern struct sram_pool *davinci_sram_pool;
 
 #endif /* __MACH_SRAM_H */
diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index 1bd73a0..f69cd7b 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -29,12 +29,6 @@
 static void (*davinci_sram_suspend) (struct davinci_pm_config *);
 static struct davinci_pm_config *pdata;
 
-static void davinci_sram_push(void *dest, void *src, unsigned int size)
-{
-	memcpy(dest, src, size);
-	flush_icache_range((unsigned long)dest, (unsigned long)(dest + size));
-}
-
 static void davinci_pm_suspend(void)
 {
 	unsigned val;
@@ -123,15 +117,13 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 		return -ENOENT;
 	}
 
-	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
+	davinci_sram_suspend = sram_pool_fncpy(davinci_sram_pool,
+				davinci_cpu_suspend, davinci_cpu_suspend_sz);
 	if (!davinci_sram_suspend) {
 		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
 		return -ENOMEM;
 	}
 
-	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
-						davinci_cpu_suspend_sz);
-
 	suspend_set_ops(&davinci_pm_ops);
 
 	return 0;
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index db0f778..ebd4d67 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -10,40 +10,13 @@
  */
 #include <linux/module.h>
 #include <linux/init.h>
-#include <linux/genalloc.h>
+#include <asm/sram-pool.h>
 
 #include <mach/common.h>
 #include <mach/sram.h>
 
-static struct gen_pool *sram_pool;
-
-void *sram_alloc(size_t len, dma_addr_t *dma)
-{
-	unsigned long vaddr;
-	dma_addr_t dma_base = davinci_soc_info.sram_dma;
-
-	if (dma)
-		*dma = 0;
-	if (!sram_pool || (dma && !dma_base))
-		return NULL;
-
-	vaddr = gen_pool_alloc(sram_pool, len);
-	if (!vaddr)
-		return NULL;
-
-	if (dma)
-		*dma = dma_base + (vaddr - SRAM_VIRT);
-	return (void *)vaddr;
-
-}
-EXPORT_SYMBOL(sram_alloc);
-
-void sram_free(void *addr, size_t len)
-{
-	gen_pool_free(sram_pool, (unsigned long) addr, len);
-}
-EXPORT_SYMBOL(sram_free);
-
+struct sram_pool *davinci_sram_pool;
+EXPORT_SYMBOL_GPL(davinci_sram_pool);
 
 /*
  * REVISIT This supports CPU and DMA access to/from SRAM, but it
@@ -58,13 +31,12 @@ static int __init sram_init(void)
 
 	if (len) {
 		len = min_t(unsigned, len, SRAM_SIZE);
-		sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
-		if (!sram_pool)
+		davinci_sram_pool = sram_pool_create((void *)SRAM_VIRT,
+				davinci_soc_info.sram_phys, len,
+				ilog2(SRAM_GRANULARITY));
+		if (!davinci_sram_pool)
 			status = -ENOMEM;
 	}
-	if (sram_pool)
-		status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
-	WARN_ON(status < 0);
 	return status;
 }
 core_initcall(sram_init);
diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..9fc27d0 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -12,16 +12,19 @@
 #define __ARCH_ARM_OMAP_SRAM_H
 
 #ifndef __ASSEMBLY__
-#include <asm/fncpy.h>
+#include <asm/sram-pool.h>
 
-extern void *omap_sram_push_address(unsigned long size);
+extern struct sram_pool *omap_sram_pool;
 
-/* Macro to push a function to the internal SRAM, using the fncpy API */
+/*
+ * Note that fncpy requires the SRAM address to be aligned to an 8-byte
+ * boundary, so the min_alloc_order for the pool is set appropriately.
+ */
 #define omap_sram_push(funcp, size) ({				\
-	typeof(&(funcp)) _res = NULL;				\
-	void *_sram_address = omap_sram_push_address(size);	\
-	if (_sram_address)					\
-		_res = fncpy(_sram_address, &(funcp), size);	\
+	typeof(&(funcp)) _res;					\
+	_res = sram_pool_fncpy(omap_sram_pool, funcp, size);	\
+	if (!_res)						\
+		pr_err("Not enough space in SRAM\n");		\
 	_res;							\
 })
 
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..3588749 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -75,7 +75,6 @@
 static unsigned long omap_sram_start;
 static unsigned long omap_sram_base;
 static unsigned long omap_sram_size;
-static unsigned long omap_sram_ceil;
 
 /*
  * Depending on the target RAMFS firewall setup, the public usable amount of
@@ -104,6 +103,8 @@ static int is_sram_locked(void)
 		return 1; /* assume locked with no PPA or security driver */
 }
 
+struct sram_pool *omap_sram_pool;
+
 /*
  * The amount of SRAM depends on the core type.
  * Note that we cannot try to test for SRAM here because writes
@@ -182,7 +183,16 @@ static void __init omap_detect_sram(void)
 			omap_sram_size - SRAM_BOOTLOADER_SZ);
 	omap_sram_size -= reserved;
 
-	omap_sram_ceil = omap_sram_base + omap_sram_size;
+	{
+		/* The first SRAM_BOOTLOADER_SZ of SRAM are reserved */
+		void *base = (void *)omap_sram_base + SRAM_BOOTLOADER_SZ;
+		phys_addr_t phys = omap_sram_start + SRAM_BOOTLOADER_SZ;
+		size_t len = omap_sram_size - SRAM_BOOTLOADER_SZ;
+
+		omap_sram_pool = sram_pool_create(base, phys, len,
+						ilog2(FNCPY_ALIGN));
+		WARN_ON(!omap_sram_pool);
+	}
 }
 
 static struct map_desc omap_sram_io_desc[] __initdata = {
@@ -242,26 +252,6 @@ static void __init omap_map_sram(void)
 	       omap_sram_size - SRAM_BOOTLOADER_SZ);
 }
 
-/*
- * Memory allocator for SRAM: calculates the new ceiling address
- * for pushing a function using the fncpy API.
- *
- * Note that fncpy requires the returned address to be aligned
- * to an 8-byte boundary.
- */
-void *omap_sram_push_address(unsigned long size)
-{
-	if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
-		printk(KERN_ERR "Not enough space in SRAM\n");
-		return NULL;
-	}
-
-	omap_sram_ceil -= size;
-	omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, FNCPY_ALIGN);
-
-	return (void *)omap_sram_ceil;
-}
-
 #ifdef CONFIG_ARCH_OMAP1
 
 static void (*_omap_sram_reprogram_clock)(u32 dpllctl, u32 ckctl);
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index daf6e77..2be3155 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -62,7 +62,7 @@ MODULE_PARM_DESC(extram_pool_sz, "external ram pool size to allocate");
 struct uio_pruss_dev {
 	struct uio_info *info;
 	struct clk *pruss_clk;
-	dma_addr_t sram_paddr;
+	phys_addr_t sram_paddr;
 	dma_addr_t ddr_paddr;
 	void __iomem *prussio_vaddr;
 	void *sram_vaddr;
@@ -106,7 +106,8 @@ static void pruss_cleanup(struct platform_device *dev,
 			gdev->ddr_paddr);
 	}
 	if (gdev->sram_vaddr)
-		sram_free(gdev->sram_vaddr, sram_pool_sz);
+		sram_pool_free(davinci_sram_pool, gdev->sram_vaddr,
+			       sram_pool_sz);
 	kfree(gdev->info);
 	clk_put(gdev->pruss_clk);
 	kfree(gdev);
@@ -152,7 +153,8 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
+	gdev->sram_vaddr = sram_pool_alloc(davinci_sram_pool, sram_pool_sz,
+					   &(gdev->sram_paddr));
 	if (!gdev->sram_vaddr) {
 		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
 		goto out_free;

[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

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>
---
 arch/arm/Kconfig                            |    2 +
 arch/arm/common/Kconfig                     |    4 ++
 arch/arm/common/Makefile                    |    1 +
 arch/arm/common/sram-pool.c                 |   69 +++++++++++++++++++++++++++
 arch/arm/include/asm/sram-pool.h            |   20 ++++++++
 arch/arm/mach-davinci/da850.c               |    2 +-
 arch/arm/mach-davinci/dm355.c               |    2 +-
 arch/arm/mach-davinci/dm365.c               |    2 +-
 arch/arm/mach-davinci/dm644x.c              |    2 +-
 arch/arm/mach-davinci/dm646x.c              |    2 +-
 arch/arm/mach-davinci/include/mach/common.h |    2 +-
 arch/arm/mach-davinci/include/mach/sram.h   |   13 +----
 arch/arm/mach-davinci/pm.c                  |   12 +----
 arch/arm/mach-davinci/sram.c                |   42 +++--------------
 arch/arm/plat-omap/include/plat/sram.h      |   17 ++++---
 arch/arm/plat-omap/sram.c                   |   34 +++++---------
 drivers/uio/uio_pruss.c                     |    8 ++-
 17 files changed, 141 insertions(+), 93 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b9f78b..5c3401c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -850,6 +850,7 @@ config ARCH_DAVINCI
 	bool "TI DaVinci"
 	select GENERIC_CLOCKEVENTS
 	select ARCH_REQUIRE_GPIOLIB
+	select ARM_SRAM_POOL
 	select ZONE_DMA
 	select HAVE_IDE
 	select CLKDEV_LOOKUP
@@ -863,6 +864,7 @@ config ARCH_OMAP
 	select HAVE_CLK
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_CPUFREQ
+	select ARM_SRAM_POOL
 	select GENERIC_CLOCKEVENTS
 	select HAVE_SCHED_CLOCK
 	select ARCH_HAS_HOLES_MEMORYMODEL
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index ea5ee4d..ddbd20b 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -39,3 +39,7 @@ config SHARP_PARAM
 
 config SHARP_SCOOP
 	bool
+
+config ARM_SRAM_POOL
+	bool
+	select GENERIC_ALLOCATOR
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e7521bca..b79ad68 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_ARCH_IXP23XX)	+= uengine.o
 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
 obj-$(CONFIG_COMMON_CLKDEV)	+= clkdev.o
 obj-$(CONFIG_ARM_TIMER_SP804)	+= timer-sp.o
+obj-$(CONFIG_ARM_SRAM_POOL)	+= sram-pool.o
diff --git a/arch/arm/common/sram-pool.c b/arch/arm/common/sram-pool.c
new file mode 100644
index 0000000..9ff1466
--- /dev/null
+++ b/arch/arm/common/sram-pool.c
@@ -0,0 +1,69 @@
+/*
+ * Unified SRAM allocator, based on mach-davinci/sram.c, which was
+ * Copyright (C) 2009 David Brownell.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/dma-mapping.h>
+#include <linux/genalloc.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+
+#include <asm/sram-pool.h>
+
+struct sram_pool {
+	struct gen_pool *genpool;
+	void *cpu_base;
+	phys_addr_t phys_base;
+};
+
+void *sram_pool_alloc(struct sram_pool *pool, size_t len, phys_addr_t *phys)
+{
+	void *addr = (void *)gen_pool_alloc(pool->genpool, len);
+
+	if (phys)
+		*phys = addr ? (pool->phys_base + (addr - pool->cpu_base)) :
+			 (phys_addr_t)-1ULL;
+
+	return addr;
+}
+EXPORT_SYMBOL_GPL(sram_pool_alloc);
+
+void sram_pool_free(struct sram_pool *pool, void *addr, size_t len)
+{
+	gen_pool_free(pool->genpool, (unsigned long)addr, len);
+}
+EXPORT_SYMBOL_GPL(sram_pool_free);
+
+struct sram_pool *sram_pool_create(void *addr, phys_addr_t phys, size_t len,
+	int min_alloc_order)
+{
+	struct sram_pool *pool = kzalloc(sizeof(struct sram_pool), GFP_KERNEL);
+
+	if (pool) {
+		pool->cpu_base = addr;
+		pool->phys_base = phys;
+		pool->genpool = gen_pool_create(min_alloc_order, -1);
+		if (!pool->genpool) {
+			kfree(pool);
+			pool = NULL;
+		} else {
+			WARN_ON(gen_pool_add(pool->genpool, (unsigned long)addr,
+						len, -1) < 0);
+		}
+	}
+
+	return pool;
+}
+EXPORT_SYMBOL_GPL(sram_pool_create);
+
+void sram_pool_destroy(struct sram_pool *pool)
+{
+	gen_pool_destroy(pool->genpool);
+	kfree(pool);
+}
+EXPORT_SYMBOL_GPL(sram_pool_destroy);
diff --git a/arch/arm/include/asm/sram-pool.h b/arch/arm/include/asm/sram-pool.h
new file mode 100644
index 0000000..b7ae871
--- /dev/null
+++ b/arch/arm/include/asm/sram-pool.h
@@ -0,0 +1,20 @@
+#ifndef __ASMARM_SRAM_POOL_H
+#define __ASMARM_SRAM_POOL_H
+
+#include <asm/fncpy.h>
+
+struct sram_pool;
+
+void *sram_pool_alloc(struct sram_pool *, size_t, phys_addr_t *);
+void sram_pool_free(struct sram_pool *, void *, size_t);
+struct sram_pool *sram_pool_create(void *, phys_addr_t, size_t, int);
+void sram_pool_destroy(struct sram_pool *);
+
+/* Macro to copy a function into SRAM, using the fncpy API */
+#define sram_pool_fncpy(pool, funcp, size) ({			\
+	size_t _sz = size;					\
+	void *_sram = sram_pool_alloc(pool, _sz, NULL);		\
+	(_sram ? fncpy(_sram, &(funcp), _sz) : NULL);		\
+})
+
+#endif
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 68fe4c2..5eca128 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
-	.sram_dma		= DA8XX_ARM_RAM_BASE,
+	.sram_phys		= DA8XX_ARM_RAM_BASE,
 	.sram_len		= SZ_8K,
 	.reset_device		= &da8xx_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 76364d1..3df8730 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
 	.serial_dev		= &dm355_serial_device,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 4604e72..d306034 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
 	.serial_dev		= &dm365_serial_device,
 	.emac_pdata		= &dm365_emac_pdata,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..4ca7295 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -764,7 +764,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.gpio_irq		= IRQ_GPIOBNK0,
 	.serial_dev		= &dm644x_serial_device,
 	.emac_pdata		= &dm644x_emac_pdata,
-	.sram_dma		= 0x00008000,
+	.sram_phys		= 0x00008000,
 	.sram_len		= SZ_16K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 1e0f809..a4365f7 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -848,7 +848,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
 	.serial_dev		= &dm646x_serial_device,
 	.emac_pdata		= &dm646x_emac_pdata,
-	.sram_dma		= 0x10010000,
+	.sram_phys		= 0x10010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index a57cba2..665d049 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -75,7 +75,7 @@ struct davinci_soc_info {
 	int				gpio_ctlrs_num;
 	struct platform_device		*serial_dev;
 	struct emac_platform_data	*emac_pdata;
-	dma_addr_t			sram_dma;
+	phys_addr_t			sram_phys;
 	unsigned			sram_len;
 	struct platform_device		*reset_device;
 	void				(*reset)(struct platform_device *);
diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h
index 111f7cc..7d77e85 100644
--- a/arch/arm/mach-davinci/include/mach/sram.h
+++ b/arch/arm/mach-davinci/include/mach/sram.h
@@ -10,18 +10,11 @@
 #ifndef __MACH_SRAM_H
 #define __MACH_SRAM_H
 
+#include <asm/sram-pool.h>
+
 /* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
 #define SRAM_GRANULARITY	512
 
-/*
- * SRAM allocations return a CPU virtual address, or NULL on error.
- * If a DMA address is requested and the SRAM supports DMA, its
- * mapped address is also returned.
- *
- * Errors include SRAM memory not being available, and requesting
- * DMA mapped SRAM on systems which don't allow that.
- */
-extern void *sram_alloc(size_t len, dma_addr_t *dma);
-extern void sram_free(void *addr, size_t len);
+extern struct sram_pool *davinci_sram_pool;
 
 #endif /* __MACH_SRAM_H */
diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index 1bd73a0..f69cd7b 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -29,12 +29,6 @@
 static void (*davinci_sram_suspend) (struct davinci_pm_config *);
 static struct davinci_pm_config *pdata;
 
-static void davinci_sram_push(void *dest, void *src, unsigned int size)
-{
-	memcpy(dest, src, size);
-	flush_icache_range((unsigned long)dest, (unsigned long)(dest + size));
-}
-
 static void davinci_pm_suspend(void)
 {
 	unsigned val;
@@ -123,15 +117,13 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 		return -ENOENT;
 	}
 
-	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
+	davinci_sram_suspend = sram_pool_fncpy(davinci_sram_pool,
+				davinci_cpu_suspend, davinci_cpu_suspend_sz);
 	if (!davinci_sram_suspend) {
 		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
 		return -ENOMEM;
 	}
 
-	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
-						davinci_cpu_suspend_sz);
-
 	suspend_set_ops(&davinci_pm_ops);
 
 	return 0;
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index db0f778..ebd4d67 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -10,40 +10,13 @@
  */
 #include <linux/module.h>
 #include <linux/init.h>
-#include <linux/genalloc.h>
+#include <asm/sram-pool.h>
 
 #include <mach/common.h>
 #include <mach/sram.h>
 
-static struct gen_pool *sram_pool;
-
-void *sram_alloc(size_t len, dma_addr_t *dma)
-{
-	unsigned long vaddr;
-	dma_addr_t dma_base = davinci_soc_info.sram_dma;
-
-	if (dma)
-		*dma = 0;
-	if (!sram_pool || (dma && !dma_base))
-		return NULL;
-
-	vaddr = gen_pool_alloc(sram_pool, len);
-	if (!vaddr)
-		return NULL;
-
-	if (dma)
-		*dma = dma_base + (vaddr - SRAM_VIRT);
-	return (void *)vaddr;
-
-}
-EXPORT_SYMBOL(sram_alloc);
-
-void sram_free(void *addr, size_t len)
-{
-	gen_pool_free(sram_pool, (unsigned long) addr, len);
-}
-EXPORT_SYMBOL(sram_free);
-
+struct sram_pool *davinci_sram_pool;
+EXPORT_SYMBOL_GPL(davinci_sram_pool);
 
 /*
  * REVISIT This supports CPU and DMA access to/from SRAM, but it
@@ -58,13 +31,12 @@ static int __init sram_init(void)
 
 	if (len) {
 		len = min_t(unsigned, len, SRAM_SIZE);
-		sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
-		if (!sram_pool)
+		davinci_sram_pool = sram_pool_create((void *)SRAM_VIRT,
+				davinci_soc_info.sram_phys, len,
+				ilog2(SRAM_GRANULARITY));
+		if (!davinci_sram_pool)
 			status = -ENOMEM;
 	}
-	if (sram_pool)
-		status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
-	WARN_ON(status < 0);
 	return status;
 }
 core_initcall(sram_init);
diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..9fc27d0 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -12,16 +12,19 @@
 #define __ARCH_ARM_OMAP_SRAM_H
 
 #ifndef __ASSEMBLY__
-#include <asm/fncpy.h>
+#include <asm/sram-pool.h>
 
-extern void *omap_sram_push_address(unsigned long size);
+extern struct sram_pool *omap_sram_pool;
 
-/* Macro to push a function to the internal SRAM, using the fncpy API */
+/*
+ * Note that fncpy requires the SRAM address to be aligned to an 8-byte
+ * boundary, so the min_alloc_order for the pool is set appropriately.
+ */
 #define omap_sram_push(funcp, size) ({				\
-	typeof(&(funcp)) _res = NULL;				\
-	void *_sram_address = omap_sram_push_address(size);	\
-	if (_sram_address)					\
-		_res = fncpy(_sram_address, &(funcp), size);	\
+	typeof(&(funcp)) _res;					\
+	_res = sram_pool_fncpy(omap_sram_pool, funcp, size);	\
+	if (!_res)						\
+		pr_err("Not enough space in SRAM\n");		\
 	_res;							\
 })
 
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..3588749 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -75,7 +75,6 @@
 static unsigned long omap_sram_start;
 static unsigned long omap_sram_base;
 static unsigned long omap_sram_size;
-static unsigned long omap_sram_ceil;
 
 /*
  * Depending on the target RAMFS firewall setup, the public usable amount of
@@ -104,6 +103,8 @@ static int is_sram_locked(void)
 		return 1; /* assume locked with no PPA or security driver */
 }
 
+struct sram_pool *omap_sram_pool;
+
 /*
  * The amount of SRAM depends on the core type.
  * Note that we cannot try to test for SRAM here because writes
@@ -182,7 +183,16 @@ static void __init omap_detect_sram(void)
 			omap_sram_size - SRAM_BOOTLOADER_SZ);
 	omap_sram_size -= reserved;
 
-	omap_sram_ceil = omap_sram_base + omap_sram_size;
+	{
+		/* The first SRAM_BOOTLOADER_SZ of SRAM are reserved */
+		void *base = (void *)omap_sram_base + SRAM_BOOTLOADER_SZ;
+		phys_addr_t phys = omap_sram_start + SRAM_BOOTLOADER_SZ;
+		size_t len = omap_sram_size - SRAM_BOOTLOADER_SZ;
+
+		omap_sram_pool = sram_pool_create(base, phys, len,
+						ilog2(FNCPY_ALIGN));
+		WARN_ON(!omap_sram_pool);
+	}
 }
 
 static struct map_desc omap_sram_io_desc[] __initdata = {
@@ -242,26 +252,6 @@ static void __init omap_map_sram(void)
 	       omap_sram_size - SRAM_BOOTLOADER_SZ);
 }
 
-/*
- * Memory allocator for SRAM: calculates the new ceiling address
- * for pushing a function using the fncpy API.
- *
- * Note that fncpy requires the returned address to be aligned
- * to an 8-byte boundary.
- */
-void *omap_sram_push_address(unsigned long size)
-{
-	if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
-		printk(KERN_ERR "Not enough space in SRAM\n");
-		return NULL;
-	}
-
-	omap_sram_ceil -= size;
-	omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, FNCPY_ALIGN);
-
-	return (void *)omap_sram_ceil;
-}
-
 #ifdef CONFIG_ARCH_OMAP1
 
 static void (*_omap_sram_reprogram_clock)(u32 dpllctl, u32 ckctl);
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index daf6e77..2be3155 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -62,7 +62,7 @@ MODULE_PARM_DESC(extram_pool_sz, "external ram pool size to allocate");
 struct uio_pruss_dev {
 	struct uio_info *info;
 	struct clk *pruss_clk;
-	dma_addr_t sram_paddr;
+	phys_addr_t sram_paddr;
 	dma_addr_t ddr_paddr;
 	void __iomem *prussio_vaddr;
 	void *sram_vaddr;
@@ -106,7 +106,8 @@ static void pruss_cleanup(struct platform_device *dev,
 			gdev->ddr_paddr);
 	}
 	if (gdev->sram_vaddr)
-		sram_free(gdev->sram_vaddr, sram_pool_sz);
+		sram_pool_free(davinci_sram_pool, gdev->sram_vaddr,
+			       sram_pool_sz);
 	kfree(gdev->info);
 	clk_put(gdev->pruss_clk);
 	kfree(gdev);
@@ -152,7 +153,8 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
+	gdev->sram_vaddr = sram_pool_alloc(davinci_sram_pool, sram_pool_sz,
+					   &(gdev->sram_paddr));
 	if (!gdev->sram_vaddr) {
 		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
 		goto out_free;

Re: [RFC PATCH] Consolidate SRAM support

[Rob Herring]

Russell,

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.

lpc32xx and pnx4008 also use iram, but do not have an allocator (only 1 
user). Both are doing a copy the suspend code to IRAM and run it which 
may also be a good thing to have generic code for. Several i.MX chips 
also need to run from IRAM for suspend.

Rob

[RFC PATCH] Consolidate SRAM support

[Rob Herring]

Russell,

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.

lpc32xx and pnx4008 also use iram, but do not have an allocator (only 1 
user). Both are doing a copy the suspend code to IRAM and run it which 
may also be a good thing to have generic code for. Several i.MX chips 
also need to run from IRAM for suspend.

Rob

Re: [RFC PATCH] Consolidate SRAM support

[Eduardo Valentin]

Hi Russel,

Just small comment,

On Fri, Apr 15, 2011 at 08:06:07AM -0500, Russell King wrote:

> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> index a3f50b3..3588749 100644
> --- a/arch/arm/plat-omap/sram.c
> +++ b/arch/arm/plat-omap/sram.c
> @@ -75,7 +75,6 @@
>  static unsigned long omap_sram_start;
>  static unsigned long omap_sram_base;
>  static unsigned long omap_sram_size;
> -static unsigned long omap_sram_ceil;

I think you missed one occurrence of omap_sram_ceil at omap3_sram_restore_context.
Probably you have compile-tested w/o CONFIG_PM?

All best,

-- 
Eduardo Valentin

[RFC PATCH] Consolidate SRAM support

[Eduardo Valentin]

Hi Russel,

Just small comment,

On Fri, Apr 15, 2011 at 08:06:07AM -0500, Russell King wrote:

> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> index a3f50b3..3588749 100644
> --- a/arch/arm/plat-omap/sram.c
> +++ b/arch/arm/plat-omap/sram.c
> @@ -75,7 +75,6 @@
>  static unsigned long omap_sram_start;
>  static unsigned long omap_sram_base;
>  static unsigned long omap_sram_size;
> -static unsigned long omap_sram_ceil;

I think you missed one occurrence of omap_sram_ceil at omap3_sram_restore_context.
Probably you have compile-tested w/o CONFIG_PM?

All best,

-- 
Eduardo Valentin

Re: [RFC PATCH] Consolidate SRAM support

[Ithamar R. Adema]

On Fri, 2011-04-15 at 08:39 -0500, Rob Herring wrote:
> lpc32xx and pnx4008 also use iram, but do not have an allocator (only
> 1 user). Both are doing a copy the suspend code to IRAM and run it
> which may also be a good thing to have generic code for. Several i.MX
> chips also need to run from IRAM for suspend.

There will be similar patches for my lpc2k architecture once it gets
accepted, a common interface would be _very_ beneficial IMHO.

Regards,

Ithamar.

[RFC PATCH] Consolidate SRAM support

[Ithamar R. Adema]

On Fri, 2011-04-15 at 08:39 -0500, Rob Herring wrote:
> lpc32xx and pnx4008 also use iram, but do not have an allocator (only
> 1 user). Both are doing a copy the suspend code to IRAM and run it
> which may also be a good thing to have generic code for. Several i.MX
> chips also need to run from IRAM for suspend.

There will be similar patches for my lpc2k architecture once it gets
accepted, a common interface would be _very_ beneficial IMHO.

Regards,

Ithamar.

Re: [RFC PATCH] Consolidate SRAM support

[Arnd Bergmann]

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.

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.

As long as CONFIG_ARM_SRAM_POOL (or perhaps just CONFIG_SRAM_POOL)
is selected only by platforms that support it, the dependency
should not hurt.

	Arnd

[RFC PATCH] Consolidate SRAM support

[Arnd Bergmann]

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.

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.

As long as CONFIG_ARM_SRAM_POOL (or perhaps just CONFIG_SRAM_POOL)
is selected only by platforms that support it, the dependency
should not hurt.

	Arnd

Re: [RFC PATCH] Consolidate SRAM support

[Detlef Vollmann]

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

[RFC PATCH] Consolidate SRAM support

[Detlef Vollmann]

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

Re: [RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 04:52:38PM +0300, Eduardo Valentin wrote:
> Hi Russel,
> 
> Just small comment,
> 
> On Fri, Apr 15, 2011 at 08:06:07AM -0500, Russell King wrote:
> 
> > diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> > index a3f50b3..3588749 100644
> > --- a/arch/arm/plat-omap/sram.c
> > +++ b/arch/arm/plat-omap/sram.c
> > @@ -75,7 +75,6 @@
> >  static unsigned long omap_sram_start;
> >  static unsigned long omap_sram_base;
> >  static unsigned long omap_sram_size;
> > -static unsigned long omap_sram_ceil;
> 
> I think you missed one occurrence of omap_sram_ceil at omap3_sram_restore_context.
> Probably you have compile-tested w/o CONFIG_PM?

I built OMAP2 only, which did have CONFIG_PM=y.  Welcome to the problems
of ifdef'ing code.

[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 04:52:38PM +0300, Eduardo Valentin wrote:
> Hi Russel,
> 
> Just small comment,
> 
> On Fri, Apr 15, 2011 at 08:06:07AM -0500, Russell King wrote:
> 
> > diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> > index a3f50b3..3588749 100644
> > --- a/arch/arm/plat-omap/sram.c
> > +++ b/arch/arm/plat-omap/sram.c
> > @@ -75,7 +75,6 @@
> >  static unsigned long omap_sram_start;
> >  static unsigned long omap_sram_base;
> >  static unsigned long omap_sram_size;
> > -static unsigned long omap_sram_ceil;
> 
> I think you missed one occurrence of omap_sram_ceil at omap3_sram_restore_context.
> Probably you have compile-tested w/o CONFIG_PM?

I built OMAP2 only, which did have CONFIG_PM=y.  Welcome to the problems
of ifdef'ing code.

Re: [RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

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.

[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

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.

Re: [RFC PATCH] Consolidate SRAM support

[Grant Likely]

On Fri, Apr 15, 2011 at 9:26 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH] Consolidate SRAM support

[Grant Likely]

On Fri, Apr 15, 2011 at 9:26 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> 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.

Re: [RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 04:50:49PM +0200, Detlef Vollmann wrote:
> I'd love to have the mapping inside the create pool, but that might
> not be possible in general.

No, think about it.  What if you need to map the RAM area with some
special attributes - eg, where ioremap() doesn't work.  Eg, OMAP you
need SRAM mapped as normal memory, except for OMAP34xx where it must
be mapped normal memory non-cacheable.

It's best to leave the mapping to the architecture.

>> 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.

Do you already combine them into a single pool, or is this a wishlist?
I'm really not interested in sorting out peoples wishlist items in
the process of consolidation.

Second point is that you'll notice that the code converts to a phys
address using this: phys = phys_base + (virt - virt_base).  As soon as
we start allowing multiple regions of SRAM, it becomes impossible to
provide the phys address without a lot more complexity.

>>   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?

Nothing, but this is the first stage of consolidation of this code.
I'm not trying to consolidate the universe down to one implementation
here - that's going to take _far_ too much effort in one go, and from
my previous experiences interacting with other arch maintainers, that's
the way to get precisely nothing done.

In my experience, arch maintainers tend to object to each others patches,
and the net result is no forward progress.  See dma_mmap API as a
brilliant example of that - the lack of which contines to cause problems
for drivers many years after I initially tried (and gave up) trying to
get agreement on that.

So, let's do what we can to consolidate our stuff and if we get some
agreement from other arch maintainers, look towards moving it out.
Moving stuff out once its properly modularized is trivial.

[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 04:50:49PM +0200, Detlef Vollmann wrote:
> I'd love to have the mapping inside the create pool, but that might
> not be possible in general.

No, think about it.  What if you need to map the RAM area with some
special attributes - eg, where ioremap() doesn't work.  Eg, OMAP you
need SRAM mapped as normal memory, except for OMAP34xx where it must
be mapped normal memory non-cacheable.

It's best to leave the mapping to the architecture.

>> 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.

Do you already combine them into a single pool, or is this a wishlist?
I'm really not interested in sorting out peoples wishlist items in
the process of consolidation.

Second point is that you'll notice that the code converts to a phys
address using this: phys = phys_base + (virt - virt_base).  As soon as
we start allowing multiple regions of SRAM, it becomes impossible to
provide the phys address without a lot more complexity.

>>   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?

Nothing, but this is the first stage of consolidation of this code.
I'm not trying to consolidate the universe down to one implementation
here - that's going to take _far_ too much effort in one go, and from
my previous experiences interacting with other arch maintainers, that's
the way to get precisely nothing done.

In my experience, arch maintainers tend to object to each others patches,
and the net result is no forward progress.  See dma_mmap API as a
brilliant example of that - the lack of which contines to cause problems
for drivers many years after I initially tried (and gave up) trying to
get agreement on that.

So, let's do what we can to consolidate our stuff and if we get some
agreement from other arch maintainers, look towards moving it out.
Moving stuff out once its properly modularized is trivial.

Re: [RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 09:32:01AM -0600, Grant Likely wrote:
> 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.

I don't agree with stuffing non-arch directories with code which people
haven't already agreed should be shared.  As I've already said, in my
experience it's hard to get agreement in the first place and even when
you can the API generally needs to be changed from what you first think
would be reasonable.

So, lets wait to see whether the SH folk reply.

[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 09:32:01AM -0600, Grant Likely wrote:
> 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.

I don't agree with stuffing non-arch directories with code which people
haven't already agreed should be shared.  As I've already said, in my
experience it's hard to get agreement in the first place and even when
you can the API generally needs to be changed from what you first think
would be reasonable.

So, lets wait to see whether the SH folk reply.

Re: [RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 08:39:55AM -0500, Rob Herring wrote:
> Russell,
>
> 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.

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?

The commit says:

    ARM: imx: Add iram allocator functions

    Add IRAM(Internal RAM) allocation functions using GENERIC_ALLOCATOR.
    The allocation size is 4KB multiples to guarantee alignment. The
    idea for these functions is for i.MX platforms to use them
    to dynamically allocate IRAM usage.

    Applies on 2.6.36-rc7

> lpc32xx and pnx4008 also use iram, but do not have an allocator (only 1  
> user). Both are doing a copy the suspend code to IRAM and run it which  
> may also be a good thing to have generic code for. Several i.MX chips  
> also need to run from IRAM for suspend.

We have support for copying functions to other bits of memory and getting
the Thumb-ness right - see asm/fncpy.h.  So that's a separate patch to
convert them over.

[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 08:39:55AM -0500, Rob Herring wrote:
> Russell,
>
> 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.

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?

The commit says:

    ARM: imx: Add iram allocator functions

    Add IRAM(Internal RAM) allocation functions using GENERIC_ALLOCATOR.
    The allocation size is 4KB multiples to guarantee alignment. The
    idea for these functions is for i.MX platforms to use them
    to dynamically allocate IRAM usage.

    Applies on 2.6.36-rc7

> lpc32xx and pnx4008 also use iram, but do not have an allocator (only 1  
> user). Both are doing a copy the suspend code to IRAM and run it which  
> may also be a good thing to have generic code for. Several i.MX chips  
> also need to run from IRAM for suspend.

We have support for copying functions to other bits of memory and getting
the Thumb-ness right - see asm/fncpy.h.  So that's a separate patch to
convert them over.

Re: [RFC PATCH] Consolidate SRAM support

[Nicolas Ferre]

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

[..]

>> 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.

In fact on at91sam9g20 (and some other at91) you can use the mirroring
of the SRAM until next bank... so you end up with a single pool.

Base @ sram1 base - sram0 size
size = sram 0 size + sram 1 size

Best regards,
-- 
Nicolas Ferre

[RFC PATCH] Consolidate SRAM support

[Nicolas Ferre]

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

[..]

>> 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.

In fact on at91sam9g20 (and some other at91) you can use the mirroring
of the SRAM until next bank... so you end up with a single pool.

Base @ sram1 base - sram0 size
size = sram 0 size + sram 1 size

Best regards,
-- 
Nicolas Ferre

RE: [RFC PATCH] Consolidate SRAM support

[Nguyen Dinh-R00091]

Hi Russell,


>-----Original Message-----
>From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-arm-kernel-
>bounces@lists.infradead.org] On Behalf Of Russell King - ARM Linux
>Sent: Friday, April 15, 2011 11:04 AM
>To: Rob Herring
>Cc: Kevin Hilman; davinci-linux-open-source@linux.davincidsp.com; Tony Lindgren; Sekhar Nori; linux-
>omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org
>Subject: Re: [RFC PATCH] Consolidate SRAM support
>
>On Fri, Apr 15, 2011 at 08:39:55AM -0500, Rob Herring wrote:
>> Russell,
>>
>> 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.
>
>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.

>
>The commit says:
>
>    ARM: imx: Add iram allocator functions
>
>    Add IRAM(Internal RAM) allocation functions using GENERIC_ALLOCATOR.
>    The allocation size is 4KB multiples to guarantee alignment. The
>    idea for these functions is for i.MX platforms to use them
>    to dynamically allocate IRAM usage.
>
>    Applies on 2.6.36-rc7
>
>> lpc32xx and pnx4008 also use iram, but do not have an allocator (only 1
>> user). Both are doing a copy the suspend code to IRAM and run it which
>> may also be a good thing to have generic code for. Several i.MX chips
>> also need to run from IRAM for suspend.
>
>We have support for copying functions to other bits of memory and getting
>the Thumb-ness right - see asm/fncpy.h.  So that's a separate patch to
>convert them over.
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC PATCH] Consolidate SRAM support

[Nguyen Dinh-R00091]

Hi Russell,


>-----Original Message-----
From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-arm-kernel-
>bounces at lists.infradead.org] On Behalf Of Russell King - ARM Linux
>Sent: Friday, April 15, 2011 11:04 AM
>To: Rob Herring
>Cc: Kevin Hilman; davinci-linux-open-source at linux.davincidsp.com; Tony Lindgren; Sekhar Nori; linux-
>omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
>Subject: Re: [RFC PATCH] Consolidate SRAM support
>
>On Fri, Apr 15, 2011 at 08:39:55AM -0500, Rob Herring wrote:
>> Russell,
>>
>> 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.
>
>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.

>
>The commit says:
>
>    ARM: imx: Add iram allocator functions
>
>    Add IRAM(Internal RAM) allocation functions using GENERIC_ALLOCATOR.
>    The allocation size is 4KB multiples to guarantee alignment. The
>    idea for these functions is for i.MX platforms to use them
>    to dynamically allocate IRAM usage.
>
>    Applies on 2.6.36-rc7
>
>> lpc32xx and pnx4008 also use iram, but do not have an allocator (only 1
>> user). Both are doing a copy the suspend code to IRAM and run it which
>> may also be a good thing to have generic code for. Several i.MX chips
>> also need to run from IRAM for suspend.
>
>We have support for copying functions to other bits of memory and getting
>the Thumb-ness right - see asm/fncpy.h.  So that's a separate patch to
>convert them over.
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

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?

[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

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?

Re: [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)

?

[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)

?

Re: [RFC PATCH] Consolidate SRAM support

[Detlef Vollmann]

On 04/15/11 17:37, Russell King - ARM Linux wrote:
> On Fri, Apr 15, 2011 at 04:50:49PM +0200, Detlef Vollmann wrote:
>> I'd love to have the mapping inside the create pool, but that might
>> not be possible in general.
>
> No, think about it.  What if you need to map the RAM area with some
> special attributes - eg, where ioremap() doesn't work.  Eg, OMAP you
> need SRAM mapped as normal memory, except for OMAP34xx where it must
> be mapped normal memory non-cacheable.
>
> It's best to leave the mapping to the architecture.
Ok, I agree.

>>> 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.
>
> Do you already combine them into a single pool, or is this a wishlist?
Well, I have it on my list for next week to write a driver that needs
that.  So your proposal came just in time :-)

> I'm really not interested in sorting out peoples wishlist items in
> the process of consolidation.
If your code doesn't support it, then I have three options:
  - implementing my own pool (this actually might make sense, as
    my requirement adds quite some overhead that others don't
    want to pay),
  - providing a patch on top of your implementation (as long as
    struct sram_pool is an opaque type, this doesn't change the API), or
  - forget dynamic allocation and assign buffers statically in the
    board setup.

Of course, if the mirroring mentioned by Nicolas I don't need any
of this...

> Second point is that you'll notice that the code converts to a phys
> address using this: phys = phys_base + (virt - virt_base).  As soon as
> we start allowing multiple regions of SRAM, it becomes impossible to
> provide the phys address without a lot more complexity.
Yes, I understand that.  This either requires some intrusive changes
to gen_pool code or quite some additional code in sram_pool_alloc.


And just one minor point: you might consider to rename sram_* to
pram_* (or similar), as there's nothing specific to SRAM in your
pool, the specific thing that sram_pool adds on top of gen_pool
is the physical address.  And a lot of systems have external SRAM
that will normally not be used with your sram_pool.

   Detlef

[RFC PATCH] Consolidate SRAM support

[Detlef Vollmann]

On 04/15/11 17:37, Russell King - ARM Linux wrote:
> On Fri, Apr 15, 2011 at 04:50:49PM +0200, Detlef Vollmann wrote:
>> I'd love to have the mapping inside the create pool, but that might
>> not be possible in general.
>
> No, think about it.  What if you need to map the RAM area with some
> special attributes - eg, where ioremap() doesn't work.  Eg, OMAP you
> need SRAM mapped as normal memory, except for OMAP34xx where it must
> be mapped normal memory non-cacheable.
>
> It's best to leave the mapping to the architecture.
Ok, I agree.

>>> 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.
>
> Do you already combine them into a single pool, or is this a wishlist?
Well, I have it on my list for next week to write a driver that needs
that.  So your proposal came just in time :-)

> I'm really not interested in sorting out peoples wishlist items in
> the process of consolidation.
If your code doesn't support it, then I have three options:
  - implementing my own pool (this actually might make sense, as
    my requirement adds quite some overhead that others don't
    want to pay),
  - providing a patch on top of your implementation (as long as
    struct sram_pool is an opaque type, this doesn't change the API), or
  - forget dynamic allocation and assign buffers statically in the
    board setup.

Of course, if the mirroring mentioned by Nicolas I don't need any
of this...

> Second point is that you'll notice that the code converts to a phys
> address using this: phys = phys_base + (virt - virt_base).  As soon as
> we start allowing multiple regions of SRAM, it becomes impossible to
> provide the phys address without a lot more complexity.
Yes, I understand that.  This either requires some intrusive changes
to gen_pool code or quite some additional code in sram_pool_alloc.


And just one minor point: you might consider to rename sram_* to
pram_* (or similar), as there's nothing specific to SRAM in your
pool, the specific thing that sram_pool adds on top of gen_pool
is the physical address.  And a lot of systems have external SRAM
that will normally not be used with your sram_pool.

   Detlef

Re: [RFC PATCH] Consolidate SRAM support

[Detlef Vollmann]

On 04/15/11 18:04, Nicolas Ferre wrote:
> Le 15/04/2011 16:50, Detlef Vollmann :
>> On 04/15/11 15:06, Russell King - ARM Linux wrote:
>>> This is work in progress.
>> Thanks, very useful.
>
> [..]
>
>>> 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.
>
> In fact on at91sam9g20 (and some other at91) you can use the mirroring
> of the SRAM until next bank... so you end up with a single pool.
>
> Base @ sram1 base - sram0 size
> size = sram 0 size + sram 1 size
Can you provide details?
I couldn't find anything in the documentation about this.

   Detlef

[RFC PATCH] Consolidate SRAM support

[Detlef Vollmann]

On 04/15/11 18:04, Nicolas Ferre wrote:
> Le 15/04/2011 16:50, Detlef Vollmann :
>> On 04/15/11 15:06, Russell King - ARM Linux wrote:
>>> This is work in progress.
>> Thanks, very useful.
>
> [..]
>
>>> 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.
>
> In fact on at91sam9g20 (and some other at91) you can use the mirroring
> of the SRAM until next bank... so you end up with a single pool.
>
> Base @ sram1 base - sram0 size
> size = sram 0 size + sram 1 size
Can you provide details?
I couldn't find anything in the documentation about this.

   Detlef

Re: [RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 08:12:07PM +0200, Detlef Vollmann wrote:
>> Second point is that you'll notice that the code converts to a phys
>> address using this: phys = phys_base + (virt - virt_base).  As soon as
>> we start allowing multiple regions of SRAM, it becomes impossible to
>> provide the phys address without a lot more complexity.
> Yes, I understand that.  This either requires some intrusive changes
> to gen_pool code or quite some additional code in sram_pool_alloc.

It would require sram_pool to track each individual buffer alongside
the similar tracking that gen_pool does, and then look up the returned
address to find out which buffer it corresponds with.

As it looks though, this functionality isn't required on AT91.  So lets
not complicate the code unless we know we have to.  While the alloc/free
API is such that it'll be able to cope if we have to add it later - the
initialization will have to become a little more complex.  And then I
start to wonder if gen_pool should just be extended for the phys address.

[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 08:12:07PM +0200, Detlef Vollmann wrote:
>> Second point is that you'll notice that the code converts to a phys
>> address using this: phys = phys_base + (virt - virt_base).  As soon as
>> we start allowing multiple regions of SRAM, it becomes impossible to
>> provide the phys address without a lot more complexity.
> Yes, I understand that.  This either requires some intrusive changes
> to gen_pool code or quite some additional code in sram_pool_alloc.

It would require sram_pool to track each individual buffer alongside
the similar tracking that gen_pool does, and then look up the returned
address to find out which buffer it corresponds with.

As it looks though, this functionality isn't required on AT91.  So lets
not complicate the code unless we know we have to.  While the alloc/free
API is such that it'll be able to cope if we have to add it later - the
initialization will have to become a little more complex.  And then I
start to wonder if gen_pool should just be extended for the phys address.

Re: [RFC PATCH] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:06 Fri 15 Apr     , 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.
> 
> 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>
Hi,

	I also work on it for at91

	and already have some patch in the mm for this

	[PATCH] genalloc: add support to specify the physical address

	so now you can do this

	as I do on at91 will send the patch after

static struct map_desc at91sam9g20_sram_desc[] __initdata = {
	{
		.virtual	= AT91_IO_VIRT_BASE - AT91SAM9G20_SRAM_SIZE,
		.pfn		= __phys_to_pfn(AT91SAM9G20_SRAM_BASE),
		.length		= AT91SAM9G20_SRAM_SIZE,
		.type		= MT_DEVICE,
	}
};

	sram_pool = gen_pool_create(2, -1);

	gen_pool_add_virt(sram_pool, io_desc->virtual __pfn_to_phys(io_desc->pfn),
			io_desc->length, -1)

	and to get the physical address

	phys = gen_pool_virt_to_phys(sram_pool, virt);

Best Resgards,
J.

[RFC PATCH] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:06 Fri 15 Apr     , 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.
> 
> 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>
Hi,

	I also work on it for at91

	and already have some patch in the mm for this

	[PATCH] genalloc: add support to specify the physical address

	so now you can do this

	as I do on at91 will send the patch after

static struct map_desc at91sam9g20_sram_desc[] __initdata = {
	{
		.virtual	= AT91_IO_VIRT_BASE - AT91SAM9G20_SRAM_SIZE,
		.pfn		= __phys_to_pfn(AT91SAM9G20_SRAM_BASE),
		.length		= AT91SAM9G20_SRAM_SIZE,
		.type		= MT_DEVICE,
	}
};

	sram_pool = gen_pool_create(2, -1);

	gen_pool_add_virt(sram_pool, io_desc->virtual __pfn_to_phys(io_desc->pfn),
			io_desc->length, -1)

	and to get the physical address

	phys = gen_pool_virt_to_phys(sram_pool, virt);

Best Resgards,
J.

[PATCH 1/2] at91: 9260 and 9g20 add support of join SRAM Memory Mapping

[Jean-Christophe PLAGNIOL-VILLARD]

on 9269 and 9g20 the sram are mirrored at then of the bank so we can join them

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Patrice Vilchez <patrice.vilchez@atmel.com>
---
 arch/arm/mach-at91/at91sam9260.c              |   22 ++++++----------------
 arch/arm/mach-at91/include/mach/at91sam9260.h |    4 ++++
 2 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index 195208b..32524ef 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -36,28 +36,18 @@ static struct map_desc at91sam9260_io_desc[] __initdata = {
 
 static struct map_desc at91sam9260_sram_desc[] __initdata = {
 	{
-		.virtual	= AT91_IO_VIRT_BASE - AT91SAM9260_SRAM0_SIZE,
-		.pfn		= __phys_to_pfn(AT91SAM9260_SRAM0_BASE),
-		.length		= AT91SAM9260_SRAM0_SIZE,
-		.type		= MT_DEVICE,
-	}, {
-		.virtual	= AT91_IO_VIRT_BASE - AT91SAM9260_SRAM0_SIZE - AT91SAM9260_SRAM1_SIZE,
-		.pfn		= __phys_to_pfn(AT91SAM9260_SRAM1_BASE),
-		.length		= AT91SAM9260_SRAM1_SIZE,
+		.virtual	= AT91_IO_VIRT_BASE - AT91SAM9260_SRAM_SIZE,
+		.pfn		= __phys_to_pfn(AT91SAM9260_SRAM_BASE),
+		.length		= AT91SAM9260_SRAM_SIZE,
 		.type		= MT_DEVICE,
 	}
 };
 
 static struct map_desc at91sam9g20_sram_desc[] __initdata = {
 	{
-		.virtual	= AT91_IO_VIRT_BASE - AT91SAM9G20_SRAM0_SIZE,
-		.pfn		= __phys_to_pfn(AT91SAM9G20_SRAM0_BASE),
-		.length		= AT91SAM9G20_SRAM0_SIZE,
-		.type		= MT_DEVICE,
-	}, {
-		.virtual	= AT91_IO_VIRT_BASE - AT91SAM9G20_SRAM0_SIZE - AT91SAM9G20_SRAM1_SIZE,
-		.pfn		= __phys_to_pfn(AT91SAM9G20_SRAM1_BASE),
-		.length		= AT91SAM9G20_SRAM1_SIZE,
+		.virtual	= AT91_IO_VIRT_BASE - AT91SAM9G20_SRAM_SIZE,
+		.pfn		= __phys_to_pfn(AT91SAM9G20_SRAM_BASE),
+		.length		= AT91SAM9G20_SRAM_SIZE,
 		.type		= MT_DEVICE,
 	}
 };
diff --git a/arch/arm/mach-at91/include/mach/at91sam9260.h b/arch/arm/mach-at91/include/mach/at91sam9260.h
index 4e79036..6c53b95 100644
--- a/arch/arm/mach-at91/include/mach/at91sam9260.h
+++ b/arch/arm/mach-at91/include/mach/at91sam9260.h
@@ -119,6 +119,8 @@
 #define AT91SAM9260_SRAM0_SIZE	SZ_4K		/* Internal SRAM 0 size (4Kb) */
 #define AT91SAM9260_SRAM1_BASE	0x00300000	/* Internal SRAM 1 base address */
 #define AT91SAM9260_SRAM1_SIZE	SZ_4K		/* Internal SRAM 1 size (4Kb) */
+#define AT91SAM9260_SRAM_BASE	0x002FF000	/* Internal SRAM base address */
+#define AT91SAM9260_SRAM_SIZE	SZ_8K		/* Internal SRAM size (8Kb) */
 
 #define AT91SAM9260_UHP_BASE	0x00500000	/* USB Host controller */
 
@@ -132,6 +134,8 @@
 #define AT91SAM9G20_SRAM0_SIZE	SZ_16K		/* Internal SRAM 0 size (16Kb) */
 #define AT91SAM9G20_SRAM1_BASE	0x00300000	/* Internal SRAM 1 base address */
 #define AT91SAM9G20_SRAM1_SIZE	SZ_16K		/* Internal SRAM 1 size (16Kb) */
+#define AT91SAM9G20_SRAM_BASE	0x002FC000	/* Internal SRAM base address */
+#define AT91SAM9G20_SRAM_SIZE	SZ_32K		/* Internal SRAM size (32Kb) */
 
 #define AT91SAM9G20_UHP_BASE	0x00500000	/* USB Host controller */
 
-- 
1.7.4.1

[PATCH 2/2] at91: add generic allocator support for sram

[Jean-Christophe PLAGNIOL-VILLARD]

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Patrice Vilchez <patrice.vilchez@atmel.com>
---
 arch/arm/Kconfig                       |    1 +
 arch/arm/mach-at91/Makefile            |    2 +-
 arch/arm/mach-at91/at91cap9.c          |    8 ++++++
 arch/arm/mach-at91/at91rm9200.c        |    8 ++++++
 arch/arm/mach-at91/at91sam9260.c       |   12 ++++++++
 arch/arm/mach-at91/at91sam9261.c       |   11 ++++++++
 arch/arm/mach-at91/at91sam9263.c       |    9 ++++++
 arch/arm/mach-at91/at91sam9g45.c       |    8 ++++++
 arch/arm/mach-at91/generic.h           |    4 +++
 arch/arm/mach-at91/include/mach/sram.h |   39 ++++++++++++++++++++++++++++
 arch/arm/mach-at91/sram.c              |   44 ++++++++++++++++++++++++++++++++
 11 files changed, 145 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-at91/include/mach/sram.h
 create mode 100644 arch/arm/mach-at91/sram.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fdc9d4d..2bc50b6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -288,6 +288,7 @@ config ARCH_AT91
 	bool "Atmel AT91"
 	select ARCH_REQUIRE_GPIOLIB
 	select HAVE_CLK
+	select GENERIC_ALLOCATOR
 	help
 	  This enables support for systems based on the Atmel AT91RM9200,
 	  AT91SAM9 and AT91CAP9 processors.
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index a83835e..0f876b4 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the linux kernel.
 #
 
-obj-y		:= irq.o gpio.o
+obj-y		:= irq.o gpio.o sram.o
 obj-m		:=
 obj-n		:=
 obj-		:=
diff --git a/arch/arm/mach-at91/at91cap9.c b/arch/arm/mach-at91/at91cap9.c
index 7337617..55da140 100644
--- a/arch/arm/mach-at91/at91cap9.c
+++ b/arch/arm/mach-at91/at91cap9.c
@@ -381,3 +381,11 @@ void __init at91cap9_init_interrupts(unsigned int priority[NR_AIC_IRQS])
 	/* Enable GPIO interrupts */
 	at91_gpio_irq_setup();
 }
+
+static int sram_init(void)
+{
+	at91_sram_init(&at91cap9_io_desc[1]);
+
+	return 0;
+}
+core_initcall(sram_init);
diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
index 2e9ecad..72184a1 100644
--- a/arch/arm/mach-at91/at91rm9200.c
+++ b/arch/arm/mach-at91/at91rm9200.c
@@ -345,3 +345,11 @@ void __init at91rm9200_init_interrupts(unsigned int priority[NR_AIC_IRQS])
 	/* Enable GPIO interrupts */
 	at91_gpio_irq_setup();
 }
+
+static int sram_init(void)
+{
+	at91_sram_init(&at91rm9200_io_desc[2]);
+
+	return 0;
+}
+core_initcall(sram_init);
diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index 32524ef..8e4db5d 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -380,3 +380,15 @@ void __init at91sam9260_init_interrupts(unsigned int priority[NR_AIC_IRQS])
 	/* Enable GPIO interrupts */
 	at91_gpio_irq_setup();
 }
+
+static int sram_init(void)
+{
+	if (cpu_is_at91sam9g20()) {
+		at91_sram_init(&at91sam9g20_sram_desc[0]);
+	} else {
+		at91_sram_init(&at91sam9260_sram_desc[0]);
+	}
+
+	return 0;
+}
+core_initcall(sram_init);
diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
index fcad886..77ab068 100644
--- a/arch/arm/mach-at91/at91sam9261.c
+++ b/arch/arm/mach-at91/at91sam9261.c
@@ -346,3 +346,14 @@ void __init at91sam9261_init_interrupts(unsigned int priority[NR_AIC_IRQS])
 	/* Enable GPIO interrupts */
 	at91_gpio_irq_setup();
 }
+
+static int sram_init(void)
+{
+	if (cpu_is_at91sam9g10())
+		at91_sram_init(&at91sam9g10_sram_desc[0]);
+	else
+		at91_sram_init(&at91sam9261_sram_desc[0]);
+
+	return 0;
+}
+core_initcall(sram_init);
diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index 249f900..b7c4215 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -351,3 +351,12 @@ void __init at91sam9263_init_interrupts(unsigned int priority[NR_AIC_IRQS])
 	/* Enable GPIO interrupts */
 	at91_gpio_irq_setup();
 }
+
+static int sram_init(void)
+{
+	at91_sram_init(&at91sam9263_io_desc[1]);
+	at91_sram_init(&at91sam9263_io_desc[2]);
+
+	return 0;
+}
+core_initcall(sram_init);
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index c67b47f..b20afdb 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -378,3 +378,11 @@ void __init at91sam9g45_init_interrupts(unsigned int priority[NR_AIC_IRQS])
 	/* Enable GPIO interrupts */
 	at91_gpio_irq_setup();
 }
+
+static int sram_init(void)
+{
+	at91_sram_init(&at91sam9g45_io_desc[1]);
+
+	return 0;
+}
+core_initcall(sram_init);
diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index 0c66deb..4100a26 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -63,3 +63,7 @@ extern void __init at91_gpio_irq_setup(void);
 
 extern void (*at91_arch_reset)(void);
 extern int at91_extern_irq;
+
+/* SRAM */
+struct map_desc;
+extern int __init at91_sram_init(struct map_desc *io_desc);
diff --git a/arch/arm/mach-at91/include/mach/sram.h b/arch/arm/mach-at91/include/mach/sram.h
new file mode 100644
index 0000000..99dac2b
--- /dev/null
+++ b/arch/arm/mach-at91/include/mach/sram.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright (C) 2011 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __MACH_SRAM_H__
+#define __MACH_SRAM_H__
+
+#include <linux/genalloc.h>
+
+extern struct gen_pool *sram_pool;
+
+static inline unsigned long sram_virt_to_phys(void* addr)
+{
+	if (!sram_pool)
+		return ~0UL;
+
+	return gen_pool_virt_to_phys(sram_pool, (unsigned long)addr);
+}
+
+static inline void* sram_alloc(size_t len)
+{
+	if (!sram_pool)
+		return NULL;
+
+	return (void*)gen_pool_alloc(sram_pool, len);
+}
+
+static inline void sram_free(void* addr, size_t len)
+{
+	if (!sram_pool)
+		return;
+
+	return gen_pool_free(sram_pool, (unsigned long)addr, len);
+}
+
+#endif /* __MACH_SRAM_H__ */
diff --git a/arch/arm/mach-at91/sram.c b/arch/arm/mach-at91/sram.c
new file mode 100644
index 0000000..11e9768
--- /dev/null
+++ b/arch/arm/mach-at91/sram.c
@@ -0,0 +1,44 @@
+/*
+ * Copyright (C) 2011 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+
+#include <asm/mach/map.h>
+#include <mach/sram.h>
+
+struct gen_pool *sram_pool;
+
+extern int __init at91_sram_init(struct map_desc *io_desc)
+{
+	int ret = -ENOMEM;
+
+	if (!io_desc) {
+		ret = -EIO;
+		goto fail;
+	}
+
+	if (!sram_pool) {
+		sram_pool = gen_pool_create(2, -1);
+		if (!sram_pool)
+			goto fail;
+	}
+
+	if (gen_pool_add_virt(sram_pool, io_desc->virtual,
+			      __pfn_to_phys(io_desc->pfn), io_desc->length, -1))
+		goto fail;
+	pr_info("AT91: create SRAM pool of 0x%x at 0x%lx (mapped at 0x%lx)\n",
+		io_desc->length,
+		gen_pool_virt_to_phys(sram_pool, io_desc->virtual),
+		io_desc->virtual);
+
+	return 0;
+
+fail:
+	pr_err("Failed to create SRAM pool\n");
+	return ret;
+}
-- 
1.7.4.1

RE: [RFC PATCH] Consolidate SRAM support

[Nguyen Dinh-R00091]

>-----Original Message-----
>From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
>Sent: Friday, April 15, 2011 11:59 AM
>To: Nguyen Dinh-R00091
>Cc: Kevin Hilman; davinci-linux-open-source@linux.davincidsp.com; Tony Lindgren; Sekhar Nori; linux-
>omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org
>Subject: Re: [RFC PATCH] Consolidate SRAM support
>
>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.

Yes, should just be a void *iram_alloc().

>
>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)
>
>?

[RFC PATCH] Consolidate SRAM support

[Nguyen Dinh-R00091]

>-----Original Message-----
>From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
>Sent: Friday, April 15, 2011 11:59 AM
>To: Nguyen Dinh-R00091
>Cc: Kevin Hilman; davinci-linux-open-source at linux.davincidsp.com; Tony Lindgren; Sekhar Nori; linux-
>omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
>Subject: Re: [RFC PATCH] Consolidate SRAM support
>
>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.

Yes, should just be a void *iram_alloc().

>
>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)
>
>?

Re: [RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 07:20:12PM +0000, Nguyen Dinh-R00091 wrote:
> 
> >-----Original Message-----
> >From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> >Sent: Friday, April 15, 2011 11:59 AM
> >To: Nguyen Dinh-R00091
> >Cc: Kevin Hilman; davinci-linux-open-source@linux.davincidsp.com; Tony Lindgren; Sekhar Nori; linux-
> >omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> >Subject: Re: [RFC PATCH] Consolidate SRAM support
> >
> >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.
> 
> Yes, should just be a void *iram_alloc().

Thanks.  As you didn't comment against the change below, I'm going to
assume that you're happy with it.  It means that the usage changes from:

	unsigned long dma;
	void __iomem *addr = iram_alloc(SZ_4K, &dma);
	...
	iram_free(dma, SZ_4K);

to:

	phys_addr_t phys;
	void *addr = iram_alloc(SZ_4K, &phys);
	...
	iram_free(addr, SZ_4K);

> >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)
> >
> >?
> 
> 

[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 07:20:12PM +0000, Nguyen Dinh-R00091 wrote:
> 
> >-----Original Message-----
> >From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> >Sent: Friday, April 15, 2011 11:59 AM
> >To: Nguyen Dinh-R00091
> >Cc: Kevin Hilman; davinci-linux-open-source at linux.davincidsp.com; Tony Lindgren; Sekhar Nori; linux-
> >omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> >Subject: Re: [RFC PATCH] Consolidate SRAM support
> >
> >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.
> 
> Yes, should just be a void *iram_alloc().

Thanks.  As you didn't comment against the change below, I'm going to
assume that you're happy with it.  It means that the usage changes from:

	unsigned long dma;
	void __iomem *addr = iram_alloc(SZ_4K, &dma);
	...
	iram_free(dma, SZ_4K);

to:

	phys_addr_t phys;
	void *addr = iram_alloc(SZ_4K, &phys);
	...
	iram_free(addr, SZ_4K);

> >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)
> >
> >?
> 
> 

RE: [RFC PATCH] Consolidate SRAM support

[Nguyen Dinh-R00091]

>-----Original Message-----
>From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
>Sent: Friday, April 15, 2011 2:40 PM
>To: Nguyen Dinh-R00091
>Cc: Kevin Hilman; davinci-linux-open-source@linux.davincidsp.com; Tony Lindgren; Sekhar Nori; linux-
>omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org
>Subject: Re: [RFC PATCH] Consolidate SRAM support
>
>On Fri, Apr 15, 2011 at 07:20:12PM +0000, Nguyen Dinh-R00091 wrote:
>>
>> >-----Original Message-----
>> >From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
>> >Sent: Friday, April 15, 2011 11:59 AM
>> >To: Nguyen Dinh-R00091
>> >Cc: Kevin Hilman; davinci-linux-open-source@linux.davincidsp.com; Tony Lindgren; Sekhar Nori;
>linux-
>> >omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org
>> >Subject: Re: [RFC PATCH] Consolidate SRAM support
>> >
>> >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.
>>
>> Yes, should just be a void *iram_alloc().
>
>Thanks.  As you didn't comment against the change below, I'm going to
>assume that you're happy with it.  It means that the usage changes from:

Sorry...yes, your proposal looks fine. 

Thanks,
Dinh

>
>	unsigned long dma;
>	void __iomem *addr = iram_alloc(SZ_4K, &dma);
>	...
>	iram_free(dma, SZ_4K);
>
>to:
>
>	phys_addr_t phys;
>	void *addr = iram_alloc(SZ_4K, &phys);
>	...
>	iram_free(addr, SZ_4K);
>
>> >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)
>> >
>> >?
>>
>>

[RFC PATCH] Consolidate SRAM support

[Nguyen Dinh-R00091]

>-----Original Message-----
>From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
>Sent: Friday, April 15, 2011 2:40 PM
>To: Nguyen Dinh-R00091
>Cc: Kevin Hilman; davinci-linux-open-source at linux.davincidsp.com; Tony Lindgren; Sekhar Nori; linux-
>omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
>Subject: Re: [RFC PATCH] Consolidate SRAM support
>
>On Fri, Apr 15, 2011 at 07:20:12PM +0000, Nguyen Dinh-R00091 wrote:
>>
>> >-----Original Message-----
>> >From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
>> >Sent: Friday, April 15, 2011 11:59 AM
>> >To: Nguyen Dinh-R00091
>> >Cc: Kevin Hilman; davinci-linux-open-source at linux.davincidsp.com; Tony Lindgren; Sekhar Nori;
>linux-
>> >omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
>> >Subject: Re: [RFC PATCH] Consolidate SRAM support
>> >
>> >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.
>>
>> Yes, should just be a void *iram_alloc().
>
>Thanks.  As you didn't comment against the change below, I'm going to
>assume that you're happy with it.  It means that the usage changes from:

Sorry...yes, your proposal looks fine. 

Thanks,
Dinh

>
>	unsigned long dma;
>	void __iomem *addr = iram_alloc(SZ_4K, &dma);
>	...
>	iram_free(dma, SZ_4K);
>
>to:
>
>	phys_addr_t phys;
>	void *addr = iram_alloc(SZ_4K, &phys);
>	...
>	iram_free(addr, SZ_4K);
>
>> >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)
>> >
>> >?
>>
>>

Re: [RFC PATCH] Consolidate SRAM support

[Uwe Kleine-König]

On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.
I havn't checked the details, but maybe the code in
arch/arm/plat-mxc/iram_alloc.c could be migrated to your approach, too?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
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

[RFC PATCH] Consolidate SRAM support

[Uwe Kleine-König]

On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.
I havn't checked the details, but maybe the code in
arch/arm/plat-mxc/iram_alloc.c could be migrated to your approach, too?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 10:11:07PM +0200, Uwe Kleine-König wrote:
> On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.
> I havn't checked the details, but maybe the code in
> arch/arm/plat-mxc/iram_alloc.c could be migrated to your approach, too?

Its already in there now that I have replies from Nguyen Dinh.  It
looks like this presently:

 arch/arm/plat-mxc/Kconfig                   |    2 +-
 arch/arm/plat-mxc/include/mach/iram.h       |   24 +++++++--
 arch/arm/plat-mxc/iram_alloc.c              |   50 +++++---------------

and if we get rid of the iram_alloc/iram_free wrappers around the
sram_pool (now pv_pool) alloc/free in iram.h, in the same way I've
done for Davinci, then we get less new additions too.
--
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

[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 10:11:07PM +0200, Uwe Kleine-K?nig wrote:
> On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.
> I havn't checked the details, but maybe the code in
> arch/arm/plat-mxc/iram_alloc.c could be migrated to your approach, too?

Its already in there now that I have replies from Nguyen Dinh.  It
looks like this presently:

 arch/arm/plat-mxc/Kconfig                   |    2 +-
 arch/arm/plat-mxc/include/mach/iram.h       |   24 +++++++--
 arch/arm/plat-mxc/iram_alloc.c              |   50 +++++---------------

and if we get rid of the iram_alloc/iram_free wrappers around the
sram_pool (now pv_pool) alloc/free in iram.h, in the same way I've
done for Davinci, then we get less new additions too.

Re: [RFC PATCH] Consolidate SRAM support

[Uwe Kleine-König]

On Fri, Apr 15, 2011 at 09:19:25PM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 15, 2011 at 10:11:07PM +0200, Uwe Kleine-König wrote:
> > On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.
> > I havn't checked the details, but maybe the code in
> > arch/arm/plat-mxc/iram_alloc.c could be migrated to your approach, too?
> 
> Its already in there now that I have replies from Nguyen Dinh.  It
> looks like this presently:
> 
>  arch/arm/plat-mxc/Kconfig                   |    2 +-
>  arch/arm/plat-mxc/include/mach/iram.h       |   24 +++++++--
>  arch/arm/plat-mxc/iram_alloc.c              |   50 +++++---------------
> 
> and if we get rid of the iram_alloc/iram_free wrappers around the
> sram_pool (now pv_pool) alloc/free in iram.h, in the same way I've
> done for Davinci, then we get less new additions too.
Great!

Thanks,
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
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

[RFC PATCH] Consolidate SRAM support

[Uwe Kleine-König]

On Fri, Apr 15, 2011 at 09:19:25PM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 15, 2011 at 10:11:07PM +0200, Uwe Kleine-K?nig wrote:
> > On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.
> > I havn't checked the details, but maybe the code in
> > arch/arm/plat-mxc/iram_alloc.c could be migrated to your approach, too?
> 
> Its already in there now that I have replies from Nguyen Dinh.  It
> looks like this presently:
> 
>  arch/arm/plat-mxc/Kconfig                   |    2 +-
>  arch/arm/plat-mxc/include/mach/iram.h       |   24 +++++++--
>  arch/arm/plat-mxc/iram_alloc.c              |   50 +++++---------------
> 
> and if we get rid of the iram_alloc/iram_free wrappers around the
> sram_pool (now pv_pool) alloc/free in iram.h, in the same way I've
> done for Davinci, then we get less new additions too.
Great!

Thanks,
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [RFC PATCH] Consolidate SRAM support

[Magnus Damm]

Hi Russell,

[CC Paul Mundt]

On Sat, Apr 16, 2011 at 12:41 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 15, 2011 at 09:32:01AM -0600, Grant Likely wrote:
>> 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.
>
> I don't agree with stuffing non-arch directories with code which people
> haven't already agreed should be shared.  As I've already said, in my
> experience it's hard to get agreement in the first place and even when
> you can the API generally needs to be changed from what you first think
> would be reasonable.
>
> So, lets wait to see whether the SH folk reply.

The SH arch is using NUMA for on-chip SRAM on some CPUs, but for
SH-Mobile ARM we have no software support at this point.

The SH/ARM hardware has a bunch of different on-chip memories in
place, and they all have individual power management support through
both clock gating and power domains. I assume other vendors have
similar setups.

I'd like to have some refcounting in place for the SRAM code if
possible, which would trickle down to runtime pm get/put which in turn
would allow us to control the power dynamically. Not sure how easy
that would be to accomplish though.

Paul may have some ideas on how to share the code between ARM and SH.

Thanks,

/ magnus
--
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

[RFC PATCH] Consolidate SRAM support

[Magnus Damm]

Hi Russell,

[CC Paul Mundt]

On Sat, Apr 16, 2011 at 12:41 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 15, 2011 at 09:32:01AM -0600, Grant Likely wrote:
>> 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.
>
> I don't agree with stuffing non-arch directories with code which people
> haven't already agreed should be shared. ?As I've already said, in my
> experience it's hard to get agreement in the first place and even when
> you can the API generally needs to be changed from what you first think
> would be reasonable.
>
> So, lets wait to see whether the SH folk reply.

The SH arch is using NUMA for on-chip SRAM on some CPUs, but for
SH-Mobile ARM we have no software support at this point.

The SH/ARM hardware has a bunch of different on-chip memories in
place, and they all have individual power management support through
both clock gating and power domains. I assume other vendors have
similar setups.

I'd like to have some refcounting in place for the SRAM code if
possible, which would trickle down to runtime pm get/put which in turn
would allow us to control the power dynamically. Not sure how easy
that would be to accomplish though.

Paul may have some ideas on how to share the code between ARM and SH.

Thanks,

/ magnus

Re: [RFC PATCH] Consolidate SRAM support

[Detlef Vollmann]

On 04/15/11 20:14, Detlef Vollmann wrote:
> On 04/15/11 18:04, Nicolas Ferre wrote:

>> In fact on at91sam9g20 (and some other at91) you can use the mirroring
>> of the SRAM until next bank... so you end up with a single pool.
>>
>> Base @ sram1 base - sram0 size
>> size = sram 0 size + sram 1 size
> Can you provide details?
> I couldn't find anything in the documentation about this.
Ok, I checked this.  It seems to be an undocumented feature and
its always mirrored.

   Detlef

[RFC PATCH] Consolidate SRAM support

[Detlef Vollmann]

On 04/15/11 20:14, Detlef Vollmann wrote:
> On 04/15/11 18:04, Nicolas Ferre wrote:

>> In fact on at91sam9g20 (and some other at91) you can use the mirroring
>> of the SRAM until next bank... so you end up with a single pool.
>>
>> Base @ sram1 base - sram0 size
>> size = sram 0 size + sram 1 size
> Can you provide details?
> I couldn't find anything in the documentation about this.
Ok, I checked this.  It seems to be an undocumented feature and
its always mirrored.

   Detlef

Re: [RFC PATCH] Consolidate SRAM support

[Haojian Zhuang]

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.

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.

Thanks
Haojian
--
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

[RFC PATCH] Consolidate SRAM support

[Haojian Zhuang]

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.

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.

Thanks
Haojian

Re: [RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

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

[RFC PATCH] Consolidate SRAM support

[Russell King - ARM Linux]

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.

Re: [RFC PATCH] Consolidate SRAM support

[Arnd Bergmann]

On Friday 15 April 2011, Russell King - ARM Linux wrote:
> On Fri, Apr 15, 2011 at 09:32:01AM -0600, Grant Likely wrote:
> > 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.
> 
> I don't agree with stuffing non-arch directories with code which people
> haven't already agreed should be shared.  As I've already said, in my
> experience it's hard to get agreement in the first place and even when
> you can the API generally needs to be changed from what you first think
> would be reasonable.

I believe we should be much more aggressive about putting code into generic
locations, especially when there is nothing hardware specific to it.

As we can see from all the mess regarding interrupt controllers, PCI busses
or dma mapping, most of the smaller architectures get it wrong when they
have to deal with these things, so when we have a common implementation,
it's much easier to make sure we only have the bugs once and don't get
incompatible interfaces.

	Arnd

[RFC PATCH] Consolidate SRAM support

[Arnd Bergmann]

On Friday 15 April 2011, Russell King - ARM Linux wrote:
> On Fri, Apr 15, 2011 at 09:32:01AM -0600, Grant Likely wrote:
> > 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.
> 
> I don't agree with stuffing non-arch directories with code which people
> haven't already agreed should be shared.  As I've already said, in my
> experience it's hard to get agreement in the first place and even when
> you can the API generally needs to be changed from what you first think
> would be reasonable.

I believe we should be much more aggressive about putting code into generic
locations, especially when there is nothing hardware specific to it.

As we can see from all the mess regarding interrupt controllers, PCI busses
or dma mapping, most of the smaller architectures get it wrong when they
have to deal with these things, so when we have a common implementation,
it's much easier to make sure we only have the bugs once and don't get
incompatible interfaces.

	Arnd

Re: [RFC PATCH] Consolidate SRAM support

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110416 16:06]:
> 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
> > >
> > > 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

I think we can just remove the omapfb SRAM support for now as it should
be optional. That will then leave out that dependency and can be added
back once we have a common framework in place.

Tomi do you see any problems with that?

> > 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.

There should not be any need code requiring fixup in most cases using
parameters passed to the functions should be enough. Usually it's
just register addresses that are different.
 
> 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.

C functions should not be needed. The SRAM size is small and typical
usage is a loop waiting for some register to lock. For any larger SRAM
areas NUMA can be used instead.

Regards,

Tony

[RFC PATCH] Consolidate SRAM support

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110416 16:06]:
> 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
> > >
> > > 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

I think we can just remove the omapfb SRAM support for now as it should
be optional. That will then leave out that dependency and can be added
back once we have a common framework in place.

Tomi do you see any problems with that?

> > 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.

There should not be any need code requiring fixup in most cases using
parameters passed to the functions should be enough. Usually it's
just register addresses that are different.
 
> 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.

C functions should not be needed. The SRAM size is small and typical
usage is a loop waiting for some register to lock. For any larger SRAM
areas NUMA can be used instead.

Regards,

Tony

Re: [RFC PATCH] Consolidate SRAM support

[Tomi Valkeinen]

On Mon, 2011-04-18 at 09:48 +0300, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110416 16:06]:
> > 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
> > > >
> > > > 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
> 
> I think we can just remove the omapfb SRAM support for now as it should
> be optional. That will then leave out that dependency and can be added
> back once we have a common framework in place.
> 
> Tomi do you see any problems with that?

I agree. Only OMAP2 has enough SRAM to possibly have a framebuffer
there, and even on OMAP2 the SRAM size is so small that it works only
for rather small displays. I'm not aware of anyone using omapfb's SRAM
support.

The SRAM support also makes our video ram allocator and omapfb more
complex, without much benefit, so I'm more than happy to remove it
totally. Additionally, I believe there is work going on with memory
allocators that omapfb could also use, and migrating to any new mem
allocator will no doubt be much easier if we just handle normal RAM.

So, I can make a patch that removes the SRAM support from omapfb, and
queue it up for the next merge window.

 Tomi

[RFC PATCH] Consolidate SRAM support

[Tomi Valkeinen]

On Mon, 2011-04-18 at 09:48 +0300, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110416 16:06]:
> > 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
> > > >
> > > > 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
> 
> I think we can just remove the omapfb SRAM support for now as it should
> be optional. That will then leave out that dependency and can be added
> back once we have a common framework in place.
> 
> Tomi do you see any problems with that?

I agree. Only OMAP2 has enough SRAM to possibly have a framebuffer
there, and even on OMAP2 the SRAM size is so small that it works only
for rather small displays. I'm not aware of anyone using omapfb's SRAM
support.

The SRAM support also makes our video ram allocator and omapfb more
complex, without much benefit, so I'm more than happy to remove it
totally. Additionally, I believe there is work going on with memory
allocators that omapfb could also use, and migrating to any new mem
allocator will no doubt be much easier if we just handle normal RAM.

So, I can make a patch that removes the SRAM support from omapfb, and
queue it up for the next merge window.

 Tomi

Re: [RFC PATCH] Consolidate SRAM support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [110418 09:57]:
> On Mon, 2011-04-18 at 09:48 +0300, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110416 16:06]:
> > > 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
> > > > >
> > > > > 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
> > 
> > I think we can just remove the omapfb SRAM support for now as it should
> > be optional. That will then leave out that dependency and can be added
> > back once we have a common framework in place.
> > 
> > Tomi do you see any problems with that?
> 
> I agree. Only OMAP2 has enough SRAM to possibly have a framebuffer
> there, and even on OMAP2 the SRAM size is so small that it works only
> for rather small displays. I'm not aware of anyone using omapfb's SRAM
> support.
> 
> The SRAM support also makes our video ram allocator and omapfb more
> complex, without much benefit, so I'm more than happy to remove it
> totally. Additionally, I believe there is work going on with memory
> allocators that omapfb could also use, and migrating to any new mem
> allocator will no doubt be much easier if we just handle normal RAM.
> 
> So, I can make a patch that removes the SRAM support from omapfb, and
> queue it up for the next merge window.

OK. That patch should probably go into Russell's tree along with
other SRAM related patches to avoid conflicts.

Regards,

Tony

[RFC PATCH] Consolidate SRAM support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [110418 09:57]:
> On Mon, 2011-04-18 at 09:48 +0300, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110416 16:06]:
> > > 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
> > > > >
> > > > > 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
> > 
> > I think we can just remove the omapfb SRAM support for now as it should
> > be optional. That will then leave out that dependency and can be added
> > back once we have a common framework in place.
> > 
> > Tomi do you see any problems with that?
> 
> I agree. Only OMAP2 has enough SRAM to possibly have a framebuffer
> there, and even on OMAP2 the SRAM size is so small that it works only
> for rather small displays. I'm not aware of anyone using omapfb's SRAM
> support.
> 
> The SRAM support also makes our video ram allocator and omapfb more
> complex, without much benefit, so I'm more than happy to remove it
> totally. Additionally, I believe there is work going on with memory
> allocators that omapfb could also use, and migrating to any new mem
> allocator will no doubt be much easier if we just handle normal RAM.
> 
> So, I can make a patch that removes the SRAM support from omapfb, and
> queue it up for the next merge window.

OK. That patch should probably go into Russell's tree along with
other SRAM related patches to avoid conflicts.

Regards,

Tony

Re: [RFC PATCH v2] Consolidate SRAM support

[Russell King - ARM Linux]

This is the second revision of this patch.  I've not moved it out of
ARM yet as I haven't had a positive response from SH yet.

It's now called pv_pool (for phys/virt pool) rather than sram_pool,
and I've included MXC's iram support in this.  Hopefully, if OMAP can
remove the FB stuff from SRAM we can clean the OMAP bits up a little
more.  Neither have I sorted out the last reference to omap_sram_ceil.
Some comments from OMAP people on what's going on there would be good.

On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.
> 
> 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.

 arch/arm/Kconfig                            |    2 +
 arch/arm/common/Kconfig                     |    4 ++
 arch/arm/common/Makefile                    |    1 +
 arch/arm/common/pv-pool.c                   |   69 +++++++++++++++++++++++++++
 arch/arm/include/asm/pv-pool.h              |   20 ++++++++
 arch/arm/mach-davinci/da850.c               |    2 +-
 arch/arm/mach-davinci/dm355.c               |    2 +-
 arch/arm/mach-davinci/dm365.c               |    2 +-
 arch/arm/mach-davinci/dm644x.c              |    2 +-
 arch/arm/mach-davinci/dm646x.c              |    2 +-
 arch/arm/mach-davinci/include/mach/common.h |    2 +-
 arch/arm/mach-davinci/include/mach/sram.h   |   13 +----
 arch/arm/mach-davinci/pm.c                  |   12 +----
 arch/arm/mach-davinci/sram.c                |   42 +++--------------
 arch/arm/plat-mxc/Kconfig                   |    2 +-
 arch/arm/plat-mxc/include/mach/iram.h       |   24 +++++++--
 arch/arm/plat-mxc/iram_alloc.c              |   50 +++++---------------
 arch/arm/plat-omap/include/plat/sram.h      |   17 ++++---
 arch/arm/plat-omap/sram.c                   |   34 +++++---------
 drivers/uio/uio_pruss.c                     |    7 ++-
 20 files changed, 171 insertions(+), 138 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b9f78b..5c3401c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -850,6 +850,7 @@ config ARCH_DAVINCI
 	bool "TI DaVinci"
 	select GENERIC_CLOCKEVENTS
 	select ARCH_REQUIRE_GPIOLIB
+	select PV_POOL
 	select ZONE_DMA
 	select HAVE_IDE
 	select CLKDEV_LOOKUP
@@ -863,6 +864,7 @@ config ARCH_OMAP
 	select HAVE_CLK
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_CPUFREQ
+	select PV_POOL
 	select GENERIC_CLOCKEVENTS
 	select HAVE_SCHED_CLOCK
 	select ARCH_HAS_HOLES_MEMORYMODEL
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index ea5ee4d..ddbd20b 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -39,3 +39,7 @@ config SHARP_PARAM
 
 config SHARP_SCOOP
 	bool
+
+config PV_POOL
+	bool
+	select GENERIC_ALLOCATOR
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e7521bca..b79ad68 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_ARCH_IXP23XX)	+= uengine.o
 obj-$(CONFIG_ARCH_IXP23XX)	+= uengine.o
 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
 obj-$(CONFIG_ARM_TIMER_SP804)	+= timer-sp.o
+obj-$(CONFIG_PV_POOL)		+= pv-pool.o
diff --git a/arch/arm/common/pv-pool.c b/arch/arm/common/pv-pool.c
new file mode 100644
index 0000000..9ff1466
--- /dev/null
+++ b/arch/arm/common/pv-pool.c
@@ -0,0 +1,69 @@
+/*
+ * Unified Phys/Virt allocator, based on mach-davinci/sram.c, which was
+ * Copyright (C) 2009 David Brownell.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/dma-mapping.h>
+#include <linux/genalloc.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+
+#include <asm/pv-pool.h>
+
+struct pv_pool {
+	struct gen_pool *genpool;
+	void *cpu_base;
+	phys_addr_t phys_base;
+};
+
+void *pv_pool_alloc(struct pv_pool *pool, size_t len, phys_addr_t *phys)
+{
+	void *addr = (void *)gen_pool_alloc(pool->genpool, len);
+
+	if (phys)
+		*phys = addr ? (pool->phys_base + (addr - pool->cpu_base)) :
+			 (phys_addr_t)-1ULL;
+
+	return addr;
+}
+EXPORT_SYMBOL_GPL(pv_pool_alloc);
+
+void pv_pool_free(struct pv_pool *pool, void *addr, size_t len)
+{
+	gen_pool_free(pool->genpool, (unsigned long)addr, len);
+}
+EXPORT_SYMBOL_GPL(pv_pool_free);
+
+struct pv_pool *pv_pool_create(void *addr, phys_addr_t phys, size_t len,
+	int min_alloc_order)
+{
+	struct pv_pool *pool = kzalloc(sizeof(struct pv_pool), GFP_KERNEL);
+
+	if (pool) {
+		pool->cpu_base = addr;
+		pool->phys_base = phys;
+		pool->genpool = gen_pool_create(min_alloc_order, -1);
+		if (!pool->genpool) {
+			kfree(pool);
+			pool = NULL;
+		} else {
+			WARN_ON(gen_pool_add(pool->genpool, (unsigned long)addr,
+						len, -1) < 0);
+		}
+	}
+
+	return pool;
+}
+EXPORT_SYMBOL_GPL(pv_pool_create);
+
+void pv_pool_destroy(struct pv_pool *pool)
+{
+	gen_pool_destroy(pool->genpool);
+	kfree(pool);
+}
+EXPORT_SYMBOL_GPL(pv_pool_destroy);
diff --git a/arch/arm/include/asm/pv-pool.h b/arch/arm/include/asm/pv-pool.h
new file mode 100644
index 0000000..b7ae871
--- /dev/null
+++ b/arch/arm/include/asm/pv-pool.h
@@ -0,0 +1,20 @@
+#ifndef __ASMARM_PV_POOL_H
+#define __ASMARM_PV_POOL_H
+
+#include <asm/fncpy.h>
+
+struct pv_pool;
+
+void *pv_pool_alloc(struct pv_pool *, size_t, phys_addr_t *);
+void pv_pool_free(struct pv_pool *, void *, size_t);
+struct pv_pool *pv_pool_create(void *, phys_addr_t, size_t, int);
+void pv_pool_destroy(struct pv_pool *);
+
+/* Macro to copy a function into SRAM, using the fncpy API */
+#define pv_pool_fncpy(pool, funcp, size) ({			\
+	size_t _sz = size;					\
+	void *_sram = pv_pool_alloc(pool, _sz, NULL);		\
+	(_sram ? fncpy(_sram, &(funcp), _sz) : NULL);		\
+})
+
+#endif
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 68fe4c2..5eca128 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
-	.sram_dma		= DA8XX_ARM_RAM_BASE,
+	.sram_phys		= DA8XX_ARM_RAM_BASE,
 	.sram_len		= SZ_8K,
 	.reset_device		= &da8xx_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 76364d1..3df8730 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
 	.serial_dev		= &dm355_serial_device,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 4604e72..d306034 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
 	.serial_dev		= &dm365_serial_device,
 	.emac_pdata		= &dm365_emac_pdata,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..4ca7295 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -764,7 +764,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.gpio_irq		= IRQ_GPIOBNK0,
 	.serial_dev		= &dm644x_serial_device,
 	.emac_pdata		= &dm644x_emac_pdata,
-	.sram_dma		= 0x00008000,
+	.sram_phys		= 0x00008000,
 	.sram_len		= SZ_16K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 1e0f809..a4365f7 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -848,7 +848,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
 	.serial_dev		= &dm646x_serial_device,
 	.emac_pdata		= &dm646x_emac_pdata,
-	.sram_dma		= 0x10010000,
+	.sram_phys		= 0x10010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index a57cba2..665d049 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -75,7 +75,7 @@ struct davinci_soc_info {
 	int				gpio_ctlrs_num;
 	struct platform_device		*serial_dev;
 	struct emac_platform_data	*emac_pdata;
-	dma_addr_t			sram_dma;
+	phys_addr_t			sram_phys;
 	unsigned			sram_len;
 	struct platform_device		*reset_device;
 	void				(*reset)(struct platform_device *);
diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h
index 111f7cc..7d77e85 100644
--- a/arch/arm/mach-davinci/include/mach/sram.h
+++ b/arch/arm/mach-davinci/include/mach/sram.h
@@ -10,18 +10,11 @@
 #ifndef __MACH_SRAM_H
 #define __MACH_SRAM_H
 
+#include <asm/pv-pool.h>
+
 /* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
 #define SRAM_GRANULARITY	512
 
-/*
- * SRAM allocations return a CPU virtual address, or NULL on error.
- * If a DMA address is requested and the SRAM supports DMA, its
- * mapped address is also returned.
- *
- * Errors include SRAM memory not being available, and requesting
- * DMA mapped SRAM on systems which don't allow that.
- */
-extern void *sram_alloc(size_t len, dma_addr_t *dma);
-extern void sram_free(void *addr, size_t len);
+extern struct pv_pool *davinci_pv_pool;
 
 #endif /* __MACH_SRAM_H */
diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index 1bd73a0..f69cd7b 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -29,12 +29,6 @@
 static void (*davinci_sram_suspend) (struct davinci_pm_config *);
 static struct davinci_pm_config *pdata;
 
-static void davinci_sram_push(void *dest, void *src, unsigned int size)
-{
-	memcpy(dest, src, size);
-	flush_icache_range((unsigned long)dest, (unsigned long)(dest + size));
-}
-
 static void davinci_pm_suspend(void)
 {
 	unsigned val;
@@ -123,15 +117,13 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 		return -ENOENT;
 	}
 
-	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
+	davinci_sram_suspend = pv_pool_fncpy(davinci_pv_pool,
+				davinci_cpu_suspend, davinci_cpu_suspend_sz);
 	if (!davinci_sram_suspend) {
 		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
 		return -ENOMEM;
 	}
 
-	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
-						davinci_cpu_suspend_sz);
-
 	suspend_set_ops(&davinci_pm_ops);
 
 	return 0;
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index db0f778..ebd4d67 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -10,40 +10,13 @@
  */
 #include <linux/module.h>
 #include <linux/init.h>
-#include <linux/genalloc.h>
+#include <asm/pv-pool.h>
 
 #include <mach/common.h>
 #include <mach/sram.h>
 
-static struct gen_pool *sram_pool;
-
-void *sram_alloc(size_t len, dma_addr_t *dma)
-{
-	unsigned long vaddr;
-	dma_addr_t dma_base = davinci_soc_info.sram_dma;
-
-	if (dma)
-		*dma = 0;
-	if (!sram_pool || (dma && !dma_base))
-		return NULL;
-
-	vaddr = gen_pool_alloc(sram_pool, len);
-	if (!vaddr)
-		return NULL;
-
-	if (dma)
-		*dma = dma_base + (vaddr - SRAM_VIRT);
-	return (void *)vaddr;
-
-}
-EXPORT_SYMBOL(sram_alloc);
-
-void sram_free(void *addr, size_t len)
-{
-	gen_pool_free(sram_pool, (unsigned long) addr, len);
-}
-EXPORT_SYMBOL(sram_free);
-
+struct pv_pool *davinci_pv_pool;
+EXPORT_SYMBOL_GPL(davinci_pv_pool);
 
 /*
  * REVISIT This supports CPU and DMA access to/from SRAM, but it
@@ -58,13 +31,12 @@ static int __init sram_init(void)
 
 	if (len) {
 		len = min_t(unsigned, len, SRAM_SIZE);
-		sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
-		if (!sram_pool)
+		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
+					davinci_soc_info.sram_phys, len,
+					ilog2(SRAM_GRANULARITY));
+		if (!davinci_pv_pool)
 			status = -ENOMEM;
 	}
-	if (sram_pool)
-		status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
-	WARN_ON(status < 0);
 	return status;
 }
 core_initcall(sram_init);
diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
index b0cb425..f60d5ea 100644
--- a/arch/arm/plat-mxc/Kconfig
+++ b/arch/arm/plat-mxc/Kconfig
@@ -118,6 +118,6 @@ config ARCH_MXC_AUDMUX_V2
 
 config IRAM_ALLOC
 	bool
-	select GENERIC_ALLOCATOR
+	select PV_POOL
 
 endif
diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
index 022690c..543c6df 100644
--- a/arch/arm/plat-mxc/include/mach/iram.h
+++ b/arch/arm/plat-mxc/include/mach/iram.h
@@ -17,25 +17,37 @@
  * MA 02110-1301, USA.
  */
 #include <linux/errno.h>
+#include <asm/pv-pool.h>
 
 #ifdef CONFIG_IRAM_ALLOC
 
-int __init iram_init(unsigned long base, unsigned long size);
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr);
-void iram_free(unsigned long dma_addr, unsigned int size);
+int __init iram_init(phys_addr_t base, size_t size);
+
+extern struct pv_pool *mxc_iram_pool;
+
+static inline void *iram_alloc(size_t size, phys_addr_t *phys)
+{
+	return pv_pool_alloc(iram_pool, size, phys);
+}
+
+static inline void iram_free(void *addr, size_t size)
+{
+	pv_pool_free(iram_pool, addr, size);
+}
 
 #else
 
-static inline int __init iram_init(unsigned long base, unsigned long size)
+static inline int __init iram_init(phys_addr_t base, size_t size)
 {
 	return -ENOMEM;
 }
 
-static inline void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
+static inline void *iram_alloc(size_t size, phys_addr_t *phys)
 {
+	*phys = (phys_addr_t)-1ULL;
 	return NULL;
 }
 
-static inline void iram_free(unsigned long base, unsigned long size) {}
+static inline void iram_free(void *addr, size_t size) {}
 
 #endif
diff --git a/arch/arm/plat-mxc/iram_alloc.c b/arch/arm/plat-mxc/iram_alloc.c
index 074c386..1e3d437 100644
--- a/arch/arm/plat-mxc/iram_alloc.c
+++ b/arch/arm/plat-mxc/iram_alloc.c
@@ -24,50 +24,24 @@
 #include <linux/genalloc.h>
 #include <mach/iram.h>
 
-static unsigned long iram_phys_base;
-static void __iomem *iram_virt_base;
-static struct gen_pool *iram_pool;
+struct pv_pool *mxc_iram_pool;
+EXPORT_SYMBOL(mxc_iram_pool);
 
-static inline void __iomem *iram_phys_to_virt(unsigned long p)
+int __init iram_init(phys_addr_t base, size_t size)
 {
-	return iram_virt_base + (p - iram_phys_base);
-}
-
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
-{
-	if (!iram_pool)
-		return NULL;
-
-	*dma_addr = gen_pool_alloc(iram_pool, size);
-	pr_debug("iram alloc - %dB@0x%lX\n", size, *dma_addr);
-	if (!*dma_addr)
-		return NULL;
-	return iram_phys_to_virt(*dma_addr);
-}
-EXPORT_SYMBOL(iram_alloc);
-
-void iram_free(unsigned long addr, unsigned int size)
-{
-	if (!iram_pool)
-		return;
-
-	gen_pool_free(iram_pool, addr, size);
-}
-EXPORT_SYMBOL(iram_free);
+	void *addr = /*FIXME*/ ioremap(base, size);
 
-int __init iram_init(unsigned long base, unsigned long size)
-{
-	iram_phys_base = base;
+	if (!addr)
+		return -EIO;
 
-	iram_pool = gen_pool_create(PAGE_SHIFT, -1);
-	if (!iram_pool)
+	mxc_iram_pool = pv_pool_create(addr, base, size, PAGE_SHIFT);
+	if (!mxc_iram_pool) {
+		iounmap(addr);
 		return -ENOMEM;
+	}
 
-	gen_pool_add(iram_pool, base, size, -1);
-	iram_virt_base = ioremap(iram_phys_base, size);
-	if (!iram_virt_base)
-		return -EIO;
+	pr_debug("i.MX IRAM pool: %lu KB@0x%08llx\n", size / 1024,
+		 (unsigned long long)base);
 
-	pr_debug("i.MX IRAM pool: %ld KB@0x%p\n", size / 1024, iram_virt_base);
 	return 0;
 }
diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..9fc27d0 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -12,16 +12,19 @@
 #define __ARCH_ARM_OMAP_SRAM_H
 
 #ifndef __ASSEMBLY__
-#include <asm/fncpy.h>
+#include <asm/pv-pool.h>
 
-extern void *omap_sram_push_address(unsigned long size);
+extern struct pv_pool *omap_pv_pool;
 
-/* Macro to push a function to the internal SRAM, using the fncpy API */
+/*
+ * Note that fncpy requires the SRAM address to be aligned to an 8-byte
+ * boundary, so the min_alloc_order for the pool is set appropriately.
+ */
 #define omap_sram_push(funcp, size) ({				\
-	typeof(&(funcp)) _res = NULL;				\
-	void *_sram_address = omap_sram_push_address(size);	\
-	if (_sram_address)					\
-		_res = fncpy(_sram_address, &(funcp), size);	\
+	typeof(&(funcp)) _res;					\
+	_res = pv_pool_fncpy(omap_pv_pool, funcp, size);	\
+	if (!_res)						\
+		pr_err("Not enough space in SRAM\n");		\
 	_res;							\
 })
 
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..3588749 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -75,7 +75,6 @@
 static unsigned long omap_sram_start;
 static unsigned long omap_sram_base;
 static unsigned long omap_sram_size;
-static unsigned long omap_sram_ceil;
 
 /*
  * Depending on the target RAMFS firewall setup, the public usable amount of
@@ -104,6 +103,8 @@ static int is_sram_locked(void)
 		return 1; /* assume locked with no PPA or security driver */
 }
 
+struct pv_pool *omap_pv_pool;
+
 /*
  * The amount of SRAM depends on the core type.
  * Note that we cannot try to test for SRAM here because writes
@@ -182,7 +183,16 @@ static void __init omap_detect_sram(void)
 			omap_sram_size - SRAM_BOOTLOADER_SZ);
 	omap_sram_size -= reserved;
 
-	omap_sram_ceil = omap_sram_base + omap_sram_size;
+	{
+		/* The first SRAM_BOOTLOADER_SZ of SRAM are reserved */
+		void *base = (void *)omap_sram_base + SRAM_BOOTLOADER_SZ;
+		phys_addr_t phys = omap_sram_start + SRAM_BOOTLOADER_SZ;
+		size_t len = omap_sram_size - SRAM_BOOTLOADER_SZ;
+
+		omap_pv_pool = pv_pool_create(base, phys, len,
+						ilog2(FNCPY_ALIGN));
+		WARN_ON(!omap_pv_pool);
+	}
 }
 
 static struct map_desc omap_sram_io_desc[] __initdata = {
@@ -242,26 +252,6 @@ static void __init omap_map_sram(void)
 	       omap_sram_size - SRAM_BOOTLOADER_SZ);
 }
 
-/*
- * Memory allocator for SRAM: calculates the new ceiling address
- * for pushing a function using the fncpy API.
- *
- * Note that fncpy requires the returned address to be aligned
- * to an 8-byte boundary.
- */
-void *omap_sram_push_address(unsigned long size)
-{
-	if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
-		printk(KERN_ERR "Not enough space in SRAM\n");
-		return NULL;
-	}
-
-	omap_sram_ceil -= size;
-	omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, FNCPY_ALIGN);
-
-	return (void *)omap_sram_ceil;
-}
-
 #ifdef CONFIG_ARCH_OMAP1
 
 static void (*_omap_sram_reprogram_clock)(u32 dpllctl, u32 ckctl);
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index daf6e77..2be3155 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -62,7 +62,7 @@ MODULE_PARM_DESC(extram_pool_sz, "external ram pool size to allocate");
 struct uio_pruss_dev {
 	struct uio_info *info;
 	struct clk *pruss_clk;
-	dma_addr_t sram_paddr;
+	phys_addr_t sram_paddr;
 	dma_addr_t ddr_paddr;
 	void __iomem *prussio_vaddr;
 	void *sram_vaddr;
@@ -106,7 +106,7 @@ static void pruss_cleanup(struct platform_device *dev,
 			gdev->ddr_paddr);
 	}
 	if (gdev->sram_vaddr)
-		sram_free(gdev->sram_vaddr, sram_pool_sz);
+		pv_pool_free(davinci_pv_pool, gdev->sram_vaddr, sram_pool_sz);
 	kfree(gdev->info);
 	clk_put(gdev->pruss_clk);
 	kfree(gdev);
@@ -152,7 +152,8 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
+	gdev->sram_vaddr = pv_pool_alloc(davinci_pv_pool, sram_pool_sz,
+					   &(gdev->sram_paddr));
 	if (!gdev->sram_vaddr) {
 		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
 		goto out_free;

[RFC PATCH v2] Consolidate SRAM support

[Russell King - ARM Linux]

This is the second revision of this patch.  I've not moved it out of
ARM yet as I haven't had a positive response from SH yet.

It's now called pv_pool (for phys/virt pool) rather than sram_pool,
and I've included MXC's iram support in this.  Hopefully, if OMAP can
remove the FB stuff from SRAM we can clean the OMAP bits up a little
more.  Neither have I sorted out the last reference to omap_sram_ceil.
Some comments from OMAP people on what's going on there would be good.

On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.
> 
> 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.

 arch/arm/Kconfig                            |    2 +
 arch/arm/common/Kconfig                     |    4 ++
 arch/arm/common/Makefile                    |    1 +
 arch/arm/common/pv-pool.c                   |   69 +++++++++++++++++++++++++++
 arch/arm/include/asm/pv-pool.h              |   20 ++++++++
 arch/arm/mach-davinci/da850.c               |    2 +-
 arch/arm/mach-davinci/dm355.c               |    2 +-
 arch/arm/mach-davinci/dm365.c               |    2 +-
 arch/arm/mach-davinci/dm644x.c              |    2 +-
 arch/arm/mach-davinci/dm646x.c              |    2 +-
 arch/arm/mach-davinci/include/mach/common.h |    2 +-
 arch/arm/mach-davinci/include/mach/sram.h   |   13 +----
 arch/arm/mach-davinci/pm.c                  |   12 +----
 arch/arm/mach-davinci/sram.c                |   42 +++--------------
 arch/arm/plat-mxc/Kconfig                   |    2 +-
 arch/arm/plat-mxc/include/mach/iram.h       |   24 +++++++--
 arch/arm/plat-mxc/iram_alloc.c              |   50 +++++---------------
 arch/arm/plat-omap/include/plat/sram.h      |   17 ++++---
 arch/arm/plat-omap/sram.c                   |   34 +++++---------
 drivers/uio/uio_pruss.c                     |    7 ++-
 20 files changed, 171 insertions(+), 138 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b9f78b..5c3401c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -850,6 +850,7 @@ config ARCH_DAVINCI
 	bool "TI DaVinci"
 	select GENERIC_CLOCKEVENTS
 	select ARCH_REQUIRE_GPIOLIB
+	select PV_POOL
 	select ZONE_DMA
 	select HAVE_IDE
 	select CLKDEV_LOOKUP
@@ -863,6 +864,7 @@ config ARCH_OMAP
 	select HAVE_CLK
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_CPUFREQ
+	select PV_POOL
 	select GENERIC_CLOCKEVENTS
 	select HAVE_SCHED_CLOCK
 	select ARCH_HAS_HOLES_MEMORYMODEL
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index ea5ee4d..ddbd20b 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -39,3 +39,7 @@ config SHARP_PARAM
 
 config SHARP_SCOOP
 	bool
+
+config PV_POOL
+	bool
+	select GENERIC_ALLOCATOR
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e7521bca..b79ad68 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_ARCH_IXP23XX)	+= uengine.o
 obj-$(CONFIG_ARCH_IXP23XX)	+= uengine.o
 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
 obj-$(CONFIG_ARM_TIMER_SP804)	+= timer-sp.o
+obj-$(CONFIG_PV_POOL)		+= pv-pool.o
diff --git a/arch/arm/common/pv-pool.c b/arch/arm/common/pv-pool.c
new file mode 100644
index 0000000..9ff1466
--- /dev/null
+++ b/arch/arm/common/pv-pool.c
@@ -0,0 +1,69 @@
+/*
+ * Unified Phys/Virt allocator, based on mach-davinci/sram.c, which was
+ * Copyright (C) 2009 David Brownell.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/dma-mapping.h>
+#include <linux/genalloc.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+
+#include <asm/pv-pool.h>
+
+struct pv_pool {
+	struct gen_pool *genpool;
+	void *cpu_base;
+	phys_addr_t phys_base;
+};
+
+void *pv_pool_alloc(struct pv_pool *pool, size_t len, phys_addr_t *phys)
+{
+	void *addr = (void *)gen_pool_alloc(pool->genpool, len);
+
+	if (phys)
+		*phys = addr ? (pool->phys_base + (addr - pool->cpu_base)) :
+			 (phys_addr_t)-1ULL;
+
+	return addr;
+}
+EXPORT_SYMBOL_GPL(pv_pool_alloc);
+
+void pv_pool_free(struct pv_pool *pool, void *addr, size_t len)
+{
+	gen_pool_free(pool->genpool, (unsigned long)addr, len);
+}
+EXPORT_SYMBOL_GPL(pv_pool_free);
+
+struct pv_pool *pv_pool_create(void *addr, phys_addr_t phys, size_t len,
+	int min_alloc_order)
+{
+	struct pv_pool *pool = kzalloc(sizeof(struct pv_pool), GFP_KERNEL);
+
+	if (pool) {
+		pool->cpu_base = addr;
+		pool->phys_base = phys;
+		pool->genpool = gen_pool_create(min_alloc_order, -1);
+		if (!pool->genpool) {
+			kfree(pool);
+			pool = NULL;
+		} else {
+			WARN_ON(gen_pool_add(pool->genpool, (unsigned long)addr,
+						len, -1) < 0);
+		}
+	}
+
+	return pool;
+}
+EXPORT_SYMBOL_GPL(pv_pool_create);
+
+void pv_pool_destroy(struct pv_pool *pool)
+{
+	gen_pool_destroy(pool->genpool);
+	kfree(pool);
+}
+EXPORT_SYMBOL_GPL(pv_pool_destroy);
diff --git a/arch/arm/include/asm/pv-pool.h b/arch/arm/include/asm/pv-pool.h
new file mode 100644
index 0000000..b7ae871
--- /dev/null
+++ b/arch/arm/include/asm/pv-pool.h
@@ -0,0 +1,20 @@
+#ifndef __ASMARM_PV_POOL_H
+#define __ASMARM_PV_POOL_H
+
+#include <asm/fncpy.h>
+
+struct pv_pool;
+
+void *pv_pool_alloc(struct pv_pool *, size_t, phys_addr_t *);
+void pv_pool_free(struct pv_pool *, void *, size_t);
+struct pv_pool *pv_pool_create(void *, phys_addr_t, size_t, int);
+void pv_pool_destroy(struct pv_pool *);
+
+/* Macro to copy a function into SRAM, using the fncpy API */
+#define pv_pool_fncpy(pool, funcp, size) ({			\
+	size_t _sz = size;					\
+	void *_sram = pv_pool_alloc(pool, _sz, NULL);		\
+	(_sram ? fncpy(_sram, &(funcp), _sz) : NULL);		\
+})
+
+#endif
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 68fe4c2..5eca128 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
-	.sram_dma		= DA8XX_ARM_RAM_BASE,
+	.sram_phys		= DA8XX_ARM_RAM_BASE,
 	.sram_len		= SZ_8K,
 	.reset_device		= &da8xx_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 76364d1..3df8730 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
 	.serial_dev		= &dm355_serial_device,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 4604e72..d306034 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
 	.serial_dev		= &dm365_serial_device,
 	.emac_pdata		= &dm365_emac_pdata,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..4ca7295 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -764,7 +764,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.gpio_irq		= IRQ_GPIOBNK0,
 	.serial_dev		= &dm644x_serial_device,
 	.emac_pdata		= &dm644x_emac_pdata,
-	.sram_dma		= 0x00008000,
+	.sram_phys		= 0x00008000,
 	.sram_len		= SZ_16K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 1e0f809..a4365f7 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -848,7 +848,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
 	.serial_dev		= &dm646x_serial_device,
 	.emac_pdata		= &dm646x_emac_pdata,
-	.sram_dma		= 0x10010000,
+	.sram_phys		= 0x10010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index a57cba2..665d049 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -75,7 +75,7 @@ struct davinci_soc_info {
 	int				gpio_ctlrs_num;
 	struct platform_device		*serial_dev;
 	struct emac_platform_data	*emac_pdata;
-	dma_addr_t			sram_dma;
+	phys_addr_t			sram_phys;
 	unsigned			sram_len;
 	struct platform_device		*reset_device;
 	void				(*reset)(struct platform_device *);
diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h
index 111f7cc..7d77e85 100644
--- a/arch/arm/mach-davinci/include/mach/sram.h
+++ b/arch/arm/mach-davinci/include/mach/sram.h
@@ -10,18 +10,11 @@
 #ifndef __MACH_SRAM_H
 #define __MACH_SRAM_H
 
+#include <asm/pv-pool.h>
+
 /* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
 #define SRAM_GRANULARITY	512
 
-/*
- * SRAM allocations return a CPU virtual address, or NULL on error.
- * If a DMA address is requested and the SRAM supports DMA, its
- * mapped address is also returned.
- *
- * Errors include SRAM memory not being available, and requesting
- * DMA mapped SRAM on systems which don't allow that.
- */
-extern void *sram_alloc(size_t len, dma_addr_t *dma);
-extern void sram_free(void *addr, size_t len);
+extern struct pv_pool *davinci_pv_pool;
 
 #endif /* __MACH_SRAM_H */
diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index 1bd73a0..f69cd7b 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -29,12 +29,6 @@
 static void (*davinci_sram_suspend) (struct davinci_pm_config *);
 static struct davinci_pm_config *pdata;
 
-static void davinci_sram_push(void *dest, void *src, unsigned int size)
-{
-	memcpy(dest, src, size);
-	flush_icache_range((unsigned long)dest, (unsigned long)(dest + size));
-}
-
 static void davinci_pm_suspend(void)
 {
 	unsigned val;
@@ -123,15 +117,13 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 		return -ENOENT;
 	}
 
-	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
+	davinci_sram_suspend = pv_pool_fncpy(davinci_pv_pool,
+				davinci_cpu_suspend, davinci_cpu_suspend_sz);
 	if (!davinci_sram_suspend) {
 		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
 		return -ENOMEM;
 	}
 
-	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
-						davinci_cpu_suspend_sz);
-
 	suspend_set_ops(&davinci_pm_ops);
 
 	return 0;
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index db0f778..ebd4d67 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -10,40 +10,13 @@
  */
 #include <linux/module.h>
 #include <linux/init.h>
-#include <linux/genalloc.h>
+#include <asm/pv-pool.h>
 
 #include <mach/common.h>
 #include <mach/sram.h>
 
-static struct gen_pool *sram_pool;
-
-void *sram_alloc(size_t len, dma_addr_t *dma)
-{
-	unsigned long vaddr;
-	dma_addr_t dma_base = davinci_soc_info.sram_dma;
-
-	if (dma)
-		*dma = 0;
-	if (!sram_pool || (dma && !dma_base))
-		return NULL;
-
-	vaddr = gen_pool_alloc(sram_pool, len);
-	if (!vaddr)
-		return NULL;
-
-	if (dma)
-		*dma = dma_base + (vaddr - SRAM_VIRT);
-	return (void *)vaddr;
-
-}
-EXPORT_SYMBOL(sram_alloc);
-
-void sram_free(void *addr, size_t len)
-{
-	gen_pool_free(sram_pool, (unsigned long) addr, len);
-}
-EXPORT_SYMBOL(sram_free);
-
+struct pv_pool *davinci_pv_pool;
+EXPORT_SYMBOL_GPL(davinci_pv_pool);
 
 /*
  * REVISIT This supports CPU and DMA access to/from SRAM, but it
@@ -58,13 +31,12 @@ static int __init sram_init(void)
 
 	if (len) {
 		len = min_t(unsigned, len, SRAM_SIZE);
-		sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
-		if (!sram_pool)
+		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
+					davinci_soc_info.sram_phys, len,
+					ilog2(SRAM_GRANULARITY));
+		if (!davinci_pv_pool)
 			status = -ENOMEM;
 	}
-	if (sram_pool)
-		status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
-	WARN_ON(status < 0);
 	return status;
 }
 core_initcall(sram_init);
diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
index b0cb425..f60d5ea 100644
--- a/arch/arm/plat-mxc/Kconfig
+++ b/arch/arm/plat-mxc/Kconfig
@@ -118,6 +118,6 @@ config ARCH_MXC_AUDMUX_V2
 
 config IRAM_ALLOC
 	bool
-	select GENERIC_ALLOCATOR
+	select PV_POOL
 
 endif
diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
index 022690c..543c6df 100644
--- a/arch/arm/plat-mxc/include/mach/iram.h
+++ b/arch/arm/plat-mxc/include/mach/iram.h
@@ -17,25 +17,37 @@
  * MA 02110-1301, USA.
  */
 #include <linux/errno.h>
+#include <asm/pv-pool.h>
 
 #ifdef CONFIG_IRAM_ALLOC
 
-int __init iram_init(unsigned long base, unsigned long size);
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr);
-void iram_free(unsigned long dma_addr, unsigned int size);
+int __init iram_init(phys_addr_t base, size_t size);
+
+extern struct pv_pool *mxc_iram_pool;
+
+static inline void *iram_alloc(size_t size, phys_addr_t *phys)
+{
+	return pv_pool_alloc(iram_pool, size, phys);
+}
+
+static inline void iram_free(void *addr, size_t size)
+{
+	pv_pool_free(iram_pool, addr, size);
+}
 
 #else
 
-static inline int __init iram_init(unsigned long base, unsigned long size)
+static inline int __init iram_init(phys_addr_t base, size_t size)
 {
 	return -ENOMEM;
 }
 
-static inline void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
+static inline void *iram_alloc(size_t size, phys_addr_t *phys)
 {
+	*phys = (phys_addr_t)-1ULL;
 	return NULL;
 }
 
-static inline void iram_free(unsigned long base, unsigned long size) {}
+static inline void iram_free(void *addr, size_t size) {}
 
 #endif
diff --git a/arch/arm/plat-mxc/iram_alloc.c b/arch/arm/plat-mxc/iram_alloc.c
index 074c386..1e3d437 100644
--- a/arch/arm/plat-mxc/iram_alloc.c
+++ b/arch/arm/plat-mxc/iram_alloc.c
@@ -24,50 +24,24 @@
 #include <linux/genalloc.h>
 #include <mach/iram.h>
 
-static unsigned long iram_phys_base;
-static void __iomem *iram_virt_base;
-static struct gen_pool *iram_pool;
+struct pv_pool *mxc_iram_pool;
+EXPORT_SYMBOL(mxc_iram_pool);
 
-static inline void __iomem *iram_phys_to_virt(unsigned long p)
+int __init iram_init(phys_addr_t base, size_t size)
 {
-	return iram_virt_base + (p - iram_phys_base);
-}
-
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
-{
-	if (!iram_pool)
-		return NULL;
-
-	*dma_addr = gen_pool_alloc(iram_pool, size);
-	pr_debug("iram alloc - %dB at 0x%lX\n", size, *dma_addr);
-	if (!*dma_addr)
-		return NULL;
-	return iram_phys_to_virt(*dma_addr);
-}
-EXPORT_SYMBOL(iram_alloc);
-
-void iram_free(unsigned long addr, unsigned int size)
-{
-	if (!iram_pool)
-		return;
-
-	gen_pool_free(iram_pool, addr, size);
-}
-EXPORT_SYMBOL(iram_free);
+	void *addr = /*FIXME*/ ioremap(base, size);
 
-int __init iram_init(unsigned long base, unsigned long size)
-{
-	iram_phys_base = base;
+	if (!addr)
+		return -EIO;
 
-	iram_pool = gen_pool_create(PAGE_SHIFT, -1);
-	if (!iram_pool)
+	mxc_iram_pool = pv_pool_create(addr, base, size, PAGE_SHIFT);
+	if (!mxc_iram_pool) {
+		iounmap(addr);
 		return -ENOMEM;
+	}
 
-	gen_pool_add(iram_pool, base, size, -1);
-	iram_virt_base = ioremap(iram_phys_base, size);
-	if (!iram_virt_base)
-		return -EIO;
+	pr_debug("i.MX IRAM pool: %lu KB at 0x%08llx\n", size / 1024,
+		 (unsigned long long)base);
 
-	pr_debug("i.MX IRAM pool: %ld KB at 0x%p\n", size / 1024, iram_virt_base);
 	return 0;
 }
diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..9fc27d0 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -12,16 +12,19 @@
 #define __ARCH_ARM_OMAP_SRAM_H
 
 #ifndef __ASSEMBLY__
-#include <asm/fncpy.h>
+#include <asm/pv-pool.h>
 
-extern void *omap_sram_push_address(unsigned long size);
+extern struct pv_pool *omap_pv_pool;
 
-/* Macro to push a function to the internal SRAM, using the fncpy API */
+/*
+ * Note that fncpy requires the SRAM address to be aligned to an 8-byte
+ * boundary, so the min_alloc_order for the pool is set appropriately.
+ */
 #define omap_sram_push(funcp, size) ({				\
-	typeof(&(funcp)) _res = NULL;				\
-	void *_sram_address = omap_sram_push_address(size);	\
-	if (_sram_address)					\
-		_res = fncpy(_sram_address, &(funcp), size);	\
+	typeof(&(funcp)) _res;					\
+	_res = pv_pool_fncpy(omap_pv_pool, funcp, size);	\
+	if (!_res)						\
+		pr_err("Not enough space in SRAM\n");		\
 	_res;							\
 })
 
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..3588749 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -75,7 +75,6 @@
 static unsigned long omap_sram_start;
 static unsigned long omap_sram_base;
 static unsigned long omap_sram_size;
-static unsigned long omap_sram_ceil;
 
 /*
  * Depending on the target RAMFS firewall setup, the public usable amount of
@@ -104,6 +103,8 @@ static int is_sram_locked(void)
 		return 1; /* assume locked with no PPA or security driver */
 }
 
+struct pv_pool *omap_pv_pool;
+
 /*
  * The amount of SRAM depends on the core type.
  * Note that we cannot try to test for SRAM here because writes
@@ -182,7 +183,16 @@ static void __init omap_detect_sram(void)
 			omap_sram_size - SRAM_BOOTLOADER_SZ);
 	omap_sram_size -= reserved;
 
-	omap_sram_ceil = omap_sram_base + omap_sram_size;
+	{
+		/* The first SRAM_BOOTLOADER_SZ of SRAM are reserved */
+		void *base = (void *)omap_sram_base + SRAM_BOOTLOADER_SZ;
+		phys_addr_t phys = omap_sram_start + SRAM_BOOTLOADER_SZ;
+		size_t len = omap_sram_size - SRAM_BOOTLOADER_SZ;
+
+		omap_pv_pool = pv_pool_create(base, phys, len,
+						ilog2(FNCPY_ALIGN));
+		WARN_ON(!omap_pv_pool);
+	}
 }
 
 static struct map_desc omap_sram_io_desc[] __initdata = {
@@ -242,26 +252,6 @@ static void __init omap_map_sram(void)
 	       omap_sram_size - SRAM_BOOTLOADER_SZ);
 }
 
-/*
- * Memory allocator for SRAM: calculates the new ceiling address
- * for pushing a function using the fncpy API.
- *
- * Note that fncpy requires the returned address to be aligned
- * to an 8-byte boundary.
- */
-void *omap_sram_push_address(unsigned long size)
-{
-	if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
-		printk(KERN_ERR "Not enough space in SRAM\n");
-		return NULL;
-	}
-
-	omap_sram_ceil -= size;
-	omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, FNCPY_ALIGN);
-
-	return (void *)omap_sram_ceil;
-}
-
 #ifdef CONFIG_ARCH_OMAP1
 
 static void (*_omap_sram_reprogram_clock)(u32 dpllctl, u32 ckctl);
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index daf6e77..2be3155 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -62,7 +62,7 @@ MODULE_PARM_DESC(extram_pool_sz, "external ram pool size to allocate");
 struct uio_pruss_dev {
 	struct uio_info *info;
 	struct clk *pruss_clk;
-	dma_addr_t sram_paddr;
+	phys_addr_t sram_paddr;
 	dma_addr_t ddr_paddr;
 	void __iomem *prussio_vaddr;
 	void *sram_vaddr;
@@ -106,7 +106,7 @@ static void pruss_cleanup(struct platform_device *dev,
 			gdev->ddr_paddr);
 	}
 	if (gdev->sram_vaddr)
-		sram_free(gdev->sram_vaddr, sram_pool_sz);
+		pv_pool_free(davinci_pv_pool, gdev->sram_vaddr, sram_pool_sz);
 	kfree(gdev->info);
 	clk_put(gdev->pruss_clk);
 	kfree(gdev);
@@ -152,7 +152,8 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
+	gdev->sram_vaddr = pv_pool_alloc(davinci_pv_pool, sram_pool_sz,
+					   &(gdev->sram_paddr));
 	if (!gdev->sram_vaddr) {
 		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
 		goto out_free;

Re: [RFC PATCH v2] Consolidate SRAM support

[Haojian Zhuang]

On Mon, Apr 18, 2011 at 4:52 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> This is the second revision of this patch.  I've not moved it out of
> ARM yet as I haven't had a positive response from SH yet.
>
> It's now called pv_pool (for phys/virt pool) rather than sram_pool,
> and I've included MXC's iram support in this.  Hopefully, if OMAP can
> remove the FB stuff from SRAM we can clean the OMAP bits up a little
> more.  Neither have I sorted out the last reference to omap_sram_ceil.
> Some comments from OMAP people on what's going on there would be good.
>
> On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.
>>
>> 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.
>>
Multiple SRAM pool does exist in Marvell MMP2 silicon. So it won't be
overdesign.

>> Lastly, uio_pruss should probably take the SRAM pool pointer via
>> platform data so that it doesn't have to include Davinci specific
>> includes.
>
--
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

[RFC PATCH v2] Consolidate SRAM support

[Haojian Zhuang]

On Mon, Apr 18, 2011 at 4:52 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> This is the second revision of this patch. ?I've not moved it out of
> ARM yet as I haven't had a positive response from SH yet.
>
> It's now called pv_pool (for phys/virt pool) rather than sram_pool,
> and I've included MXC's iram support in this. ?Hopefully, if OMAP can
> remove the FB stuff from SRAM we can clean the OMAP bits up a little
> more. ?Neither have I sorted out the last reference to omap_sram_ceil.
> Some comments from OMAP people on what's going on there would be good.
>
> On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.
>>
>> 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.
>>
Multiple SRAM pool does exist in Marvell MMP2 silicon. So it won't be
overdesign.

>> Lastly, uio_pruss should probably take the SRAM pool pointer via
>> platform data so that it doesn't have to include Davinci specific
>> includes.
>

Re: [RFC PATCH v2] Consolidate SRAM support

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110418 11:50]:
> This is the second revision of this patch.  I've not moved it out of
> ARM yet as I haven't had a positive response from SH yet.
> 
> It's now called pv_pool (for phys/virt pool) rather than sram_pool,
> and I've included MXC's iram support in this.  Hopefully, if OMAP can
> remove the FB stuff from SRAM we can clean the OMAP bits up a little
> more.  Neither have I sorted out the last reference to omap_sram_ceil.
> Some comments from OMAP people on what's going on there would be good.

I believe the omap_sram_ceil should also disappear with the omapfb
SRAM patch.

Tony

[RFC PATCH v2] Consolidate SRAM support

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110418 11:50]:
> This is the second revision of this patch.  I've not moved it out of
> ARM yet as I haven't had a positive response from SH yet.
> 
> It's now called pv_pool (for phys/virt pool) rather than sram_pool,
> and I've included MXC's iram support in this.  Hopefully, if OMAP can
> remove the FB stuff from SRAM we can clean the OMAP bits up a little
> more.  Neither have I sorted out the last reference to omap_sram_ceil.
> Some comments from OMAP people on what's going on there would be good.

I believe the omap_sram_ceil should also disappear with the omapfb
SRAM patch.

Tony

Re: [RFC PATCH v2] Consolidate SRAM support

[Detlef Vollmann]

On 04/18/11 10:52, Russell King - ARM Linux wrote:
> This is the second revision of this patch.
Thanks, looks good :-)

Just to minor issues:

> diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
> index ea5ee4d..ddbd20b 100644
> --- a/arch/arm/common/Kconfig
> +++ b/arch/arm/common/Kconfig
> @@ -39,3 +39,7 @@ config SHARP_PARAM
>
>   config SHARP_SCOOP
>   	bool
> +
> +config PV_POOL
> +	bool
Could you add a prompt here, so that this gets selectable on machs
that don't automatically select it?

> diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> index db0f778..ebd4d67 100644
> --- a/arch/arm/mach-davinci/sram.c
> +++ b/arch/arm/mach-davinci/sram.c
> @@ -10,40 +10,13 @@
> +struct pv_pool *davinci_pv_pool;
> +EXPORT_SYMBOL_GPL(davinci_pv_pool);
>
>   /*
>    * REVISIT This supports CPU and DMA access to/from SRAM, but it
This comment here doesn't look correct anymore.
Maybe it should be removed completely.

   Detlef

[RFC PATCH v2] Consolidate SRAM support

[Detlef Vollmann]

On 04/18/11 10:52, Russell King - ARM Linux wrote:
> This is the second revision of this patch.
Thanks, looks good :-)

Just to minor issues:

> diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
> index ea5ee4d..ddbd20b 100644
> --- a/arch/arm/common/Kconfig
> +++ b/arch/arm/common/Kconfig
> @@ -39,3 +39,7 @@ config SHARP_PARAM
>
>   config SHARP_SCOOP
>   	bool
> +
> +config PV_POOL
> +	bool
Could you add a prompt here, so that this gets selectable on machs
that don't automatically select it?

> diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> index db0f778..ebd4d67 100644
> --- a/arch/arm/mach-davinci/sram.c
> +++ b/arch/arm/mach-davinci/sram.c
> @@ -10,40 +10,13 @@
> +struct pv_pool *davinci_pv_pool;
> +EXPORT_SYMBOL_GPL(davinci_pv_pool);
>
>   /*
>    * REVISIT This supports CPU and DMA access to/from SRAM, but it
This comment here doesn't look correct anymore.
Maybe it should be removed completely.

   Detlef

RE: [RFC PATCH v2] Consolidate SRAM support

[Nori, Sekhar]

Hi Russell,

On Mon, Apr 18, 2011 at 14:22:59, Russell King - ARM Linux wrote:
> This is the second revision of this patch.  I've not moved it out of
> ARM yet as I haven't had a positive response from SH yet.

I was able to test this on DaVinci (DA850 suspend-to-RAM) with
the following additional changes:

There was a sram_free call remaining in pm.c file.

diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index 06eb0ff..0068e41 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -131,7 +131,8 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 
 static int __exit davinci_pm_remove(struct platform_device *pdev)
 {
-	sram_free(davinci_sram_suspend, davinci_cpu_suspend_sz);
+	pv_pool_free(davinci_pv_pool, davinci_sram_suspend,
+					davinci_cpu_suspend_sz);
 	return 0;
 }

The cpu suspend code on DaVinci was not aligned 8 to bytes
and so the fncpy function was throwing a bug.

diff --git a/arch/arm/mach-davinci/sleep.S b/arch/arm/mach-davinci/sleep.S
index fb5e72b..dcb8e9d 100644
--- a/arch/arm/mach-davinci/sleep.S
+++ b/arch/arm/mach-davinci/sleep.S
@@ -50,6 +50,8 @@
  * 	r4: contains virtual address of the DEEPSLEEP register
  */
 ENTRY(davinci_cpu_suspend)
+	.align 3
+
 	stmfd	sp!, {r0-r12, lr}		@ save registers on stack
 
 	ldr 	ip, CACHE_FLUSH

> > Lastly, uio_pruss should probably take the SRAM pool pointer via
> > platform data so that it doesn't have to include Davinci specific
> > includes.
> 
>  arch/arm/Kconfig                            |    2 +
>  arch/arm/common/Kconfig                     |    4 ++
>  arch/arm/common/Makefile                    |    1 +
>  arch/arm/common/pv-pool.c                   |   69 +++++++++++++++++++++++++++
>  arch/arm/include/asm/pv-pool.h              |   20 ++++++++
>  arch/arm/mach-davinci/da850.c               |    2 +-
>  arch/arm/mach-davinci/dm355.c               |    2 +-
>  arch/arm/mach-davinci/dm365.c               |    2 +-
>  arch/arm/mach-davinci/dm644x.c              |    2 +-
>  arch/arm/mach-davinci/dm646x.c              |    2 +-
>  arch/arm/mach-davinci/include/mach/common.h |    2 +-
>  arch/arm/mach-davinci/include/mach/sram.h   |   13 +----
>  arch/arm/mach-davinci/pm.c                  |   12 +----
>  arch/arm/mach-davinci/sram.c                |   42 +++--------------
>  arch/arm/plat-mxc/Kconfig                   |    2 +-
>  arch/arm/plat-mxc/include/mach/iram.h       |   24 +++++++--
>  arch/arm/plat-mxc/iram_alloc.c              |   50 +++++---------------
>  arch/arm/plat-omap/include/plat/sram.h      |   17 ++++---
>  arch/arm/plat-omap/sram.c                   |   34 +++++---------
>  drivers/uio/uio_pruss.c                     |    7 ++-
>  20 files changed, 171 insertions(+), 138 deletions(-)

The davinci audio driver in sound/soc/davinci/davinci-pcm.c uses
the sram allocator too and would need to be converted to the
new API.

Thanks,
Sekhar

[RFC PATCH v2] Consolidate SRAM support

[Nori, Sekhar]

Hi Russell,

On Mon, Apr 18, 2011 at 14:22:59, Russell King - ARM Linux wrote:
> This is the second revision of this patch.  I've not moved it out of
> ARM yet as I haven't had a positive response from SH yet.

I was able to test this on DaVinci (DA850 suspend-to-RAM) with
the following additional changes:

There was a sram_free call remaining in pm.c file.

diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index 06eb0ff..0068e41 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -131,7 +131,8 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 
 static int __exit davinci_pm_remove(struct platform_device *pdev)
 {
-	sram_free(davinci_sram_suspend, davinci_cpu_suspend_sz);
+	pv_pool_free(davinci_pv_pool, davinci_sram_suspend,
+					davinci_cpu_suspend_sz);
 	return 0;
 }

The cpu suspend code on DaVinci was not aligned 8 to bytes
and so the fncpy function was throwing a bug.

diff --git a/arch/arm/mach-davinci/sleep.S b/arch/arm/mach-davinci/sleep.S
index fb5e72b..dcb8e9d 100644
--- a/arch/arm/mach-davinci/sleep.S
+++ b/arch/arm/mach-davinci/sleep.S
@@ -50,6 +50,8 @@
  * 	r4: contains virtual address of the DEEPSLEEP register
  */
 ENTRY(davinci_cpu_suspend)
+	.align 3
+
 	stmfd	sp!, {r0-r12, lr}		@ save registers on stack
 
 	ldr 	ip, CACHE_FLUSH

> > Lastly, uio_pruss should probably take the SRAM pool pointer via
> > platform data so that it doesn't have to include Davinci specific
> > includes.
> 
>  arch/arm/Kconfig                            |    2 +
>  arch/arm/common/Kconfig                     |    4 ++
>  arch/arm/common/Makefile                    |    1 +
>  arch/arm/common/pv-pool.c                   |   69 +++++++++++++++++++++++++++
>  arch/arm/include/asm/pv-pool.h              |   20 ++++++++
>  arch/arm/mach-davinci/da850.c               |    2 +-
>  arch/arm/mach-davinci/dm355.c               |    2 +-
>  arch/arm/mach-davinci/dm365.c               |    2 +-
>  arch/arm/mach-davinci/dm644x.c              |    2 +-
>  arch/arm/mach-davinci/dm646x.c              |    2 +-
>  arch/arm/mach-davinci/include/mach/common.h |    2 +-
>  arch/arm/mach-davinci/include/mach/sram.h   |   13 +----
>  arch/arm/mach-davinci/pm.c                  |   12 +----
>  arch/arm/mach-davinci/sram.c                |   42 +++--------------
>  arch/arm/plat-mxc/Kconfig                   |    2 +-
>  arch/arm/plat-mxc/include/mach/iram.h       |   24 +++++++--
>  arch/arm/plat-mxc/iram_alloc.c              |   50 +++++---------------
>  arch/arm/plat-omap/include/plat/sram.h      |   17 ++++---
>  arch/arm/plat-omap/sram.c                   |   34 +++++---------
>  drivers/uio/uio_pruss.c                     |    7 ++-
>  20 files changed, 171 insertions(+), 138 deletions(-)

The davinci audio driver in sound/soc/davinci/davinci-pcm.c uses
the sram allocator too and would need to be converted to the
new API.

Thanks,
Sekhar

Re: [RFC PATCH v2] Consolidate SRAM support

[Russell King - ARM Linux]

On Mon, Apr 18, 2011 at 09:42:10PM +0530, Nori, Sekhar wrote:
> I was able to test this on DaVinci (DA850 suspend-to-RAM) with
> the following additional changes:
> 
> There was a sram_free call remaining in pm.c file.

Hmm, wonder why my build for DaVinci didn't pick that up.  Thanks for
that and I'll merge it in.

> diff --git a/arch/arm/mach-davinci/sleep.S b/arch/arm/mach-davinci/sleep.S
> index fb5e72b..dcb8e9d 100644
> --- a/arch/arm/mach-davinci/sleep.S
> +++ b/arch/arm/mach-davinci/sleep.S
> @@ -50,6 +50,8 @@
>   * 	r4: contains virtual address of the DEEPSLEEP register
>   */
>  ENTRY(davinci_cpu_suspend)
> +	.align 3
> +

I think you want the .align 3 on the line before ENTRY().

> The davinci audio driver in sound/soc/davinci/davinci-pcm.c uses
> the sram allocator too and would need to be converted to the
> new API.

Ah, right - I'll sort that too.  Slightly annoying that sound stuff
is outside the drivers/ subdir.

[RFC PATCH v2] Consolidate SRAM support

[Russell King - ARM Linux]

On Mon, Apr 18, 2011 at 09:42:10PM +0530, Nori, Sekhar wrote:
> I was able to test this on DaVinci (DA850 suspend-to-RAM) with
> the following additional changes:
> 
> There was a sram_free call remaining in pm.c file.

Hmm, wonder why my build for DaVinci didn't pick that up.  Thanks for
that and I'll merge it in.

> diff --git a/arch/arm/mach-davinci/sleep.S b/arch/arm/mach-davinci/sleep.S
> index fb5e72b..dcb8e9d 100644
> --- a/arch/arm/mach-davinci/sleep.S
> +++ b/arch/arm/mach-davinci/sleep.S
> @@ -50,6 +50,8 @@
>   * 	r4: contains virtual address of the DEEPSLEEP register
>   */
>  ENTRY(davinci_cpu_suspend)
> +	.align 3
> +

I think you want the .align 3 on the line before ENTRY().

> The davinci audio driver in sound/soc/davinci/davinci-pcm.c uses
> the sram allocator too and would need to be converted to the
> new API.

Ah, right - I'll sort that too.  Slightly annoying that sound stuff
is outside the drivers/ subdir.

Re: [RFC PATCH] Consolidate SRAM support

[Linus Walleij]

2011/4/15 Russell King - ARM Linux <linux@arm.linux.org.uk>:

> 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.

Great initiative!

I'm thinking about how to unify this with the bits I have in kernel/tcm.c.

For TCM memory (cacheless, inside CPU core, controlled by CP15
registers to recap) we can compile plain C into that memory too, which
seems like a lot of these SRAM drivers actually want to do, but fail at
and instead write some assembler and copy it there.

The remainder of the TCM memory is put into an allocation pool
of uneven size, maybe that should reuse this mechanism instead
of rolling its own atleast.

On the odd PB11MPCore the TCM memories are NUMA, so one
on each CPU not reachable from other cores (like Magnus Damm
mentioned for SH-ARM) and I have no idea on how to handle that,
neither for an allocator nor for compiling code directly into it.
Suggestions welcome.

Linus Walleij

[RFC PATCH] Consolidate SRAM support

[Linus Walleij]

2011/4/15 Russell King - ARM Linux <linux@arm.linux.org.uk>:

> 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.

Great initiative!

I'm thinking about how to unify this with the bits I have in kernel/tcm.c.

For TCM memory (cacheless, inside CPU core, controlled by CP15
registers to recap) we can compile plain C into that memory too, which
seems like a lot of these SRAM drivers actually want to do, but fail at
and instead write some assembler and copy it there.

The remainder of the TCM memory is put into an allocation pool
of uneven size, maybe that should reuse this mechanism instead
of rolling its own atleast.

On the odd PB11MPCore the TCM memories are NUMA, so one
on each CPU not reachable from other cores (like Magnus Damm
mentioned for SH-ARM) and I have no idea on how to handle that,
neither for an allocator nor for compiling code directly into it.
Suggestions welcome.

Linus Walleij

Re: [RFC PATCH] Consolidate SRAM support

[Tomi Valkeinen]

Hi Tony and Russell,

On Mon, 2011-04-18 at 11:17 +0300, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [110418 09:57]:

> > So, I can make a patch that removes the SRAM support from omapfb, and
> > queue it up for the next merge window.
> 
> OK. That patch should probably go into Russell's tree along with
> other SRAM related patches to avoid conflicts.

Here's a simple patch to remove SRAM support from omapfb. Or more
precisely, this just disables it.

I started to remove the SRAM support from the drivers, but the patches
got quite big and will probably cause conflicts if they reside in
somebody else's tree than mine. So I believe it's easiest to divide SRAM
FB removal into this patch, handled by Russell (?), and then the rest,
handled by me.

Is there something else related to OMAP FB than the code removed in this
patch that is hindering the SRAM work?

 Tomi


>From 8a32eb1762d9ecead1aee08cbe955748d67999fd Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Tue, 19 Apr 2011 16:58:51 +0300
Subject: [PATCH] OMAP: Remove reserve_sram calls to omapfb

This patch removes calls from arch/arm/plat-omap/sram.c to
omapfb_reserve_sram() and omap_vram_reserve_sram(), effectively
disabling SRAM support for the old and new display drivers.

SRAM code in the display drivers will be removed in separate patches.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/plat-omap/sram.c |   13 -------------
 1 files changed, 0 insertions(+), 13 deletions(-)

diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..e10eeed 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -19,7 +19,6 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
-#include <linux/omapfb.h>
 
 #include <asm/tlb.h>
 #include <asm/cacheflush.h>
@@ -32,7 +31,6 @@
 #include <plat/vram.h>
 
 #include "sram.h"
-#include "fb.h"
 
 /* XXX These "sideways" includes are a sign that something is wrong */
 #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
@@ -170,17 +168,6 @@ static void __init omap_detect_sram(void)
 			omap_sram_size = 0x4000;
 		}
 	}
-	reserved = omapfb_reserve_sram(omap_sram_start, omap_sram_base,
-				       omap_sram_size,
-				       omap_sram_start + SRAM_BOOTLOADER_SZ,
-				       omap_sram_size - SRAM_BOOTLOADER_SZ);
-	omap_sram_size -= reserved;
-
-	reserved = omap_vram_reserve_sram(omap_sram_start, omap_sram_base,
-			omap_sram_size,
-			omap_sram_start + SRAM_BOOTLOADER_SZ,
-			omap_sram_size - SRAM_BOOTLOADER_SZ);
-	omap_sram_size -= reserved;
 
 	omap_sram_ceil = omap_sram_base + omap_sram_size;
 }
-- 
1.7.1

[RFC PATCH] Consolidate SRAM support

[Tomi Valkeinen]

Hi Tony and Russell,

On Mon, 2011-04-18 at 11:17 +0300, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [110418 09:57]:

> > So, I can make a patch that removes the SRAM support from omapfb, and
> > queue it up for the next merge window.
> 
> OK. That patch should probably go into Russell's tree along with
> other SRAM related patches to avoid conflicts.

Here's a simple patch to remove SRAM support from omapfb. Or more
precisely, this just disables it.

I started to remove the SRAM support from the drivers, but the patches
got quite big and will probably cause conflicts if they reside in
somebody else's tree than mine. So I believe it's easiest to divide SRAM
FB removal into this patch, handled by Russell (?), and then the rest,
handled by me.

Is there something else related to OMAP FB than the code removed in this
patch that is hindering the SRAM work?

 Tomi

Re: [RFC PATCH v2] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

Hi,

	I do post a patch to add the support to specify a virt and phys
	address to the generic allocator so the pv-pool.c is not needed
	we can just use the generic fucntion

	I'll post a v3 updated again it

Best Regards,
J.
> --- /dev/null > +++ b/arch/arm/common/pv-pool.c
> @@ -0,0 +1,69 @@
> +/*
> + * Unified Phys/Virt allocator, based on mach-davinci/sram.c, which was
> + * Copyright (C) 2009 David Brownell.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include <linux/dma-mapping.h>
> +#include <linux/genalloc.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +
> +#include <asm/pv-pool.h>
> +
> +struct pv_pool {
> +	struct gen_pool *genpool;
> +	void *cpu_base;
> +	phys_addr_t phys_base;
> +};
> +
> +void *pv_pool_alloc(struct pv_pool *pool, size_t len, phys_addr_t *phys)
> +{
> +	void *addr = (void *)gen_pool_alloc(pool->genpool, len);
> +
> +	if (phys)
> +		*phys = addr ? (pool->phys_base + (addr - pool->cpu_base)) :
> +			 (phys_addr_t)-1ULL;
> +
> +	return addr;
> +}
> +EXPORT_SYMBOL_GPL(pv_pool_alloc);
> +
> +void pv_pool_free(struct pv_pool *pool, void *addr, size_t len)
> +{
> +	gen_pool_free(pool->genpool, (unsigned long)addr, len);
> +}
> +EXPORT_SYMBOL_GPL(pv_pool_free);
> +
> +struct pv_pool *pv_pool_create(void *addr, phys_addr_t phys, size_t len,
> +	int min_alloc_order)
> +{
> +	struct pv_pool *pool = kzalloc(sizeof(struct pv_pool), GFP_KERNEL);
> +
> +	if (pool) {
> +		pool->cpu_base = addr;
> +		pool->phys_base = phys;
> +		pool->genpool = gen_pool_create(min_alloc_order, -1);
> +		if (!pool->genpool) {
> +			kfree(pool);
> +			pool = NULL;
> +		} else {
> +			WARN_ON(gen_pool_add(pool->genpool, (unsigned long)addr,
> +						len, -1) < 0);
> +		}
> +	}
> +
> +	return pool;
> +}
> +EXPORT_SYMBOL_GPL(pv_pool_create);
> +
> +void pv_pool_destroy(struct pv_pool *pool)
> +{
> +	gen_pool_destroy(pool->genpool);
> +	kfree(pool);
> +}
> +EXPORT_SYMBOL_GPL(pv_pool_destroy);
> diff --git a/arch/arm/include/asm/pv-pool.h b/arch/arm/include/asm/pv-pool.h
> new file mode 100644
> index 0000000..b7ae871
> --- /dev/null
> +++ b/arch/arm/include/asm/pv-pool.h
> @@ -0,0 +1,20 @@
> +#ifndef __ASMARM_PV_POOL_H
> +#define __ASMARM_PV_POOL_H
> +
> +#include <asm/fncpy.h>
> +
> +struct pv_pool;
> +
> +void *pv_pool_alloc(struct pv_pool *, size_t, phys_addr_t *);
> +void pv_pool_free(struct pv_pool *, void *, size_t);
> +struct pv_pool *pv_pool_create(void *, phys_addr_t, size_t, int);
> +void pv_pool_destroy(struct pv_pool *);
> +
> +/* Macro to copy a function into SRAM, using the fncpy API */
> +#define pv_pool_fncpy(pool, funcp, size) ({			\
> +	size_t _sz = size;					\
> +	void *_sram = pv_pool_alloc(pool, _sz, NULL);		\
> +	(_sram ? fncpy(_sram, &(funcp), _sz) : NULL);		\
> +})
> +
> +#endif
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 68fe4c2..5eca128 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
>  	.gpio_irq		= IRQ_DA8XX_GPIO0,
>  	.serial_dev		= &da8xx_serial_device,
>  	.emac_pdata		= &da8xx_emac_pdata,
> -	.sram_dma		= DA8XX_ARM_RAM_BASE,
> +	.sram_phys		= DA8XX_ARM_RAM_BASE,
>  	.sram_len		= SZ_8K,
>  	.reset_device		= &da8xx_wdt_device,
>  };
> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
> index 76364d1..3df8730 100644
> --- a/arch/arm/mach-davinci/dm355.c
> +++ b/arch/arm/mach-davinci/dm355.c
> @@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
>  	.gpio_num		= 104,
>  	.gpio_irq		= IRQ_DM355_GPIOBNK0,
>  	.serial_dev		= &dm355_serial_device,
> -	.sram_dma		= 0x00010000,
> +	.sram_phys		= 0x00010000,
>  	.sram_len		= SZ_32K,
>  	.reset_device		= &davinci_wdt_device,
>  };
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index 4604e72..d306034 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
>  	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
>  	.serial_dev		= &dm365_serial_device,
>  	.emac_pdata		= &dm365_emac_pdata,
> -	.sram_dma		= 0x00010000,
> +	.sram_phys		= 0x00010000,
>  	.sram_len		= SZ_32K,
>  	.reset_device		= &davinci_wdt_device,
>  };
> diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
> index 9a2376b..4ca7295 100644
> --- a/arch/arm/mach-davinci/dm644x.c
> +++ b/arch/arm/mach-davinci/dm644x.c
> @@ -764,7 +764,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
>  	.gpio_irq		= IRQ_GPIOBNK0,
>  	.serial_dev		= &dm644x_serial_device,
>  	.emac_pdata		= &dm644x_emac_pdata,
> -	.sram_dma		= 0x00008000,
> +	.sram_phys		= 0x00008000,
>  	.sram_len		= SZ_16K,
>  	.reset_device		= &davinci_wdt_device,
>  };
> diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
> index 1e0f809..a4365f7 100644
> --- a/arch/arm/mach-davinci/dm646x.c
> +++ b/arch/arm/mach-davinci/dm646x.c
> @@ -848,7 +848,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
>  	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
>  	.serial_dev		= &dm646x_serial_device,
>  	.emac_pdata		= &dm646x_emac_pdata,
> -	.sram_dma		= 0x10010000,
> +	.sram_phys		= 0x10010000,
>  	.sram_len		= SZ_32K,
>  	.reset_device		= &davinci_wdt_device,
>  };
> diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
> index a57cba2..665d049 100644
> --- a/arch/arm/mach-davinci/include/mach/common.h
> +++ b/arch/arm/mach-davinci/include/mach/common.h
> @@ -75,7 +75,7 @@ struct davinci_soc_info {
>  	int				gpio_ctlrs_num;
>  	struct platform_device		*serial_dev;
>  	struct emac_platform_data	*emac_pdata;
> -	dma_addr_t			sram_dma;
> +	phys_addr_t			sram_phys;
>  	unsigned			sram_len;
>  	struct platform_device		*reset_device;
>  	void				(*reset)(struct platform_device *);
> diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h
> index 111f7cc..7d77e85 100644
> --- a/arch/arm/mach-davinci/include/mach/sram.h
> +++ b/arch/arm/mach-davinci/include/mach/sram.h
> @@ -10,18 +10,11 @@
>  #ifndef __MACH_SRAM_H
>  #define __MACH_SRAM_H
>  
> +#include <asm/pv-pool.h>
> +
>  /* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
>  #define SRAM_GRANULARITY	512
>  
> -/*
> - * SRAM allocations return a CPU virtual address, or NULL on error.
> - * If a DMA address is requested and the SRAM supports DMA, its
> - * mapped address is also returned.
> - *
> - * Errors include SRAM memory not being available, and requesting
> - * DMA mapped SRAM on systems which don't allow that.
> - */
> -extern void *sram_alloc(size_t len, dma_addr_t *dma);
> -extern void sram_free(void *addr, size_t len);
> +extern struct pv_pool *davinci_pv_pool;
>  
>  #endif /* __MACH_SRAM_H */
> diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
> index 1bd73a0..f69cd7b 100644
> --- a/arch/arm/mach-davinci/pm.c
> +++ b/arch/arm/mach-davinci/pm.c
> @@ -29,12 +29,6 @@
>  static void (*davinci_sram_suspend) (struct davinci_pm_config *);
>  static struct davinci_pm_config *pdata;
>  
> -static void davinci_sram_push(void *dest, void *src, unsigned int size)
> -{
> -	memcpy(dest, src, size);
> -	flush_icache_range((unsigned long)dest, (unsigned long)(dest + size));
> -}
> -
>  static void davinci_pm_suspend(void)
>  {
>  	unsigned val;
> @@ -123,15 +117,13 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
>  		return -ENOENT;
>  	}
>  
> -	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
> +	davinci_sram_suspend = pv_pool_fncpy(davinci_pv_pool,
> +				davinci_cpu_suspend, davinci_cpu_suspend_sz);
>  	if (!davinci_sram_suspend) {
>  		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
>  		return -ENOMEM;
>  	}
>  
> -	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
> -						davinci_cpu_suspend_sz);
> -
>  	suspend_set_ops(&davinci_pm_ops);
>  
>  	return 0;
> diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> index db0f778..ebd4d67 100644
> --- a/arch/arm/mach-davinci/sram.c
> +++ b/arch/arm/mach-davinci/sram.c
> @@ -10,40 +10,13 @@
>   */
>  #include <linux/module.h>
>  #include <linux/init.h>
> -#include <linux/genalloc.h>
> +#include <asm/pv-pool.h>
>  
>  #include <mach/common.h>
>  #include <mach/sram.h>
>  
> -static struct gen_pool *sram_pool;
> -
> -void *sram_alloc(size_t len, dma_addr_t *dma)
> -{
> -	unsigned long vaddr;
> -	dma_addr_t dma_base = davinci_soc_info.sram_dma;
> -
> -	if (dma)
> -		*dma = 0;
> -	if (!sram_pool || (dma && !dma_base))
> -		return NULL;
> -
> -	vaddr = gen_pool_alloc(sram_pool, len);
> -	if (!vaddr)
> -		return NULL;
> -
> -	if (dma)
> -		*dma = dma_base + (vaddr - SRAM_VIRT);
> -	return (void *)vaddr;
> -
> -}
> -EXPORT_SYMBOL(sram_alloc);
> -
> -void sram_free(void *addr, size_t len)
> -{
> -	gen_pool_free(sram_pool, (unsigned long) addr, len);
> -}
> -EXPORT_SYMBOL(sram_free);
> -
> +struct pv_pool *davinci_pv_pool;
> +EXPORT_SYMBOL_GPL(davinci_pv_pool);
>  
>  /*
>   * REVISIT This supports CPU and DMA access to/from SRAM, but it
> @@ -58,13 +31,12 @@ static int __init sram_init(void)
>  
>  	if (len) {
>  		len = min_t(unsigned, len, SRAM_SIZE);
> -		sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
> -		if (!sram_pool)
> +		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
> +					davinci_soc_info.sram_phys, len,
> +					ilog2(SRAM_GRANULARITY));
> +		if (!davinci_pv_pool)
>  			status = -ENOMEM;
>  	}
> -	if (sram_pool)
> -		status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
> -	WARN_ON(status < 0);
>  	return status;
>  }
>  core_initcall(sram_init);
> diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
> index b0cb425..f60d5ea 100644
> --- a/arch/arm/plat-mxc/Kconfig
> +++ b/arch/arm/plat-mxc/Kconfig
> @@ -118,6 +118,6 @@ config ARCH_MXC_AUDMUX_V2
>  
>  config IRAM_ALLOC
>  	bool
> -	select GENERIC_ALLOCATOR
> +	select PV_POOL
>  
>  endif
> diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
> index 022690c..543c6df 100644
> --- a/arch/arm/plat-mxc/include/mach/iram.h
> +++ b/arch/arm/plat-mxc/include/mach/iram.h
> @@ -17,25 +17,37 @@
>   * MA 02110-1301, USA.
>   */
>  #include <linux/errno.h>
> +#include <asm/pv-pool.h>
>  
>  #ifdef CONFIG_IRAM_ALLOC
>  
> -int __init iram_init(unsigned long base, unsigned long size);
> -void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr);
> -void iram_free(unsigned long dma_addr, unsigned int size);
> +int __init iram_init(phys_addr_t base, size_t size);
> +
> +extern struct pv_pool *mxc_iram_pool;
> +
> +static inline void *iram_alloc(size_t size, phys_addr_t *phys)
> +{
> +	return pv_pool_alloc(iram_pool, size, phys);
> +}
> +
> +static inline void iram_free(void *addr, size_t size)
> +{
> +	pv_pool_free(iram_pool, addr, size);
> +}
>  
>  #else
>  
> -static inline int __init iram_init(unsigned long base, unsigned long size)
> +static inline int __init iram_init(phys_addr_t base, size_t size)
>  {
>  	return -ENOMEM;
>  }
>  
> -static inline void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
> +static inline void *iram_alloc(size_t size, phys_addr_t *phys)
>  {
> +	*phys = (phys_addr_t)-1ULL;
>  	return NULL;
>  }
>  
> -static inline void iram_free(unsigned long base, unsigned long size) {}
> +static inline void iram_free(void *addr, size_t size) {}
>  
>  #endif
> diff --git a/arch/arm/plat-mxc/iram_alloc.c b/arch/arm/plat-mxc/iram_alloc.c
> index 074c386..1e3d437 100644
> --- a/arch/arm/plat-mxc/iram_alloc.c
> +++ b/arch/arm/plat-mxc/iram_alloc.c
> @@ -24,50 +24,24 @@
>  #include <linux/genalloc.h>
>  #include <mach/iram.h>
>  
> -static unsigned long iram_phys_base;
> -static void __iomem *iram_virt_base;
> -static struct gen_pool *iram_pool;
> +struct pv_pool *mxc_iram_pool;
> +EXPORT_SYMBOL(mxc_iram_pool);
>  
> -static inline void __iomem *iram_phys_to_virt(unsigned long p)
> +int __init iram_init(phys_addr_t base, size_t size)
>  {
> -	return iram_virt_base + (p - iram_phys_base);
> -}
> -
> -void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
> -{
> -	if (!iram_pool)
> -		return NULL;
> -
> -	*dma_addr = gen_pool_alloc(iram_pool, size);
> -	pr_debug("iram alloc - %dB@0x%lX\n", size, *dma_addr);
> -	if (!*dma_addr)
> -		return NULL;
> -	return iram_phys_to_virt(*dma_addr);
> -}
> -EXPORT_SYMBOL(iram_alloc);
> -
> -void iram_free(unsigned long addr, unsigned int size)
> -{
> -	if (!iram_pool)
> -		return;
> -
> -	gen_pool_free(iram_pool, addr, size);
> -}
> -EXPORT_SYMBOL(iram_free);
> +	void *addr = /*FIXME*/ ioremap(base, size);
>  
> -int __init iram_init(unsigned long base, unsigned long size)
> -{
> -	iram_phys_base = base;
> +	if (!addr)
> +		return -EIO;
>  
> -	iram_pool = gen_pool_create(PAGE_SHIFT, -1);
> -	if (!iram_pool)
> +	mxc_iram_pool = pv_pool_create(addr, base, size, PAGE_SHIFT);
> +	if (!mxc_iram_pool) {
> +		iounmap(addr);
>  		return -ENOMEM;
> +	}
>  
> -	gen_pool_add(iram_pool, base, size, -1);
> -	iram_virt_base = ioremap(iram_phys_base, size);
> -	if (!iram_virt_base)
> -		return -EIO;
> +	pr_debug("i.MX IRAM pool: %lu KB@0x%08llx\n", size / 1024,
> +		 (unsigned long long)base);
>  
> -	pr_debug("i.MX IRAM pool: %ld KB@0x%p\n", size / 1024, iram_virt_base);
>  	return 0;
>  }
> diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
> index f500fc3..9fc27d0 100644
> --- a/arch/arm/plat-omap/include/plat/sram.h
> +++ b/arch/arm/plat-omap/include/plat/sram.h
> @@ -12,16 +12,19 @@
>  #define __ARCH_ARM_OMAP_SRAM_H
>  
>  #ifndef __ASSEMBLY__
> -#include <asm/fncpy.h>
> +#include <asm/pv-pool.h>
>  
> -extern void *omap_sram_push_address(unsigned long size);
> +extern struct pv_pool *omap_pv_pool;
>  
> -/* Macro to push a function to the internal SRAM, using the fncpy API */
> +/*
> + * Note that fncpy requires the SRAM address to be aligned to an 8-byte
> + * boundary, so the min_alloc_order for the pool is set appropriately.
> + */
>  #define omap_sram_push(funcp, size) ({				\
> -	typeof(&(funcp)) _res = NULL;				\
> -	void *_sram_address = omap_sram_push_address(size);	\
> -	if (_sram_address)					\
> -		_res = fncpy(_sram_address, &(funcp), size);	\
> +	typeof(&(funcp)) _res;					\
> +	_res = pv_pool_fncpy(omap_pv_pool, funcp, size);	\
> +	if (!_res)						\
> +		pr_err("Not enough space in SRAM\n");		\
>  	_res;							\
>  })
>  
> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> index a3f50b3..3588749 100644
> --- a/arch/arm/plat-omap/sram.c
> +++ b/arch/arm/plat-omap/sram.c
> @@ -75,7 +75,6 @@
>  static unsigned long omap_sram_start;
>  static unsigned long omap_sram_base;
>  static unsigned long omap_sram_size;
> -static unsigned long omap_sram_ceil;
>  
>  /*
>   * Depending on the target RAMFS firewall setup, the public usable amount of
> @@ -104,6 +103,8 @@ static int is_sram_locked(void)
>  		return 1; /* assume locked with no PPA or security driver */
>  }
>  
> +struct pv_pool *omap_pv_pool;
> +
>  /*
>   * The amount of SRAM depends on the core type.
>   * Note that we cannot try to test for SRAM here because writes
> @@ -182,7 +183,16 @@ static void __init omap_detect_sram(void)
>  			omap_sram_size - SRAM_BOOTLOADER_SZ);
>  	omap_sram_size -= reserved;
>  
> -	omap_sram_ceil = omap_sram_base + omap_sram_size;
> +	{
> +		/* The first SRAM_BOOTLOADER_SZ of SRAM are reserved */
> +		void *base = (void *)omap_sram_base + SRAM_BOOTLOADER_SZ;
> +		phys_addr_t phys = omap_sram_start + SRAM_BOOTLOADER_SZ;
> +		size_t len = omap_sram_size - SRAM_BOOTLOADER_SZ;
> +
> +		omap_pv_pool = pv_pool_create(base, phys, len,
> +						ilog2(FNCPY_ALIGN));
> +		WARN_ON(!omap_pv_pool);
> +	}
>  }
>  
>  static struct map_desc omap_sram_io_desc[] __initdata = {
> @@ -242,26 +252,6 @@ static void __init omap_map_sram(void)
>  	       omap_sram_size - SRAM_BOOTLOADER_SZ);
>  }
>  
> -/*
> - * Memory allocator for SRAM: calculates the new ceiling address
> - * for pushing a function using the fncpy API.
> - *
> - * Note that fncpy requires the returned address to be aligned
> - * to an 8-byte boundary.
> - */
> -void *omap_sram_push_address(unsigned long size)
> -{
> -	if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
> -		printk(KERN_ERR "Not enough space in SRAM\n");
> -		return NULL;
> -	}
> -
> -	omap_sram_ceil -= size;
> -	omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, FNCPY_ALIGN);
> -
> -	return (void *)omap_sram_ceil;
> -}
> -
>  #ifdef CONFIG_ARCH_OMAP1
>  
>  static void (*_omap_sram_reprogram_clock)(u32 dpllctl, u32 ckctl);
> diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
> index daf6e77..2be3155 100644
> --- a/drivers/uio/uio_pruss.c
> +++ b/drivers/uio/uio_pruss.c
> @@ -62,7 +62,7 @@ MODULE_PARM_DESC(extram_pool_sz, "external ram pool size to allocate");
>  struct uio_pruss_dev {
>  	struct uio_info *info;
>  	struct clk *pruss_clk;
> -	dma_addr_t sram_paddr;
> +	phys_addr_t sram_paddr;
>  	dma_addr_t ddr_paddr;
>  	void __iomem *prussio_vaddr;
>  	void *sram_vaddr;
> @@ -106,7 +106,7 @@ static void pruss_cleanup(struct platform_device *dev,
>  			gdev->ddr_paddr);
>  	}
>  	if (gdev->sram_vaddr)
> -		sram_free(gdev->sram_vaddr, sram_pool_sz);
> +		pv_pool_free(davinci_pv_pool, gdev->sram_vaddr, sram_pool_sz);
>  	kfree(gdev->info);
>  	clk_put(gdev->pruss_clk);
>  	kfree(gdev);
> @@ -152,7 +152,8 @@ static int __devinit pruss_probe(struct platform_device *dev)
>  		goto out_free;
>  	}
>  
> -	gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
> +	gdev->sram_vaddr = pv_pool_alloc(davinci_pv_pool, sram_pool_sz,
> +					   &(gdev->sram_paddr));
>  	if (!gdev->sram_vaddr) {
>  		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
>  		goto out_free;
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC PATCH v2] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

Hi,

	I do post a patch to add the support to specify a virt and phys
	address to the generic allocator so the pv-pool.c is not needed
	we can just use the generic fucntion

	I'll post a v3 updated again it

Best Regards,
J.
> --- /dev/null > +++ b/arch/arm/common/pv-pool.c
> @@ -0,0 +1,69 @@
> +/*
> + * Unified Phys/Virt allocator, based on mach-davinci/sram.c, which was
> + * Copyright (C) 2009 David Brownell.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include <linux/dma-mapping.h>
> +#include <linux/genalloc.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +
> +#include <asm/pv-pool.h>
> +
> +struct pv_pool {
> +	struct gen_pool *genpool;
> +	void *cpu_base;
> +	phys_addr_t phys_base;
> +};
> +
> +void *pv_pool_alloc(struct pv_pool *pool, size_t len, phys_addr_t *phys)
> +{
> +	void *addr = (void *)gen_pool_alloc(pool->genpool, len);
> +
> +	if (phys)
> +		*phys = addr ? (pool->phys_base + (addr - pool->cpu_base)) :
> +			 (phys_addr_t)-1ULL;
> +
> +	return addr;
> +}
> +EXPORT_SYMBOL_GPL(pv_pool_alloc);
> +
> +void pv_pool_free(struct pv_pool *pool, void *addr, size_t len)
> +{
> +	gen_pool_free(pool->genpool, (unsigned long)addr, len);
> +}
> +EXPORT_SYMBOL_GPL(pv_pool_free);
> +
> +struct pv_pool *pv_pool_create(void *addr, phys_addr_t phys, size_t len,
> +	int min_alloc_order)
> +{
> +	struct pv_pool *pool = kzalloc(sizeof(struct pv_pool), GFP_KERNEL);
> +
> +	if (pool) {
> +		pool->cpu_base = addr;
> +		pool->phys_base = phys;
> +		pool->genpool = gen_pool_create(min_alloc_order, -1);
> +		if (!pool->genpool) {
> +			kfree(pool);
> +			pool = NULL;
> +		} else {
> +			WARN_ON(gen_pool_add(pool->genpool, (unsigned long)addr,
> +						len, -1) < 0);
> +		}
> +	}
> +
> +	return pool;
> +}
> +EXPORT_SYMBOL_GPL(pv_pool_create);
> +
> +void pv_pool_destroy(struct pv_pool *pool)
> +{
> +	gen_pool_destroy(pool->genpool);
> +	kfree(pool);
> +}
> +EXPORT_SYMBOL_GPL(pv_pool_destroy);
> diff --git a/arch/arm/include/asm/pv-pool.h b/arch/arm/include/asm/pv-pool.h
> new file mode 100644
> index 0000000..b7ae871
> --- /dev/null
> +++ b/arch/arm/include/asm/pv-pool.h
> @@ -0,0 +1,20 @@
> +#ifndef __ASMARM_PV_POOL_H
> +#define __ASMARM_PV_POOL_H
> +
> +#include <asm/fncpy.h>
> +
> +struct pv_pool;
> +
> +void *pv_pool_alloc(struct pv_pool *, size_t, phys_addr_t *);
> +void pv_pool_free(struct pv_pool *, void *, size_t);
> +struct pv_pool *pv_pool_create(void *, phys_addr_t, size_t, int);
> +void pv_pool_destroy(struct pv_pool *);
> +
> +/* Macro to copy a function into SRAM, using the fncpy API */
> +#define pv_pool_fncpy(pool, funcp, size) ({			\
> +	size_t _sz = size;					\
> +	void *_sram = pv_pool_alloc(pool, _sz, NULL);		\
> +	(_sram ? fncpy(_sram, &(funcp), _sz) : NULL);		\
> +})
> +
> +#endif
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 68fe4c2..5eca128 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
>  	.gpio_irq		= IRQ_DA8XX_GPIO0,
>  	.serial_dev		= &da8xx_serial_device,
>  	.emac_pdata		= &da8xx_emac_pdata,
> -	.sram_dma		= DA8XX_ARM_RAM_BASE,
> +	.sram_phys		= DA8XX_ARM_RAM_BASE,
>  	.sram_len		= SZ_8K,
>  	.reset_device		= &da8xx_wdt_device,
>  };
> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
> index 76364d1..3df8730 100644
> --- a/arch/arm/mach-davinci/dm355.c
> +++ b/arch/arm/mach-davinci/dm355.c
> @@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
>  	.gpio_num		= 104,
>  	.gpio_irq		= IRQ_DM355_GPIOBNK0,
>  	.serial_dev		= &dm355_serial_device,
> -	.sram_dma		= 0x00010000,
> +	.sram_phys		= 0x00010000,
>  	.sram_len		= SZ_32K,
>  	.reset_device		= &davinci_wdt_device,
>  };
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index 4604e72..d306034 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
>  	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
>  	.serial_dev		= &dm365_serial_device,
>  	.emac_pdata		= &dm365_emac_pdata,
> -	.sram_dma		= 0x00010000,
> +	.sram_phys		= 0x00010000,
>  	.sram_len		= SZ_32K,
>  	.reset_device		= &davinci_wdt_device,
>  };
> diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
> index 9a2376b..4ca7295 100644
> --- a/arch/arm/mach-davinci/dm644x.c
> +++ b/arch/arm/mach-davinci/dm644x.c
> @@ -764,7 +764,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
>  	.gpio_irq		= IRQ_GPIOBNK0,
>  	.serial_dev		= &dm644x_serial_device,
>  	.emac_pdata		= &dm644x_emac_pdata,
> -	.sram_dma		= 0x00008000,
> +	.sram_phys		= 0x00008000,
>  	.sram_len		= SZ_16K,
>  	.reset_device		= &davinci_wdt_device,
>  };
> diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
> index 1e0f809..a4365f7 100644
> --- a/arch/arm/mach-davinci/dm646x.c
> +++ b/arch/arm/mach-davinci/dm646x.c
> @@ -848,7 +848,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
>  	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
>  	.serial_dev		= &dm646x_serial_device,
>  	.emac_pdata		= &dm646x_emac_pdata,
> -	.sram_dma		= 0x10010000,
> +	.sram_phys		= 0x10010000,
>  	.sram_len		= SZ_32K,
>  	.reset_device		= &davinci_wdt_device,
>  };
> diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
> index a57cba2..665d049 100644
> --- a/arch/arm/mach-davinci/include/mach/common.h
> +++ b/arch/arm/mach-davinci/include/mach/common.h
> @@ -75,7 +75,7 @@ struct davinci_soc_info {
>  	int				gpio_ctlrs_num;
>  	struct platform_device		*serial_dev;
>  	struct emac_platform_data	*emac_pdata;
> -	dma_addr_t			sram_dma;
> +	phys_addr_t			sram_phys;
>  	unsigned			sram_len;
>  	struct platform_device		*reset_device;
>  	void				(*reset)(struct platform_device *);
> diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h
> index 111f7cc..7d77e85 100644
> --- a/arch/arm/mach-davinci/include/mach/sram.h
> +++ b/arch/arm/mach-davinci/include/mach/sram.h
> @@ -10,18 +10,11 @@
>  #ifndef __MACH_SRAM_H
>  #define __MACH_SRAM_H
>  
> +#include <asm/pv-pool.h>
> +
>  /* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
>  #define SRAM_GRANULARITY	512
>  
> -/*
> - * SRAM allocations return a CPU virtual address, or NULL on error.
> - * If a DMA address is requested and the SRAM supports DMA, its
> - * mapped address is also returned.
> - *
> - * Errors include SRAM memory not being available, and requesting
> - * DMA mapped SRAM on systems which don't allow that.
> - */
> -extern void *sram_alloc(size_t len, dma_addr_t *dma);
> -extern void sram_free(void *addr, size_t len);
> +extern struct pv_pool *davinci_pv_pool;
>  
>  #endif /* __MACH_SRAM_H */
> diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
> index 1bd73a0..f69cd7b 100644
> --- a/arch/arm/mach-davinci/pm.c
> +++ b/arch/arm/mach-davinci/pm.c
> @@ -29,12 +29,6 @@
>  static void (*davinci_sram_suspend) (struct davinci_pm_config *);
>  static struct davinci_pm_config *pdata;
>  
> -static void davinci_sram_push(void *dest, void *src, unsigned int size)
> -{
> -	memcpy(dest, src, size);
> -	flush_icache_range((unsigned long)dest, (unsigned long)(dest + size));
> -}
> -
>  static void davinci_pm_suspend(void)
>  {
>  	unsigned val;
> @@ -123,15 +117,13 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
>  		return -ENOENT;
>  	}
>  
> -	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
> +	davinci_sram_suspend = pv_pool_fncpy(davinci_pv_pool,
> +				davinci_cpu_suspend, davinci_cpu_suspend_sz);
>  	if (!davinci_sram_suspend) {
>  		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
>  		return -ENOMEM;
>  	}
>  
> -	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
> -						davinci_cpu_suspend_sz);
> -
>  	suspend_set_ops(&davinci_pm_ops);
>  
>  	return 0;
> diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> index db0f778..ebd4d67 100644
> --- a/arch/arm/mach-davinci/sram.c
> +++ b/arch/arm/mach-davinci/sram.c
> @@ -10,40 +10,13 @@
>   */
>  #include <linux/module.h>
>  #include <linux/init.h>
> -#include <linux/genalloc.h>
> +#include <asm/pv-pool.h>
>  
>  #include <mach/common.h>
>  #include <mach/sram.h>
>  
> -static struct gen_pool *sram_pool;
> -
> -void *sram_alloc(size_t len, dma_addr_t *dma)
> -{
> -	unsigned long vaddr;
> -	dma_addr_t dma_base = davinci_soc_info.sram_dma;
> -
> -	if (dma)
> -		*dma = 0;
> -	if (!sram_pool || (dma && !dma_base))
> -		return NULL;
> -
> -	vaddr = gen_pool_alloc(sram_pool, len);
> -	if (!vaddr)
> -		return NULL;
> -
> -	if (dma)
> -		*dma = dma_base + (vaddr - SRAM_VIRT);
> -	return (void *)vaddr;
> -
> -}
> -EXPORT_SYMBOL(sram_alloc);
> -
> -void sram_free(void *addr, size_t len)
> -{
> -	gen_pool_free(sram_pool, (unsigned long) addr, len);
> -}
> -EXPORT_SYMBOL(sram_free);
> -
> +struct pv_pool *davinci_pv_pool;
> +EXPORT_SYMBOL_GPL(davinci_pv_pool);
>  
>  /*
>   * REVISIT This supports CPU and DMA access to/from SRAM, but it
> @@ -58,13 +31,12 @@ static int __init sram_init(void)
>  
>  	if (len) {
>  		len = min_t(unsigned, len, SRAM_SIZE);
> -		sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
> -		if (!sram_pool)
> +		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
> +					davinci_soc_info.sram_phys, len,
> +					ilog2(SRAM_GRANULARITY));
> +		if (!davinci_pv_pool)
>  			status = -ENOMEM;
>  	}
> -	if (sram_pool)
> -		status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
> -	WARN_ON(status < 0);
>  	return status;
>  }
>  core_initcall(sram_init);
> diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
> index b0cb425..f60d5ea 100644
> --- a/arch/arm/plat-mxc/Kconfig
> +++ b/arch/arm/plat-mxc/Kconfig
> @@ -118,6 +118,6 @@ config ARCH_MXC_AUDMUX_V2
>  
>  config IRAM_ALLOC
>  	bool
> -	select GENERIC_ALLOCATOR
> +	select PV_POOL
>  
>  endif
> diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
> index 022690c..543c6df 100644
> --- a/arch/arm/plat-mxc/include/mach/iram.h
> +++ b/arch/arm/plat-mxc/include/mach/iram.h
> @@ -17,25 +17,37 @@
>   * MA 02110-1301, USA.
>   */
>  #include <linux/errno.h>
> +#include <asm/pv-pool.h>
>  
>  #ifdef CONFIG_IRAM_ALLOC
>  
> -int __init iram_init(unsigned long base, unsigned long size);
> -void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr);
> -void iram_free(unsigned long dma_addr, unsigned int size);
> +int __init iram_init(phys_addr_t base, size_t size);
> +
> +extern struct pv_pool *mxc_iram_pool;
> +
> +static inline void *iram_alloc(size_t size, phys_addr_t *phys)
> +{
> +	return pv_pool_alloc(iram_pool, size, phys);
> +}
> +
> +static inline void iram_free(void *addr, size_t size)
> +{
> +	pv_pool_free(iram_pool, addr, size);
> +}
>  
>  #else
>  
> -static inline int __init iram_init(unsigned long base, unsigned long size)
> +static inline int __init iram_init(phys_addr_t base, size_t size)
>  {
>  	return -ENOMEM;
>  }
>  
> -static inline void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
> +static inline void *iram_alloc(size_t size, phys_addr_t *phys)
>  {
> +	*phys = (phys_addr_t)-1ULL;
>  	return NULL;
>  }
>  
> -static inline void iram_free(unsigned long base, unsigned long size) {}
> +static inline void iram_free(void *addr, size_t size) {}
>  
>  #endif
> diff --git a/arch/arm/plat-mxc/iram_alloc.c b/arch/arm/plat-mxc/iram_alloc.c
> index 074c386..1e3d437 100644
> --- a/arch/arm/plat-mxc/iram_alloc.c
> +++ b/arch/arm/plat-mxc/iram_alloc.c
> @@ -24,50 +24,24 @@
>  #include <linux/genalloc.h>
>  #include <mach/iram.h>
>  
> -static unsigned long iram_phys_base;
> -static void __iomem *iram_virt_base;
> -static struct gen_pool *iram_pool;
> +struct pv_pool *mxc_iram_pool;
> +EXPORT_SYMBOL(mxc_iram_pool);
>  
> -static inline void __iomem *iram_phys_to_virt(unsigned long p)
> +int __init iram_init(phys_addr_t base, size_t size)
>  {
> -	return iram_virt_base + (p - iram_phys_base);
> -}
> -
> -void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
> -{
> -	if (!iram_pool)
> -		return NULL;
> -
> -	*dma_addr = gen_pool_alloc(iram_pool, size);
> -	pr_debug("iram alloc - %dB at 0x%lX\n", size, *dma_addr);
> -	if (!*dma_addr)
> -		return NULL;
> -	return iram_phys_to_virt(*dma_addr);
> -}
> -EXPORT_SYMBOL(iram_alloc);
> -
> -void iram_free(unsigned long addr, unsigned int size)
> -{
> -	if (!iram_pool)
> -		return;
> -
> -	gen_pool_free(iram_pool, addr, size);
> -}
> -EXPORT_SYMBOL(iram_free);
> +	void *addr = /*FIXME*/ ioremap(base, size);
>  
> -int __init iram_init(unsigned long base, unsigned long size)
> -{
> -	iram_phys_base = base;
> +	if (!addr)
> +		return -EIO;
>  
> -	iram_pool = gen_pool_create(PAGE_SHIFT, -1);
> -	if (!iram_pool)
> +	mxc_iram_pool = pv_pool_create(addr, base, size, PAGE_SHIFT);
> +	if (!mxc_iram_pool) {
> +		iounmap(addr);
>  		return -ENOMEM;
> +	}
>  
> -	gen_pool_add(iram_pool, base, size, -1);
> -	iram_virt_base = ioremap(iram_phys_base, size);
> -	if (!iram_virt_base)
> -		return -EIO;
> +	pr_debug("i.MX IRAM pool: %lu KB at 0x%08llx\n", size / 1024,
> +		 (unsigned long long)base);
>  
> -	pr_debug("i.MX IRAM pool: %ld KB at 0x%p\n", size / 1024, iram_virt_base);
>  	return 0;
>  }
> diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
> index f500fc3..9fc27d0 100644
> --- a/arch/arm/plat-omap/include/plat/sram.h
> +++ b/arch/arm/plat-omap/include/plat/sram.h
> @@ -12,16 +12,19 @@
>  #define __ARCH_ARM_OMAP_SRAM_H
>  
>  #ifndef __ASSEMBLY__
> -#include <asm/fncpy.h>
> +#include <asm/pv-pool.h>
>  
> -extern void *omap_sram_push_address(unsigned long size);
> +extern struct pv_pool *omap_pv_pool;
>  
> -/* Macro to push a function to the internal SRAM, using the fncpy API */
> +/*
> + * Note that fncpy requires the SRAM address to be aligned to an 8-byte
> + * boundary, so the min_alloc_order for the pool is set appropriately.
> + */
>  #define omap_sram_push(funcp, size) ({				\
> -	typeof(&(funcp)) _res = NULL;				\
> -	void *_sram_address = omap_sram_push_address(size);	\
> -	if (_sram_address)					\
> -		_res = fncpy(_sram_address, &(funcp), size);	\
> +	typeof(&(funcp)) _res;					\
> +	_res = pv_pool_fncpy(omap_pv_pool, funcp, size);	\
> +	if (!_res)						\
> +		pr_err("Not enough space in SRAM\n");		\
>  	_res;							\
>  })
>  
> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> index a3f50b3..3588749 100644
> --- a/arch/arm/plat-omap/sram.c
> +++ b/arch/arm/plat-omap/sram.c
> @@ -75,7 +75,6 @@
>  static unsigned long omap_sram_start;
>  static unsigned long omap_sram_base;
>  static unsigned long omap_sram_size;
> -static unsigned long omap_sram_ceil;
>  
>  /*
>   * Depending on the target RAMFS firewall setup, the public usable amount of
> @@ -104,6 +103,8 @@ static int is_sram_locked(void)
>  		return 1; /* assume locked with no PPA or security driver */
>  }
>  
> +struct pv_pool *omap_pv_pool;
> +
>  /*
>   * The amount of SRAM depends on the core type.
>   * Note that we cannot try to test for SRAM here because writes
> @@ -182,7 +183,16 @@ static void __init omap_detect_sram(void)
>  			omap_sram_size - SRAM_BOOTLOADER_SZ);
>  	omap_sram_size -= reserved;
>  
> -	omap_sram_ceil = omap_sram_base + omap_sram_size;
> +	{
> +		/* The first SRAM_BOOTLOADER_SZ of SRAM are reserved */
> +		void *base = (void *)omap_sram_base + SRAM_BOOTLOADER_SZ;
> +		phys_addr_t phys = omap_sram_start + SRAM_BOOTLOADER_SZ;
> +		size_t len = omap_sram_size - SRAM_BOOTLOADER_SZ;
> +
> +		omap_pv_pool = pv_pool_create(base, phys, len,
> +						ilog2(FNCPY_ALIGN));
> +		WARN_ON(!omap_pv_pool);
> +	}
>  }
>  
>  static struct map_desc omap_sram_io_desc[] __initdata = {
> @@ -242,26 +252,6 @@ static void __init omap_map_sram(void)
>  	       omap_sram_size - SRAM_BOOTLOADER_SZ);
>  }
>  
> -/*
> - * Memory allocator for SRAM: calculates the new ceiling address
> - * for pushing a function using the fncpy API.
> - *
> - * Note that fncpy requires the returned address to be aligned
> - * to an 8-byte boundary.
> - */
> -void *omap_sram_push_address(unsigned long size)
> -{
> -	if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
> -		printk(KERN_ERR "Not enough space in SRAM\n");
> -		return NULL;
> -	}
> -
> -	omap_sram_ceil -= size;
> -	omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, FNCPY_ALIGN);
> -
> -	return (void *)omap_sram_ceil;
> -}
> -
>  #ifdef CONFIG_ARCH_OMAP1
>  
>  static void (*_omap_sram_reprogram_clock)(u32 dpllctl, u32 ckctl);
> diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
> index daf6e77..2be3155 100644
> --- a/drivers/uio/uio_pruss.c
> +++ b/drivers/uio/uio_pruss.c
> @@ -62,7 +62,7 @@ MODULE_PARM_DESC(extram_pool_sz, "external ram pool size to allocate");
>  struct uio_pruss_dev {
>  	struct uio_info *info;
>  	struct clk *pruss_clk;
> -	dma_addr_t sram_paddr;
> +	phys_addr_t sram_paddr;
>  	dma_addr_t ddr_paddr;
>  	void __iomem *prussio_vaddr;
>  	void *sram_vaddr;
> @@ -106,7 +106,7 @@ static void pruss_cleanup(struct platform_device *dev,
>  			gdev->ddr_paddr);
>  	}
>  	if (gdev->sram_vaddr)
> -		sram_free(gdev->sram_vaddr, sram_pool_sz);
> +		pv_pool_free(davinci_pv_pool, gdev->sram_vaddr, sram_pool_sz);
>  	kfree(gdev->info);
>  	clk_put(gdev->pruss_clk);
>  	kfree(gdev);
> @@ -152,7 +152,8 @@ static int __devinit pruss_probe(struct platform_device *dev)
>  		goto out_free;
>  	}
>  
> -	gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
> +	gdev->sram_vaddr = pv_pool_alloc(davinci_pv_pool, sram_pool_sz,
> +					   &(gdev->sram_paddr));
>  	if (!gdev->sram_vaddr) {
>  		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
>  		goto out_free;
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2] Consolidate SRAM support

[Russell King - ARM Linux]

On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Hi,
> 
> 	I do post a patch to add the support to specify a virt and phys
> 	address to the generic allocator so the pv-pool.c is not needed
> 	we can just use the generic fucntion

You've talked about this before in the thread, but the patch never appeared.

[RFC PATCH v2] Consolidate SRAM support

[Russell King - ARM Linux]

On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Hi,
> 
> 	I do post a patch to add the support to specify a virt and phys
> 	address to the generic allocator so the pv-pool.c is not needed
> 	we can just use the generic fucntion

You've talked about this before in the thread, but the patch never appeared.

Re: [RFC PATCH v2] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

On 17:18 Tue 19 Apr     , Russell King - ARM Linux wrote:
> On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > Hi,
> > 
> > 	I do post a patch to add the support to specify a virt and phys
> > 	address to the generic allocator so the pv-pool.c is not needed
> > 	we can just use the generic fucntion
> 
> You've talked about this before in the thread, but the patch never appeared.
I forget to re-send it sorry
it's the mm tree

patch attached

Best Regards,
J.

[-- Attachment #2: 0001-genalloc-add-support-to-specify-the-physical-address.patch --]
[-- Type: text/x-diff, Size: 4672 bytes --]

>From 05f5a21ca6423b3051d442eaad3ba34ac131ef98 Mon Sep 17 00:00:00 2001
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Date: Thu, 7 Apr 2011 01:23:45 +0800
Subject: [PATCH] genalloc: add support to specify the physical address

so we specify the virtual address as base of the pool chunk and then
get the physical address for hardware IP

as example on at91 we will use on spi, uart or macb

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
 include/linux/genalloc.h |   20 +++++++++++++++++++-
 lib/genalloc.c           |   39 ++++++++++++++++++++++++++++++++-------
 2 files changed, 51 insertions(+), 8 deletions(-)

diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index b1c70f1..b44625b 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -26,13 +26,31 @@ struct gen_pool {
 struct gen_pool_chunk {
 	spinlock_t lock;
 	struct list_head next_chunk;	/* next chunk in pool */
+	unsigned long phys_addr;	/* physical starting address of memory chunk */
 	unsigned long start_addr;	/* starting address of memory chunk */
 	unsigned long end_addr;		/* ending address of memory chunk */
 	unsigned long bits[0];		/* bitmap for allocating memory chunk */
 };
 
 extern struct gen_pool *gen_pool_create(int, int);
-extern int gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
+extern unsigned long gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long);
+extern int gen_pool_add_virt(struct gen_pool *, unsigned long, unsigned long,
+			     size_t, int);
+/**
+ * gen_pool_add - add a new chunk of special memory to the pool
+ * @pool: pool to add new memory chunk to
+ * @addr: starting address of memory chunk to add to pool
+ * @size: size in bytes of the memory chunk to add to pool
+ * @nid: node id of the node the chunk structure and bitmap should be
+ *       allocated on, or -1
+ *
+ * Add a new chunk of special memory to the specified pool.
+ */
+static inline int gen_pool_add(struct gen_pool *pool, unsigned long addr,
+			       size_t size, int nid)
+{
+	return gen_pool_add_virt(pool, addr, 0, size, nid);
+}
 extern void gen_pool_destroy(struct gen_pool *);
 extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
 extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 1923f14..83b069b 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -39,17 +39,18 @@ struct gen_pool *gen_pool_create(int min_alloc_order, int nid)
 EXPORT_SYMBOL(gen_pool_create);
 
 /**
- * gen_pool_add - add a new chunk of special memory to the pool
+ * gen_pool_add_virt - add a new chunk of special memory to the pool
  * @pool: pool to add new memory chunk to
- * @addr: starting address of memory chunk to add to pool
+ * @virt: virtual starting address of memory chunk to add to pool
+ * @phys: physical starting address of memory chunk to add to pool
  * @size: size in bytes of the memory chunk to add to pool
  * @nid: node id of the node the chunk structure and bitmap should be
  *       allocated on, or -1
  *
  * Add a new chunk of special memory to the specified pool.
  */
-int gen_pool_add(struct gen_pool *pool, unsigned long addr, size_t size,
-		 int nid)
+int gen_pool_add_virt(struct gen_pool *pool, unsigned long virt, unsigned long phys,
+		 size_t size, int nid)
 {
 	struct gen_pool_chunk *chunk;
 	int nbits = size >> pool->min_alloc_order;
@@ -61,8 +62,9 @@ int gen_pool_add(struct gen_pool *pool, unsigned long addr, size_t size,
 		return -1;
 
 	spin_lock_init(&chunk->lock);
-	chunk->start_addr = addr;
-	chunk->end_addr = addr + size;
+	chunk->phys_addr = phys;
+	chunk->start_addr = virt;
+	chunk->end_addr = virt + size;
 
 	write_lock(&pool->lock);
 	list_add(&chunk->next_chunk, &pool->chunks);
@@ -70,7 +72,30 @@ int gen_pool_add(struct gen_pool *pool, unsigned long addr, size_t size,
 
 	return 0;
 }
-EXPORT_SYMBOL(gen_pool_add);
+EXPORT_SYMBOL(gen_pool_add_virt);
+
+/**
+ * gen_pool_virt_to_phys - return the physical address of memory
+ * @pool: pool to allocate from
+ * @addr: starting address of memory
+ */
+unsigned long gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long addr)
+{
+	struct list_head *_chunk;
+	struct gen_pool_chunk *chunk;
+
+	read_lock(&pool->lock);
+	list_for_each(_chunk, &pool->chunks) {
+		chunk = list_entry(_chunk, struct gen_pool_chunk, next_chunk);
+
+		if (addr >= chunk->start_addr && addr < chunk->end_addr)
+			return chunk->phys_addr + addr - chunk->start_addr;
+	}
+	read_unlock(&pool->lock);
+
+	return ~0UL;
+}
+EXPORT_SYMBOL(gen_pool_virt_to_phys);
 
 /**
  * gen_pool_destroy - destroy a special memory pool
-- 
1.7.4.1

[RFC PATCH v2] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:18 Tue 19 Apr     , Russell King - ARM Linux wrote:
> On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > Hi,
> > 
> > 	I do post a patch to add the support to specify a virt and phys
> > 	address to the generic allocator so the pv-pool.c is not needed
> > 	we can just use the generic fucntion
> 
> You've talked about this before in the thread, but the patch never appeared.
I forget to re-send it sorry
it's the mm tree

patch attached

Best Regards,
J.

Re: [RFC PATCH v2] Consolidate SRAM support

[Russell King - ARM Linux]

On Tue, Apr 19, 2011 at 09:05:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 17:18 Tue 19 Apr     , Russell King - ARM Linux wrote:
> > On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > Hi,
> > > 
> > > 	I do post a patch to add the support to specify a virt and phys
> > > 	address to the generic allocator so the pv-pool.c is not needed
> > > 	we can just use the generic fucntion
> > 
> > You've talked about this before in the thread, but the patch never appeared.
> I forget to re-send it sorry
> it's the mm tree

One obvious issue here is that you're using 'unsigned long' for phys
addresses.  With LPAE we could start seeing SRAM outside of the 4GB
PA range, and so would need this to be phys_addr_t.

[RFC PATCH v2] Consolidate SRAM support

[Russell King - ARM Linux]

On Tue, Apr 19, 2011 at 09:05:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 17:18 Tue 19 Apr     , Russell King - ARM Linux wrote:
> > On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > Hi,
> > > 
> > > 	I do post a patch to add the support to specify a virt and phys
> > > 	address to the generic allocator so the pv-pool.c is not needed
> > > 	we can just use the generic fucntion
> > 
> > You've talked about this before in the thread, but the patch never appeared.
> I forget to re-send it sorry
> it's the mm tree

One obvious issue here is that you're using 'unsigned long' for phys
addresses.  With LPAE we could start seeing SRAM outside of the 4GB
PA range, and so would need this to be phys_addr_t.

Re: [RFC PATCH v2] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

On 00:20 Wed 20 Apr     , Russell King - ARM Linux wrote:
> On Tue, Apr 19, 2011 at 09:05:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 17:18 Tue 19 Apr     , Russell King - ARM Linux wrote:
> > > On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > Hi,
> > > > 
> > > > 	I do post a patch to add the support to specify a virt and phys
> > > > 	address to the generic allocator so the pv-pool.c is not needed
> > > > 	we can just use the generic fucntion
> > > 
> > > You've talked about this before in the thread, but the patch never appeared.
> > I forget to re-send it sorry
> > it's the mm tree
> 
> One obvious issue here is that you're using 'unsigned long' for phys
> addresses.  With LPAE we could start seeing SRAM outside of the 4GB
> PA range, and so would need this to be phys_addr_t.

I'll update it

any other issue?

Best Regards,
J.

[RFC PATCH v2] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

On 00:20 Wed 20 Apr     , Russell King - ARM Linux wrote:
> On Tue, Apr 19, 2011 at 09:05:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 17:18 Tue 19 Apr     , Russell King - ARM Linux wrote:
> > > On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > Hi,
> > > > 
> > > > 	I do post a patch to add the support to specify a virt and phys
> > > > 	address to the generic allocator so the pv-pool.c is not needed
> > > > 	we can just use the generic fucntion
> > > 
> > > You've talked about this before in the thread, but the patch never appeared.
> > I forget to re-send it sorry
> > it's the mm tree
> 
> One obvious issue here is that you're using 'unsigned long' for phys
> addresses.  With LPAE we could start seeing SRAM outside of the 4GB
> PA range, and so would need this to be phys_addr_t.

I'll update it

any other issue?

Best Regards,
J.

Re: [RFC PATCH] Consolidate SRAM support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [110419 17:13]:
> Hi Tony and Russell,
> 
> On Mon, 2011-04-18 at 11:17 +0300, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [110418 09:57]:
> 
> > > So, I can make a patch that removes the SRAM support from omapfb, and
> > > queue it up for the next merge window.
> > 
> > OK. That patch should probably go into Russell's tree along with
> > other SRAM related patches to avoid conflicts.
> 
> Here's a simple patch to remove SRAM support from omapfb. Or more
> precisely, this just disables it.
> 
> I started to remove the SRAM support from the drivers, but the patches
> got quite big and will probably cause conflicts if they reside in
> somebody else's tree than mine. So I believe it's easiest to divide SRAM
> FB removal into this patch, handled by Russell (?), and then the rest,
> handled by me.

OK sounds like a plan.
 
> Is there something else related to OMAP FB than the code removed in this
> patch that is hindering the SRAM work?

I think we can now also remove sram_ceil and omap_sram_push_address?

Regards,

Tony

[RFC PATCH] Consolidate SRAM support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [110419 17:13]:
> Hi Tony and Russell,
> 
> On Mon, 2011-04-18 at 11:17 +0300, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [110418 09:57]:
> 
> > > So, I can make a patch that removes the SRAM support from omapfb, and
> > > queue it up for the next merge window.
> > 
> > OK. That patch should probably go into Russell's tree along with
> > other SRAM related patches to avoid conflicts.
> 
> Here's a simple patch to remove SRAM support from omapfb. Or more
> precisely, this just disables it.
> 
> I started to remove the SRAM support from the drivers, but the patches
> got quite big and will probably cause conflicts if they reside in
> somebody else's tree than mine. So I believe it's easiest to divide SRAM
> FB removal into this patch, handled by Russell (?), and then the rest,
> handled by me.

OK sounds like a plan.
 
> Is there something else related to OMAP FB than the code removed in this
> patch that is hindering the SRAM work?

I think we can now also remove sram_ceil and omap_sram_push_address?

Regards,

Tony

[RFC PATCH v3] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.

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 version fixes the davinci pm free, and adds updates for the
davinci pcm driver.  As I don't know what's happening with Jean's
patch tweaking the genpool allocator, I've kept my version.

This still suffers from the "only one region per pvpool" problem
which I believe Jean's patch doesn't suffer.

 arch/arm/Kconfig                            |    2 +
 arch/arm/common/Kconfig                     |    4 ++
 arch/arm/common/Makefile                    |    1 +
 arch/arm/common/pv-pool.c                   |   69 +++++++++++++++++++++++++++
 arch/arm/include/asm/pv-pool.h              |   20 ++++++++
 arch/arm/mach-davinci/da850.c               |    2 +-
 arch/arm/mach-davinci/dm355.c               |    2 +-
 arch/arm/mach-davinci/dm365.c               |    2 +-
 arch/arm/mach-davinci/dm644x.c              |    2 +-
 arch/arm/mach-davinci/dm646x.c              |    2 +-
 arch/arm/mach-davinci/include/mach/common.h |    2 +-
 arch/arm/mach-davinci/include/mach/sram.h   |   13 +----
 arch/arm/mach-davinci/pm.c                  |   20 +++-----
 arch/arm/mach-davinci/sram.c                |   42 +++--------------
 arch/arm/plat-mxc/Kconfig                   |    2 +-
 arch/arm/plat-mxc/include/mach/iram.h       |   24 +++++++--
 arch/arm/plat-mxc/iram_alloc.c              |   50 +++++---------------
 arch/arm/plat-omap/include/plat/sram.h      |   17 ++++---
 arch/arm/plat-omap/sram.c                   |   34 +++++---------
 drivers/uio/uio_pruss.c                     |    7 ++-
 sound/soc/davinci/davinci-pcm.c             |    9 ++--
 21 files changed, 182 insertions(+), 144 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 903c9c4..7a4a625 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -862,6 +862,7 @@ config ARCH_DAVINCI
 	bool "TI DaVinci"
 	select GENERIC_CLOCKEVENTS
 	select ARCH_REQUIRE_GPIOLIB
+	select PV_POOL
 	select ZONE_DMA
 	select HAVE_IDE
 	select CLKDEV_LOOKUP
@@ -875,6 +876,7 @@ config ARCH_OMAP
 	select HAVE_CLK
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_CPUFREQ
+	select PV_POOL
 	select GENERIC_CLOCKEVENTS
 	select HAVE_SCHED_CLOCK
 	select ARCH_HAS_HOLES_MEMORYMODEL
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index ea5ee4d..abee3ca 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -39,3 +39,7 @@ config SHARP_PARAM
 
 config SHARP_SCOOP
 	bool
+
+config PV_POOL
+	bool
+	select GENERIC_ALLOCATOR
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 6ea9b6f..4ae455e 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_ARCH_IXP2000)	+= uengine.o
 obj-$(CONFIG_ARCH_IXP23XX)	+= uengine.o
 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
 obj-$(CONFIG_ARM_TIMER_SP804)	+= timer-sp.o
+obj-$(CONFIG_PV_POOL)		+= pv-pool.o
diff --git a/arch/arm/common/pv-pool.c b/arch/arm/common/pv-pool.c
index e69de29..748367a 100644
--- a/arch/arm/common/pv-pool.c
+++ b/arch/arm/common/pv-pool.c
@@ -0,0 +1,69 @@
+/*
+ * Unified Phys/Virt allocator, based on mach-davinci/sram.c, which was
+ * Copyright (C) 2009 David Brownell.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/dma-mapping.h>
+#include <linux/genalloc.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+
+#include <asm/pv-pool.h>
+
+struct pv_pool {
+	struct gen_pool *genpool;
+	void *cpu_base;
+	phys_addr_t phys_base;
+};
+
+void *pv_pool_alloc(struct pv_pool *pool, size_t len, phys_addr_t *phys)
+{
+	void *addr = (void *)gen_pool_alloc(pool->genpool, len);
+
+	if (phys)
+		*phys = addr ? (pool->phys_base + (addr - pool->cpu_base)) :
+			 (phys_addr_t)-1ULL;
+
+	return addr;
+}
+EXPORT_SYMBOL_GPL(pv_pool_alloc);
+
+void pv_pool_free(struct pv_pool *pool, void *addr, size_t len)
+{
+	gen_pool_free(pool->genpool, (unsigned long)addr, len);
+}
+EXPORT_SYMBOL_GPL(pv_pool_free);
+
+struct pv_pool *pv_pool_create(void *addr, phys_addr_t phys, size_t len,
+	int min_alloc_order)
+{
+	struct pv_pool *pool = kzalloc(sizeof(struct pv_pool), GFP_KERNEL);
+
+	if (pool) {
+		pool->cpu_base = addr;
+		pool->phys_base = phys;
+		pool->genpool = gen_pool_create(min_alloc_order, -1);
+		if (!pool->genpool) {
+			kfree(pool);
+			pool = NULL;
+		} else {
+			WARN_ON(gen_pool_add(pool->genpool, (unsigned long)addr,
+						len, -1) < 0);
+		}
+	}
+
+	return pool;
+}
+EXPORT_SYMBOL_GPL(pv_pool_create);
+
+void pv_pool_destroy(struct pv_pool *pool)
+{
+	gen_pool_destroy(pool->genpool);
+	kfree(pool);
+}
+EXPORT_SYMBOL_GPL(pv_pool_destroy);
diff --git a/arch/arm/include/asm/pv-pool.h b/arch/arm/include/asm/pv-pool.h
index e69de29..0834216 100644
--- a/arch/arm/include/asm/pv-pool.h
+++ b/arch/arm/include/asm/pv-pool.h
@@ -0,0 +1,20 @@
+#ifndef __ASMARM_PV_POOL_H
+#define __ASMARM_PV_POOL_H
+
+#include <asm/fncpy.h>
+
+struct pv_pool;
+
+void *pv_pool_alloc(struct pv_pool *, size_t, phys_addr_t *);
+void pv_pool_free(struct pv_pool *, void *, size_t);
+struct pv_pool *pv_pool_create(void *, phys_addr_t, size_t, int);
+void pv_pool_destroy(struct pv_pool *);
+
+/* Macro to copy a function into SRAM, using the fncpy API */
+#define pv_pool_fncpy(pool, funcp, size) ({			\
+	size_t _sz = size;					\
+	void *_sram = pv_pool_alloc(pool, _sz, NULL);		\
+	(_sram ? fncpy(_sram, &(funcp), _sz) : NULL);		\
+})
+
+#endif
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index b95b919..09f6c12 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
-	.sram_dma		= DA8XX_ARM_RAM_BASE,
+	.sram_phys		= DA8XX_ARM_RAM_BASE,
 	.sram_len		= SZ_8K,
 	.reset_device		= &da8xx_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a3a94e9..9bda687 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
 	.serial_dev		= &dm355_serial_device,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 4604e72..d306034 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
 	.serial_dev		= &dm365_serial_device,
 	.emac_pdata		= &dm365_emac_pdata,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 4c82c27..3949ed7 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -764,7 +764,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.gpio_irq		= IRQ_GPIOBNK0,
 	.serial_dev		= &dm644x_serial_device,
 	.emac_pdata		= &dm644x_emac_pdata,
-	.sram_dma		= 0x00008000,
+	.sram_phys		= 0x00008000,
 	.sram_len		= SZ_16K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 1e0f809..a4365f7 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -848,7 +848,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
 	.serial_dev		= &dm646x_serial_device,
 	.emac_pdata		= &dm646x_emac_pdata,
-	.sram_dma		= 0x10010000,
+	.sram_phys		= 0x10010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index a57cba2..665d049 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -75,7 +75,7 @@ struct davinci_soc_info {
 	int				gpio_ctlrs_num;
 	struct platform_device		*serial_dev;
 	struct emac_platform_data	*emac_pdata;
-	dma_addr_t			sram_dma;
+	phys_addr_t			sram_phys;
 	unsigned			sram_len;
 	struct platform_device		*reset_device;
 	void				(*reset)(struct platform_device *);
diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h
index 111f7cc..14676de 100644
--- a/arch/arm/mach-davinci/include/mach/sram.h
+++ b/arch/arm/mach-davinci/include/mach/sram.h
@@ -10,18 +10,11 @@
 #ifndef __MACH_SRAM_H
 #define __MACH_SRAM_H
 
+#include <asm/pv-pool.h>
+
 /* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
 #define SRAM_GRANULARITY	512
 
-/*
- * SRAM allocations return a CPU virtual address, or NULL on error.
- * If a DMA address is requested and the SRAM supports DMA, its
- * mapped address is also returned.
- *
- * Errors include SRAM memory not being available, and requesting
- * DMA mapped SRAM on systems which don't allow that.
- */
-extern void *sram_alloc(size_t len, dma_addr_t *dma);
-extern void sram_free(void *addr, size_t len);
+extern struct pv_pool *davinci_pv_pool;
 
 #endif /* __MACH_SRAM_H */
diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index 1bd73a0..c2f9767 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -27,14 +27,9 @@
 #define DEEPSLEEP_SLEEPCOUNT_MASK	0xFFFF
 
 static void (*davinci_sram_suspend) (struct davinci_pm_config *);
+static void *davinci_sram_suspend_mem;
 static struct davinci_pm_config *pdata;
 
-static void davinci_sram_push(void *dest, void *src, unsigned int size)
-{
-	memcpy(dest, src, size);
-	flush_icache_range((unsigned long)dest, (unsigned long)(dest + size));
-}
-
 static void davinci_pm_suspend(void)
 {
 	unsigned val;
@@ -123,14 +118,14 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 		return -ENOENT;
 	}
 
-	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
-	if (!davinci_sram_suspend) {
+	davinci_sram_suspend_mem = pv_pool_alloc(davinci_pv_pool,
+				davinci_cpu_suspend_sz, NULL);
+	if (!davinci_sram_suspend_mem) {
 		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
 		return -ENOMEM;
 	}
-
-	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
-						davinci_cpu_suspend_sz);
+	davinci_sram_suspend = fncpy(davinci_sram_suspend_mem,
+				davinci_cpu_suspend, davinci_cpu_suspend_sz);
 
 	suspend_set_ops(&davinci_pm_ops);
 
@@ -139,7 +134,8 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 
 static int __exit davinci_pm_remove(struct platform_device *pdev)
 {
-	sram_free(davinci_sram_suspend, davinci_cpu_suspend_sz);
+	pv_pool_free(davinci_pv_pool, davinci_sram_suspend_mem,
+		davinci_cpu_suspend_sz);
 	return 0;
 }
 
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index db0f778..219d4c5 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -10,40 +10,13 @@
  */
 #include <linux/module.h>
 #include <linux/init.h>
-#include <linux/genalloc.h>
+#include <asm/pv-pool.h>
 
 #include <mach/common.h>
 #include <mach/sram.h>
 
-static struct gen_pool *sram_pool;
-
-void *sram_alloc(size_t len, dma_addr_t *dma)
-{
-	unsigned long vaddr;
-	dma_addr_t dma_base = davinci_soc_info.sram_dma;
-
-	if (dma)
-		*dma = 0;
-	if (!sram_pool || (dma && !dma_base))
-		return NULL;
-
-	vaddr = gen_pool_alloc(sram_pool, len);
-	if (!vaddr)
-		return NULL;
-
-	if (dma)
-		*dma = dma_base + (vaddr - SRAM_VIRT);
-	return (void *)vaddr;
-
-}
-EXPORT_SYMBOL(sram_alloc);
-
-void sram_free(void *addr, size_t len)
-{
-	gen_pool_free(sram_pool, (unsigned long) addr, len);
-}
-EXPORT_SYMBOL(sram_free);
-
+struct pv_pool *davinci_pv_pool;
+EXPORT_SYMBOL_GPL(davinci_pv_pool);
 
 /*
  * REVISIT This supports CPU and DMA access to/from SRAM, but it
@@ -58,13 +31,12 @@ static int __init sram_init(void)
 
 	if (len) {
 		len = min_t(unsigned, len, SRAM_SIZE);
-		sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
-		if (!sram_pool)
+		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
+					davinci_soc_info.sram_phys, len,
+					ilog2(SRAM_GRANULARITY));
+		if (!davinci_pv_pool)
 			status = -ENOMEM;
 	}
-	if (sram_pool)
-		status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
-	WARN_ON(status < 0);
 	return status;
 }
 core_initcall(sram_init);
diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
index b0cb425..fb23497 100644
--- a/arch/arm/plat-mxc/Kconfig
+++ b/arch/arm/plat-mxc/Kconfig
@@ -118,6 +118,6 @@ config ARCH_MXC_AUDMUX_V2
 
 config IRAM_ALLOC
 	bool
-	select GENERIC_ALLOCATOR
+	select PV_POOL
 
 endif
diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
index 022690c..a989bff 100644
--- a/arch/arm/plat-mxc/include/mach/iram.h
+++ b/arch/arm/plat-mxc/include/mach/iram.h
@@ -17,25 +17,37 @@
  * MA 02110-1301, USA.
  */
 #include <linux/errno.h>
+#include <asm/pv-pool.h>
 
 #ifdef CONFIG_IRAM_ALLOC
 
-int __init iram_init(unsigned long base, unsigned long size);
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr);
-void iram_free(unsigned long dma_addr, unsigned int size);
+int __init iram_init(phys_addr_t base, size_t size);
+
+extern struct pv_pool *mxc_iram_pool;
+
+static inline void *iram_alloc(size_t size, phys_addr_t *phys)
+{
+	return pv_pool_alloc(iram_pool, size, phys);
+}
+
+static inline void iram_free(void *addr, size_t size)
+{
+	pv_pool_free(iram_pool, addr, size);
+}
 
 #else
 
-static inline int __init iram_init(unsigned long base, unsigned long size)
+static inline int __init iram_init(phys_addr_t base, size_t size)
 {
 	return -ENOMEM;
 }
 
-static inline void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
+static inline void *iram_alloc(size_t size, phys_addr_t *phys)
 {
+	*phys = (phys_addr_t)-1ULL;
 	return NULL;
 }
 
-static inline void iram_free(unsigned long base, unsigned long size) {}
+static inline void iram_free(void *addr, size_t size) {}
 
 #endif
diff --git a/arch/arm/plat-mxc/iram_alloc.c b/arch/arm/plat-mxc/iram_alloc.c
index 074c386..30bccc8 100644
--- a/arch/arm/plat-mxc/iram_alloc.c
+++ b/arch/arm/plat-mxc/iram_alloc.c
@@ -24,50 +24,24 @@
 #include <linux/genalloc.h>
 #include <mach/iram.h>
 
-static unsigned long iram_phys_base;
-static void __iomem *iram_virt_base;
-static struct gen_pool *iram_pool;
+struct pv_pool *mxc_iram_pool;
+EXPORT_SYMBOL(mxc_iram_pool);
 
-static inline void __iomem *iram_phys_to_virt(unsigned long p)
+int __init iram_init(phys_addr_t base, size_t size)
 {
-	return iram_virt_base + (p - iram_phys_base);
-}
-
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
-{
-	if (!iram_pool)
-		return NULL;
-
-	*dma_addr = gen_pool_alloc(iram_pool, size);
-	pr_debug("iram alloc - %dB@0x%lX\n", size, *dma_addr);
-	if (!*dma_addr)
-		return NULL;
-	return iram_phys_to_virt(*dma_addr);
-}
-EXPORT_SYMBOL(iram_alloc);
-
-void iram_free(unsigned long addr, unsigned int size)
-{
-	if (!iram_pool)
-		return;
-
-	gen_pool_free(iram_pool, addr, size);
-}
-EXPORT_SYMBOL(iram_free);
+	void *addr = /*FIXME*/ ioremap(base, size);
 
-int __init iram_init(unsigned long base, unsigned long size)
-{
-	iram_phys_base = base;
+	if (!addr)
+		return -EIO;
 
-	iram_pool = gen_pool_create(PAGE_SHIFT, -1);
-	if (!iram_pool)
+	mxc_iram_pool = pv_pool_create(addr, base, size, PAGE_SHIFT);
+	if (!mxc_iram_pool) {
+		iounmap(addr);
 		return -ENOMEM;
+	}
 
-	gen_pool_add(iram_pool, base, size, -1);
-	iram_virt_base = ioremap(iram_phys_base, size);
-	if (!iram_virt_base)
-		return -EIO;
+	pr_debug("i.MX IRAM pool: %lu KB@0x%08llx\n", size / 1024,
+		 (unsigned long long)base);
 
-	pr_debug("i.MX IRAM pool: %ld KB@0x%p\n", size / 1024, iram_virt_base);
 	return 0;
 }
diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..711931a 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -12,16 +12,19 @@
 #define __ARCH_ARM_OMAP_SRAM_H
 
 #ifndef __ASSEMBLY__
-#include <asm/fncpy.h>
+#include <asm/pv-pool.h>
 
-extern void *omap_sram_push_address(unsigned long size);
+extern struct pv_pool *omap_pv_pool;
 
-/* Macro to push a function to the internal SRAM, using the fncpy API */
+/*
+ * Note that fncpy requires the SRAM address to be aligned to an 8-byte
+ * boundary, so the min_alloc_order for the pool is set appropriately.
+ */
 #define omap_sram_push(funcp, size) ({				\
-	typeof(&(funcp)) _res = NULL;				\
-	void *_sram_address = omap_sram_push_address(size);	\
-	if (_sram_address)					\
-		_res = fncpy(_sram_address, &(funcp), size);	\
+	typeof(&(funcp)) _res;					\
+	_res = pv_pool_fncpy(omap_pv_pool, funcp, size);	\
+	if (!_res)						\
+		pr_err("Not enough space in SRAM\n");		\
 	_res;							\
 })
 
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..68f57ff 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -75,7 +75,6 @@
 static unsigned long omap_sram_start;
 static unsigned long omap_sram_base;
 static unsigned long omap_sram_size;
-static unsigned long omap_sram_ceil;
 
 /*
  * Depending on the target RAMFS firewall setup, the public usable amount of
@@ -104,6 +103,8 @@ static int is_sram_locked(void)
 		return 1; /* assume locked with no PPA or security driver */
 }
 
+struct pv_pool *omap_pv_pool;
+
 /*
  * The amount of SRAM depends on the core type.
  * Note that we cannot try to test for SRAM here because writes
@@ -182,7 +183,16 @@ static void __init omap_detect_sram(void)
 			omap_sram_size - SRAM_BOOTLOADER_SZ);
 	omap_sram_size -= reserved;
 
-	omap_sram_ceil = omap_sram_base + omap_sram_size;
+	{
+		/* The first SRAM_BOOTLOADER_SZ of SRAM are reserved */
+		void *base = (void *)omap_sram_base + SRAM_BOOTLOADER_SZ;
+		phys_addr_t phys = omap_sram_start + SRAM_BOOTLOADER_SZ;
+		size_t len = omap_sram_size - SRAM_BOOTLOADER_SZ;
+
+		omap_pv_pool = pv_pool_create(base, phys, len,
+						ilog2(FNCPY_ALIGN));
+		WARN_ON(!omap_pv_pool);
+	}
 }
 
 static struct map_desc omap_sram_io_desc[] __initdata = {
@@ -242,26 +252,6 @@ static void __init omap_map_sram(void)
 	       omap_sram_size - SRAM_BOOTLOADER_SZ);
 }
 
-/*
- * Memory allocator for SRAM: calculates the new ceiling address
- * for pushing a function using the fncpy API.
- *
- * Note that fncpy requires the returned address to be aligned
- * to an 8-byte boundary.
- */
-void *omap_sram_push_address(unsigned long size)
-{
-	if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
-		printk(KERN_ERR "Not enough space in SRAM\n");
-		return NULL;
-	}
-
-	omap_sram_ceil -= size;
-	omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, FNCPY_ALIGN);
-
-	return (void *)omap_sram_ceil;
-}
-
 #ifdef CONFIG_ARCH_OMAP1
 
 static void (*_omap_sram_reprogram_clock)(u32 dpllctl, u32 ckctl);
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index e67b566..0c558e7 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -62,7 +62,7 @@ MODULE_PARM_DESC(extram_pool_sz, "external ram pool size to allocate");
 struct uio_pruss_dev {
 	struct uio_info *info;
 	struct clk *pruss_clk;
-	dma_addr_t sram_paddr;
+	phys_addr_t sram_paddr;
 	dma_addr_t ddr_paddr;
 	void __iomem *prussio_vaddr;
 	void *sram_vaddr;
@@ -106,7 +106,7 @@ static void pruss_cleanup(struct platform_device *dev,
 			gdev->ddr_paddr);
 	}
 	if (gdev->sram_vaddr)
-		sram_free(gdev->sram_vaddr, sram_pool_sz);
+		pv_pool_free(davinci_pv_pool, gdev->sram_vaddr, sram_pool_sz);
 	kfree(gdev->info);
 	clk_put(gdev->pruss_clk);
 	kfree(gdev);
@@ -152,7 +152,8 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
+	gdev->sram_vaddr = pv_pool_alloc(davinci_pv_pool, sram_pool_sz,
+					   &(gdev->sram_paddr));
 	if (!gdev->sram_vaddr) {
 		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
 		goto out_free;
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
index 9d35b8c..621e2a1 100644
--- a/sound/soc/davinci/davinci-pcm.c
+++ b/sound/soc/davinci/davinci-pcm.c
@@ -232,14 +232,14 @@ static int allocate_sram(struct snd_pcm_substream *substream, unsigned size,
 {
 	struct snd_dma_buffer *buf = &substream->dma_buffer;
 	struct snd_dma_buffer *iram_dma = NULL;
-	dma_addr_t iram_phys = 0;
+	phys_addr_t iram_phys;
 	void *iram_virt = NULL;
 
 	if (buf->private_data || !size)
 		return 0;
 
 	ppcm->period_bytes_max = size;
-	iram_virt = sram_alloc(size, &iram_phys);
+	iram_virt = pv_pool_alloc(davinci_pv_pool, size, &iram_phys);
 	if (!iram_virt)
 		goto exit1;
 	iram_dma = kzalloc(sizeof(*iram_dma), GFP_KERNEL);
@@ -253,7 +253,7 @@ static int allocate_sram(struct snd_pcm_substream *substream, unsigned size,
 	return 0;
 exit2:
 	if (iram_virt)
-		sram_free(iram_virt, size);
+		pv_pool_free(davinci_pv_pool, iram_virt, size);
 exit1:
 	return -ENOMEM;
 }
@@ -803,7 +803,8 @@ static void davinci_pcm_free(struct snd_pcm *pcm)
 		buf->area = NULL;
 		iram_dma = buf->private_data;
 		if (iram_dma) {
-			sram_free(iram_dma->area, iram_dma->bytes);
+			pv_pool_free(davinci_pv_pool, iram_dma->area,
+				iram_dma->bytes);
 			kfree(iram_dma);
 		}
 	}

[RFC PATCH v3] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.

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 version fixes the davinci pm free, and adds updates for the
davinci pcm driver.  As I don't know what's happening with Jean's
patch tweaking the genpool allocator, I've kept my version.

This still suffers from the "only one region per pvpool" problem
which I believe Jean's patch doesn't suffer.

 arch/arm/Kconfig                            |    2 +
 arch/arm/common/Kconfig                     |    4 ++
 arch/arm/common/Makefile                    |    1 +
 arch/arm/common/pv-pool.c                   |   69 +++++++++++++++++++++++++++
 arch/arm/include/asm/pv-pool.h              |   20 ++++++++
 arch/arm/mach-davinci/da850.c               |    2 +-
 arch/arm/mach-davinci/dm355.c               |    2 +-
 arch/arm/mach-davinci/dm365.c               |    2 +-
 arch/arm/mach-davinci/dm644x.c              |    2 +-
 arch/arm/mach-davinci/dm646x.c              |    2 +-
 arch/arm/mach-davinci/include/mach/common.h |    2 +-
 arch/arm/mach-davinci/include/mach/sram.h   |   13 +----
 arch/arm/mach-davinci/pm.c                  |   20 +++-----
 arch/arm/mach-davinci/sram.c                |   42 +++--------------
 arch/arm/plat-mxc/Kconfig                   |    2 +-
 arch/arm/plat-mxc/include/mach/iram.h       |   24 +++++++--
 arch/arm/plat-mxc/iram_alloc.c              |   50 +++++---------------
 arch/arm/plat-omap/include/plat/sram.h      |   17 ++++---
 arch/arm/plat-omap/sram.c                   |   34 +++++---------
 drivers/uio/uio_pruss.c                     |    7 ++-
 sound/soc/davinci/davinci-pcm.c             |    9 ++--
 21 files changed, 182 insertions(+), 144 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 903c9c4..7a4a625 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -862,6 +862,7 @@ config ARCH_DAVINCI
 	bool "TI DaVinci"
 	select GENERIC_CLOCKEVENTS
 	select ARCH_REQUIRE_GPIOLIB
+	select PV_POOL
 	select ZONE_DMA
 	select HAVE_IDE
 	select CLKDEV_LOOKUP
@@ -875,6 +876,7 @@ config ARCH_OMAP
 	select HAVE_CLK
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_CPUFREQ
+	select PV_POOL
 	select GENERIC_CLOCKEVENTS
 	select HAVE_SCHED_CLOCK
 	select ARCH_HAS_HOLES_MEMORYMODEL
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index ea5ee4d..abee3ca 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -39,3 +39,7 @@ config SHARP_PARAM
 
 config SHARP_SCOOP
 	bool
+
+config PV_POOL
+	bool
+	select GENERIC_ALLOCATOR
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 6ea9b6f..4ae455e 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_ARCH_IXP2000)	+= uengine.o
 obj-$(CONFIG_ARCH_IXP23XX)	+= uengine.o
 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
 obj-$(CONFIG_ARM_TIMER_SP804)	+= timer-sp.o
+obj-$(CONFIG_PV_POOL)		+= pv-pool.o
diff --git a/arch/arm/common/pv-pool.c b/arch/arm/common/pv-pool.c
index e69de29..748367a 100644
--- a/arch/arm/common/pv-pool.c
+++ b/arch/arm/common/pv-pool.c
@@ -0,0 +1,69 @@
+/*
+ * Unified Phys/Virt allocator, based on mach-davinci/sram.c, which was
+ * Copyright (C) 2009 David Brownell.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/dma-mapping.h>
+#include <linux/genalloc.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+
+#include <asm/pv-pool.h>
+
+struct pv_pool {
+	struct gen_pool *genpool;
+	void *cpu_base;
+	phys_addr_t phys_base;
+};
+
+void *pv_pool_alloc(struct pv_pool *pool, size_t len, phys_addr_t *phys)
+{
+	void *addr = (void *)gen_pool_alloc(pool->genpool, len);
+
+	if (phys)
+		*phys = addr ? (pool->phys_base + (addr - pool->cpu_base)) :
+			 (phys_addr_t)-1ULL;
+
+	return addr;
+}
+EXPORT_SYMBOL_GPL(pv_pool_alloc);
+
+void pv_pool_free(struct pv_pool *pool, void *addr, size_t len)
+{
+	gen_pool_free(pool->genpool, (unsigned long)addr, len);
+}
+EXPORT_SYMBOL_GPL(pv_pool_free);
+
+struct pv_pool *pv_pool_create(void *addr, phys_addr_t phys, size_t len,
+	int min_alloc_order)
+{
+	struct pv_pool *pool = kzalloc(sizeof(struct pv_pool), GFP_KERNEL);
+
+	if (pool) {
+		pool->cpu_base = addr;
+		pool->phys_base = phys;
+		pool->genpool = gen_pool_create(min_alloc_order, -1);
+		if (!pool->genpool) {
+			kfree(pool);
+			pool = NULL;
+		} else {
+			WARN_ON(gen_pool_add(pool->genpool, (unsigned long)addr,
+						len, -1) < 0);
+		}
+	}
+
+	return pool;
+}
+EXPORT_SYMBOL_GPL(pv_pool_create);
+
+void pv_pool_destroy(struct pv_pool *pool)
+{
+	gen_pool_destroy(pool->genpool);
+	kfree(pool);
+}
+EXPORT_SYMBOL_GPL(pv_pool_destroy);
diff --git a/arch/arm/include/asm/pv-pool.h b/arch/arm/include/asm/pv-pool.h
index e69de29..0834216 100644
--- a/arch/arm/include/asm/pv-pool.h
+++ b/arch/arm/include/asm/pv-pool.h
@@ -0,0 +1,20 @@
+#ifndef __ASMARM_PV_POOL_H
+#define __ASMARM_PV_POOL_H
+
+#include <asm/fncpy.h>
+
+struct pv_pool;
+
+void *pv_pool_alloc(struct pv_pool *, size_t, phys_addr_t *);
+void pv_pool_free(struct pv_pool *, void *, size_t);
+struct pv_pool *pv_pool_create(void *, phys_addr_t, size_t, int);
+void pv_pool_destroy(struct pv_pool *);
+
+/* Macro to copy a function into SRAM, using the fncpy API */
+#define pv_pool_fncpy(pool, funcp, size) ({			\
+	size_t _sz = size;					\
+	void *_sram = pv_pool_alloc(pool, _sz, NULL);		\
+	(_sram ? fncpy(_sram, &(funcp), _sz) : NULL);		\
+})
+
+#endif
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index b95b919..09f6c12 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
-	.sram_dma		= DA8XX_ARM_RAM_BASE,
+	.sram_phys		= DA8XX_ARM_RAM_BASE,
 	.sram_len		= SZ_8K,
 	.reset_device		= &da8xx_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a3a94e9..9bda687 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
 	.serial_dev		= &dm355_serial_device,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 4604e72..d306034 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
 	.serial_dev		= &dm365_serial_device,
 	.emac_pdata		= &dm365_emac_pdata,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 4c82c27..3949ed7 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -764,7 +764,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.gpio_irq		= IRQ_GPIOBNK0,
 	.serial_dev		= &dm644x_serial_device,
 	.emac_pdata		= &dm644x_emac_pdata,
-	.sram_dma		= 0x00008000,
+	.sram_phys		= 0x00008000,
 	.sram_len		= SZ_16K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 1e0f809..a4365f7 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -848,7 +848,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
 	.serial_dev		= &dm646x_serial_device,
 	.emac_pdata		= &dm646x_emac_pdata,
-	.sram_dma		= 0x10010000,
+	.sram_phys		= 0x10010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index a57cba2..665d049 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -75,7 +75,7 @@ struct davinci_soc_info {
 	int				gpio_ctlrs_num;
 	struct platform_device		*serial_dev;
 	struct emac_platform_data	*emac_pdata;
-	dma_addr_t			sram_dma;
+	phys_addr_t			sram_phys;
 	unsigned			sram_len;
 	struct platform_device		*reset_device;
 	void				(*reset)(struct platform_device *);
diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h
index 111f7cc..14676de 100644
--- a/arch/arm/mach-davinci/include/mach/sram.h
+++ b/arch/arm/mach-davinci/include/mach/sram.h
@@ -10,18 +10,11 @@
 #ifndef __MACH_SRAM_H
 #define __MACH_SRAM_H
 
+#include <asm/pv-pool.h>
+
 /* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
 #define SRAM_GRANULARITY	512
 
-/*
- * SRAM allocations return a CPU virtual address, or NULL on error.
- * If a DMA address is requested and the SRAM supports DMA, its
- * mapped address is also returned.
- *
- * Errors include SRAM memory not being available, and requesting
- * DMA mapped SRAM on systems which don't allow that.
- */
-extern void *sram_alloc(size_t len, dma_addr_t *dma);
-extern void sram_free(void *addr, size_t len);
+extern struct pv_pool *davinci_pv_pool;
 
 #endif /* __MACH_SRAM_H */
diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index 1bd73a0..c2f9767 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -27,14 +27,9 @@
 #define DEEPSLEEP_SLEEPCOUNT_MASK	0xFFFF
 
 static void (*davinci_sram_suspend) (struct davinci_pm_config *);
+static void *davinci_sram_suspend_mem;
 static struct davinci_pm_config *pdata;
 
-static void davinci_sram_push(void *dest, void *src, unsigned int size)
-{
-	memcpy(dest, src, size);
-	flush_icache_range((unsigned long)dest, (unsigned long)(dest + size));
-}
-
 static void davinci_pm_suspend(void)
 {
 	unsigned val;
@@ -123,14 +118,14 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 		return -ENOENT;
 	}
 
-	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
-	if (!davinci_sram_suspend) {
+	davinci_sram_suspend_mem = pv_pool_alloc(davinci_pv_pool,
+				davinci_cpu_suspend_sz, NULL);
+	if (!davinci_sram_suspend_mem) {
 		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
 		return -ENOMEM;
 	}
-
-	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
-						davinci_cpu_suspend_sz);
+	davinci_sram_suspend = fncpy(davinci_sram_suspend_mem,
+				davinci_cpu_suspend, davinci_cpu_suspend_sz);
 
 	suspend_set_ops(&davinci_pm_ops);
 
@@ -139,7 +134,8 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 
 static int __exit davinci_pm_remove(struct platform_device *pdev)
 {
-	sram_free(davinci_sram_suspend, davinci_cpu_suspend_sz);
+	pv_pool_free(davinci_pv_pool, davinci_sram_suspend_mem,
+		davinci_cpu_suspend_sz);
 	return 0;
 }
 
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index db0f778..219d4c5 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -10,40 +10,13 @@
  */
 #include <linux/module.h>
 #include <linux/init.h>
-#include <linux/genalloc.h>
+#include <asm/pv-pool.h>
 
 #include <mach/common.h>
 #include <mach/sram.h>
 
-static struct gen_pool *sram_pool;
-
-void *sram_alloc(size_t len, dma_addr_t *dma)
-{
-	unsigned long vaddr;
-	dma_addr_t dma_base = davinci_soc_info.sram_dma;
-
-	if (dma)
-		*dma = 0;
-	if (!sram_pool || (dma && !dma_base))
-		return NULL;
-
-	vaddr = gen_pool_alloc(sram_pool, len);
-	if (!vaddr)
-		return NULL;
-
-	if (dma)
-		*dma = dma_base + (vaddr - SRAM_VIRT);
-	return (void *)vaddr;
-
-}
-EXPORT_SYMBOL(sram_alloc);
-
-void sram_free(void *addr, size_t len)
-{
-	gen_pool_free(sram_pool, (unsigned long) addr, len);
-}
-EXPORT_SYMBOL(sram_free);
-
+struct pv_pool *davinci_pv_pool;
+EXPORT_SYMBOL_GPL(davinci_pv_pool);
 
 /*
  * REVISIT This supports CPU and DMA access to/from SRAM, but it
@@ -58,13 +31,12 @@ static int __init sram_init(void)
 
 	if (len) {
 		len = min_t(unsigned, len, SRAM_SIZE);
-		sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
-		if (!sram_pool)
+		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
+					davinci_soc_info.sram_phys, len,
+					ilog2(SRAM_GRANULARITY));
+		if (!davinci_pv_pool)
 			status = -ENOMEM;
 	}
-	if (sram_pool)
-		status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
-	WARN_ON(status < 0);
 	return status;
 }
 core_initcall(sram_init);
diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
index b0cb425..fb23497 100644
--- a/arch/arm/plat-mxc/Kconfig
+++ b/arch/arm/plat-mxc/Kconfig
@@ -118,6 +118,6 @@ config ARCH_MXC_AUDMUX_V2
 
 config IRAM_ALLOC
 	bool
-	select GENERIC_ALLOCATOR
+	select PV_POOL
 
 endif
diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
index 022690c..a989bff 100644
--- a/arch/arm/plat-mxc/include/mach/iram.h
+++ b/arch/arm/plat-mxc/include/mach/iram.h
@@ -17,25 +17,37 @@
  * MA 02110-1301, USA.
  */
 #include <linux/errno.h>
+#include <asm/pv-pool.h>
 
 #ifdef CONFIG_IRAM_ALLOC
 
-int __init iram_init(unsigned long base, unsigned long size);
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr);
-void iram_free(unsigned long dma_addr, unsigned int size);
+int __init iram_init(phys_addr_t base, size_t size);
+
+extern struct pv_pool *mxc_iram_pool;
+
+static inline void *iram_alloc(size_t size, phys_addr_t *phys)
+{
+	return pv_pool_alloc(iram_pool, size, phys);
+}
+
+static inline void iram_free(void *addr, size_t size)
+{
+	pv_pool_free(iram_pool, addr, size);
+}
 
 #else
 
-static inline int __init iram_init(unsigned long base, unsigned long size)
+static inline int __init iram_init(phys_addr_t base, size_t size)
 {
 	return -ENOMEM;
 }
 
-static inline void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
+static inline void *iram_alloc(size_t size, phys_addr_t *phys)
 {
+	*phys = (phys_addr_t)-1ULL;
 	return NULL;
 }
 
-static inline void iram_free(unsigned long base, unsigned long size) {}
+static inline void iram_free(void *addr, size_t size) {}
 
 #endif
diff --git a/arch/arm/plat-mxc/iram_alloc.c b/arch/arm/plat-mxc/iram_alloc.c
index 074c386..30bccc8 100644
--- a/arch/arm/plat-mxc/iram_alloc.c
+++ b/arch/arm/plat-mxc/iram_alloc.c
@@ -24,50 +24,24 @@
 #include <linux/genalloc.h>
 #include <mach/iram.h>
 
-static unsigned long iram_phys_base;
-static void __iomem *iram_virt_base;
-static struct gen_pool *iram_pool;
+struct pv_pool *mxc_iram_pool;
+EXPORT_SYMBOL(mxc_iram_pool);
 
-static inline void __iomem *iram_phys_to_virt(unsigned long p)
+int __init iram_init(phys_addr_t base, size_t size)
 {
-	return iram_virt_base + (p - iram_phys_base);
-}
-
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
-{
-	if (!iram_pool)
-		return NULL;
-
-	*dma_addr = gen_pool_alloc(iram_pool, size);
-	pr_debug("iram alloc - %dB at 0x%lX\n", size, *dma_addr);
-	if (!*dma_addr)
-		return NULL;
-	return iram_phys_to_virt(*dma_addr);
-}
-EXPORT_SYMBOL(iram_alloc);
-
-void iram_free(unsigned long addr, unsigned int size)
-{
-	if (!iram_pool)
-		return;
-
-	gen_pool_free(iram_pool, addr, size);
-}
-EXPORT_SYMBOL(iram_free);
+	void *addr = /*FIXME*/ ioremap(base, size);
 
-int __init iram_init(unsigned long base, unsigned long size)
-{
-	iram_phys_base = base;
+	if (!addr)
+		return -EIO;
 
-	iram_pool = gen_pool_create(PAGE_SHIFT, -1);
-	if (!iram_pool)
+	mxc_iram_pool = pv_pool_create(addr, base, size, PAGE_SHIFT);
+	if (!mxc_iram_pool) {
+		iounmap(addr);
 		return -ENOMEM;
+	}
 
-	gen_pool_add(iram_pool, base, size, -1);
-	iram_virt_base = ioremap(iram_phys_base, size);
-	if (!iram_virt_base)
-		return -EIO;
+	pr_debug("i.MX IRAM pool: %lu KB at 0x%08llx\n", size / 1024,
+		 (unsigned long long)base);
 
-	pr_debug("i.MX IRAM pool: %ld KB at 0x%p\n", size / 1024, iram_virt_base);
 	return 0;
 }
diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..711931a 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -12,16 +12,19 @@
 #define __ARCH_ARM_OMAP_SRAM_H
 
 #ifndef __ASSEMBLY__
-#include <asm/fncpy.h>
+#include <asm/pv-pool.h>
 
-extern void *omap_sram_push_address(unsigned long size);
+extern struct pv_pool *omap_pv_pool;
 
-/* Macro to push a function to the internal SRAM, using the fncpy API */
+/*
+ * Note that fncpy requires the SRAM address to be aligned to an 8-byte
+ * boundary, so the min_alloc_order for the pool is set appropriately.
+ */
 #define omap_sram_push(funcp, size) ({				\
-	typeof(&(funcp)) _res = NULL;				\
-	void *_sram_address = omap_sram_push_address(size);	\
-	if (_sram_address)					\
-		_res = fncpy(_sram_address, &(funcp), size);	\
+	typeof(&(funcp)) _res;					\
+	_res = pv_pool_fncpy(omap_pv_pool, funcp, size);	\
+	if (!_res)						\
+		pr_err("Not enough space in SRAM\n");		\
 	_res;							\
 })
 
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..68f57ff 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -75,7 +75,6 @@
 static unsigned long omap_sram_start;
 static unsigned long omap_sram_base;
 static unsigned long omap_sram_size;
-static unsigned long omap_sram_ceil;
 
 /*
  * Depending on the target RAMFS firewall setup, the public usable amount of
@@ -104,6 +103,8 @@ static int is_sram_locked(void)
 		return 1; /* assume locked with no PPA or security driver */
 }
 
+struct pv_pool *omap_pv_pool;
+
 /*
  * The amount of SRAM depends on the core type.
  * Note that we cannot try to test for SRAM here because writes
@@ -182,7 +183,16 @@ static void __init omap_detect_sram(void)
 			omap_sram_size - SRAM_BOOTLOADER_SZ);
 	omap_sram_size -= reserved;
 
-	omap_sram_ceil = omap_sram_base + omap_sram_size;
+	{
+		/* The first SRAM_BOOTLOADER_SZ of SRAM are reserved */
+		void *base = (void *)omap_sram_base + SRAM_BOOTLOADER_SZ;
+		phys_addr_t phys = omap_sram_start + SRAM_BOOTLOADER_SZ;
+		size_t len = omap_sram_size - SRAM_BOOTLOADER_SZ;
+
+		omap_pv_pool = pv_pool_create(base, phys, len,
+						ilog2(FNCPY_ALIGN));
+		WARN_ON(!omap_pv_pool);
+	}
 }
 
 static struct map_desc omap_sram_io_desc[] __initdata = {
@@ -242,26 +252,6 @@ static void __init omap_map_sram(void)
 	       omap_sram_size - SRAM_BOOTLOADER_SZ);
 }
 
-/*
- * Memory allocator for SRAM: calculates the new ceiling address
- * for pushing a function using the fncpy API.
- *
- * Note that fncpy requires the returned address to be aligned
- * to an 8-byte boundary.
- */
-void *omap_sram_push_address(unsigned long size)
-{
-	if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
-		printk(KERN_ERR "Not enough space in SRAM\n");
-		return NULL;
-	}
-
-	omap_sram_ceil -= size;
-	omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, FNCPY_ALIGN);
-
-	return (void *)omap_sram_ceil;
-}
-
 #ifdef CONFIG_ARCH_OMAP1
 
 static void (*_omap_sram_reprogram_clock)(u32 dpllctl, u32 ckctl);
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index e67b566..0c558e7 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -62,7 +62,7 @@ MODULE_PARM_DESC(extram_pool_sz, "external ram pool size to allocate");
 struct uio_pruss_dev {
 	struct uio_info *info;
 	struct clk *pruss_clk;
-	dma_addr_t sram_paddr;
+	phys_addr_t sram_paddr;
 	dma_addr_t ddr_paddr;
 	void __iomem *prussio_vaddr;
 	void *sram_vaddr;
@@ -106,7 +106,7 @@ static void pruss_cleanup(struct platform_device *dev,
 			gdev->ddr_paddr);
 	}
 	if (gdev->sram_vaddr)
-		sram_free(gdev->sram_vaddr, sram_pool_sz);
+		pv_pool_free(davinci_pv_pool, gdev->sram_vaddr, sram_pool_sz);
 	kfree(gdev->info);
 	clk_put(gdev->pruss_clk);
 	kfree(gdev);
@@ -152,7 +152,8 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
+	gdev->sram_vaddr = pv_pool_alloc(davinci_pv_pool, sram_pool_sz,
+					   &(gdev->sram_paddr));
 	if (!gdev->sram_vaddr) {
 		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
 		goto out_free;
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
index 9d35b8c..621e2a1 100644
--- a/sound/soc/davinci/davinci-pcm.c
+++ b/sound/soc/davinci/davinci-pcm.c
@@ -232,14 +232,14 @@ static int allocate_sram(struct snd_pcm_substream *substream, unsigned size,
 {
 	struct snd_dma_buffer *buf = &substream->dma_buffer;
 	struct snd_dma_buffer *iram_dma = NULL;
-	dma_addr_t iram_phys = 0;
+	phys_addr_t iram_phys;
 	void *iram_virt = NULL;
 
 	if (buf->private_data || !size)
 		return 0;
 
 	ppcm->period_bytes_max = size;
-	iram_virt = sram_alloc(size, &iram_phys);
+	iram_virt = pv_pool_alloc(davinci_pv_pool, size, &iram_phys);
 	if (!iram_virt)
 		goto exit1;
 	iram_dma = kzalloc(sizeof(*iram_dma), GFP_KERNEL);
@@ -253,7 +253,7 @@ static int allocate_sram(struct snd_pcm_substream *substream, unsigned size,
 	return 0;
 exit2:
 	if (iram_virt)
-		sram_free(iram_virt, size);
+		pv_pool_free(davinci_pv_pool, iram_virt, size);
 exit1:
 	return -ENOMEM;
 }
@@ -803,7 +803,8 @@ static void davinci_pcm_free(struct snd_pcm *pcm)
 		buf->area = NULL;
 		iram_dma = buf->private_data;
 		if (iram_dma) {
-			sram_free(iram_dma->area, iram_dma->bytes);
+			pv_pool_free(davinci_pv_pool, iram_dma->area,
+				iram_dma->bytes);
 			kfree(iram_dma);
 		}
 	}

Re: [RFC PATCH v3] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:45 Thu 12 May     , Russell King - ARM Linux wrote:
> On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.
> 
> 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 version fixes the davinci pm free, and adds updates for the
> davinci pcm driver.  As I don't know what's happening with Jean's
> patch tweaking the genpool allocator, I've kept my version.
> 
> This still suffers from the "only one region per pvpool" problem
> which I believe Jean's patch doesn't suffer.
yes excatly and on at91sam9263 I need this :(

Best Regards,
J.

[RFC PATCH v3] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:45 Thu 12 May     , Russell King - ARM Linux wrote:
> On Fri, Apr 15, 2011 at 02:06:07PM +0100, 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.
> 
> 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 version fixes the davinci pm free, and adds updates for the
> davinci pcm driver.  As I don't know what's happening with Jean's
> patch tweaking the genpool allocator, I've kept my version.
> 
> This still suffers from the "only one region per pvpool" problem
> which I believe Jean's patch doesn't suffer.
yes excatly and on at91sam9263 I need this :(

Best Regards,
J.

Re: [RFC PATCH v3] Consolidate SRAM support

[Jean Pihet]

On Thu, May 12, 2011 at 7:45 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>    This version fixes the davinci pm free, and adds updates for the
>    davinci pcm driver.  As I don't know what's happening with Jean's
>    patch tweaking the genpool allocator, I've kept my version.

Sorry I do not get the question. The latest changes I submitted have
been merged in mainline as 'ARM: 6649/1: omap: use fncpy to copy the
PM code functions to SRAM' [1] . Thanks for that!
This change is only about the simple linear SRAM allocator, not the
genpool allocator.

>    This still suffers from the "only one region per pvpool" problem
>    which I believe Jean's patch doesn't suffer.

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b6338bdc8305b27688a7feb8689e4ccfd42f0292

Regards,
Jean

[RFC PATCH v3] Consolidate SRAM support

[Jean Pihet]

On Thu, May 12, 2011 at 7:45 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>    This version fixes the davinci pm free, and adds updates for the
>    davinci pcm driver.  As I don't know what's happening with Jean's
>    patch tweaking the genpool allocator, I've kept my version.

Sorry I do not get the question. The latest changes I submitted have
been merged in mainline as 'ARM: 6649/1: omap: use fncpy to copy the
PM code functions to SRAM' [1] . Thanks for that!
This change is only about the simple linear SRAM allocator, not the
genpool allocator.

>    This still suffers from the "only one region per pvpool" problem
>    which I believe Jean's patch doesn't suffer.

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b6338bdc8305b27688a7feb8689e4ccfd42f0292

Regards,
Jean

Re: [RFC PATCH v3] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, May 13, 2011 at 09:30:14AM +0200, Jean Pihet wrote:
> On Thu, May 12, 2011 at 7:45 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >    This version fixes the davinci pm free, and adds updates for the
> >    davinci pcm driver.  As I don't know what's happening with Jean's
> >    patch tweaking the genpool allocator, I've kept my version.
> 
> Sorry I do not get the question. The latest changes I submitted have
> been merged in mainline as 'ARM: 6649/1: omap: use fncpy to copy the
> PM code functions to SRAM' [1] . Thanks for that!
> This change is only about the simple linear SRAM allocator, not the
> genpool allocator.

The wrong Jean!  I meant Jean-Christophe PLAGNIOL-VILLARD.

[RFC PATCH v3] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, May 13, 2011 at 09:30:14AM +0200, Jean Pihet wrote:
> On Thu, May 12, 2011 at 7:45 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >    This version fixes the davinci pm free, and adds updates for the
> >    davinci pcm driver.  As I don't know what's happening with Jean's
> >    patch tweaking the genpool allocator, I've kept my version.
> 
> Sorry I do not get the question. The latest changes I submitted have
> been merged in mainline as 'ARM: 6649/1: omap: use fncpy to copy the
> PM code functions to SRAM' [1] . Thanks for that!
> This change is only about the simple linear SRAM allocator, not the
> genpool allocator.

The wrong Jean!  I meant Jean-Christophe PLAGNIOL-VILLARD.

Re: [RFC PATCH v3] Consolidate SRAM support

[Santosh Shilimkar]

Russell,

On 5/12/2011 11:15 PM, Russell King - ARM Linux wrote:
> On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote:
> This is work in progress.
>

Tried this patch on OMAP and found couple of issues.

1. Compilation break. Below is the fix for the same.

diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 68f57ff..78d1af4 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -75,6 +75,7 @@
  static unsigned long omap_sram_start;
  static unsigned long omap_sram_base;
  static unsigned long omap_sram_size;
+static unsigned long omap_sram_ceil;

  /*
   * Depending on the target RAMFS firewall setup, the public usable 
amount of
-- 
1.6.0.4


2. The boot takes data abort while allocating memory for
struct pv_pool. Here is the back-trace.
I haven't debugged it further though.

-000|NSR:0xFFFF0010(asm)
  -->|exception
-001|kmem_cache_alloc_trace(size = 0x0C, cachep = 0x0, flags = 0x80D0)
-002|pv_pool_create(addr = 0xFE400000, phys = 0x40200000, len = 
0x00010000, min_alloc_order = 0x3)
-003|omap_sram_init()
-004|paging_init(?)
-005|setup_arch(cmdline_p = 0xC058BFE4)
-006|start_kernel()
-007|NSR:0x8000803C(asm)
  ---|end of frame
     |

Regards
Santosh

[RFC PATCH v3] Consolidate SRAM support

[Santosh Shilimkar]

Russell,

On 5/12/2011 11:15 PM, Russell King - ARM Linux wrote:
> On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote:
> This is work in progress.
>

Tried this patch on OMAP and found couple of issues.

1. Compilation break. Below is the fix for the same.

diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 68f57ff..78d1af4 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -75,6 +75,7 @@
  static unsigned long omap_sram_start;
  static unsigned long omap_sram_base;
  static unsigned long omap_sram_size;
+static unsigned long omap_sram_ceil;

  /*
   * Depending on the target RAMFS firewall setup, the public usable 
amount of
-- 
1.6.0.4


2. The boot takes data abort while allocating memory for
struct pv_pool. Here is the back-trace.
I haven't debugged it further though.

-000|NSR:0xFFFF0010(asm)
  -->|exception
-001|kmem_cache_alloc_trace(size = 0x0C, cachep = 0x0, flags = 0x80D0)
-002|pv_pool_create(addr = 0xFE400000, phys = 0x40200000, len = 
0x00010000, min_alloc_order = 0x3)
-003|omap_sram_init()
-004|paging_init(?)
-005|setup_arch(cmdline_p = 0xC058BFE4)
-006|start_kernel()
-007|NSR:0x8000803C(asm)
  ---|end of frame
     |

Regards
Santosh

Re: [RFC PATCH v3] Consolidate SRAM support

[Jean Pihet]

On Fri, May 13, 2011 at 11:11 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, May 13, 2011 at 09:30:14AM +0200, Jean Pihet wrote:
>> On Thu, May 12, 2011 at 7:45 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> >    This version fixes the davinci pm free, and adds updates for the
>> >    davinci pcm driver.  As I don't know what's happening with Jean's
>> >    patch tweaking the genpool allocator, I've kept my version.
>>
>> Sorry I do not get the question. The latest changes I submitted have
>> been merged in mainline as 'ARM: 6649/1: omap: use fncpy to copy the
>> PM code functions to SRAM' [1] . Thanks for that!
>> This change is only about the simple linear SRAM allocator, not the
>> genpool allocator.
>
> The wrong Jean!  I meant Jean-Christophe PLAGNIOL-VILLARD.
Ok, sorry about that!

Regards,
Jean

>
--
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

[RFC PATCH v3] Consolidate SRAM support

[Jean Pihet]

On Fri, May 13, 2011 at 11:11 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, May 13, 2011 at 09:30:14AM +0200, Jean Pihet wrote:
>> On Thu, May 12, 2011 at 7:45 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > ? ?This version fixes the davinci pm free, and adds updates for the
>> > ? ?davinci pcm driver. ?As I don't know what's happening with Jean's
>> > ? ?patch tweaking the genpool allocator, I've kept my version.
>>
>> Sorry I do not get the question. The latest changes I submitted have
>> been merged in mainline as 'ARM: 6649/1: omap: use fncpy to copy the
>> PM code functions to SRAM' [1] . Thanks for that!
>> This change is only about the simple linear SRAM allocator, not the
>> genpool allocator.
>
> The wrong Jean! ?I meant Jean-Christophe PLAGNIOL-VILLARD.
Ok, sorry about that!

Regards,
Jean

>

RE: [RFC PATCH v3] Consolidate SRAM support

[Nori, Sekhar]

Hi Russell,

On Thu, May 12, 2011 at 23:15:46, Russell King - ARM Linux wrote:

> diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
> index 1bd73a0..c2f9767 100644
> --- a/arch/arm/mach-davinci/pm.c
> +++ b/arch/arm/mach-davinci/pm.c

[...]

> @@ -123,14 +118,14 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
>  		return -ENOENT;
>  	}
>  
> -	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
> -	if (!davinci_sram_suspend) {
> +	davinci_sram_suspend_mem = pv_pool_alloc(davinci_pv_pool,
> +				davinci_cpu_suspend_sz, NULL);
> +	if (!davinci_sram_suspend_mem) {
>  		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
>  		return -ENOMEM;
>  	}
> -
> -	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
> -						davinci_cpu_suspend_sz);
> +	davinci_sram_suspend = fncpy(davinci_sram_suspend_mem,
> +				davinci_cpu_suspend, davinci_cpu_suspend_sz);

This gave these build errors:

arch/arm/mach-davinci/pm.c: In function 'davinci_pm_probe':
arch/arm/mach-davinci/pm.c:127: error: lvalue required in asm statement
arch/arm/mach-davinci/pm.c:127: error: invalid lvalue in asm output 0
make[1]: *** [arch/arm/mach-davinci/pm.o] Error 1

Replacing davinci_cpu_suspend with &davinci_cpu_suspend fixed the issue.

With that change done, tested suspend-to-RAM on DA850 platform.
Also tested audio driver on DM365 platform with IRAM buffers enabled.

Can you also fold the following patch in? Without this the
kernel panics when suspend-to-RAM is enabled. 

diff --git a/arch/arm/mach-davinci/sleep.S b/arch/arm/mach-davinci/sleep.S
index fb5e72b..2cef533 100644
--- a/arch/arm/mach-davinci/sleep.S
+++ b/arch/arm/mach-davinci/sleep.S
@@ -37,6 +37,7 @@
 #define DEEPSLEEP_SLEEPENABLE_BIT      BIT(31)

        .text
+       .align 3
 /*
  * Move DaVinci into deep sleep state
  *

Thanks,
Sekhar

[RFC PATCH v3] Consolidate SRAM support

[Nori, Sekhar]

Hi Russell,

On Thu, May 12, 2011 at 23:15:46, Russell King - ARM Linux wrote:

> diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
> index 1bd73a0..c2f9767 100644
> --- a/arch/arm/mach-davinci/pm.c
> +++ b/arch/arm/mach-davinci/pm.c

[...]

> @@ -123,14 +118,14 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
>  		return -ENOENT;
>  	}
>  
> -	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
> -	if (!davinci_sram_suspend) {
> +	davinci_sram_suspend_mem = pv_pool_alloc(davinci_pv_pool,
> +				davinci_cpu_suspend_sz, NULL);
> +	if (!davinci_sram_suspend_mem) {
>  		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
>  		return -ENOMEM;
>  	}
> -
> -	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
> -						davinci_cpu_suspend_sz);
> +	davinci_sram_suspend = fncpy(davinci_sram_suspend_mem,
> +				davinci_cpu_suspend, davinci_cpu_suspend_sz);

This gave these build errors:

arch/arm/mach-davinci/pm.c: In function 'davinci_pm_probe':
arch/arm/mach-davinci/pm.c:127: error: lvalue required in asm statement
arch/arm/mach-davinci/pm.c:127: error: invalid lvalue in asm output 0
make[1]: *** [arch/arm/mach-davinci/pm.o] Error 1

Replacing davinci_cpu_suspend with &davinci_cpu_suspend fixed the issue.

With that change done, tested suspend-to-RAM on DA850 platform.
Also tested audio driver on DM365 platform with IRAM buffers enabled.

Can you also fold the following patch in? Without this the
kernel panics when suspend-to-RAM is enabled. 

diff --git a/arch/arm/mach-davinci/sleep.S b/arch/arm/mach-davinci/sleep.S
index fb5e72b..2cef533 100644
--- a/arch/arm/mach-davinci/sleep.S
+++ b/arch/arm/mach-davinci/sleep.S
@@ -37,6 +37,7 @@
 #define DEEPSLEEP_SLEEPENABLE_BIT      BIT(31)

        .text
+       .align 3
 /*
  * Move DaVinci into deep sleep state
  *

Thanks,
Sekhar

[PATCH 0/9]

[Ben Gardiner]

The davinci platforms are mapping their io regions using iotables. This patch
series converts them to mapping using ioremap. 

This series is based on-top-of '[RFC PATCH v3] Consolidate SRAM support' from
Russell King.

The first patch in the series is a squash of the neccessary changes as
reported by Sekhar Nori in that thread.

The davinci sram init is first changed to ioremap the regions specified by 
each of the soc_infos; then the iotables are each removed; then the SRAM_VIRT
definition is removed. Finally, the da850's sram region is changed from 
the ARM local RAM region to the Shared RAM region. This change is needed
to support mcasp ping-pong buffers on da850. Suspend was tested with rtcwake
and was found to work.

Ben Gardiner (7):
  davinci: sram: ioremap the davinci_soc_info specified sram regions
  davinci: da850: remove the SRAM_VIRT iotable entry
  davinci: dm355: remove the SRAM_VIRT iotable entry
  davinci: dm365: remove the SRAM_VIRT iotable entry
  davinci: dm644x: remove the SRAM_VIRT iotable entry
  davinci: dm646x: remove the SRAM_VIRT iotable entry
  davinci: remove definition of SRAM_VIRT

Nori, Sekhar (1):
  davinci: pm: fix compiler errors and kernel panics from sram
    consolidation

Subhasish Ghosh (1):
  davinci: da850: changed SRAM allocator to shared ram.

 arch/arm/mach-davinci/da850.c               |   10 ++--------
 arch/arm/mach-davinci/dm355.c               |    6 ------
 arch/arm/mach-davinci/dm365.c               |    6 ------
 arch/arm/mach-davinci/dm644x.c              |    6 ------
 arch/arm/mach-davinci/dm646x.c              |    6 ------
 arch/arm/mach-davinci/include/mach/common.h |    2 --
 arch/arm/mach-davinci/include/mach/da8xx.h  |    1 +
 arch/arm/mach-davinci/pm.c                  |    2 +-
 arch/arm/mach-davinci/sleep.S               |    1 +
 arch/arm/mach-davinci/sram.c                |   12 ++++++++++--
 10 files changed, 15 insertions(+), 37 deletions(-)

-- 
1.7.4.1

[PATCH 1/9] davinci: pm: fix compiler errors and kernel panics from sram consolidation

[Ben Gardiner]

From: Nori, Sekhar <nsekhar@ti.com>

Hi Russell,

On Thu, May 12, 2011 at 23:15:46, Russell King - ARM Linux wrote:

> diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
> index 1bd73a0..c2f9767 100644
> --- a/arch/arm/mach-davinci/pm.c
> +++ b/arch/arm/mach-davinci/pm.c

[...]

> @@ -123,14 +118,14 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
>  		return -ENOENT;
>  	}
>
> -	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
> -	if (!davinci_sram_suspend) {
> +	davinci_sram_suspend_mem = pv_pool_alloc(davinci_pv_pool,
> +				davinci_cpu_suspend_sz, NULL);
> +	if (!davinci_sram_suspend_mem) {
>  		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
>  		return -ENOMEM;
>  	}
> -
> -	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
> -						davinci_cpu_suspend_sz);
> +	davinci_sram_suspend = fncpy(davinci_sram_suspend_mem,
> +				davinci_cpu_suspend, davinci_cpu_suspend_sz);

This gave these build errors:

arch/arm/mach-davinci/pm.c: In function 'davinci_pm_probe':
arch/arm/mach-davinci/pm.c:127: error: lvalue required in asm statement
arch/arm/mach-davinci/pm.c:127: error: invalid lvalue in asm output 0
make[1]: *** [arch/arm/mach-davinci/pm.o] Error 1

Replacing davinci_cpu_suspend with &davinci_cpu_suspend fixed the issue.

With that change done, tested suspend-to-RAM on DA850 platform.
Also tested audio driver on DM365 platform with IRAM buffers enabled.

Can you also fold the following patch in? Without this the
kernel panics when suspend-to-RAM is enabled.

Thanks,
Sekhar
---
 arch/arm/mach-davinci/pm.c    |    2 +-
 arch/arm/mach-davinci/sleep.S |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index c2f9767..5255223 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -125,7 +125,7 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 	davinci_sram_suspend = fncpy(davinci_sram_suspend_mem,
-				davinci_cpu_suspend, davinci_cpu_suspend_sz);
+				&davinci_cpu_suspend, davinci_cpu_suspend_sz);
 
 	suspend_set_ops(&davinci_pm_ops);
 
diff --git a/arch/arm/mach-davinci/sleep.S b/arch/arm/mach-davinci/sleep.S
index fb5e72b..2cef533 100644
--- a/arch/arm/mach-davinci/sleep.S
+++ b/arch/arm/mach-davinci/sleep.S
@@ -37,6 +37,7 @@
 #define DEEPSLEEP_SLEEPENABLE_BIT	BIT(31)
 
 	.text
+	.align 3
 /*
  * Move DaVinci into deep sleep state
  *
-- 
1.7.4.1

[PATCH 2/9] davinci: sram: ioremap the davinci_soc_info specified sram regions

[Ben Gardiner]

The current davinci init sets up SRAM in iotables. There has been an observed
failure to boot a da850 with 128K specified in the iotable.

Make the davinci sram allocator -- now based on RMK's consolidated SRAM
support -- do an ioremap of the region specified by the entries in
davinci_soc_info before registering with pv_pool_create().

This commit breaks runtime of davinci boards since the regions that
the sram init is now trying to ioremap have been iomapped by their
iotable entries. The iotable entries will be removed in the patches
to come.

Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
---
 arch/arm/mach-davinci/sram.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index 219d4c5..96026df 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -8,6 +8,7 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  */
+#include <linux/io.h>
 #include <linux/module.h>
 #include <linux/init.h>
 #include <asm/pv-pool.h>
@@ -26,16 +27,23 @@ EXPORT_SYMBOL_GPL(davinci_pv_pool);
  */
 static int __init sram_init(void)
 {
+	void *addr;
 	unsigned len = davinci_soc_info.sram_len;
 	int status = 0;
 
 	if (len) {
 		len = min_t(unsigned, len, SRAM_SIZE);
-		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
+		addr = ioremap(davinci_soc_info.sram_phys, len);
+		if (!addr)
+			return -EIO;
+
+		davinci_pv_pool = pv_pool_create(addr,
 					davinci_soc_info.sram_phys, len,
 					ilog2(SRAM_GRANULARITY));
-		if (!davinci_pv_pool)
+		if (!davinci_pv_pool) {
+			iounmap(addr);
 			status = -ENOMEM;
+		}
 	}
 	return status;
 }
-- 
1.7.4.1

[PATCH 3/9] davinci: da850: remove the SRAM_VIRT iotable entry

[Ben Gardiner]

The sram region defined for da850 in the iotable entry removed is also
defined in its davinci_soc_info, davinci_soc_info_da850 in da850.c.

Remove this duplicate information which is now uneccessary since sram
init will ioremap the region defined by davinci_soc_info_da850.

Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
---
 arch/arm/mach-davinci/da850.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 09f6c12..5754338 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -725,12 +725,6 @@ static struct map_desc da850_io_desc[] = {
 		.length		= DA8XX_CP_INTC_SIZE,
 		.type		= MT_DEVICE
 	},
-	{
-		.virtual	= SRAM_VIRT,
-		.pfn		= __phys_to_pfn(DA8XX_ARM_RAM_BASE),
-		.length		= SZ_8K,
-		.type		= MT_DEVICE
-	},
 };
 
 static u32 da850_psc_bases[] = { DA8XX_PSC0_BASE, DA8XX_PSC1_BASE };
-- 
1.7.4.1

[PATCH 4/9] davinci: dm355: remove the SRAM_VIRT iotable entry

[Ben Gardiner]

The sram region defined for dm355 in the iotable entry removed is also
defined in its davinci_soc_info, davinci_soc_info_dm355 in dm355.c.

Remove this duplicate information which is now uneccessary since sram
init will ioremap the region defined by davinci_soc_info_dm355.

Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
---
 arch/arm/mach-davinci/dm355.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 9bda687..94f44d3 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -757,12 +757,6 @@ static struct map_desc dm355_io_desc[] = {
 		.length		= IO_SIZE,
 		.type		= MT_DEVICE
 	},
-	{
-		.virtual	= SRAM_VIRT,
-		.pfn		= __phys_to_pfn(0x00010000),
-		.length		= SZ_32K,
-		.type		= MT_MEMORY_NONCACHED,
-	},
 };
 
 /* Contents of JTAG ID register used to identify exact cpu type */
-- 
1.7.4.1

[PATCH 5/9] davinci: dm365: remove the SRAM_VIRT iotable entry

[Ben Gardiner]

The sram region defined for dm365 in the iotable entry removed is also
defined in its davinci_soc_info, davinci_soc_info_dm365 in dm365.c.

Remove this duplicate information which is now uneccessary since sram
init will ioremap the region defined by davinci_soc_info_dm365.

Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
---
 arch/arm/mach-davinci/dm365.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index d306034..58f5b0a 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -970,12 +970,6 @@ static struct map_desc dm365_io_desc[] = {
 		.length		= IO_SIZE,
 		.type		= MT_DEVICE
 	},
-	{
-		.virtual	= SRAM_VIRT,
-		.pfn		= __phys_to_pfn(0x00010000),
-		.length		= SZ_32K,
-		.type		= MT_MEMORY_NONCACHED,
-	},
 };
 
 static struct resource dm365_ks_resources[] = {
-- 
1.7.4.1

[PATCH 6/9] davinci: dm644x: remove the SRAM_VIRT iotable entry

[Ben Gardiner]

The sram region defined for dm644x in the iotable entry removed is also
defined in its davinci_soc_info, davinci_soc_info_dm644x in da644x.c.

Remove this duplicate information which is now uneccessary since sram
init will ioremap the region defined by davinci_soc_info_dm644x.

Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
---
 arch/arm/mach-davinci/dm644x.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 3949ed7..11e6481 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -663,12 +663,6 @@ static struct map_desc dm644x_io_desc[] = {
 		.length		= IO_SIZE,
 		.type		= MT_DEVICE
 	},
-	{
-		.virtual	= SRAM_VIRT,
-		.pfn		= __phys_to_pfn(0x00008000),
-		.length		= SZ_16K,
-		.type		= MT_MEMORY_NONCACHED,
-	},
 };
 
 /* Contents of JTAG ID register used to identify exact cpu type */
-- 
1.7.4.1

[PATCH 7/9] davinci: dm646x: remove the SRAM_VIRT iotable entry

[Ben Gardiner]

The sram region defined for dm646x in the iotable entry removed is also
defined in its davinci_soc_info, davinci_soc_info_dm646x in dm646x.c.

Remove this duplicate information which is now uneccessary since sram
init will ioremap the region defined by davinci_soc_info_dm646x.

Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
---
 arch/arm/mach-davinci/dm646x.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index a4365f7..57d697e 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -747,12 +747,6 @@ static struct map_desc dm646x_io_desc[] = {
 		.length		= IO_SIZE,
 		.type		= MT_DEVICE
 	},
-	{
-		.virtual	= SRAM_VIRT,
-		.pfn		= __phys_to_pfn(0x00010000),
-		.length		= SZ_32K,
-		.type		= MT_MEMORY_NONCACHED,
-	},
 };
 
 /* Contents of JTAG ID register used to identify exact cpu type */
-- 
1.7.4.1

[PATCH 8/9] davinci: remove definition of SRAM_VIRT

[Ben Gardiner]

Previously all platforms were iomapping their SRAM using iotable entries with
SRAM_VIRT as the target virtual address.

Remove the SRAM_VIRT definition now that all the iotables are removed and
sram init is doing ioremaps before regsitering with pv_pool_create.

Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
---
 arch/arm/mach-davinci/include/mach/common.h |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 665d049..16b5ec5 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -86,8 +86,6 @@ extern struct davinci_soc_info davinci_soc_info;
 extern void davinci_common_init(struct davinci_soc_info *soc_info);
 extern void davinci_init_ide(void);
 
-/* standard place to map on-chip SRAMs; they *may* support DMA */
-#define SRAM_VIRT	0xfffe0000
 #define SRAM_SIZE	SZ_128K
 
 #endif /* __ARCH_ARM_MACH_DAVINCI_COMMON_H */
-- 
1.7.4.1

[PATCH 9/9] davinci: da850: changed SRAM allocator to shared ram.

[Ben Gardiner]

From: Subhasish Ghosh <subhasish@mistralsolutions.com>

This patch modifies the sram allocator to allocate memory
from the DA8XX shared RAM.

Signed-off-by: Subhasish Ghosh <subhasish@mistralsolutions.com>
[rebased onto consolidated SRAM patches]
Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
---
 arch/arm/mach-davinci/da850.c              |    4 ++--
 arch/arm/mach-davinci/include/mach/da8xx.h |    1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 5754338..cdb7e77 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1093,8 +1093,8 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
-	.sram_phys		= DA8XX_ARM_RAM_BASE,
-	.sram_len		= SZ_8K,
+	.sram_phys		= DA8XX_SHARED_RAM_BASE,
+	.sram_len		= SZ_128K,
 	.reset_device		= &da8xx_wdt_device,
 };
 
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index e4fc1af..09b8ddb 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -72,6 +72,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_AEMIF_CTL_BASE	0x68000000
 #define DA8XX_DDR2_CTL_BASE	0xb0000000
 #define DA8XX_ARM_RAM_BASE	0xffff0000
+#define DA8XX_SHARED_RAM_BASE	0x80000000
 
 void __init da830_init(void);
 void __init da850_init(void);
-- 
1.7.4.1

[PATCH 2/9] davinci: sram: ioremap the davinci_soc_info specified sram regions

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:41 Tue 17 May     , Ben Gardiner wrote:
> The current davinci init sets up SRAM in iotables. There has been an observed
> failure to boot a da850 with 128K specified in the iotable.
> 
> Make the davinci sram allocator -- now based on RMK's consolidated SRAM
> support -- do an ioremap of the region specified by the entries in
> davinci_soc_info before registering with pv_pool_create().
> 
> This commit breaks runtime of davinci boards since the regions that
> the sram init is now trying to ioremap have been iomapped by their
> iotable entries. The iotable entries will be removed in the patches
> to come.
> 
> Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
> ---
>  arch/arm/mach-davinci/sram.c |   12 ++++++++++--
>  1 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> index 219d4c5..96026df 100644
> --- a/arch/arm/mach-davinci/sram.c
> +++ b/arch/arm/mach-davinci/sram.c
> @@ -8,6 +8,7 @@
>   * the Free Software Foundation; either version 2 of the License, or
>   * (at your option) any later version.
>   */
> +#include <linux/io.h>
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <asm/pv-pool.h>
> @@ -26,16 +27,23 @@ EXPORT_SYMBOL_GPL(davinci_pv_pool);
>   */
>  static int __init sram_init(void)
>  {
> +	void *addr;
>  	unsigned len = davinci_soc_info.sram_len;
>  	int status = 0;
>  
>  	if (len) {
>  		len = min_t(unsigned, len, SRAM_SIZE);
> -		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
> +		addr = ioremap(davinci_soc_info.sram_phys, len);
> +		if (!addr)
> +			return -EIO;
> +
> +		davinci_pv_pool = pv_pool_create(addr,
>  					davinci_soc_info.sram_phys, len,
>  					ilog2(SRAM_GRANULARITY));
please use the gennalloc directly as discuss with Andrew and Russell my patch
will present in the .40

Best Regards,
J.

[PATCH 9/9] davinci: da850: changed SRAM allocator to shared ram.

[Sergei Shtylyov]

Hello.

On 18-05-2011 1:42, Ben Gardiner wrote:

> From: Subhasish Ghosh<subhasish@mistralsolutions.com>

> This patch modifies the sram allocator to allocate memory
> from the DA8XX shared RAM.

> Signed-off-by: Subhasish Ghosh<subhasish@mistralsolutions.com>
> [rebased onto consolidated SRAM patches]
> Signed-off-by: Ben Gardiner<bengardiner@nanometrics.ca>
[...]

> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 5754338..cdb7e77 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -1093,8 +1093,8 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
>   	.gpio_irq		= IRQ_DA8XX_GPIO0,
>   	.serial_dev		=&da8xx_serial_device,
>   	.emac_pdata		=&da8xx_emac_pdata,
> -	.sram_phys		= DA8XX_ARM_RAM_BASE,
> -	.sram_len		= SZ_8K,
> +	.sram_phys		= DA8XX_SHARED_RAM_BASE,
> +	.sram_len		= SZ_128K,
>   	.reset_device		=&da8xx_wdt_device,
>   };

    I wonder why da830.c doesn't have SRAM setting?

> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
> index e4fc1af..09b8ddb 100644
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -72,6 +72,7 @@ extern unsigned int da850_max_speed;
>   #define DA8XX_AEMIF_CTL_BASE	0x68000000
>   #define DA8XX_DDR2_CTL_BASE	0xb0000000
>   #define DA8XX_ARM_RAM_BASE	0xffff0000
> +#define DA8XX_SHARED_RAM_BASE	0x80000000

    Please keep this list sorted.

WBR, Sergei

[PATCH 8/9] davinci: remove definition of SRAM_VIRT

[Sergei Shtylyov]

Hello.

On 18-05-2011 1:42, Ben Gardiner wrote:

> Previously all platforms were iomapping their SRAM using iotable entries with
> SRAM_VIRT as the target virtual address.

> Remove the SRAM_VIRT definition now that all the iotables are removed and
> sram init is doing ioremaps before regsitering with pv_pool_create.

> Signed-off-by: Ben Gardiner<bengardiner@nanometrics.ca>

    I think patches 3-8 can safely be merged into one patch.

WBR, Sergei

[PATCH 2/9] davinci: sram: ioremap the davinci_soc_info specified sram regions

[Nori, Sekhar]

Hi Russell,

On Wed, May 18, 2011 at 10:21:40, Jean-Christophe PLAGNIOL-VILLARD wrote:

> On 17:41 Tue 17 May     , Ben Gardiner wrote:

> > diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> > index 219d4c5..96026df 100644
> > --- a/arch/arm/mach-davinci/sram.c
> > +++ b/arch/arm/mach-davinci/sram.c
> > @@ -8,6 +8,7 @@
> >   * the Free Software Foundation; either version 2 of the License, or
> >   * (at your option) any later version.
> >   */
> > +#include <linux/io.h>
> >  #include <linux/module.h>
> >  #include <linux/init.h>
> >  #include <asm/pv-pool.h>
> > @@ -26,16 +27,23 @@ EXPORT_SYMBOL_GPL(davinci_pv_pool);
> >   */
> >  static int __init sram_init(void)
> >  {
> > +	void *addr;
> >  	unsigned len = davinci_soc_info.sram_len;
> >  	int status = 0;
> >  
> >  	if (len) {
> >  		len = min_t(unsigned, len, SRAM_SIZE);
> > -		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
> > +		addr = ioremap(davinci_soc_info.sram_phys, len);
> > +		if (!addr)
> > +			return -EIO;
> > +
> > +		davinci_pv_pool = pv_pool_create(addr,
> >  					davinci_soc_info.sram_phys, len,
> >  					ilog2(SRAM_GRANULARITY));
> please use the gennalloc directly as discuss with Andrew and Russell my patch
> will present in the .40

With Jean-Christophe's patch getting merged, would you be dropping
your PV pool patch?

Thanks,
Sekhar

[PATCH 2/9] davinci: sram: ioremap the davinci_soc_info specified sram regions

[Russell King - ARM Linux]

On Wed, May 18, 2011 at 05:41:56PM +0530, Nori, Sekhar wrote:
> Hi Russell,
> 
> On Wed, May 18, 2011 at 10:21:40, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 
> > On 17:41 Tue 17 May     , Ben Gardiner wrote:
> 
> > > diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> > > index 219d4c5..96026df 100644
> > > --- a/arch/arm/mach-davinci/sram.c
> > > +++ b/arch/arm/mach-davinci/sram.c
> > > @@ -8,6 +8,7 @@
> > >   * the Free Software Foundation; either version 2 of the License, or
> > >   * (at your option) any later version.
> > >   */
> > > +#include <linux/io.h>
> > >  #include <linux/module.h>
> > >  #include <linux/init.h>
> > >  #include <asm/pv-pool.h>
> > > @@ -26,16 +27,23 @@ EXPORT_SYMBOL_GPL(davinci_pv_pool);
> > >   */
> > >  static int __init sram_init(void)
> > >  {
> > > +	void *addr;
> > >  	unsigned len = davinci_soc_info.sram_len;
> > >  	int status = 0;
> > >  
> > >  	if (len) {
> > >  		len = min_t(unsigned, len, SRAM_SIZE);
> > > -		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
> > > +		addr = ioremap(davinci_soc_info.sram_phys, len);
> > > +		if (!addr)
> > > +			return -EIO;
> > > +
> > > +		davinci_pv_pool = pv_pool_create(addr,
> > >  					davinci_soc_info.sram_phys, len,
> > >  					ilog2(SRAM_GRANULARITY));
> > please use the gennalloc directly as discuss with Andrew and Russell my patch
> > will present in the .40
> 
> With Jean-Christophe's patch getting merged, would you be dropping
> your PV pool patch?

I'll make that decision once JC's patch has actually been merged.  JC's
patch doesn't do any of the consolidation work, so that needs addressing
still.

[PATCH 9/9] davinci: da850: changed SRAM allocator to shared ram.

[Ben Gardiner]

Hi Sergei,

Thank you for the reviews.

On Wed, May 18, 2011 at 6:29 AM, Sergei Shtylyov <sshtylyov@mvista.com> wrote:

[...]

>> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
>> b/arch/arm/mach-davinci/include/mach/da8xx.h
>> index e4fc1af..09b8ddb 100644
>> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
>> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
>> @@ -72,6 +72,7 @@ extern unsigned int da850_max_speed;
>> ?#define DA8XX_AEMIF_CTL_BASE ?0x68000000
>> ?#define DA8XX_DDR2_CTL_BASE ? 0xb0000000
>> ?#define DA8XX_ARM_RAM_BASE ? ?0xffff0000
>> +#define DA8XX_SHARED_RAM_BASE ?0x80000000
>
> ? Please keep this list sorted.

Will do so in V2. I am currently imagining that the v2 series will be
based on Russell's next SRAM consolidation patch based on
Jean-Christophe's genpool patch.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

[PATCH 2/9] davinci: sram: ioremap the davinci_soc_info specified sram regions

[Nori, Sekhar]

Hi Ben,

On Wed, May 18, 2011 at 03:11:58, Ben Gardiner wrote:

> diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> index 219d4c5..96026df 100644
> --- a/arch/arm/mach-davinci/sram.c
> +++ b/arch/arm/mach-davinci/sram.c
> @@ -8,6 +8,7 @@
>   * the Free Software Foundation; either version 2 of the License, or
>   * (at your option) any later version.
>   */
> +#include <linux/io.h>
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <asm/pv-pool.h>
> @@ -26,16 +27,23 @@ EXPORT_SYMBOL_GPL(davinci_pv_pool);
>   */
>  static int __init sram_init(void)
>  {
> +	void *addr;
>  	unsigned len = davinci_soc_info.sram_len;
>  	int status = 0;
>  
>  	if (len) {
>  		len = min_t(unsigned, len, SRAM_SIZE);
> -		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
> +		addr = ioremap(davinci_soc_info.sram_phys, len);
> +		if (!addr)
> +			return -EIO;

-ENOMEM here (for the next time you post). See Sergei's
mail on error codes below. Useful stuff.

https://patchwork.kernel.org/patch/47365/

Thanks,
Sekhar

[PATCH 2/9] davinci: sram: ioremap the davinci_soc_info specified sram regions

[Ben Gardiner]

Hi Sekhar,

Thanks for the review.

On Wed, May 18, 2011 at 9:18 AM, Nori, Sekhar <nsekhar@ti.com> wrote:

[...]

>> ? ? ? if (len) {
>> ? ? ? ? ? ? ? len = min_t(unsigned, len, SRAM_SIZE);
>> - ? ? ? ? ? ? davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
>> + ? ? ? ? ? ? addr = ioremap(davinci_soc_info.sram_phys, len);
>> + ? ? ? ? ? ? if (!addr)
>> + ? ? ? ? ? ? ? ? ? ? return -EIO;
>
> -ENOMEM here (for the next time you post). See Sergei's
> mail on error codes below. Useful stuff.
>
> https://patchwork.kernel.org/patch/47365/

Will do. Thanks for the useful reference also (and to Sergei for writing it).

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

[PATCH 2/9] davinci: sram: ioremap the davinci_soc_info specified sram regions

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:14 Wed 18 May     , Russell King - ARM Linux wrote:
> On Wed, May 18, 2011 at 05:41:56PM +0530, Nori, Sekhar wrote:
> > Hi Russell,
> > 
> > On Wed, May 18, 2011 at 10:21:40, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > 
> > > On 17:41 Tue 17 May     , Ben Gardiner wrote:
> > 
> > > > diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> > > > index 219d4c5..96026df 100644
> > > > --- a/arch/arm/mach-davinci/sram.c
> > > > +++ b/arch/arm/mach-davinci/sram.c
> > > > @@ -8,6 +8,7 @@
> > > >   * the Free Software Foundation; either version 2 of the License, or
> > > >   * (at your option) any later version.
> > > >   */
> > > > +#include <linux/io.h>
> > > >  #include <linux/module.h>
> > > >  #include <linux/init.h>
> > > >  #include <asm/pv-pool.h>
> > > > @@ -26,16 +27,23 @@ EXPORT_SYMBOL_GPL(davinci_pv_pool);
> > > >   */
> > > >  static int __init sram_init(void)
> > > >  {
> > > > +	void *addr;
> > > >  	unsigned len = davinci_soc_info.sram_len;
> > > >  	int status = 0;
> > > >  
> > > >  	if (len) {
> > > >  		len = min_t(unsigned, len, SRAM_SIZE);
> > > > -		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
> > > > +		addr = ioremap(davinci_soc_info.sram_phys, len);
> > > > +		if (!addr)
> > > > +			return -EIO;
> > > > +
> > > > +		davinci_pv_pool = pv_pool_create(addr,
> > > >  					davinci_soc_info.sram_phys, len,
> > > >  					ilog2(SRAM_GRANULARITY));
> > > please use the gennalloc directly as discuss with Andrew and Russell my patch
> > > will present in the .40
> > 
> > With Jean-Christophe's patch getting merged, would you be dropping
> > your PV pool patch?
> 
> I'll make that decision once JC's patch has actually been merged.  JC's
> patch doesn't do any of the consolidation work, so that needs addressing
> still.
Agreed this patch just add the support to have physicall address link to the
pool, the consolidation need to be done on the top of it

Hope see the merge soon

Best Regards,
J.

[PATCH 2/9] davinci: sram: ioremap the davinci_soc_info specified sram regions

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:58 Wed 18 May     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:14 Wed 18 May     , Russell King - ARM Linux wrote:
> > On Wed, May 18, 2011 at 05:41:56PM +0530, Nori, Sekhar wrote:
> > > Hi Russell,
> > > 
> > > On Wed, May 18, 2011 at 10:21:40, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > 
> > > > On 17:41 Tue 17 May     , Ben Gardiner wrote:
> > > 
> > > > > diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> > > > > index 219d4c5..96026df 100644
> > > > > --- a/arch/arm/mach-davinci/sram.c
> > > > > +++ b/arch/arm/mach-davinci/sram.c
> > > > > @@ -8,6 +8,7 @@
> > > > >   * the Free Software Foundation; either version 2 of the License, or
> > > > >   * (at your option) any later version.
> > > > >   */
> > > > > +#include <linux/io.h>
> > > > >  #include <linux/module.h>
> > > > >  #include <linux/init.h>
> > > > >  #include <asm/pv-pool.h>
> > > > > @@ -26,16 +27,23 @@ EXPORT_SYMBOL_GPL(davinci_pv_pool);
> > > > >   */
> > > > >  static int __init sram_init(void)
> > > > >  {
> > > > > +	void *addr;
> > > > >  	unsigned len = davinci_soc_info.sram_len;
> > > > >  	int status = 0;
> > > > >  
> > > > >  	if (len) {
> > > > >  		len = min_t(unsigned, len, SRAM_SIZE);
> > > > > -		davinci_pv_pool = pv_pool_create((void *)SRAM_VIRT,
> > > > > +		addr = ioremap(davinci_soc_info.sram_phys, len);
> > > > > +		if (!addr)
> > > > > +			return -EIO;
> > > > > +
> > > > > +		davinci_pv_pool = pv_pool_create(addr,
> > > > >  					davinci_soc_info.sram_phys, len,
> > > > >  					ilog2(SRAM_GRANULARITY));
> > > > please use the gennalloc directly as discuss with Andrew and Russell my patch
> > > > will present in the .40
> > > 
> > > With Jean-Christophe's patch getting merged, would you be dropping
> > > your PV pool patch?
> > 
> > I'll make that decision once JC's patch has actually been merged.  JC's
> > patch doesn't do any of the consolidation work, so that needs addressing
> > still.
> Agreed this patch just add the support to have physicall address link to the
> pool, the consolidation need to be done on the top of it
> 
> Hope see the merge soon
patch in linus tree
commit 3c8f370ded3483 and 6aae6e0304d

Best Regards,
J.

[RFC PATCH v4] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

From: Russell King - ARM Linux <linux@arm.linux.org.uk>

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.

For this use the generic allocator and the newly introduce
gen_pool_add_virt and gen_pool_virt_to_phys

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>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
---
v4:
	update against linus tree and genalloc gen_pool_add_virt and
	gen_pool_virt_to_phys

Best Regards,
J.
 arch/arm/Kconfig                                   |    2 +
 arch/arm/mach-davinci/da850.c                      |    2 +-
 arch/arm/mach-davinci/dm355.c                      |    2 +-
 arch/arm/mach-davinci/dm365.c                      |    2 +-
 arch/arm/mach-davinci/dm644x.c                     |    2 +-
 arch/arm/mach-davinci/dm646x.c                     |    2 +-
 arch/arm/mach-davinci/include/mach/common.h        |    2 +-
 arch/arm/mach-davinci/include/mach/sram.h          |   13 +----
 arch/arm/mach-davinci/pm.c                         |   21 +++----
 arch/arm/mach-davinci/sram.c                       |   57 +++++--------------
 arch/arm/plat-mxc/include/mach/iram.h              |   28 ++++++++--
 .../plat-mxc/{include/mach/iram.h => iram_alloc.c} |   40 ++++++++------
 arch/arm/plat-omap/include/plat/sram.h             |   19 +++++--
 arch/arm/plat-omap/sram.c                          |   38 +++++--------
 drivers/uio/uio_pruss.c                            |   10 +++-
 sound/soc/davinci/davinci-pcm.c                    |   11 +++--
 16 files changed, 122 insertions(+), 129 deletions(-)
 copy arch/arm/plat-mxc/{include/mach/iram.h => iram_alloc.c} (56%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f4b7dfa..5ec5e5f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -848,6 +848,7 @@ config ARCH_DAVINCI
 	bool "TI DaVinci"
 	select GENERIC_CLOCKEVENTS
 	select ARCH_REQUIRE_GPIOLIB
+	select GENERIC_ALLOCATOR
 	select ZONE_DMA
 	select HAVE_IDE
 	select CLKDEV_LOOKUP
@@ -862,6 +863,7 @@ config ARCH_OMAP
 	select HAVE_CLK
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_CPUFREQ
+	select GENERIC_ALLOCATOR
 	select GENERIC_CLOCKEVENTS
 	select HAVE_SCHED_CLOCK
 	select ARCH_HAS_HOLES_MEMORYMODEL
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index b95b919..09f6c12 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
-	.sram_dma		= DA8XX_ARM_RAM_BASE,
+	.sram_phys		= DA8XX_ARM_RAM_BASE,
 	.sram_len		= SZ_8K,
 	.reset_device		= &da8xx_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a3a94e9..9bda687 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
 	.serial_dev		= &dm355_serial_device,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 4604e72..d306034 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
 	.serial_dev		= &dm365_serial_device,
 	.emac_pdata		= &dm365_emac_pdata,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 4c82c27..3949ed7 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -764,7 +764,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.gpio_irq		= IRQ_GPIOBNK0,
 	.serial_dev		= &dm644x_serial_device,
 	.emac_pdata		= &dm644x_emac_pdata,
-	.sram_dma		= 0x00008000,
+	.sram_phys		= 0x00008000,
 	.sram_len		= SZ_16K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 1e0f809..a4365f7 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -848,7 +848,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
 	.serial_dev		= &dm646x_serial_device,
 	.emac_pdata		= &dm646x_emac_pdata,
-	.sram_dma		= 0x10010000,
+	.sram_phys		= 0x10010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index a57cba2..665d049 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -75,7 +75,7 @@ struct davinci_soc_info {
 	int				gpio_ctlrs_num;
 	struct platform_device		*serial_dev;
 	struct emac_platform_data	*emac_pdata;
-	dma_addr_t			sram_dma;
+	phys_addr_t			sram_phys;
 	unsigned			sram_len;
 	struct platform_device		*reset_device;
 	void				(*reset)(struct platform_device *);
diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h
index 111f7cc..aa52009 100644
--- a/arch/arm/mach-davinci/include/mach/sram.h
+++ b/arch/arm/mach-davinci/include/mach/sram.h
@@ -10,18 +10,11 @@
 #ifndef __MACH_SRAM_H
 #define __MACH_SRAM_H
 
+#include <linux/genalloc.h>
+
 /* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
 #define SRAM_GRANULARITY	512
 
-/*
- * SRAM allocations return a CPU virtual address, or NULL on error.
- * If a DMA address is requested and the SRAM supports DMA, its
- * mapped address is also returned.
- *
- * Errors include SRAM memory not being available, and requesting
- * DMA mapped SRAM on systems which don't allow that.
- */
-extern void *sram_alloc(size_t len, dma_addr_t *dma);
-extern void sram_free(void *addr, size_t len);
+extern struct gen_pool *davinci_gen_pool;
 
 #endif /* __MACH_SRAM_H */
diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index 1bd73a0..ef2ebe4 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -17,6 +17,7 @@
 
 #include <asm/cacheflush.h>
 #include <asm/delay.h>
+#include <asm/fncpy.h>
 
 #include <mach/da8xx.h>
 #include <mach/sram.h>
@@ -27,14 +28,9 @@
 #define DEEPSLEEP_SLEEPCOUNT_MASK	0xFFFF
 
 static void (*davinci_sram_suspend) (struct davinci_pm_config *);
+static void *davinci_sram_suspend_mem;
 static struct davinci_pm_config *pdata;
 
-static void davinci_sram_push(void *dest, void *src, unsigned int size)
-{
-	memcpy(dest, src, size);
-	flush_icache_range((unsigned long)dest, (unsigned long)(dest + size));
-}
-
 static void davinci_pm_suspend(void)
 {
 	unsigned val;
@@ -123,14 +119,14 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 		return -ENOENT;
 	}
 
-	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
-	if (!davinci_sram_suspend) {
+	davinci_sram_suspend_mem = (void *)gen_pool_alloc(davinci_gen_pool,
+				davinci_cpu_suspend_sz);
+	if (!davinci_sram_suspend_mem) {
 		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
 		return -ENOMEM;
 	}
-
-	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
-						davinci_cpu_suspend_sz);
+	davinci_sram_suspend = fncpy(davinci_sram_suspend_mem,
+				&davinci_cpu_suspend, davinci_cpu_suspend_sz);
 
 	suspend_set_ops(&davinci_pm_ops);
 
@@ -139,7 +135,8 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 
 static int __exit davinci_pm_remove(struct platform_device *pdev)
 {
-	sram_free(davinci_sram_suspend, davinci_cpu_suspend_sz);
+	gen_pool_free(davinci_gen_pool, (unsigned long)davinci_sram_suspend_mem,
+		davinci_cpu_suspend_sz);
 	return 0;
 }
 
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index db0f778..2c53db2 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -10,40 +10,12 @@
  */
 #include <linux/module.h>
 #include <linux/init.h>
-#include <linux/genalloc.h>
 
 #include <mach/common.h>
 #include <mach/sram.h>
 
-static struct gen_pool *sram_pool;
-
-void *sram_alloc(size_t len, dma_addr_t *dma)
-{
-	unsigned long vaddr;
-	dma_addr_t dma_base = davinci_soc_info.sram_dma;
-
-	if (dma)
-		*dma = 0;
-	if (!sram_pool || (dma && !dma_base))
-		return NULL;
-
-	vaddr = gen_pool_alloc(sram_pool, len);
-	if (!vaddr)
-		return NULL;
-
-	if (dma)
-		*dma = dma_base + (vaddr - SRAM_VIRT);
-	return (void *)vaddr;
-
-}
-EXPORT_SYMBOL(sram_alloc);
-
-void sram_free(void *addr, size_t len)
-{
-	gen_pool_free(sram_pool, (unsigned long) addr, len);
-}
-EXPORT_SYMBOL(sram_free);
-
+struct gen_pool *davinci_gen_pool;
+EXPORT_SYMBOL_GPL(davinci_gen_pool);
 
 /*
  * REVISIT This supports CPU and DMA access to/from SRAM, but it
@@ -54,18 +26,19 @@ EXPORT_SYMBOL(sram_free);
 static int __init sram_init(void)
 {
 	unsigned len = davinci_soc_info.sram_len;
-	int status = 0;
 
-	if (len) {
-		len = min_t(unsigned, len, SRAM_SIZE);
-		sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
-		if (!sram_pool)
-			status = -ENOMEM;
-	}
-	if (sram_pool)
-		status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
-	WARN_ON(status < 0);
-	return status;
+	if (!len)
+		return 0;
+
+	len = min_t(unsigned, len, SRAM_SIZE);
+	davinci_gen_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
+
+	if (!davinci_gen_pool)
+		return -ENOMEM;
+
+	WARN_ON(gen_pool_add_virt(davinci_gen_pool, SRAM_VIRT,
+				  davinci_soc_info.sram_phys, len, -1));
+
+	return 0;
 }
 core_initcall(sram_init);
-
diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
index 022690c..8279c47 100644
--- a/arch/arm/plat-mxc/include/mach/iram.h
+++ b/arch/arm/plat-mxc/include/mach/iram.h
@@ -17,25 +17,41 @@
  * MA 02110-1301, USA.
  */
 #include <linux/errno.h>
+#include <linux/genalloc.h>
 
 #ifdef CONFIG_IRAM_ALLOC
 
-int __init iram_init(unsigned long base, unsigned long size);
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr);
-void iram_free(unsigned long dma_addr, unsigned int size);
+int __init iram_init(phys_addr_t base, size_t size);
+
+extern struct gen_pool *mxc_iram_pool;
+
+static inline void *iram_alloc(size_t size, phys_addr_t *phys)
+{
+	unsigned long addr = gen_pool_alloc(iram_pool, size);
+
+	*phys = gen_pool_virt_to_phys(iram_pool, addr);
+
+	return (void*)addr;
+}
+
+static inline void iram_free(void *addr, size_t size)
+{
+	gen_pool_free(iram_pool, (unsigned long)addr, size);
+}
 
 #else
 
-static inline int __init iram_init(unsigned long base, unsigned long size)
+static inline int __init iram_init(phys_addr_t base, size_t size)
 {
 	return -ENOMEM;
 }
 
-static inline void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
+static inline void *iram_alloc(size_t size, phys_addr_t *phys)
 {
+	*phys = (phys_addr_t)-1ULL;
 	return NULL;
 }
 
-static inline void iram_free(unsigned long base, unsigned long size) {}
+static inline void iram_free(void *addr, size_t size) {}
 
 #endif
diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/iram_alloc.c
similarity index 56%
copy from arch/arm/plat-mxc/include/mach/iram.h
copy to arch/arm/plat-mxc/iram_alloc.c
index 022690c..728d59e 100644
--- a/arch/arm/plat-mxc/include/mach/iram.h
+++ b/arch/arm/plat-mxc/iram_alloc.c
@@ -16,26 +16,34 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
  * MA 02110-1301, USA.
  */
-#include <linux/errno.h>
 
-#ifdef CONFIG_IRAM_ALLOC
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/genalloc.h>
+#include <mach/iram.h>
 
-int __init iram_init(unsigned long base, unsigned long size);
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr);
-void iram_free(unsigned long dma_addr, unsigned int size);
+struct gen_pool *mxc_iram_pool;
+EXPORT_SYMBOL(mxc_iram_pool);
 
-#else
-
-static inline int __init iram_init(unsigned long base, unsigned long size)
+int __init iram_init(phys_addr_t base, size_t size)
 {
-	return -ENOMEM;
-}
+	void *addr = /*FIXME*/ ioremap(base, size);
 
-static inline void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
-{
-	return NULL;
-}
+	if (!addr)
+		return -EIO;
 
-static inline void iram_free(unsigned long base, unsigned long size) {}
+	mxc_iram_pool = gen_pool_create(PAGE_SHIFT, -1);
+	if (!mxc_iram_pool) {
+		iounmap(addr);
+		return -ENOMEM;
+	}
 
-#endif
+	WARN_ON(gen_pool_add_virt(mxc_iram_pool, addr, base, size, -1));
+
+	pr_debug("i.MX IRAM pool: %lu KB@0x%08llx\n", size / 1024,
+		 (unsigned long long)base);
+
+	return 0;
+}
diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..52b9b5c 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -12,16 +12,23 @@
 #define __ARCH_ARM_OMAP_SRAM_H
 
 #ifndef __ASSEMBLY__
+#include <linux/slab.h>
+#include <linux/genalloc.h>
 #include <asm/fncpy.h>
 
-extern void *omap_sram_push_address(unsigned long size);
+extern struct gen_pool *omap_gen_pool;
 
-/* Macro to push a function to the internal SRAM, using the fncpy API */
+/*
+ * Note that fncpy requires the SRAM address to be aligned to an 8-byte
+ * boundary, so the min_alloc_order for the pool is set appropriately.
+ */
 #define omap_sram_push(funcp, size) ({				\
-	typeof(&(funcp)) _res = NULL;				\
-	void *_sram_address = omap_sram_push_address(size);	\
-	if (_sram_address)					\
-		_res = fncpy(_sram_address, &(funcp), size);	\
+	typeof(&(funcp)) _res;					\
+	size_t _sz = size;					\
+	void *_sram = gen_pool_alloc(omap_gen_pool, _sz);	\
+	_res = (_sram ? fncpy(_sram, &(funcp), _sz) : NULL);	\
+	if (!_res) 						\
+		pr_err("Not enough space in SRAM\n");		\
 	_res;							\
 })
 
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..4337bba 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -75,7 +75,6 @@
 static unsigned long omap_sram_start;
 static unsigned long omap_sram_base;
 static unsigned long omap_sram_size;
-static unsigned long omap_sram_ceil;
 
 /*
  * Depending on the target RAMFS firewall setup, the public usable amount of
@@ -104,6 +103,8 @@ static int is_sram_locked(void)
 		return 1; /* assume locked with no PPA or security driver */
 }
 
+struct gen_pool *omap_gen_pool;
+
 /*
  * The amount of SRAM depends on the core type.
  * Note that we cannot try to test for SRAM here because writes
@@ -182,7 +183,18 @@ static void __init omap_detect_sram(void)
 			omap_sram_size - SRAM_BOOTLOADER_SZ);
 	omap_sram_size -= reserved;
 
-	omap_sram_ceil = omap_sram_base + omap_sram_size;
+	{
+		/* The first SRAM_BOOTLOADER_SZ of SRAM are reserved */
+		void *base = (void *)omap_sram_base + SRAM_BOOTLOADER_SZ;
+		phys_addr_t phys = omap_sram_start + SRAM_BOOTLOADER_SZ;
+		size_t len = omap_sram_size - SRAM_BOOTLOADER_SZ;
+
+		omap_gen_pool = gen_pool_create(ilog2(FNCPY_ALIGN), -1);
+		if (omap_gen_pool)
+			WARN_ON(gen_pool_add_virt(omap_gen_pool,
+					(unsigned long)base, phys, len, -1));
+		WARN_ON(!omap_gen_pool);
+	}
 }
 
 static struct map_desc omap_sram_io_desc[] __initdata = {
@@ -242,26 +254,6 @@ static void __init omap_map_sram(void)
 	       omap_sram_size - SRAM_BOOTLOADER_SZ);
 }
 
-/*
- * Memory allocator for SRAM: calculates the new ceiling address
- * for pushing a function using the fncpy API.
- *
- * Note that fncpy requires the returned address to be aligned
- * to an 8-byte boundary.
- */
-void *omap_sram_push_address(unsigned long size)
-{
-	if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
-		printk(KERN_ERR "Not enough space in SRAM\n");
-		return NULL;
-	}
-
-	omap_sram_ceil -= size;
-	omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, FNCPY_ALIGN);
-
-	return (void *)omap_sram_ceil;
-}
-
 #ifdef CONFIG_ARCH_OMAP1
 
 static void (*_omap_sram_reprogram_clock)(u32 dpllctl, u32 ckctl);
@@ -385,8 +377,6 @@ u32 omap3_configure_core_dpll(u32 m2, u32 unlock_dll, u32 f, u32 inc,
 #ifdef CONFIG_PM
 void omap3_sram_restore_context(void)
 {
-	omap_sram_ceil = omap_sram_base + omap_sram_size;
-
 	_omap3_sram_configure_core_dpll =
 		omap_sram_push(omap3_sram_configure_core_dpll,
 			       omap3_sram_configure_core_dpll_sz);
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index e67b566..db486cc 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -62,7 +62,7 @@ MODULE_PARM_DESC(extram_pool_sz, "external ram pool size to allocate");
 struct uio_pruss_dev {
 	struct uio_info *info;
 	struct clk *pruss_clk;
-	dma_addr_t sram_paddr;
+	phys_addr_t sram_paddr;
 	dma_addr_t ddr_paddr;
 	void __iomem *prussio_vaddr;
 	void *sram_vaddr;
@@ -106,7 +106,8 @@ static void pruss_cleanup(struct platform_device *dev,
 			gdev->ddr_paddr);
 	}
 	if (gdev->sram_vaddr)
-		sram_free(gdev->sram_vaddr, sram_pool_sz);
+		gen_pool_free(davinci_gen_pool,
+			      (unsigned long)gdev->sram_vaddr, sram_pool_sz);
 	kfree(gdev->info);
 	clk_put(gdev->pruss_clk);
 	kfree(gdev);
@@ -152,12 +153,15 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
+	gdev->sram_vaddr = (void*)gen_pool_alloc(davinci_gen_pool, sram_pool_sz);
 	if (!gdev->sram_vaddr) {
 		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
 		goto out_free;
 	}
 
+	gdev->sram_paddr = gen_pool_virt_to_phys(davinci_gen_pool,
+					(unsigned long)gdev->sram_vaddr);
+
 	gdev->ddr_vaddr = dma_alloc_coherent(&dev->dev, extram_pool_sz,
 				&(gdev->ddr_paddr), GFP_KERNEL | GFP_DMA);
 	if (!gdev->ddr_vaddr) {
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
index 9d35b8c..dd305a2 100644
--- a/sound/soc/davinci/davinci-pcm.c
+++ b/sound/soc/davinci/davinci-pcm.c
@@ -232,16 +232,18 @@ static int allocate_sram(struct snd_pcm_substream *substream, unsigned size,
 {
 	struct snd_dma_buffer *buf = &substream->dma_buffer;
 	struct snd_dma_buffer *iram_dma = NULL;
-	dma_addr_t iram_phys = 0;
+	phys_addr_t iram_phys;
 	void *iram_virt = NULL;
 
 	if (buf->private_data || !size)
 		return 0;
 
 	ppcm->period_bytes_max = size;
-	iram_virt = sram_alloc(size, &iram_phys);
+	iram_virt = (void*)gen_pool_alloc(davinci_gen_pool, size);
 	if (!iram_virt)
 		goto exit1;
+	iram_phys = gen_pool_virt_to_phys(davinci_gen_pool,
+					(unsigned long)iram_virt);
 	iram_dma = kzalloc(sizeof(*iram_dma), GFP_KERNEL);
 	if (!iram_dma)
 		goto exit2;
@@ -253,7 +255,7 @@ static int allocate_sram(struct snd_pcm_substream *substream, unsigned size,
 	return 0;
 exit2:
 	if (iram_virt)
-		sram_free(iram_virt, size);
+		gen_pool_free(davinci_gen_pool, (unsigned long)iram_virt, size);
 exit1:
 	return -ENOMEM;
 }
@@ -803,7 +805,8 @@ static void davinci_pcm_free(struct snd_pcm *pcm)
 		buf->area = NULL;
 		iram_dma = buf->private_data;
 		if (iram_dma) {
-			sram_free(iram_dma->area, iram_dma->bytes);
+			gen_pool_free(davinci_gen_pool,
+			      (unsigned long)iram_dma->area, iram_dma->bytes);
 			kfree(iram_dma);
 		}
 	}
-- 
1.7.4.1

[RFC PATCH v4] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

From: Russell King - ARM Linux <linux@arm.linux.org.uk>

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.

For this use the generic allocator and the newly introduce
gen_pool_add_virt and gen_pool_virt_to_phys

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>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
---
v4:
	update against linus tree and genalloc gen_pool_add_virt and
	gen_pool_virt_to_phys

Best Regards,
J.
 arch/arm/Kconfig                                   |    2 +
 arch/arm/mach-davinci/da850.c                      |    2 +-
 arch/arm/mach-davinci/dm355.c                      |    2 +-
 arch/arm/mach-davinci/dm365.c                      |    2 +-
 arch/arm/mach-davinci/dm644x.c                     |    2 +-
 arch/arm/mach-davinci/dm646x.c                     |    2 +-
 arch/arm/mach-davinci/include/mach/common.h        |    2 +-
 arch/arm/mach-davinci/include/mach/sram.h          |   13 +----
 arch/arm/mach-davinci/pm.c                         |   21 +++----
 arch/arm/mach-davinci/sram.c                       |   57 +++++--------------
 arch/arm/plat-mxc/include/mach/iram.h              |   28 ++++++++--
 .../plat-mxc/{include/mach/iram.h => iram_alloc.c} |   40 ++++++++------
 arch/arm/plat-omap/include/plat/sram.h             |   19 +++++--
 arch/arm/plat-omap/sram.c                          |   38 +++++--------
 drivers/uio/uio_pruss.c                            |   10 +++-
 sound/soc/davinci/davinci-pcm.c                    |   11 +++--
 16 files changed, 122 insertions(+), 129 deletions(-)
 copy arch/arm/plat-mxc/{include/mach/iram.h => iram_alloc.c} (56%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f4b7dfa..5ec5e5f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -848,6 +848,7 @@ config ARCH_DAVINCI
 	bool "TI DaVinci"
 	select GENERIC_CLOCKEVENTS
 	select ARCH_REQUIRE_GPIOLIB
+	select GENERIC_ALLOCATOR
 	select ZONE_DMA
 	select HAVE_IDE
 	select CLKDEV_LOOKUP
@@ -862,6 +863,7 @@ config ARCH_OMAP
 	select HAVE_CLK
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_CPUFREQ
+	select GENERIC_ALLOCATOR
 	select GENERIC_CLOCKEVENTS
 	select HAVE_SCHED_CLOCK
 	select ARCH_HAS_HOLES_MEMORYMODEL
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index b95b919..09f6c12 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
 	.serial_dev		= &da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
-	.sram_dma		= DA8XX_ARM_RAM_BASE,
+	.sram_phys		= DA8XX_ARM_RAM_BASE,
 	.sram_len		= SZ_8K,
 	.reset_device		= &da8xx_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a3a94e9..9bda687 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
 	.serial_dev		= &dm355_serial_device,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 4604e72..d306034 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
 	.serial_dev		= &dm365_serial_device,
 	.emac_pdata		= &dm365_emac_pdata,
-	.sram_dma		= 0x00010000,
+	.sram_phys		= 0x00010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 4c82c27..3949ed7 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -764,7 +764,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.gpio_irq		= IRQ_GPIOBNK0,
 	.serial_dev		= &dm644x_serial_device,
 	.emac_pdata		= &dm644x_emac_pdata,
-	.sram_dma		= 0x00008000,
+	.sram_phys		= 0x00008000,
 	.sram_len		= SZ_16K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 1e0f809..a4365f7 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -848,7 +848,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
 	.serial_dev		= &dm646x_serial_device,
 	.emac_pdata		= &dm646x_emac_pdata,
-	.sram_dma		= 0x10010000,
+	.sram_phys		= 0x10010000,
 	.sram_len		= SZ_32K,
 	.reset_device		= &davinci_wdt_device,
 };
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index a57cba2..665d049 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -75,7 +75,7 @@ struct davinci_soc_info {
 	int				gpio_ctlrs_num;
 	struct platform_device		*serial_dev;
 	struct emac_platform_data	*emac_pdata;
-	dma_addr_t			sram_dma;
+	phys_addr_t			sram_phys;
 	unsigned			sram_len;
 	struct platform_device		*reset_device;
 	void				(*reset)(struct platform_device *);
diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h
index 111f7cc..aa52009 100644
--- a/arch/arm/mach-davinci/include/mach/sram.h
+++ b/arch/arm/mach-davinci/include/mach/sram.h
@@ -10,18 +10,11 @@
 #ifndef __MACH_SRAM_H
 #define __MACH_SRAM_H
 
+#include <linux/genalloc.h>
+
 /* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
 #define SRAM_GRANULARITY	512
 
-/*
- * SRAM allocations return a CPU virtual address, or NULL on error.
- * If a DMA address is requested and the SRAM supports DMA, its
- * mapped address is also returned.
- *
- * Errors include SRAM memory not being available, and requesting
- * DMA mapped SRAM on systems which don't allow that.
- */
-extern void *sram_alloc(size_t len, dma_addr_t *dma);
-extern void sram_free(void *addr, size_t len);
+extern struct gen_pool *davinci_gen_pool;
 
 #endif /* __MACH_SRAM_H */
diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index 1bd73a0..ef2ebe4 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -17,6 +17,7 @@
 
 #include <asm/cacheflush.h>
 #include <asm/delay.h>
+#include <asm/fncpy.h>
 
 #include <mach/da8xx.h>
 #include <mach/sram.h>
@@ -27,14 +28,9 @@
 #define DEEPSLEEP_SLEEPCOUNT_MASK	0xFFFF
 
 static void (*davinci_sram_suspend) (struct davinci_pm_config *);
+static void *davinci_sram_suspend_mem;
 static struct davinci_pm_config *pdata;
 
-static void davinci_sram_push(void *dest, void *src, unsigned int size)
-{
-	memcpy(dest, src, size);
-	flush_icache_range((unsigned long)dest, (unsigned long)(dest + size));
-}
-
 static void davinci_pm_suspend(void)
 {
 	unsigned val;
@@ -123,14 +119,14 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 		return -ENOENT;
 	}
 
-	davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
-	if (!davinci_sram_suspend) {
+	davinci_sram_suspend_mem = (void *)gen_pool_alloc(davinci_gen_pool,
+				davinci_cpu_suspend_sz);
+	if (!davinci_sram_suspend_mem) {
 		dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
 		return -ENOMEM;
 	}
-
-	davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
-						davinci_cpu_suspend_sz);
+	davinci_sram_suspend = fncpy(davinci_sram_suspend_mem,
+				&davinci_cpu_suspend, davinci_cpu_suspend_sz);
 
 	suspend_set_ops(&davinci_pm_ops);
 
@@ -139,7 +135,8 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
 
 static int __exit davinci_pm_remove(struct platform_device *pdev)
 {
-	sram_free(davinci_sram_suspend, davinci_cpu_suspend_sz);
+	gen_pool_free(davinci_gen_pool, (unsigned long)davinci_sram_suspend_mem,
+		davinci_cpu_suspend_sz);
 	return 0;
 }
 
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index db0f778..2c53db2 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -10,40 +10,12 @@
  */
 #include <linux/module.h>
 #include <linux/init.h>
-#include <linux/genalloc.h>
 
 #include <mach/common.h>
 #include <mach/sram.h>
 
-static struct gen_pool *sram_pool;
-
-void *sram_alloc(size_t len, dma_addr_t *dma)
-{
-	unsigned long vaddr;
-	dma_addr_t dma_base = davinci_soc_info.sram_dma;
-
-	if (dma)
-		*dma = 0;
-	if (!sram_pool || (dma && !dma_base))
-		return NULL;
-
-	vaddr = gen_pool_alloc(sram_pool, len);
-	if (!vaddr)
-		return NULL;
-
-	if (dma)
-		*dma = dma_base + (vaddr - SRAM_VIRT);
-	return (void *)vaddr;
-
-}
-EXPORT_SYMBOL(sram_alloc);
-
-void sram_free(void *addr, size_t len)
-{
-	gen_pool_free(sram_pool, (unsigned long) addr, len);
-}
-EXPORT_SYMBOL(sram_free);
-
+struct gen_pool *davinci_gen_pool;
+EXPORT_SYMBOL_GPL(davinci_gen_pool);
 
 /*
  * REVISIT This supports CPU and DMA access to/from SRAM, but it
@@ -54,18 +26,19 @@ EXPORT_SYMBOL(sram_free);
 static int __init sram_init(void)
 {
 	unsigned len = davinci_soc_info.sram_len;
-	int status = 0;
 
-	if (len) {
-		len = min_t(unsigned, len, SRAM_SIZE);
-		sram_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
-		if (!sram_pool)
-			status = -ENOMEM;
-	}
-	if (sram_pool)
-		status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
-	WARN_ON(status < 0);
-	return status;
+	if (!len)
+		return 0;
+
+	len = min_t(unsigned, len, SRAM_SIZE);
+	davinci_gen_pool = gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
+
+	if (!davinci_gen_pool)
+		return -ENOMEM;
+
+	WARN_ON(gen_pool_add_virt(davinci_gen_pool, SRAM_VIRT,
+				  davinci_soc_info.sram_phys, len, -1));
+
+	return 0;
 }
 core_initcall(sram_init);
-
diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
index 022690c..8279c47 100644
--- a/arch/arm/plat-mxc/include/mach/iram.h
+++ b/arch/arm/plat-mxc/include/mach/iram.h
@@ -17,25 +17,41 @@
  * MA 02110-1301, USA.
  */
 #include <linux/errno.h>
+#include <linux/genalloc.h>
 
 #ifdef CONFIG_IRAM_ALLOC
 
-int __init iram_init(unsigned long base, unsigned long size);
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr);
-void iram_free(unsigned long dma_addr, unsigned int size);
+int __init iram_init(phys_addr_t base, size_t size);
+
+extern struct gen_pool *mxc_iram_pool;
+
+static inline void *iram_alloc(size_t size, phys_addr_t *phys)
+{
+	unsigned long addr = gen_pool_alloc(iram_pool, size);
+
+	*phys = gen_pool_virt_to_phys(iram_pool, addr);
+
+	return (void*)addr;
+}
+
+static inline void iram_free(void *addr, size_t size)
+{
+	gen_pool_free(iram_pool, (unsigned long)addr, size);
+}
 
 #else
 
-static inline int __init iram_init(unsigned long base, unsigned long size)
+static inline int __init iram_init(phys_addr_t base, size_t size)
 {
 	return -ENOMEM;
 }
 
-static inline void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
+static inline void *iram_alloc(size_t size, phys_addr_t *phys)
 {
+	*phys = (phys_addr_t)-1ULL;
 	return NULL;
 }
 
-static inline void iram_free(unsigned long base, unsigned long size) {}
+static inline void iram_free(void *addr, size_t size) {}
 
 #endif
diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/iram_alloc.c
similarity index 56%
copy from arch/arm/plat-mxc/include/mach/iram.h
copy to arch/arm/plat-mxc/iram_alloc.c
index 022690c..728d59e 100644
--- a/arch/arm/plat-mxc/include/mach/iram.h
+++ b/arch/arm/plat-mxc/iram_alloc.c
@@ -16,26 +16,34 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
  * MA 02110-1301, USA.
  */
-#include <linux/errno.h>
 
-#ifdef CONFIG_IRAM_ALLOC
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/genalloc.h>
+#include <mach/iram.h>
 
-int __init iram_init(unsigned long base, unsigned long size);
-void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr);
-void iram_free(unsigned long dma_addr, unsigned int size);
+struct gen_pool *mxc_iram_pool;
+EXPORT_SYMBOL(mxc_iram_pool);
 
-#else
-
-static inline int __init iram_init(unsigned long base, unsigned long size)
+int __init iram_init(phys_addr_t base, size_t size)
 {
-	return -ENOMEM;
-}
+	void *addr = /*FIXME*/ ioremap(base, size);
 
-static inline void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
-{
-	return NULL;
-}
+	if (!addr)
+		return -EIO;
 
-static inline void iram_free(unsigned long base, unsigned long size) {}
+	mxc_iram_pool = gen_pool_create(PAGE_SHIFT, -1);
+	if (!mxc_iram_pool) {
+		iounmap(addr);
+		return -ENOMEM;
+	}
 
-#endif
+	WARN_ON(gen_pool_add_virt(mxc_iram_pool, addr, base, size, -1));
+
+	pr_debug("i.MX IRAM pool: %lu KB at 0x%08llx\n", size / 1024,
+		 (unsigned long long)base);
+
+	return 0;
+}
diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..52b9b5c 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -12,16 +12,23 @@
 #define __ARCH_ARM_OMAP_SRAM_H
 
 #ifndef __ASSEMBLY__
+#include <linux/slab.h>
+#include <linux/genalloc.h>
 #include <asm/fncpy.h>
 
-extern void *omap_sram_push_address(unsigned long size);
+extern struct gen_pool *omap_gen_pool;
 
-/* Macro to push a function to the internal SRAM, using the fncpy API */
+/*
+ * Note that fncpy requires the SRAM address to be aligned to an 8-byte
+ * boundary, so the min_alloc_order for the pool is set appropriately.
+ */
 #define omap_sram_push(funcp, size) ({				\
-	typeof(&(funcp)) _res = NULL;				\
-	void *_sram_address = omap_sram_push_address(size);	\
-	if (_sram_address)					\
-		_res = fncpy(_sram_address, &(funcp), size);	\
+	typeof(&(funcp)) _res;					\
+	size_t _sz = size;					\
+	void *_sram = gen_pool_alloc(omap_gen_pool, _sz);	\
+	_res = (_sram ? fncpy(_sram, &(funcp), _sz) : NULL);	\
+	if (!_res) 						\
+		pr_err("Not enough space in SRAM\n");		\
 	_res;							\
 })
 
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..4337bba 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -75,7 +75,6 @@
 static unsigned long omap_sram_start;
 static unsigned long omap_sram_base;
 static unsigned long omap_sram_size;
-static unsigned long omap_sram_ceil;
 
 /*
  * Depending on the target RAMFS firewall setup, the public usable amount of
@@ -104,6 +103,8 @@ static int is_sram_locked(void)
 		return 1; /* assume locked with no PPA or security driver */
 }
 
+struct gen_pool *omap_gen_pool;
+
 /*
  * The amount of SRAM depends on the core type.
  * Note that we cannot try to test for SRAM here because writes
@@ -182,7 +183,18 @@ static void __init omap_detect_sram(void)
 			omap_sram_size - SRAM_BOOTLOADER_SZ);
 	omap_sram_size -= reserved;
 
-	omap_sram_ceil = omap_sram_base + omap_sram_size;
+	{
+		/* The first SRAM_BOOTLOADER_SZ of SRAM are reserved */
+		void *base = (void *)omap_sram_base + SRAM_BOOTLOADER_SZ;
+		phys_addr_t phys = omap_sram_start + SRAM_BOOTLOADER_SZ;
+		size_t len = omap_sram_size - SRAM_BOOTLOADER_SZ;
+
+		omap_gen_pool = gen_pool_create(ilog2(FNCPY_ALIGN), -1);
+		if (omap_gen_pool)
+			WARN_ON(gen_pool_add_virt(omap_gen_pool,
+					(unsigned long)base, phys, len, -1));
+		WARN_ON(!omap_gen_pool);
+	}
 }
 
 static struct map_desc omap_sram_io_desc[] __initdata = {
@@ -242,26 +254,6 @@ static void __init omap_map_sram(void)
 	       omap_sram_size - SRAM_BOOTLOADER_SZ);
 }
 
-/*
- * Memory allocator for SRAM: calculates the new ceiling address
- * for pushing a function using the fncpy API.
- *
- * Note that fncpy requires the returned address to be aligned
- * to an 8-byte boundary.
- */
-void *omap_sram_push_address(unsigned long size)
-{
-	if (size > (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
-		printk(KERN_ERR "Not enough space in SRAM\n");
-		return NULL;
-	}
-
-	omap_sram_ceil -= size;
-	omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, FNCPY_ALIGN);
-
-	return (void *)omap_sram_ceil;
-}
-
 #ifdef CONFIG_ARCH_OMAP1
 
 static void (*_omap_sram_reprogram_clock)(u32 dpllctl, u32 ckctl);
@@ -385,8 +377,6 @@ u32 omap3_configure_core_dpll(u32 m2, u32 unlock_dll, u32 f, u32 inc,
 #ifdef CONFIG_PM
 void omap3_sram_restore_context(void)
 {
-	omap_sram_ceil = omap_sram_base + omap_sram_size;
-
 	_omap3_sram_configure_core_dpll =
 		omap_sram_push(omap3_sram_configure_core_dpll,
 			       omap3_sram_configure_core_dpll_sz);
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index e67b566..db486cc 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -62,7 +62,7 @@ MODULE_PARM_DESC(extram_pool_sz, "external ram pool size to allocate");
 struct uio_pruss_dev {
 	struct uio_info *info;
 	struct clk *pruss_clk;
-	dma_addr_t sram_paddr;
+	phys_addr_t sram_paddr;
 	dma_addr_t ddr_paddr;
 	void __iomem *prussio_vaddr;
 	void *sram_vaddr;
@@ -106,7 +106,8 @@ static void pruss_cleanup(struct platform_device *dev,
 			gdev->ddr_paddr);
 	}
 	if (gdev->sram_vaddr)
-		sram_free(gdev->sram_vaddr, sram_pool_sz);
+		gen_pool_free(davinci_gen_pool,
+			      (unsigned long)gdev->sram_vaddr, sram_pool_sz);
 	kfree(gdev->info);
 	clk_put(gdev->pruss_clk);
 	kfree(gdev);
@@ -152,12 +153,15 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
+	gdev->sram_vaddr = (void*)gen_pool_alloc(davinci_gen_pool, sram_pool_sz);
 	if (!gdev->sram_vaddr) {
 		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
 		goto out_free;
 	}
 
+	gdev->sram_paddr = gen_pool_virt_to_phys(davinci_gen_pool,
+					(unsigned long)gdev->sram_vaddr);
+
 	gdev->ddr_vaddr = dma_alloc_coherent(&dev->dev, extram_pool_sz,
 				&(gdev->ddr_paddr), GFP_KERNEL | GFP_DMA);
 	if (!gdev->ddr_vaddr) {
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
index 9d35b8c..dd305a2 100644
--- a/sound/soc/davinci/davinci-pcm.c
+++ b/sound/soc/davinci/davinci-pcm.c
@@ -232,16 +232,18 @@ static int allocate_sram(struct snd_pcm_substream *substream, unsigned size,
 {
 	struct snd_dma_buffer *buf = &substream->dma_buffer;
 	struct snd_dma_buffer *iram_dma = NULL;
-	dma_addr_t iram_phys = 0;
+	phys_addr_t iram_phys;
 	void *iram_virt = NULL;
 
 	if (buf->private_data || !size)
 		return 0;
 
 	ppcm->period_bytes_max = size;
-	iram_virt = sram_alloc(size, &iram_phys);
+	iram_virt = (void*)gen_pool_alloc(davinci_gen_pool, size);
 	if (!iram_virt)
 		goto exit1;
+	iram_phys = gen_pool_virt_to_phys(davinci_gen_pool,
+					(unsigned long)iram_virt);
 	iram_dma = kzalloc(sizeof(*iram_dma), GFP_KERNEL);
 	if (!iram_dma)
 		goto exit2;
@@ -253,7 +255,7 @@ static int allocate_sram(struct snd_pcm_substream *substream, unsigned size,
 	return 0;
 exit2:
 	if (iram_virt)
-		sram_free(iram_virt, size);
+		gen_pool_free(davinci_gen_pool, (unsigned long)iram_virt, size);
 exit1:
 	return -ENOMEM;
 }
@@ -803,7 +805,8 @@ static void davinci_pcm_free(struct snd_pcm *pcm)
 		buf->area = NULL;
 		iram_dma = buf->private_data;
 		if (iram_dma) {
-			sram_free(iram_dma->area, iram_dma->bytes);
+			gen_pool_free(davinci_gen_pool,
+			      (unsigned long)iram_dma->area, iram_dma->bytes);
 			kfree(iram_dma);
 		}
 	}
-- 
1.7.4.1

RE: [RFC PATCH v4] Consolidate SRAM support

[Nori, Sekhar]

Hi Jean-Christophe,

On Thu, May 26, 2011 at 06:32:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
> From: Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> 
> 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.
> 
> For this use the generic allocator and the newly introduce
> gen_pool_add_virt and gen_pool_virt_to_phys
> 
> 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-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
> Cc: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
> Cc: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>
> Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

I tested this on DA850 using suspend-to-RAM and audio, it works
well!

>  arch/arm/Kconfig                                   |    2 +
>  arch/arm/mach-davinci/da850.c                      |    2 +-
>  arch/arm/mach-davinci/dm355.c                      |    2 +-
>  arch/arm/mach-davinci/dm365.c                      |    2 +-
>  arch/arm/mach-davinci/dm644x.c                     |    2 +-
>  arch/arm/mach-davinci/dm646x.c                     |    2 +-
>  arch/arm/mach-davinci/include/mach/common.h        |    2 +-
>  arch/arm/mach-davinci/include/mach/sram.h          |   13 +----
>  arch/arm/mach-davinci/pm.c                         |   21 +++----
>  arch/arm/mach-davinci/sram.c                       |   57 +++++--------------

>  arch/arm/plat-mxc/include/mach/iram.h              |   28 ++++++++--
>  .../plat-mxc/{include/mach/iram.h => iram_alloc.c} |   40 ++++++++------

I had trouble applying the plat-mxc stuff on v3.0-rc1.
Can you please check?

I also found some check patch errors. Feel free to merge
the attached patch.

With these, please add my:

Acked-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>

Thanks,
Sekhar

----8<-------
diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
index 8279c47..aae5e35 100644
--- a/arch/arm/plat-mxc/include/mach/iram.h
+++ b/arch/arm/plat-mxc/include/mach/iram.h
@@ -31,7 +31,7 @@ static inline void *iram_alloc(size_t size, phys_addr_t *phys)
 
 	*phys = gen_pool_virt_to_phys(iram_pool, addr);
 
-	return (void*)addr;
+	return (void *) addr;
 }
 
 static inline void iram_free(void *addr, size_t size)
diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
index 52b9b5c..cc99397 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -27,7 +27,7 @@ extern struct gen_pool *omap_gen_pool;
 	size_t _sz = size;					\
 	void *_sram = gen_pool_alloc(omap_gen_pool, _sz);	\
 	_res = (_sram ? fncpy(_sram, &(funcp), _sz) : NULL);	\
-	if (!_res) 						\
+	if (!_res)						\
 		pr_err("Not enough space in SRAM\n");		\
 	_res;							\
 })
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index db486cc..444176e 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -153,7 +153,7 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	gdev->sram_vaddr = (void*)gen_pool_alloc(davinci_gen_pool, sram_pool_sz);
+	gdev->sram_vaddr = (void *)gen_pool_alloc(davinci_gen_pool, sram_pool_sz);
 	if (!gdev->sram_vaddr) {
 		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
 		goto out_free;
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
index dd305a2..1c383ab 100644
--- a/sound/soc/davinci/davinci-pcm.c
+++ b/sound/soc/davinci/davinci-pcm.c
@@ -239,7 +239,7 @@ static int allocate_sram(struct snd_pcm_substream *substream, unsigned size,
 		return 0;
 
 	ppcm->period_bytes_max = size;
-	iram_virt = (void*)gen_pool_alloc(davinci_gen_pool, size);
+	iram_virt = (void *)gen_pool_alloc(davinci_gen_pool, size);
 	if (!iram_virt)
 		goto exit1;
 	iram_phys = gen_pool_virt_to_phys(davinci_gen_pool,

[RFC PATCH v4] Consolidate SRAM support

[Nori, Sekhar]

Hi Jean-Christophe,

On Thu, May 26, 2011 at 06:32:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
> 
> 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.
> 
> For this use the generic allocator and the newly introduce
> gen_pool_add_virt and gen_pool_virt_to_phys
> 
> 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>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>

I tested this on DA850 using suspend-to-RAM and audio, it works
well!

>  arch/arm/Kconfig                                   |    2 +
>  arch/arm/mach-davinci/da850.c                      |    2 +-
>  arch/arm/mach-davinci/dm355.c                      |    2 +-
>  arch/arm/mach-davinci/dm365.c                      |    2 +-
>  arch/arm/mach-davinci/dm644x.c                     |    2 +-
>  arch/arm/mach-davinci/dm646x.c                     |    2 +-
>  arch/arm/mach-davinci/include/mach/common.h        |    2 +-
>  arch/arm/mach-davinci/include/mach/sram.h          |   13 +----
>  arch/arm/mach-davinci/pm.c                         |   21 +++----
>  arch/arm/mach-davinci/sram.c                       |   57 +++++--------------

>  arch/arm/plat-mxc/include/mach/iram.h              |   28 ++++++++--
>  .../plat-mxc/{include/mach/iram.h => iram_alloc.c} |   40 ++++++++------

I had trouble applying the plat-mxc stuff on v3.0-rc1.
Can you please check?

I also found some check patch errors. Feel free to merge
the attached patch.

With these, please add my:

Acked-by: Sekhar Nori <nsekhar@ti.com>

Thanks,
Sekhar

----8<-------
diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
index 8279c47..aae5e35 100644
--- a/arch/arm/plat-mxc/include/mach/iram.h
+++ b/arch/arm/plat-mxc/include/mach/iram.h
@@ -31,7 +31,7 @@ static inline void *iram_alloc(size_t size, phys_addr_t *phys)
 
 	*phys = gen_pool_virt_to_phys(iram_pool, addr);
 
-	return (void*)addr;
+	return (void *) addr;
 }
 
 static inline void iram_free(void *addr, size_t size)
diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
index 52b9b5c..cc99397 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -27,7 +27,7 @@ extern struct gen_pool *omap_gen_pool;
 	size_t _sz = size;					\
 	void *_sram = gen_pool_alloc(omap_gen_pool, _sz);	\
 	_res = (_sram ? fncpy(_sram, &(funcp), _sz) : NULL);	\
-	if (!_res) 						\
+	if (!_res)						\
 		pr_err("Not enough space in SRAM\n");		\
 	_res;							\
 })
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index db486cc..444176e 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -153,7 +153,7 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	gdev->sram_vaddr = (void*)gen_pool_alloc(davinci_gen_pool, sram_pool_sz);
+	gdev->sram_vaddr = (void *)gen_pool_alloc(davinci_gen_pool, sram_pool_sz);
 	if (!gdev->sram_vaddr) {
 		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
 		goto out_free;
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
index dd305a2..1c383ab 100644
--- a/sound/soc/davinci/davinci-pcm.c
+++ b/sound/soc/davinci/davinci-pcm.c
@@ -239,7 +239,7 @@ static int allocate_sram(struct snd_pcm_substream *substream, unsigned size,
 		return 0;
 
 	ppcm->period_bytes_max = size;
-	iram_virt = (void*)gen_pool_alloc(davinci_gen_pool, size);
+	iram_virt = (void *)gen_pool_alloc(davinci_gen_pool, size);
 	if (!iram_virt)
 		goto exit1;
 	iram_phys = gen_pool_virt_to_phys(davinci_gen_pool,

Re: [RFC PATCH v4] Consolidate SRAM support

[Russell King - ARM Linux]

On Tue, May 31, 2011 at 10:39:48PM +0530, Nori, Sekhar wrote:
> I also found some check patch errors. Feel free to merge
> the attached patch.

And this introduces another style issue...

> diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
> index 8279c47..aae5e35 100644
> --- a/arch/arm/plat-mxc/include/mach/iram.h
> +++ b/arch/arm/plat-mxc/include/mach/iram.h
> @@ -31,7 +31,7 @@ static inline void *iram_alloc(size_t size, phys_addr_t *phys)
>  
>  	*phys = gen_pool_virt_to_phys(iram_pool, addr);
>  
> -	return (void*)addr;
> +	return (void *) addr;

The style here is:
	return (void *)addr;

[RFC PATCH v4] Consolidate SRAM support

[Russell King - ARM Linux]

On Tue, May 31, 2011 at 10:39:48PM +0530, Nori, Sekhar wrote:
> I also found some check patch errors. Feel free to merge
> the attached patch.

And this introduces another style issue...

> diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
> index 8279c47..aae5e35 100644
> --- a/arch/arm/plat-mxc/include/mach/iram.h
> +++ b/arch/arm/plat-mxc/include/mach/iram.h
> @@ -31,7 +31,7 @@ static inline void *iram_alloc(size_t size, phys_addr_t *phys)
>  
>  	*phys = gen_pool_virt_to_phys(iram_pool, addr);
>  
> -	return (void*)addr;
> +	return (void *) addr;

The style here is:
	return (void *)addr;

RE: [RFC PATCH v4] Consolidate SRAM support

[Nori, Sekhar]

Hi Jean-Christophe,

On Thu, May 26, 2011 at 06:32:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
> 
> 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.
> 
> For this use the generic allocator and the newly introduce
> gen_pool_add_virt and gen_pool_virt_to_phys
> 
> 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>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>

Is this patch slated to be merged for v3.1?
I did not find it in linux-next.

There is some further cleanup done by Ben
Gardiner for DaVinci which depends on this patch.

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f4b7dfa..5ec5e5f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -848,6 +848,7 @@ config ARCH_DAVINCI
>  	bool "TI DaVinci"
>  	select GENERIC_CLOCKEVENTS
>  	select ARCH_REQUIRE_GPIOLIB
> +	select GENERIC_ALLOCATOR
>  	select ZONE_DMA
>  	select HAVE_IDE
>  	select CLKDEV_LOOKUP

Just noticed that GENERIC_ALLOCATOR is already selected
For DaVinci (it is right below the CLKDEV_LOOKUP selection)
so this part of the patch can be dropped.

Thanks,
Sekhar

[RFC PATCH v4] Consolidate SRAM support

[Nori, Sekhar]

Hi Jean-Christophe,

On Thu, May 26, 2011 at 06:32:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
> 
> 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.
> 
> For this use the generic allocator and the newly introduce
> gen_pool_add_virt and gen_pool_virt_to_phys
> 
> 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>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>

Is this patch slated to be merged for v3.1?
I did not find it in linux-next.

There is some further cleanup done by Ben
Gardiner for DaVinci which depends on this patch.

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f4b7dfa..5ec5e5f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -848,6 +848,7 @@ config ARCH_DAVINCI
>  	bool "TI DaVinci"
>  	select GENERIC_CLOCKEVENTS
>  	select ARCH_REQUIRE_GPIOLIB
> +	select GENERIC_ALLOCATOR
>  	select ZONE_DMA
>  	select HAVE_IDE
>  	select CLKDEV_LOOKUP

Just noticed that GENERIC_ALLOCATOR is already selected
For DaVinci (it is right below the CLKDEV_LOOKUP selection)
so this part of the patch can be dropped.

Thanks,
Sekhar

RE: [RFC PATCH v4] Consolidate SRAM support

[Nori, Sekhar]

Hi Jean-Christophe,

On Thu, May 26, 2011 at 06:32:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
> 
> 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.
> 
> For this use the generic allocator and the newly introduce
> gen_pool_add_virt and gen_pool_virt_to_phys
> 
> 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>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f4b7dfa..5ec5e5f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -848,6 +848,7 @@ config ARCH_DAVINCI
>  	bool "TI DaVinci"
>  	select GENERIC_CLOCKEVENTS
>  	select ARCH_REQUIRE_GPIOLIB
> +	select GENERIC_ALLOCATOR
>  	select ZONE_DMA
>  	select HAVE_IDE
>  	select CLKDEV_LOOKUP

GENERIC_ALLOCATOR is already selected for
DaVinci (below the "select CLKDEV_LOOKUP"
line).

Please drop this hunk.

Thanks,
Sekhar

[RFC PATCH v4] Consolidate SRAM support

[Nori, Sekhar]

Hi Jean-Christophe,

On Thu, May 26, 2011 at 06:32:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
> 
> 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.
> 
> For this use the generic allocator and the newly introduce
> gen_pool_add_virt and gen_pool_virt_to_phys
> 
> 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>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f4b7dfa..5ec5e5f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -848,6 +848,7 @@ config ARCH_DAVINCI
>  	bool "TI DaVinci"
>  	select GENERIC_CLOCKEVENTS
>  	select ARCH_REQUIRE_GPIOLIB
> +	select GENERIC_ALLOCATOR
>  	select ZONE_DMA
>  	select HAVE_IDE
>  	select CLKDEV_LOOKUP

GENERIC_ALLOCATOR is already selected for
DaVinci (below the "select CLKDEV_LOOKUP"
line).

Please drop this hunk.

Thanks,
Sekhar

RE: [RFC PATCH v4] Consolidate SRAM support

[Nori, Sekhar]

On Fri, Jul 08, 2011 at 22:21:52, Nori, Sekhar wrote:
> Hi Jean-Christophe,
> 
> On Thu, May 26, 2011 at 06:32:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > From: Russell King - ARM Linux <linux@arm.linux.org.uk>

> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index f4b7dfa..5ec5e5f 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -848,6 +848,7 @@ config ARCH_DAVINCI
> >  	bool "TI DaVinci"
> >  	select GENERIC_CLOCKEVENTS
> >  	select ARCH_REQUIRE_GPIOLIB
> > +	select GENERIC_ALLOCATOR
> >  	select ZONE_DMA
> >  	select HAVE_IDE
> >  	select CLKDEV_LOOKUP
> 
> GENERIC_ALLOCATOR is already selected for
> DaVinci (below the "select CLKDEV_LOOKUP"
> line).
> 
> Please drop this hunk.

This mail popped up at the top of my inbox
as an unread message and I replied to it
without looking at the sent date assuming
it is a patch resend.

Sorry about the noise.

Thanks,
Sekhar

[RFC PATCH v4] Consolidate SRAM support

[Nori, Sekhar]

On Fri, Jul 08, 2011 at 22:21:52, Nori, Sekhar wrote:
> Hi Jean-Christophe,
> 
> On Thu, May 26, 2011 at 06:32:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > From: Russell King - ARM Linux <linux@arm.linux.org.uk>

> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index f4b7dfa..5ec5e5f 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -848,6 +848,7 @@ config ARCH_DAVINCI
> >  	bool "TI DaVinci"
> >  	select GENERIC_CLOCKEVENTS
> >  	select ARCH_REQUIRE_GPIOLIB
> > +	select GENERIC_ALLOCATOR
> >  	select ZONE_DMA
> >  	select HAVE_IDE
> >  	select CLKDEV_LOOKUP
> 
> GENERIC_ALLOCATOR is already selected for
> DaVinci (below the "select CLKDEV_LOOKUP"
> line).
> 
> Please drop this hunk.

This mail popped up at the top of my inbox
as an unread message and I replied to it
without looking at the sent date assuming
it is a patch resend.

Sorry about the noise.

Thanks,
Sekhar