Re: [RFC PATCH v2] Consolidate SRAM support
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2] Consolidate SRAM support
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2] Consolidate SRAM support
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.
>From 05f5a21ca6423b3051d442eaad3ba34ac131ef98 Mon Sep 17 00:00:00 2001
From: Jean-Christophe PLAGNIOL-VILLARD
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
---
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->loc
Re: [RFC PATCH v2] Consolidate SRAM support
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2] Consolidate SRAM support
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
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +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 000..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
> +
> +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 = 0x0001,
> + .sram_phys = 0x0001,
> .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 = 0x0001
Re: [RFC PATCH v2] Consolidate SRAM support
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH v2] Consolidate SRAM support
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2] Consolidate SRAM support
* Russell King - ARM Linux [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2] Consolidate SRAM support
On Mon, Apr 18, 2011 at 4:52 PM, 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. > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2] Consolidate SRAM support
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/co
