[PATCH V4 0/3] ARM: mmp: add audio sram support

[PATCH V4 0/3] ARM: mmp: add audio sram support

[Leo Yan]

On mmp platform, there have two sram banks:
audio sram bank, and internal sram bank for video and PM.
So add the sram module to manage these sram banks.

And register the sram banks so can dynamically alloc/free
the buffer.

Leo Yan (3):
  ARM: mmp: add sram allocator
  ARM: mmp: register audio sram bank
  ARM: mmp: register internal sram bank

 arch/arm/Kconfig                      |    1 +
 arch/arm/mach-mmp/Makefile            |    2 +-
 arch/arm/mach-mmp/brownstone.c        |   11 ++
 arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
 arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
 arch/arm/mach-mmp/mmp2.c              |    3 +
 arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
 7 files changed, 232 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
 create mode 100644 arch/arm/mach-mmp/sram.c

-- 
1.7.4.1

[PATCH V4 0/3] ARM: mmp: add audio sram support

[Leo Yan]

On mmp platform, there have two sram banks:
audio sram bank, and internal sram bank for video and PM.
So add the sram module to manage these sram banks.

And register the sram banks so can dynamically alloc/free
the buffer.

Leo Yan (3):
  ARM: mmp: add sram allocator
  ARM: mmp: register audio sram bank
  ARM: mmp: register internal sram bank

 arch/arm/Kconfig                      |    1 +
 arch/arm/mach-mmp/Makefile            |    2 +-
 arch/arm/mach-mmp/brownstone.c        |   11 ++
 arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
 arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
 arch/arm/mach-mmp/mmp2.c              |    3 +
 arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
 7 files changed, 232 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
 create mode 100644 arch/arm/mach-mmp/sram.c

-- 
1.7.4.1

[PATCH 1/3] ARM: mmp: add sram allocator

[Leo Yan]

On mmp platform, there have two sram banks:
audio sram and internal sram. The audio sram is mainly for audio;
the internal sram is for video, wtm and power management.
So add the sram allocator using genalloc to manage them.

Every sram bank will register its own platform device
info, after the sram allocator create the generic pool
for the sram bank, the user module can use the pool's
name to get the pool handler; then it can use the handler
to alloc/free memory with genalloc APIs.

Signed-off-by: Leo Yan <leoy@marvell.com>
---
 arch/arm/Kconfig                      |    1 +
 arch/arm/mach-mmp/Makefile            |    2 +-
 arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
 arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
 4 files changed, 205 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
 create mode 100644 arch/arm/mach-mmp/sram.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c71a8f..c7545d1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -559,6 +559,7 @@ config ARCH_MMP
 	select TICK_ONESHOT
 	select PLAT_PXA
 	select SPARSE_IRQ
+	select GENERIC_ALLOCATOR
 	help
 	  Support for Marvell's PXA168/PXA910(MMP) and MMP2 processor line.
 
diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
index b0ac942..169c674 100644
--- a/arch/arm/mach-mmp/Makefile
+++ b/arch/arm/mach-mmp/Makefile
@@ -7,7 +7,7 @@ obj-y				+= common.o clock.o devices.o time.o
 # SoC support
 obj-$(CONFIG_CPU_PXA168)	+= pxa168.o irq-pxa168.o
 obj-$(CONFIG_CPU_PXA910)	+= pxa910.o irq-pxa168.o
-obj-$(CONFIG_CPU_MMP2)		+= mmp2.o irq-mmp2.o
+obj-$(CONFIG_CPU_MMP2)		+= mmp2.o irq-mmp2.o sram.o
 
 # board support
 obj-$(CONFIG_MACH_ASPENITE)	+= aspenite.o
diff --git a/arch/arm/mach-mmp/include/mach/sram.h b/arch/arm/mach-mmp/include/mach/sram.h
new file mode 100644
index 0000000..239e0fc
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/sram.h
@@ -0,0 +1,35 @@
+/*
+ *  linux/arch/arm/mach-mmp/include/mach/sram.h
+ *
+ *  SRAM Memory Management
+ *
+ *  Copyright (c) 2011 Marvell Semiconductors Inc.
+ *
+ *  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 __ASM_ARCH_SRAM_H
+#define __ASM_ARCH_SRAM_H
+
+#include <linux/genalloc.h>
+
+/* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
+#define SRAM_GRANULARITY	512
+
+enum sram_type {
+	MMP_SRAM_UNDEFINED = 0,
+	MMP_ASRAM,
+	MMP_ISRAM,
+};
+
+struct sram_platdata {
+	char *pool_name;
+	int granularity;
+};
+
+extern struct gen_pool *sram_get_gpool(char *pool_name);
+
+#endif /* __ASM_ARCH_SRAM_H */
diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
new file mode 100644
index 0000000..4304f95
--- /dev/null
+++ b/arch/arm/mach-mmp/sram.c
@@ -0,0 +1,168 @@
+/*
+ *  linux/arch/arm/mach-mmp/sram.c
+ *
+ *  based on mach-davinci/sram.c - DaVinci simple SRAM allocator
+ *
+ *  Copyright (c) 2011 Marvell Semiconductors Inc.
+ *  All Rights Reserved
+ *
+ *  Add for mmp sram support - Leo Yan <leoy@marvell.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 <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/slab.h>
+#include <linux/genalloc.h>
+
+#include <mach/sram.h>
+
+struct sram_bank_info {
+	char *pool_name;
+	struct gen_pool *gpool;
+	int granularity;
+
+	phys_addr_t sram_phys;
+	void __iomem *sram_virt;
+	u32 sram_size;
+
+	struct list_head node;
+};
+
+static DEFINE_MUTEX(sram_lock);
+static LIST_HEAD(sram_bank_list);
+
+struct gen_pool *sram_get_gpool(char *pool_name)
+{
+	struct sram_bank_info *info = NULL;
+
+	if (!pool_name)
+		return NULL;
+
+	mutex_lock(&sram_lock);
+
+	list_for_each_entry(info, &sram_bank_list, node)
+		if (!strcmp(pool_name, info->pool_name))
+			break;
+
+	mutex_unlock(&sram_lock);
+
+	if (&info->node == &sram_bank_list)
+		return NULL;
+
+	return info->gpool;
+}
+EXPORT_SYMBOL(sram_get_gpool);
+
+static int __devinit sram_probe(struct platform_device *pdev)
+{
+	struct sram_platdata *pdata = pdev->dev.platform_data;
+	struct sram_bank_info *info;
+	struct resource *res;
+	int ret = 0;
+
+	if (!pdata && !pdata->pool_name)
+		return -ENODEV;
+
+	info = kzalloc(sizeof(*info), GFP_KERNEL);
+	if (!info)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (res == NULL) {
+		dev_err(&pdev->dev, "no memory resource defined\n");
+		ret = -ENODEV;
+		goto out;
+	}
+
+	if (!resource_size(res))
+		return 0;
+
+	info->sram_phys   = (phys_addr_t)res->start;
+	info->sram_size   = resource_size(res);
+	info->sram_virt   = ioremap(info->sram_phys, info->sram_size);
+	info->pool_name	  = kstrdup(pdata->pool_name, GFP_KERNEL);
+	info->granularity = pdata->granularity;
+
+	info->gpool = gen_pool_create(ilog2(info->granularity), -1);
+	if (!info->gpool) {
+		dev_err(&pdev->dev, "create pool failed\n");
+		ret = -ENOMEM;
+		goto create_pool_err;
+	}
+
+	ret = gen_pool_add_virt(info->gpool, (unsigned long)info->sram_virt,
+				info->sram_phys, info->sram_size, -1);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "add new chunk failed\n");
+		ret = -ENOMEM;
+		goto add_chunk_err;
+	}
+
+	mutex_lock(&sram_lock);
+	list_add(&info->node, &sram_bank_list);
+	mutex_unlock(&sram_lock);
+
+	platform_set_drvdata(pdev, info);
+
+	dev_info(&pdev->dev, "initialized\n");
+	return 0;
+
+add_chunk_err:
+	gen_pool_destroy(info->gpool);
+create_pool_err:
+	iounmap(info->sram_virt);
+	kfree(info->pool_name);
+out:
+	kfree(info);
+	return ret;
+}
+
+static int __devexit sram_remove(struct platform_device *pdev)
+{
+	struct sram_bank_info *info;
+
+	info = platform_get_drvdata(pdev);
+	if (info == NULL)
+		return -ENODEV;
+
+	mutex_lock(&sram_lock);
+	list_del(&info->node);
+	mutex_unlock(&sram_lock);
+
+	gen_pool_destroy(info->gpool);
+	iounmap(info->sram_virt);
+	kfree(info->pool_name);
+	kfree(info);
+	return 0;
+}
+
+static const struct platform_device_id sram_id_table[] = {
+	{ "asram", MMP_ASRAM },
+	{ "isram", MMP_ISRAM },
+	{ }
+};
+
+static struct platform_driver sram_driver = {
+	.probe		= sram_probe,
+	.remove		= sram_remove,
+	.driver		= {
+		.name	= "mmp-sram",
+	},
+	.id_table	= sram_id_table,
+};
+
+static int __init sram_init(void)
+{
+	return platform_driver_register(&sram_driver);
+}
+core_initcall(sram_init);
+
+MODULE_LICENSE("GPL");
-- 
1.7.4.1

[PATCH 1/3] ARM: mmp: add sram allocator

[Leo Yan]

On mmp platform, there have two sram banks:
audio sram and internal sram. The audio sram is mainly for audio;
the internal sram is for video, wtm and power management.
So add the sram allocator using genalloc to manage them.

Every sram bank will register its own platform device
info, after the sram allocator create the generic pool
for the sram bank, the user module can use the pool's
name to get the pool handler; then it can use the handler
to alloc/free memory with genalloc APIs.

Signed-off-by: Leo Yan <leoy@marvell.com>
---
 arch/arm/Kconfig                      |    1 +
 arch/arm/mach-mmp/Makefile            |    2 +-
 arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
 arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
 4 files changed, 205 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
 create mode 100644 arch/arm/mach-mmp/sram.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c71a8f..c7545d1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -559,6 +559,7 @@ config ARCH_MMP
 	select TICK_ONESHOT
 	select PLAT_PXA
 	select SPARSE_IRQ
+	select GENERIC_ALLOCATOR
 	help
 	  Support for Marvell's PXA168/PXA910(MMP) and MMP2 processor line.
 
diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
index b0ac942..169c674 100644
--- a/arch/arm/mach-mmp/Makefile
+++ b/arch/arm/mach-mmp/Makefile
@@ -7,7 +7,7 @@ obj-y				+= common.o clock.o devices.o time.o
 # SoC support
 obj-$(CONFIG_CPU_PXA168)	+= pxa168.o irq-pxa168.o
 obj-$(CONFIG_CPU_PXA910)	+= pxa910.o irq-pxa168.o
-obj-$(CONFIG_CPU_MMP2)		+= mmp2.o irq-mmp2.o
+obj-$(CONFIG_CPU_MMP2)		+= mmp2.o irq-mmp2.o sram.o
 
 # board support
 obj-$(CONFIG_MACH_ASPENITE)	+= aspenite.o
diff --git a/arch/arm/mach-mmp/include/mach/sram.h b/arch/arm/mach-mmp/include/mach/sram.h
new file mode 100644
index 0000000..239e0fc
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/sram.h
@@ -0,0 +1,35 @@
+/*
+ *  linux/arch/arm/mach-mmp/include/mach/sram.h
+ *
+ *  SRAM Memory Management
+ *
+ *  Copyright (c) 2011 Marvell Semiconductors Inc.
+ *
+ *  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 __ASM_ARCH_SRAM_H
+#define __ASM_ARCH_SRAM_H
+
+#include <linux/genalloc.h>
+
+/* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
+#define SRAM_GRANULARITY	512
+
+enum sram_type {
+	MMP_SRAM_UNDEFINED = 0,
+	MMP_ASRAM,
+	MMP_ISRAM,
+};
+
+struct sram_platdata {
+	char *pool_name;
+	int granularity;
+};
+
+extern struct gen_pool *sram_get_gpool(char *pool_name);
+
+#endif /* __ASM_ARCH_SRAM_H */
diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
new file mode 100644
index 0000000..4304f95
--- /dev/null
+++ b/arch/arm/mach-mmp/sram.c
@@ -0,0 +1,168 @@
+/*
+ *  linux/arch/arm/mach-mmp/sram.c
+ *
+ *  based on mach-davinci/sram.c - DaVinci simple SRAM allocator
+ *
+ *  Copyright (c) 2011 Marvell Semiconductors Inc.
+ *  All Rights Reserved
+ *
+ *  Add for mmp sram support - Leo Yan <leoy@marvell.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 <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/slab.h>
+#include <linux/genalloc.h>
+
+#include <mach/sram.h>
+
+struct sram_bank_info {
+	char *pool_name;
+	struct gen_pool *gpool;
+	int granularity;
+
+	phys_addr_t sram_phys;
+	void __iomem *sram_virt;
+	u32 sram_size;
+
+	struct list_head node;
+};
+
+static DEFINE_MUTEX(sram_lock);
+static LIST_HEAD(sram_bank_list);
+
+struct gen_pool *sram_get_gpool(char *pool_name)
+{
+	struct sram_bank_info *info = NULL;
+
+	if (!pool_name)
+		return NULL;
+
+	mutex_lock(&sram_lock);
+
+	list_for_each_entry(info, &sram_bank_list, node)
+		if (!strcmp(pool_name, info->pool_name))
+			break;
+
+	mutex_unlock(&sram_lock);
+
+	if (&info->node == &sram_bank_list)
+		return NULL;
+
+	return info->gpool;
+}
+EXPORT_SYMBOL(sram_get_gpool);
+
+static int __devinit sram_probe(struct platform_device *pdev)
+{
+	struct sram_platdata *pdata = pdev->dev.platform_data;
+	struct sram_bank_info *info;
+	struct resource *res;
+	int ret = 0;
+
+	if (!pdata && !pdata->pool_name)
+		return -ENODEV;
+
+	info = kzalloc(sizeof(*info), GFP_KERNEL);
+	if (!info)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (res == NULL) {
+		dev_err(&pdev->dev, "no memory resource defined\n");
+		ret = -ENODEV;
+		goto out;
+	}
+
+	if (!resource_size(res))
+		return 0;
+
+	info->sram_phys   = (phys_addr_t)res->start;
+	info->sram_size   = resource_size(res);
+	info->sram_virt   = ioremap(info->sram_phys, info->sram_size);
+	info->pool_name	  = kstrdup(pdata->pool_name, GFP_KERNEL);
+	info->granularity = pdata->granularity;
+
+	info->gpool = gen_pool_create(ilog2(info->granularity), -1);
+	if (!info->gpool) {
+		dev_err(&pdev->dev, "create pool failed\n");
+		ret = -ENOMEM;
+		goto create_pool_err;
+	}
+
+	ret = gen_pool_add_virt(info->gpool, (unsigned long)info->sram_virt,
+				info->sram_phys, info->sram_size, -1);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "add new chunk failed\n");
+		ret = -ENOMEM;
+		goto add_chunk_err;
+	}
+
+	mutex_lock(&sram_lock);
+	list_add(&info->node, &sram_bank_list);
+	mutex_unlock(&sram_lock);
+
+	platform_set_drvdata(pdev, info);
+
+	dev_info(&pdev->dev, "initialized\n");
+	return 0;
+
+add_chunk_err:
+	gen_pool_destroy(info->gpool);
+create_pool_err:
+	iounmap(info->sram_virt);
+	kfree(info->pool_name);
+out:
+	kfree(info);
+	return ret;
+}
+
+static int __devexit sram_remove(struct platform_device *pdev)
+{
+	struct sram_bank_info *info;
+
+	info = platform_get_drvdata(pdev);
+	if (info == NULL)
+		return -ENODEV;
+
+	mutex_lock(&sram_lock);
+	list_del(&info->node);
+	mutex_unlock(&sram_lock);
+
+	gen_pool_destroy(info->gpool);
+	iounmap(info->sram_virt);
+	kfree(info->pool_name);
+	kfree(info);
+	return 0;
+}
+
+static const struct platform_device_id sram_id_table[] = {
+	{ "asram", MMP_ASRAM },
+	{ "isram", MMP_ISRAM },
+	{ }
+};
+
+static struct platform_driver sram_driver = {
+	.probe		= sram_probe,
+	.remove		= sram_remove,
+	.driver		= {
+		.name	= "mmp-sram",
+	},
+	.id_table	= sram_id_table,
+};
+
+static int __init sram_init(void)
+{
+	return platform_driver_register(&sram_driver);
+}
+core_initcall(sram_init);
+
+MODULE_LICENSE("GPL");
-- 
1.7.4.1

[PATCH 1/3] ARM: mmp: add sram allocator

[Arnd Bergmann]

On Monday 15 August 2011 11:09:52 Leo Yan wrote:
> On mmp platform, there have two sram banks:
> audio sram and internal sram. The audio sram is mainly for audio;
> the internal sram is for video, wtm and power management.
> So add the sram allocator using genalloc to manage them.
> 
> Every sram bank will register its own platform device
> info, after the sram allocator create the generic pool
> for the sram bank, the user module can use the pool's
> name to get the pool handler; then it can use the handler
> to alloc/free memory with genalloc APIs.
> 
> Signed-off-by: Leo Yan <leoy@marvell.com>
> ---
>  arch/arm/Kconfig                      |    1 +
>  arch/arm/mach-mmp/Makefile            |    2 +-
>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>  4 files changed, 205 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>  create mode 100644 arch/arm/mach-mmp/sram.c

Some time ago, there was talk of merging the existing sram drivers
and creating a common driver that is easy to hook into.

What has happened with that? My feeling is that we should stop adding
more drivers like this in the platform code but rather put an
authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
and change over the existing drivers to hook into that one.

	Arnd

Re: [PATCH 1/3] ARM: mmp: add sram allocator

[Arnd Bergmann]

On Monday 15 August 2011 11:09:52 Leo Yan wrote:
> On mmp platform, there have two sram banks:
> audio sram and internal sram. The audio sram is mainly for audio;
> the internal sram is for video, wtm and power management.
> So add the sram allocator using genalloc to manage them.
> 
> Every sram bank will register its own platform device
> info, after the sram allocator create the generic pool
> for the sram bank, the user module can use the pool's
> name to get the pool handler; then it can use the handler
> to alloc/free memory with genalloc APIs.
> 
> Signed-off-by: Leo Yan <leoy@marvell.com>
> ---
>  arch/arm/Kconfig                      |    1 +
>  arch/arm/mach-mmp/Makefile            |    2 +-
>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>  4 files changed, 205 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>  create mode 100644 arch/arm/mach-mmp/sram.c

Some time ago, there was talk of merging the existing sram drivers
and creating a common driver that is easy to hook into.

What has happened with that? My feeling is that we should stop adding
more drivers like this in the platform code but rather put an
authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
and change over the existing drivers to hook into that one.

	Arnd

[PATCH 1/3] ARM: mmp: add sram allocator

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:59 Mon 15 Aug     , Arnd Bergmann wrote:
> On Monday 15 August 2011 11:09:52 Leo Yan wrote:
> > On mmp platform, there have two sram banks:
> > audio sram and internal sram. The audio sram is mainly for audio;
> > the internal sram is for video, wtm and power management.
> > So add the sram allocator using genalloc to manage them.
> > 
> > Every sram bank will register its own platform device
> > info, after the sram allocator create the generic pool
> > for the sram bank, the user module can use the pool's
> > name to get the pool handler; then it can use the handler
> > to alloc/free memory with genalloc APIs.
> > 
> > Signed-off-by: Leo Yan <leoy@marvell.com>
> > ---
> >  arch/arm/Kconfig                      |    1 +
> >  arch/arm/mach-mmp/Makefile            |    2 +-
> >  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
> >  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
> >  4 files changed, 205 insertions(+), 1 deletions(-)
> >  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
> >  create mode 100644 arch/arm/mach-mmp/sram.c
> 
> Some time ago, there was talk of merging the existing sram drivers
> and creating a common driver that is easy to hook into.
> 
> What has happened with that? My feeling is that we should stop adding
> more drivers like this in the platform code but rather put an
> authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
> and change over the existing drivers to hook into that one.
no need anymore I send patch to add the support of phys/virt to genalloc so
now we just have to use it

Best Regards,
J.

Re: [PATCH 1/3] ARM: mmp: add sram allocator

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:59 Mon 15 Aug     , Arnd Bergmann wrote:
> On Monday 15 August 2011 11:09:52 Leo Yan wrote:
> > On mmp platform, there have two sram banks:
> > audio sram and internal sram. The audio sram is mainly for audio;
> > the internal sram is for video, wtm and power management.
> > So add the sram allocator using genalloc to manage them.
> > 
> > Every sram bank will register its own platform device
> > info, after the sram allocator create the generic pool
> > for the sram bank, the user module can use the pool's
> > name to get the pool handler; then it can use the handler
> > to alloc/free memory with genalloc APIs.
> > 
> > Signed-off-by: Leo Yan <leoy@marvell.com>
> > ---
> >  arch/arm/Kconfig                      |    1 +
> >  arch/arm/mach-mmp/Makefile            |    2 +-
> >  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
> >  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
> >  4 files changed, 205 insertions(+), 1 deletions(-)
> >  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
> >  create mode 100644 arch/arm/mach-mmp/sram.c
> 
> Some time ago, there was talk of merging the existing sram drivers
> and creating a common driver that is easy to hook into.
> 
> What has happened with that? My feeling is that we should stop adding
> more drivers like this in the platform code but rather put an
> authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
> and change over the existing drivers to hook into that one.
no need anymore I send patch to add the support of phys/virt to genalloc so
now we just have to use it

Best Regards,
J.

[PATCH 1/3] ARM: mmp: add sram allocator

[Haojian Zhuang]

On Mon, Aug 15, 2011 at 5:09 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 10:59 Mon 15 Aug ? ? , Arnd Bergmann wrote:
>> On Monday 15 August 2011 11:09:52 Leo Yan wrote:
>> > On mmp platform, there have two sram banks:
>> > audio sram and internal sram. The audio sram is mainly for audio;
>> > the internal sram is for video, wtm and power management.
>> > So add the sram allocator using genalloc to manage them.
>> >
>> > Every sram bank will register its own platform device
>> > info, after the sram allocator create the generic pool
>> > for the sram bank, the user module can use the pool's
>> > name to get the pool handler; then it can use the handler
>> > to alloc/free memory with genalloc APIs.
>> >
>> > Signed-off-by: Leo Yan <leoy@marvell.com>
>> > ---
>> > ?arch/arm/Kconfig ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
>> > ?arch/arm/mach-mmp/Makefile ? ? ? ? ? ?| ? ?2 +-
>> > ?arch/arm/mach-mmp/include/mach/sram.h | ? 35 +++++++
>> > ?arch/arm/mach-mmp/sram.c ? ? ? ? ? ? ?| ?168 +++++++++++++++++++++++++++++++++
>> > ?4 files changed, 205 insertions(+), 1 deletions(-)
>> > ?create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>> > ?create mode 100644 arch/arm/mach-mmp/sram.c
>>
>> Some time ago, there was talk of merging the existing sram drivers
>> and creating a common driver that is easy to hook into.
>>
>> What has happened with that? My feeling is that we should stop adding
>> more drivers like this in the platform code but rather put an
>> authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
>> and change over the existing drivers to hook into that one.
> no need anymore I send patch to add the support of phys/virt to genalloc so
> now we just have to use it
>
> Best Regards,
> J.
>
Exactly, and Russel already gave up on original patch. genpool is already a
common driver.

Thanks
Haojian

Re: [PATCH 1/3] ARM: mmp: add sram allocator

[Haojian Zhuang]

On Mon, Aug 15, 2011 at 5:09 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 10:59 Mon 15 Aug     , Arnd Bergmann wrote:
>> On Monday 15 August 2011 11:09:52 Leo Yan wrote:
>> > On mmp platform, there have two sram banks:
>> > audio sram and internal sram. The audio sram is mainly for audio;
>> > the internal sram is for video, wtm and power management.
>> > So add the sram allocator using genalloc to manage them.
>> >
>> > Every sram bank will register its own platform device
>> > info, after the sram allocator create the generic pool
>> > for the sram bank, the user module can use the pool's
>> > name to get the pool handler; then it can use the handler
>> > to alloc/free memory with genalloc APIs.
>> >
>> > Signed-off-by: Leo Yan <leoy@marvell.com>
>> > ---
>> >  arch/arm/Kconfig                      |    1 +
>> >  arch/arm/mach-mmp/Makefile            |    2 +-
>> >  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>> >  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>> >  4 files changed, 205 insertions(+), 1 deletions(-)
>> >  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>> >  create mode 100644 arch/arm/mach-mmp/sram.c
>>
>> Some time ago, there was talk of merging the existing sram drivers
>> and creating a common driver that is easy to hook into.
>>
>> What has happened with that? My feeling is that we should stop adding
>> more drivers like this in the platform code but rather put an
>> authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
>> and change over the existing drivers to hook into that one.
> no need anymore I send patch to add the support of phys/virt to genalloc so
> now we just have to use it
>
> Best Regards,
> J.
>
Exactly, and Russel already gave up on original patch. genpool is already a
common driver.

Thanks
Haojian

[PATCH 1/3] ARM: mmp: add sram allocator

[Tony Lindgren]

* Haojian Zhuang <haojian.zhuang@gmail.com> [110815 01:57]:
> On Mon, Aug 15, 2011 at 5:09 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > On 10:59 Mon 15 Aug ? ? , Arnd Bergmann wrote:
> >> On Monday 15 August 2011 11:09:52 Leo Yan wrote:
> >> > On mmp platform, there have two sram banks:
> >> > audio sram and internal sram. The audio sram is mainly for audio;
> >> > the internal sram is for video, wtm and power management.
> >> > So add the sram allocator using genalloc to manage them.
> >> >
> >> > Every sram bank will register its own platform device
> >> > info, after the sram allocator create the generic pool
> >> > for the sram bank, the user module can use the pool's
> >> > name to get the pool handler; then it can use the handler
> >> > to alloc/free memory with genalloc APIs.
> >> >
> >> > Signed-off-by: Leo Yan <leoy@marvell.com>
> >> > ---
> >> > ?arch/arm/Kconfig ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> >> > ?arch/arm/mach-mmp/Makefile ? ? ? ? ? ?| ? ?2 +-
> >> > ?arch/arm/mach-mmp/include/mach/sram.h | ? 35 +++++++
> >> > ?arch/arm/mach-mmp/sram.c ? ? ? ? ? ? ?| ?168 +++++++++++++++++++++++++++++++++
> >> > ?4 files changed, 205 insertions(+), 1 deletions(-)
> >> > ?create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
> >> > ?create mode 100644 arch/arm/mach-mmp/sram.c
> >>
> >> Some time ago, there was talk of merging the existing sram drivers
> >> and creating a common driver that is easy to hook into.
> >>
> >> What has happened with that? My feeling is that we should stop adding
> >> more drivers like this in the platform code but rather put an
> >> authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
> >> and change over the existing drivers to hook into that one.
> > no need anymore I send patch to add the support of phys/virt to genalloc so
> > now we just have to use it
> >
> > Best Regards,
> > J.
> >
> Exactly, and Russel already gave up on original patch. genpool is already a
> common driver.

Yeah but it seems that we can make arch/arm/mach-mmp/sram.c posted
in this thread a generic driver instead.

Regards,

Tony

Re: [PATCH 1/3] ARM: mmp: add sram allocator

[Tony Lindgren]

* Haojian Zhuang <haojian.zhuang@gmail.com> [110815 01:57]:
> On Mon, Aug 15, 2011 at 5:09 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > On 10:59 Mon 15 Aug     , Arnd Bergmann wrote:
> >> On Monday 15 August 2011 11:09:52 Leo Yan wrote:
> >> > On mmp platform, there have two sram banks:
> >> > audio sram and internal sram. The audio sram is mainly for audio;
> >> > the internal sram is for video, wtm and power management.
> >> > So add the sram allocator using genalloc to manage them.
> >> >
> >> > Every sram bank will register its own platform device
> >> > info, after the sram allocator create the generic pool
> >> > for the sram bank, the user module can use the pool's
> >> > name to get the pool handler; then it can use the handler
> >> > to alloc/free memory with genalloc APIs.
> >> >
> >> > Signed-off-by: Leo Yan <leoy@marvell.com>
> >> > ---
> >> >  arch/arm/Kconfig                      |    1 +
> >> >  arch/arm/mach-mmp/Makefile            |    2 +-
> >> >  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
> >> >  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
> >> >  4 files changed, 205 insertions(+), 1 deletions(-)
> >> >  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
> >> >  create mode 100644 arch/arm/mach-mmp/sram.c
> >>
> >> Some time ago, there was talk of merging the existing sram drivers
> >> and creating a common driver that is easy to hook into.
> >>
> >> What has happened with that? My feeling is that we should stop adding
> >> more drivers like this in the platform code but rather put an
> >> authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
> >> and change over the existing drivers to hook into that one.
> > no need anymore I send patch to add the support of phys/virt to genalloc so
> > now we just have to use it
> >
> > Best Regards,
> > J.
> >
> Exactly, and Russel already gave up on original patch. genpool is already a
> common driver.

Yeah but it seems that we can make arch/arm/mach-mmp/sram.c posted
in this thread a generic driver instead.

Regards,

Tony

[PATCH 1/3] ARM: mmp: add sram allocator

[Leo Yan]

On 08/15/2011 04:59 PM, Arnd Bergmann wrote:
> On Monday 15 August 2011 11:09:52 Leo Yan wrote:
>> On mmp platform, there have two sram banks:
>> audio sram and internal sram. The audio sram is mainly for audio;
>> the internal sram is for video, wtm and power management.
>> So add the sram allocator using genalloc to manage them.
>>
>> Every sram bank will register its own platform device
>> info, after the sram allocator create the generic pool
>> for the sram bank, the user module can use the pool's
>> name to get the pool handler; then it can use the handler
>> to alloc/free memory with genalloc APIs.
>>
>> Signed-off-by: Leo Yan<leoy@marvell.com>
>> ---
>>   arch/arm/Kconfig                      |    1 +
>>   arch/arm/mach-mmp/Makefile            |    2 +-
>>   arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>>   arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>>   4 files changed, 205 insertions(+), 1 deletions(-)
>>   create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>>   create mode 100644 arch/arm/mach-mmp/sram.c
>
> Some time ago, there was talk of merging the existing sram drivers
> and creating a common driver that is easy to hook into.
>
> What has happened with that? My feeling is that we should stop adding
> more drivers like this in the platform code but rather put an
> authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
> and change over the existing drivers to hook into that one.
>
> 	Arnd

I think this is the mail thread for merging sram drivers: Consolidate 
SRAM support;
Here is the latest status for this topic:
http://lists.arm.linux.org.uk/lurker/message/20110710.121939.129161bf.en.html

For JC's genalloc patches has been merged,
in genalloc lib there has maintained the mapping for phys/virt address;
so now just need to create a gen pool, and use this pool handler to 
alloc/free buffer, get the phys address, etc.

My patches has refined the code with the new genalloc APIs.
So you can see now the sram management is pretty simple, just
create the gen pool, then later can directly access genalloc APIs.

Re: [PATCH 1/3] ARM: mmp: add sram allocator

[Leo Yan]

On 08/15/2011 04:59 PM, Arnd Bergmann wrote:
> On Monday 15 August 2011 11:09:52 Leo Yan wrote:
>> On mmp platform, there have two sram banks:
>> audio sram and internal sram. The audio sram is mainly for audio;
>> the internal sram is for video, wtm and power management.
>> So add the sram allocator using genalloc to manage them.
>>
>> Every sram bank will register its own platform device
>> info, after the sram allocator create the generic pool
>> for the sram bank, the user module can use the pool's
>> name to get the pool handler; then it can use the handler
>> to alloc/free memory with genalloc APIs.
>>
>> Signed-off-by: Leo Yan<leoy@marvell.com>
>> ---
>>   arch/arm/Kconfig                      |    1 +
>>   arch/arm/mach-mmp/Makefile            |    2 +-
>>   arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>>   arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>>   4 files changed, 205 insertions(+), 1 deletions(-)
>>   create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>>   create mode 100644 arch/arm/mach-mmp/sram.c
>
> Some time ago, there was talk of merging the existing sram drivers
> and creating a common driver that is easy to hook into.
>
> What has happened with that? My feeling is that we should stop adding
> more drivers like this in the platform code but rather put an
> authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
> and change over the existing drivers to hook into that one.
>
> 	Arnd

I think this is the mail thread for merging sram drivers: Consolidate 
SRAM support;
Here is the latest status for this topic:
http://lists.arm.linux.org.uk/lurker/message/20110710.121939.129161bf.en.html

For JC's genalloc patches has been merged,
in genalloc lib there has maintained the mapping for phys/virt address;
so now just need to create a gen pool, and use this pool handler to 
alloc/free buffer, get the phys address, etc.

My patches has refined the code with the new genalloc APIs.
So you can see now the sram management is pretty simple, just
create the gen pool, then later can directly access genalloc APIs.

[PATCH 1/3] ARM: mmp: add sram allocator

[Nicolas Pitre]

On Mon, 15 Aug 2011, Arnd Bergmann wrote:

> Some time ago, there was talk of merging the existing sram drivers
> and creating a common driver that is easy to hook into.

Absolutely.

> What has happened with that? My feeling is that we should stop adding
> more drivers like this in the platform code but rather put an
> authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
> and change over the existing drivers to hook into that one.

IIRC, this was driven by Russell.  Maybe this is a good time to revive 
discussion around it.


Nicolas

Re: [PATCH 1/3] ARM: mmp: add sram allocator

[Nicolas Pitre]

On Mon, 15 Aug 2011, Arnd Bergmann wrote:

> Some time ago, there was talk of merging the existing sram drivers
> and creating a common driver that is easy to hook into.

Absolutely.

> What has happened with that? My feeling is that we should stop adding
> more drivers like this in the platform code but rather put an
> authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
> and change over the existing drivers to hook into that one.

IIRC, this was driven by Russell.  Maybe this is a good time to revive 
discussion around it.


Nicolas

[PATCH 1/3] ARM: mmp: add sram allocator

[Russell King - ARM Linux]

On Mon, Aug 15, 2011 at 09:23:49AM -0400, Nicolas Pitre wrote:
> On Mon, 15 Aug 2011, Arnd Bergmann wrote:
> 
> > Some time ago, there was talk of merging the existing sram drivers
> > and creating a common driver that is easy to hook into.
> 
> Absolutely.
> 
> > What has happened with that? My feeling is that we should stop adding
> > more drivers like this in the platform code but rather put an
> > authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
> > and change over the existing drivers to hook into that one.
> 
> IIRC, this was driven by Russell.  Maybe this is a good time to revive 
> discussion around it.

As I understand it, Jean-Christophe's patches were essentially a
replacement for my infrastructure changes, and it is Jean-Christophe's
patches which went in.  So, my work is obsolete.

I'm not sure what else there is to be done here - if Jean-Christophe's
genpool interfaces are not sufficient, maybe when the discussion surrounding
my patches and Jean-Christophe's patches happened, maybe someone should've
sorted out finishing off Jean-Christophe's patches to the same extent
that mine have.  Or maybe my patches should've been merged instead of
Jean-Christophe's and Jean-Christophe's brought forward to plug into the
core of my patches.

Either way, I completely gave up with the idea because I saw no future
for my patches, and now I'm no longer interested in it.

Re: [PATCH 1/3] ARM: mmp: add sram allocator

[Russell King - ARM Linux]

On Mon, Aug 15, 2011 at 09:23:49AM -0400, Nicolas Pitre wrote:
> On Mon, 15 Aug 2011, Arnd Bergmann wrote:
> 
> > Some time ago, there was talk of merging the existing sram drivers
> > and creating a common driver that is easy to hook into.
> 
> Absolutely.
> 
> > What has happened with that? My feeling is that we should stop adding
> > more drivers like this in the platform code but rather put an
> > authoritative copy into arch/arm/mm/ or even the top-level mm/ directory
> > and change over the existing drivers to hook into that one.
> 
> IIRC, this was driven by Russell.  Maybe this is a good time to revive 
> discussion around it.

As I understand it, Jean-Christophe's patches were essentially a
replacement for my infrastructure changes, and it is Jean-Christophe's
patches which went in.  So, my work is obsolete.

I'm not sure what else there is to be done here - if Jean-Christophe's
genpool interfaces are not sufficient, maybe when the discussion surrounding
my patches and Jean-Christophe's patches happened, maybe someone should've
sorted out finishing off Jean-Christophe's patches to the same extent
that mine have.  Or maybe my patches should've been merged instead of
Jean-Christophe's and Jean-Christophe's brought forward to plug into the
core of my patches.

Either way, I completely gave up with the idea because I saw no future
for my patches, and now I'm no longer interested in it.

[PATCH 1/3] ARM: mmp: add sram allocator

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:09 Mon 15 Aug     , Leo Yan wrote:
> On mmp platform, there have two sram banks:
> audio sram and internal sram. The audio sram is mainly for audio;
> the internal sram is for video, wtm and power management.
> So add the sram allocator using genalloc to manage them.
> 
> Every sram bank will register its own platform device
> info, after the sram allocator create the generic pool
> for the sram bank, the user module can use the pool's
> name to get the pool handler; then it can use the handler
> to alloc/free memory with genalloc APIs.
> 
> Signed-off-by: Leo Yan <leoy@marvell.com>
> ---
>  arch/arm/Kconfig                      |    1 +
>  arch/arm/mach-mmp/Makefile            |    2 +-
>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>  4 files changed, 205 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>  create mode 100644 arch/arm/mach-mmp/sram.c
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2c71a8f..c7545d1 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -559,6 +559,7 @@ config ARCH_MMP
>  	select TICK_ONESHOT
>  	select PLAT_PXA
>  	select SPARSE_IRQ
> +	select GENERIC_ALLOCATOR
>  	help
>  	  Support for Marvell's PXA168/PXA910(MMP) and MMP2 processor line.
>  
> diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
> index b0ac942..169c674 100644
> --- a/arch/arm/mach-mmp/Makefile
> +++ b/arch/arm/mach-mmp/Makefile
> @@ -7,7 +7,7 @@ obj-y				+= common.o clock.o devices.o time.o
>  # SoC support
>  obj-$(CONFIG_CPU_PXA168)	+= pxa168.o irq-pxa168.o
>  obj-$(CONFIG_CPU_PXA910)	+= pxa910.o irq-pxa168.o
> -obj-$(CONFIG_CPU_MMP2)		+= mmp2.o irq-mmp2.o
> +obj-$(CONFIG_CPU_MMP2)		+= mmp2.o irq-mmp2.o sram.o
>  
>  # board support
>  obj-$(CONFIG_MACH_ASPENITE)	+= aspenite.o
> diff --git a/arch/arm/mach-mmp/include/mach/sram.h b/arch/arm/mach-mmp/include/mach/sram.h
> new file mode 100644
> index 0000000..239e0fc
> --- /dev/null
> +++ b/arch/arm/mach-mmp/include/mach/sram.h
> @@ -0,0 +1,35 @@
> +/*
> + *  linux/arch/arm/mach-mmp/include/mach/sram.h
> + *
> + *  SRAM Memory Management
> + *
> + *  Copyright (c) 2011 Marvell Semiconductors Inc.
> + *
> + *  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 __ASM_ARCH_SRAM_H
> +#define __ASM_ARCH_SRAM_H
> +
> +#include <linux/genalloc.h>
> +
> +/* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
> +#define SRAM_GRANULARITY	512
> +
> +enum sram_type {
> +	MMP_SRAM_UNDEFINED = 0,
> +	MMP_ASRAM,
> +	MMP_ISRAM,
> +};
> +
> +struct sram_platdata {
> +	char *pool_name;
> +	int granularity;
> +};
> +
> +extern struct gen_pool *sram_get_gpool(char *pool_name);
> +
> +#endif /* __ASM_ARCH_SRAM_H */
> diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
> new file mode 100644
> index 0000000..4304f95
> --- /dev/null
> +++ b/arch/arm/mach-mmp/sram.c
> @@ -0,0 +1,168 @@
> +/*
> + *  linux/arch/arm/mach-mmp/sram.c
> + *
> + *  based on mach-davinci/sram.c - DaVinci simple SRAM allocator
> + *
> + *  Copyright (c) 2011 Marvell Semiconductors Inc.
> + *  All Rights Reserved
> + *
> + *  Add for mmp sram support - Leo Yan <leoy@marvell.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 <linux/init.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/err.h>
> +#include <linux/slab.h>
> +#include <linux/genalloc.h>
> +
> +#include <mach/sram.h>
> +
> +struct sram_bank_info {
> +	char *pool_name;
> +	struct gen_pool *gpool;
> +	int granularity;
> +
> +	phys_addr_t sram_phys;
> +	void __iomem *sram_virt;
> +	u32 sram_size;
> +
> +	struct list_head node;
> +};
> +
> +static DEFINE_MUTEX(sram_lock);
> +static LIST_HEAD(sram_bank_list);
> +
> +struct gen_pool *sram_get_gpool(char *pool_name)
> +{
> +	struct sram_bank_info *info = NULL;
> +
> +	if (!pool_name)
> +		return NULL;
> +
> +	mutex_lock(&sram_lock);
> +
> +	list_for_each_entry(info, &sram_bank_list, node)
> +		if (!strcmp(pool_name, info->pool_name))
> +			break;
> +
> +	mutex_unlock(&sram_lock);
> +
> +	if (&info->node == &sram_bank_list)
> +		return NULL;
> +
> +	return info->gpool;
> +}
> +EXPORT_SYMBOL(sram_get_gpool);
> +
> +static int __devinit sram_probe(struct platform_device *pdev)
> +{
> +	struct sram_platdata *pdata = pdev->dev.platform_data;
> +	struct sram_bank_info *info;
> +	struct resource *res;
> +	int ret = 0;
> +
> +	if (!pdata && !pdata->pool_name)
> +		return -ENODEV;
> +
> +	info = kzalloc(sizeof(*info), GFP_KERNEL);
> +	if (!info)
> +		return -ENOMEM;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (res == NULL) {
> +		dev_err(&pdev->dev, "no memory resource defined\n");
> +		ret = -ENODEV;
> +		goto out;
> +	}
> +
> +	if (!resource_size(res))
> +		return 0;
> +
> +	info->sram_phys   = (phys_addr_t)res->start;
> +	info->sram_size   = resource_size(res);
> +	info->sram_virt   = ioremap(info->sram_phys, info->sram_size);
> +	info->pool_name	  = kstrdup(pdata->pool_name, GFP_KERNEL);
> +	info->granularity = pdata->granularity;
if we want name pool this need to be managed at gen alloc level directly
not here

Best Regards,
J.

Re: [PATCH 1/3] ARM: mmp: add sram allocator

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:09 Mon 15 Aug     , Leo Yan wrote:
> On mmp platform, there have two sram banks:
> audio sram and internal sram. The audio sram is mainly for audio;
> the internal sram is for video, wtm and power management.
> So add the sram allocator using genalloc to manage them.
> 
> Every sram bank will register its own platform device
> info, after the sram allocator create the generic pool
> for the sram bank, the user module can use the pool's
> name to get the pool handler; then it can use the handler
> to alloc/free memory with genalloc APIs.
> 
> Signed-off-by: Leo Yan <leoy@marvell.com>
> ---
>  arch/arm/Kconfig                      |    1 +
>  arch/arm/mach-mmp/Makefile            |    2 +-
>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>  4 files changed, 205 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>  create mode 100644 arch/arm/mach-mmp/sram.c
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2c71a8f..c7545d1 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -559,6 +559,7 @@ config ARCH_MMP
>  	select TICK_ONESHOT
>  	select PLAT_PXA
>  	select SPARSE_IRQ
> +	select GENERIC_ALLOCATOR
>  	help
>  	  Support for Marvell's PXA168/PXA910(MMP) and MMP2 processor line.
>  
> diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
> index b0ac942..169c674 100644
> --- a/arch/arm/mach-mmp/Makefile
> +++ b/arch/arm/mach-mmp/Makefile
> @@ -7,7 +7,7 @@ obj-y				+= common.o clock.o devices.o time.o
>  # SoC support
>  obj-$(CONFIG_CPU_PXA168)	+= pxa168.o irq-pxa168.o
>  obj-$(CONFIG_CPU_PXA910)	+= pxa910.o irq-pxa168.o
> -obj-$(CONFIG_CPU_MMP2)		+= mmp2.o irq-mmp2.o
> +obj-$(CONFIG_CPU_MMP2)		+= mmp2.o irq-mmp2.o sram.o
>  
>  # board support
>  obj-$(CONFIG_MACH_ASPENITE)	+= aspenite.o
> diff --git a/arch/arm/mach-mmp/include/mach/sram.h b/arch/arm/mach-mmp/include/mach/sram.h
> new file mode 100644
> index 0000000..239e0fc
> --- /dev/null
> +++ b/arch/arm/mach-mmp/include/mach/sram.h
> @@ -0,0 +1,35 @@
> +/*
> + *  linux/arch/arm/mach-mmp/include/mach/sram.h
> + *
> + *  SRAM Memory Management
> + *
> + *  Copyright (c) 2011 Marvell Semiconductors Inc.
> + *
> + *  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 __ASM_ARCH_SRAM_H
> +#define __ASM_ARCH_SRAM_H
> +
> +#include <linux/genalloc.h>
> +
> +/* ARBITRARY:  SRAM allocations are multiples of this 2^N size */
> +#define SRAM_GRANULARITY	512
> +
> +enum sram_type {
> +	MMP_SRAM_UNDEFINED = 0,
> +	MMP_ASRAM,
> +	MMP_ISRAM,
> +};
> +
> +struct sram_platdata {
> +	char *pool_name;
> +	int granularity;
> +};
> +
> +extern struct gen_pool *sram_get_gpool(char *pool_name);
> +
> +#endif /* __ASM_ARCH_SRAM_H */
> diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
> new file mode 100644
> index 0000000..4304f95
> --- /dev/null
> +++ b/arch/arm/mach-mmp/sram.c
> @@ -0,0 +1,168 @@
> +/*
> + *  linux/arch/arm/mach-mmp/sram.c
> + *
> + *  based on mach-davinci/sram.c - DaVinci simple SRAM allocator
> + *
> + *  Copyright (c) 2011 Marvell Semiconductors Inc.
> + *  All Rights Reserved
> + *
> + *  Add for mmp sram support - Leo Yan <leoy@marvell.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 <linux/init.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/err.h>
> +#include <linux/slab.h>
> +#include <linux/genalloc.h>
> +
> +#include <mach/sram.h>
> +
> +struct sram_bank_info {
> +	char *pool_name;
> +	struct gen_pool *gpool;
> +	int granularity;
> +
> +	phys_addr_t sram_phys;
> +	void __iomem *sram_virt;
> +	u32 sram_size;
> +
> +	struct list_head node;
> +};
> +
> +static DEFINE_MUTEX(sram_lock);
> +static LIST_HEAD(sram_bank_list);
> +
> +struct gen_pool *sram_get_gpool(char *pool_name)
> +{
> +	struct sram_bank_info *info = NULL;
> +
> +	if (!pool_name)
> +		return NULL;
> +
> +	mutex_lock(&sram_lock);
> +
> +	list_for_each_entry(info, &sram_bank_list, node)
> +		if (!strcmp(pool_name, info->pool_name))
> +			break;
> +
> +	mutex_unlock(&sram_lock);
> +
> +	if (&info->node == &sram_bank_list)
> +		return NULL;
> +
> +	return info->gpool;
> +}
> +EXPORT_SYMBOL(sram_get_gpool);
> +
> +static int __devinit sram_probe(struct platform_device *pdev)
> +{
> +	struct sram_platdata *pdata = pdev->dev.platform_data;
> +	struct sram_bank_info *info;
> +	struct resource *res;
> +	int ret = 0;
> +
> +	if (!pdata && !pdata->pool_name)
> +		return -ENODEV;
> +
> +	info = kzalloc(sizeof(*info), GFP_KERNEL);
> +	if (!info)
> +		return -ENOMEM;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (res == NULL) {
> +		dev_err(&pdev->dev, "no memory resource defined\n");
> +		ret = -ENODEV;
> +		goto out;
> +	}
> +
> +	if (!resource_size(res))
> +		return 0;
> +
> +	info->sram_phys   = (phys_addr_t)res->start;
> +	info->sram_size   = resource_size(res);
> +	info->sram_virt   = ioremap(info->sram_phys, info->sram_size);
> +	info->pool_name	  = kstrdup(pdata->pool_name, GFP_KERNEL);
> +	info->granularity = pdata->granularity;
if we want name pool this need to be managed at gen alloc level directly
not here

Best Regards,
J.

[PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Andres Salomon]

The sram code allocates memory with ioremap, which assumes MT_DEVICE
for memory protections.  This explodes when we map sram for power
management purposes and then attempt to execute it (jump_to_lp_sram)
on the OLPC XO-1.75.  Instead, we want to specify MT_MEMORY, which
doesn't set the L_PTE_XN bit.

Signed-off-by: Andres Salomon <dilinger@queued.net>
---
 arch/arm/mach-mmp/sram.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

Eric, this patch is against the devel branch of your pxa tree.

diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
index 4304f95..ca4d3c1 100644
--- a/arch/arm/mach-mmp/sram.c
+++ b/arch/arm/mach-mmp/sram.c
@@ -21,6 +21,7 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <linux/genalloc.h>
+#include <asm/mach/map.h>
 
 #include <mach/sram.h>
 
@@ -87,7 +88,8 @@ static int __devinit sram_probe(struct platform_device *pdev)
 
 	info->sram_phys   = (phys_addr_t)res->start;
 	info->sram_size   = resource_size(res);
-	info->sram_virt   = ioremap(info->sram_phys, info->sram_size);
+	info->sram_virt   = __arm_ioremap(info->sram_phys, info->sram_size,
+					  MT_MEMORY);
 	info->pool_name	  = kstrdup(pdata->pool_name, GFP_KERNEL);
 	info->granularity = pdata->granularity;
 
-- 
1.7.2.5

[PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Andres Salomon]

The sram code allocates memory with ioremap, which assumes MT_DEVICE
for memory protections.  This explodes when we map sram for power
management purposes and then attempt to execute it (jump_to_lp_sram)
on the OLPC XO-1.75.  Instead, we want to specify MT_MEMORY, which
doesn't set the L_PTE_XN bit.

Signed-off-by: Andres Salomon <dilinger@queued.net>
---
 arch/arm/mach-mmp/sram.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

Eric, this patch is against the devel branch of your pxa tree.

diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
index 4304f95..ca4d3c1 100644
--- a/arch/arm/mach-mmp/sram.c
+++ b/arch/arm/mach-mmp/sram.c
@@ -21,6 +21,7 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <linux/genalloc.h>
+#include <asm/mach/map.h>
 
 #include <mach/sram.h>
 
@@ -87,7 +88,8 @@ static int __devinit sram_probe(struct platform_device *pdev)
 
 	info->sram_phys   = (phys_addr_t)res->start;
 	info->sram_size   = resource_size(res);
-	info->sram_virt   = ioremap(info->sram_phys, info->sram_size);
+	info->sram_virt   = __arm_ioremap(info->sram_phys, info->sram_size,
+					  MT_MEMORY);
 	info->pool_name	  = kstrdup(pdata->pool_name, GFP_KERNEL);
 	info->granularity = pdata->granularity;
 
-- 
1.7.2.5

[PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Eric Miao]

On Tue, Aug 23, 2011 at 7:47 AM, Andres Salomon <dilinger@queued.net> wrote:
> The sram code allocates memory with ioremap, which assumes MT_DEVICE
> for memory protections. ?This explodes when we map sram for power
> management purposes and then attempt to execute it (jump_to_lp_sram)
> on the OLPC XO-1.75. ?Instead, we want to specify MT_MEMORY, which
> doesn't set the L_PTE_XN bit.
>
> Signed-off-by: Andres Salomon <dilinger@queued.net>
> ---
> ?arch/arm/mach-mmp/sram.c | ? ?4 +++-
> ?1 files changed, 3 insertions(+), 1 deletions(-)
>
> Eric, this patch is against the devel branch of your pxa tree.
>
> diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
> index 4304f95..ca4d3c1 100644
> --- a/arch/arm/mach-mmp/sram.c
> +++ b/arch/arm/mach-mmp/sram.c
> @@ -21,6 +21,7 @@
> ?#include <linux/err.h>
> ?#include <linux/slab.h>
> ?#include <linux/genalloc.h>
> +#include <asm/mach/map.h>
>
> ?#include <mach/sram.h>
>
> @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct platform_device *pdev)
>
> ? ? ? ?info->sram_phys ? = (phys_addr_t)res->start;
> ? ? ? ?info->sram_size ? = resource_size(res);
> - ? ? ? info->sram_virt ? = ioremap(info->sram_phys, info->sram_size);
> + ? ? ? info->sram_virt ? = __arm_ioremap(info->sram_phys, info->sram_size,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? MT_MEMORY);

I doubt MT_MEMORY is intended for use with __arm_ioremap(). There could
be other way around to the L_PTE_XN bit.

One other way I'm actually thinking of is to add the SRAM mapping to
mmp_map_io(). The difference of SRAM offset/size may result the
separation of mmp_map_io() into {pxa168,pxa910,mmp2}_map_io()
if necessary.

> ? ? ? ?info->pool_name ? = kstrdup(pdata->pool_name, GFP_KERNEL);
> ? ? ? ?info->granularity = pdata->granularity;
>
> --
> 1.7.2.5
>
>

Re: [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Eric Miao]

On Tue, Aug 23, 2011 at 7:47 AM, Andres Salomon <dilinger@queued.net> wrote:
> The sram code allocates memory with ioremap, which assumes MT_DEVICE
> for memory protections.  This explodes when we map sram for power
> management purposes and then attempt to execute it (jump_to_lp_sram)
> on the OLPC XO-1.75.  Instead, we want to specify MT_MEMORY, which
> doesn't set the L_PTE_XN bit.
>
> Signed-off-by: Andres Salomon <dilinger@queued.net>
> ---
>  arch/arm/mach-mmp/sram.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> Eric, this patch is against the devel branch of your pxa tree.
>
> diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
> index 4304f95..ca4d3c1 100644
> --- a/arch/arm/mach-mmp/sram.c
> +++ b/arch/arm/mach-mmp/sram.c
> @@ -21,6 +21,7 @@
>  #include <linux/err.h>
>  #include <linux/slab.h>
>  #include <linux/genalloc.h>
> +#include <asm/mach/map.h>
>
>  #include <mach/sram.h>
>
> @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct platform_device *pdev)
>
>        info->sram_phys   = (phys_addr_t)res->start;
>        info->sram_size   = resource_size(res);
> -       info->sram_virt   = ioremap(info->sram_phys, info->sram_size);
> +       info->sram_virt   = __arm_ioremap(info->sram_phys, info->sram_size,
> +                                         MT_MEMORY);

I doubt MT_MEMORY is intended for use with __arm_ioremap(). There could
be other way around to the L_PTE_XN bit.

One other way I'm actually thinking of is to add the SRAM mapping to
mmp_map_io(). The difference of SRAM offset/size may result the
separation of mmp_map_io() into {pxa168,pxa910,mmp2}_map_io()
if necessary.

>        info->pool_name   = kstrdup(pdata->pool_name, GFP_KERNEL);
>        info->granularity = pdata->granularity;
>
> --
> 1.7.2.5
>
>

[PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Andres Salomon]

On Tue, 23 Aug 2011 08:07:41 +0800
Eric Miao <eric.y.miao@gmail.com> wrote:

> On Tue, Aug 23, 2011 at 7:47 AM, Andres Salomon <dilinger@queued.net>
> wrote:
> > The sram code allocates memory with ioremap, which assumes MT_DEVICE
> > for memory protections. ?This explodes when we map sram for power
> > management purposes and then attempt to execute it (jump_to_lp_sram)
> > on the OLPC XO-1.75. ?Instead, we want to specify MT_MEMORY, which
> > doesn't set the L_PTE_XN bit.
> >
> > Signed-off-by: Andres Salomon <dilinger@queued.net>
> > ---
> > ?arch/arm/mach-mmp/sram.c | ? ?4 +++-
> > ?1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > Eric, this patch is against the devel branch of your pxa tree.
> >
> > diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
> > index 4304f95..ca4d3c1 100644
> > --- a/arch/arm/mach-mmp/sram.c
> > +++ b/arch/arm/mach-mmp/sram.c
> > @@ -21,6 +21,7 @@
> > ?#include <linux/err.h>
> > ?#include <linux/slab.h>
> > ?#include <linux/genalloc.h>
> > +#include <asm/mach/map.h>
> >
> > ?#include <mach/sram.h>
> >
> > @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct
> > platform_device *pdev)
> >
> > ? ? ? ?info->sram_phys ? = (phys_addr_t)res->start;
> > ? ? ? ?info->sram_size ? = resource_size(res);
> > - ? ? ? info->sram_virt ? = ioremap(info->sram_phys,
> > info->sram_size);
> > + ? ? ? info->sram_virt ? = __arm_ioremap(info->sram_phys,
> > info->sram_size,
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? MT_MEMORY);
> 
> I doubt MT_MEMORY is intended for use with __arm_ioremap(). There
> could be other way around to the L_PTE_XN bit.
> 
> One other way I'm actually thinking of is to add the SRAM mapping to
> mmp_map_io(). The difference of SRAM offset/size may result the
> separation of mmp_map_io() into {pxa168,pxa910,mmp2}_map_io()
> if necessary.
> 

I guess I don't follow.  I think you're talking about adding it to the
standard_io_desc array, but that would require having it pre-mapped and
knowing the virtual address.  Or were you planning to ioremap it?

Re: [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Andres Salomon]

On Tue, 23 Aug 2011 08:07:41 +0800
Eric Miao <eric.y.miao@gmail.com> wrote:

> On Tue, Aug 23, 2011 at 7:47 AM, Andres Salomon <dilinger@queued.net>
> wrote:
> > The sram code allocates memory with ioremap, which assumes MT_DEVICE
> > for memory protections.  This explodes when we map sram for power
> > management purposes and then attempt to execute it (jump_to_lp_sram)
> > on the OLPC XO-1.75.  Instead, we want to specify MT_MEMORY, which
> > doesn't set the L_PTE_XN bit.
> >
> > Signed-off-by: Andres Salomon <dilinger@queued.net>
> > ---
> >  arch/arm/mach-mmp/sram.c |    4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > Eric, this patch is against the devel branch of your pxa tree.
> >
> > diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
> > index 4304f95..ca4d3c1 100644
> > --- a/arch/arm/mach-mmp/sram.c
> > +++ b/arch/arm/mach-mmp/sram.c
> > @@ -21,6 +21,7 @@
> >  #include <linux/err.h>
> >  #include <linux/slab.h>
> >  #include <linux/genalloc.h>
> > +#include <asm/mach/map.h>
> >
> >  #include <mach/sram.h>
> >
> > @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct
> > platform_device *pdev)
> >
> >        info->sram_phys   = (phys_addr_t)res->start;
> >        info->sram_size   = resource_size(res);
> > -       info->sram_virt   = ioremap(info->sram_phys,
> > info->sram_size);
> > +       info->sram_virt   = __arm_ioremap(info->sram_phys,
> > info->sram_size,
> > +                                         MT_MEMORY);
> 
> I doubt MT_MEMORY is intended for use with __arm_ioremap(). There
> could be other way around to the L_PTE_XN bit.
> 
> One other way I'm actually thinking of is to add the SRAM mapping to
> mmp_map_io(). The difference of SRAM offset/size may result the
> separation of mmp_map_io() into {pxa168,pxa910,mmp2}_map_io()
> if necessary.
> 

I guess I don't follow.  I think you're talking about adding it to the
standard_io_desc array, but that would require having it pre-mapped and
knowing the virtual address.  Or were you planning to ioremap it?

[PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Leo Yan]

On 08/23/2011 10:08 AM, Andres Salomon wrote:
> On Tue, 23 Aug 2011 08:07:41 +0800
> Eric Miao<eric.y.miao@gmail.com>  wrote:
>
>> On Tue, Aug 23, 2011 at 7:47 AM, Andres Salomon<dilinger@queued.net>
>> wrote:
>>> The sram code allocates memory with ioremap, which assumes MT_DEVICE
>>> for memory protections.  This explodes when we map sram for power
>>> management purposes and then attempt to execute it (jump_to_lp_sram)
>>> on the OLPC XO-1.75.  Instead, we want to specify MT_MEMORY, which
>>> doesn't set the L_PTE_XN bit.
>>>
>>> Signed-off-by: Andres Salomon<dilinger@queued.net>
>>> ---
>>>   arch/arm/mach-mmp/sram.c |    4 +++-
>>>   1 files changed, 3 insertions(+), 1 deletions(-)
>>>
>>> Eric, this patch is against the devel branch of your pxa tree.
>>>
>>> diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
>>> index 4304f95..ca4d3c1 100644
>>> --- a/arch/arm/mach-mmp/sram.c
>>> +++ b/arch/arm/mach-mmp/sram.c
>>> @@ -21,6 +21,7 @@
>>>   #include<linux/err.h>
>>>   #include<linux/slab.h>
>>>   #include<linux/genalloc.h>
>>> +#include<asm/mach/map.h>
>>>
>>>   #include<mach/sram.h>
>>>
>>> @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct
>>> platform_device *pdev)
>>>
>>>         info->sram_phys   = (phys_addr_t)res->start;
>>>         info->sram_size   = resource_size(res);
>>> -       info->sram_virt   = ioremap(info->sram_phys,
>>> info->sram_size);
>>> +       info->sram_virt   = __arm_ioremap(info->sram_phys,
>>> info->sram_size,
>>> +                                         MT_MEMORY);
>>
>> I doubt MT_MEMORY is intended for use with __arm_ioremap(). There
>> could be other way around to the L_PTE_XN bit.
>>
>> One other way I'm actually thinking of is to add the SRAM mapping to
>> mmp_map_io(). The difference of SRAM offset/size may result the
>> separation of mmp_map_io() into {pxa168,pxa910,mmp2}_map_io()
>> if necessary.
>>
>
> I guess I don't follow.  I think you're talking about adding it to the
> standard_io_desc array, but that would require having it pre-mapped and
> knowing the virtual address.  Or were you planning to ioremap it?

I missed the L_PTE_XN bit.
The patch is originally for audio sram, so use the ioremap is ok for 
that. But for the internal sram we should need the different mapping 
property.

so far, the standard_io_desc is shared by pxa168/pxa910/mmp2;
we can not add the sram's entry into it for now sram is only dedicated
to mmp2; just like Eric's suggestion, we need mmp2_map_io() only for
mmp2, and add the sram's entries into the structure.
if so, we need transfer the mapped info into the sram module,
and sram module just keep the info and do not need remap it again.

so what's your opinion?

Re: [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Leo Yan]

On 08/23/2011 10:08 AM, Andres Salomon wrote:
> On Tue, 23 Aug 2011 08:07:41 +0800
> Eric Miao<eric.y.miao@gmail.com>  wrote:
>
>> On Tue, Aug 23, 2011 at 7:47 AM, Andres Salomon<dilinger@queued.net>
>> wrote:
>>> The sram code allocates memory with ioremap, which assumes MT_DEVICE
>>> for memory protections.  This explodes when we map sram for power
>>> management purposes and then attempt to execute it (jump_to_lp_sram)
>>> on the OLPC XO-1.75.  Instead, we want to specify MT_MEMORY, which
>>> doesn't set the L_PTE_XN bit.
>>>
>>> Signed-off-by: Andres Salomon<dilinger@queued.net>
>>> ---
>>>   arch/arm/mach-mmp/sram.c |    4 +++-
>>>   1 files changed, 3 insertions(+), 1 deletions(-)
>>>
>>> Eric, this patch is against the devel branch of your pxa tree.
>>>
>>> diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
>>> index 4304f95..ca4d3c1 100644
>>> --- a/arch/arm/mach-mmp/sram.c
>>> +++ b/arch/arm/mach-mmp/sram.c
>>> @@ -21,6 +21,7 @@
>>>   #include<linux/err.h>
>>>   #include<linux/slab.h>
>>>   #include<linux/genalloc.h>
>>> +#include<asm/mach/map.h>
>>>
>>>   #include<mach/sram.h>
>>>
>>> @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct
>>> platform_device *pdev)
>>>
>>>         info->sram_phys   = (phys_addr_t)res->start;
>>>         info->sram_size   = resource_size(res);
>>> -       info->sram_virt   = ioremap(info->sram_phys,
>>> info->sram_size);
>>> +       info->sram_virt   = __arm_ioremap(info->sram_phys,
>>> info->sram_size,
>>> +                                         MT_MEMORY);
>>
>> I doubt MT_MEMORY is intended for use with __arm_ioremap(). There
>> could be other way around to the L_PTE_XN bit.
>>
>> One other way I'm actually thinking of is to add the SRAM mapping to
>> mmp_map_io(). The difference of SRAM offset/size may result the
>> separation of mmp_map_io() into {pxa168,pxa910,mmp2}_map_io()
>> if necessary.
>>
>
> I guess I don't follow.  I think you're talking about adding it to the
> standard_io_desc array, but that would require having it pre-mapped and
> knowing the virtual address.  Or were you planning to ioremap it?

I missed the L_PTE_XN bit.
The patch is originally for audio sram, so use the ioremap is ok for 
that. But for the internal sram we should need the different mapping 
property.

so far, the standard_io_desc is shared by pxa168/pxa910/mmp2;
we can not add the sram's entry into it for now sram is only dedicated
to mmp2; just like Eric's suggestion, we need mmp2_map_io() only for
mmp2, and add the sram's entries into the structure.
if so, we need transfer the mapped info into the sram module,
and sram module just keep the info and do not need remap it again.

so what's your opinion?

[PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Haojian Zhuang]

On Tue, 2011-08-23 at 00:48 -0700, Leo Yan wrote:
> 
> On 08/23/2011 10:08 AM, Andres Salomon wrote:
> > On Tue, 23 Aug 2011 08:07:41 +0800
> > Eric Miao<eric.y.miao@gmail.com>  wrote:
> >
> >> On Tue, Aug 23, 2011 at 7:47 AM, Andres Salomon<dilinger@queued.net>
> >> wrote:
> >>> The sram code allocates memory with ioremap, which assumes MT_DEVICE
> >>> for memory protections.  This explodes when we map sram for power
> >>> management purposes and then attempt to execute it (jump_to_lp_sram)
> >>> on the OLPC XO-1.75.  Instead, we want to specify MT_MEMORY, which
> >>> doesn't set the L_PTE_XN bit.
> >>>
> >>> Signed-off-by: Andres Salomon<dilinger@queued.net>
> >>> ---
> >>>   arch/arm/mach-mmp/sram.c |    4 +++-
> >>>   1 files changed, 3 insertions(+), 1 deletions(-)
> >>>
> >>> Eric, this patch is against the devel branch of your pxa tree.
> >>>
> >>> diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
> >>> index 4304f95..ca4d3c1 100644
> >>> --- a/arch/arm/mach-mmp/sram.c
> >>> +++ b/arch/arm/mach-mmp/sram.c
> >>> @@ -21,6 +21,7 @@
> >>>   #include<linux/err.h>
> >>>   #include<linux/slab.h>
> >>>   #include<linux/genalloc.h>
> >>> +#include<asm/mach/map.h>
> >>>
> >>>   #include<mach/sram.h>
> >>>
> >>> @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct
> >>> platform_device *pdev)
> >>>
> >>>         info->sram_phys   = (phys_addr_t)res->start;
> >>>         info->sram_size   = resource_size(res);
> >>> -       info->sram_virt   = ioremap(info->sram_phys,
> >>> info->sram_size);
> >>> +       info->sram_virt   = __arm_ioremap(info->sram_phys,
> >>> info->sram_size,
> >>> +                                         MT_MEMORY);
> >>
> >> I doubt MT_MEMORY is intended for use with __arm_ioremap(). There
> >> could be other way around to the L_PTE_XN bit.
> >>
> >> One other way I'm actually thinking of is to add the SRAM mapping to
> >> mmp_map_io(). The difference of SRAM offset/size may result the
> >> separation of mmp_map_io() into {pxa168,pxa910,mmp2}_map_io()
> >> if necessary.
> >>
> >
> > I guess I don't follow.  I think you're talking about adding it to the
> > standard_io_desc array, but that would require having it pre-mapped and
> > knowing the virtual address.  Or were you planning to ioremap it?
> 
> I missed the L_PTE_XN bit.
> The patch is originally for audio sram, so use the ioremap is ok for 
> that. But for the internal sram we should need the different mapping 
> property.
> 
> so far, the standard_io_desc is shared by pxa168/pxa910/mmp2;
> we can not add the sram's entry into it for now sram is only dedicated
> to mmp2; just like Eric's suggestion, we need mmp2_map_io() only for
> mmp2, and add the sram's entries into the structure.
> if so, we need transfer the mapped info into the sram module,
> and sram module just keep the info and do not need remap it again.
> 
> so what's your opinion?

Could we use resource or platform data to specify sram is used for
device or memory? If so, it may be helpful to customize.

Re: [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Haojian Zhuang]

On Tue, 2011-08-23 at 00:48 -0700, Leo Yan wrote:
> 
> On 08/23/2011 10:08 AM, Andres Salomon wrote:
> > On Tue, 23 Aug 2011 08:07:41 +0800
> > Eric Miao<eric.y.miao@gmail.com>  wrote:
> >
> >> On Tue, Aug 23, 2011 at 7:47 AM, Andres Salomon<dilinger@queued.net>
> >> wrote:
> >>> The sram code allocates memory with ioremap, which assumes MT_DEVICE
> >>> for memory protections.  This explodes when we map sram for power
> >>> management purposes and then attempt to execute it (jump_to_lp_sram)
> >>> on the OLPC XO-1.75.  Instead, we want to specify MT_MEMORY, which
> >>> doesn't set the L_PTE_XN bit.
> >>>
> >>> Signed-off-by: Andres Salomon<dilinger@queued.net>
> >>> ---
> >>>   arch/arm/mach-mmp/sram.c |    4 +++-
> >>>   1 files changed, 3 insertions(+), 1 deletions(-)
> >>>
> >>> Eric, this patch is against the devel branch of your pxa tree.
> >>>
> >>> diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
> >>> index 4304f95..ca4d3c1 100644
> >>> --- a/arch/arm/mach-mmp/sram.c
> >>> +++ b/arch/arm/mach-mmp/sram.c
> >>> @@ -21,6 +21,7 @@
> >>>   #include<linux/err.h>
> >>>   #include<linux/slab.h>
> >>>   #include<linux/genalloc.h>
> >>> +#include<asm/mach/map.h>
> >>>
> >>>   #include<mach/sram.h>
> >>>
> >>> @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct
> >>> platform_device *pdev)
> >>>
> >>>         info->sram_phys   = (phys_addr_t)res->start;
> >>>         info->sram_size   = resource_size(res);
> >>> -       info->sram_virt   = ioremap(info->sram_phys,
> >>> info->sram_size);
> >>> +       info->sram_virt   = __arm_ioremap(info->sram_phys,
> >>> info->sram_size,
> >>> +                                         MT_MEMORY);
> >>
> >> I doubt MT_MEMORY is intended for use with __arm_ioremap(). There
> >> could be other way around to the L_PTE_XN bit.
> >>
> >> One other way I'm actually thinking of is to add the SRAM mapping to
> >> mmp_map_io(). The difference of SRAM offset/size may result the
> >> separation of mmp_map_io() into {pxa168,pxa910,mmp2}_map_io()
> >> if necessary.
> >>
> >
> > I guess I don't follow.  I think you're talking about adding it to the
> > standard_io_desc array, but that would require having it pre-mapped and
> > knowing the virtual address.  Or were you planning to ioremap it?
> 
> I missed the L_PTE_XN bit.
> The patch is originally for audio sram, so use the ioremap is ok for 
> that. But for the internal sram we should need the different mapping 
> property.
> 
> so far, the standard_io_desc is shared by pxa168/pxa910/mmp2;
> we can not add the sram's entry into it for now sram is only dedicated
> to mmp2; just like Eric's suggestion, we need mmp2_map_io() only for
> mmp2, and add the sram's entries into the structure.
> if so, we need transfer the mapped info into the sram module,
> and sram module just keep the info and do not need remap it again.
> 
> so what's your opinion?

Could we use resource or platform data to specify sram is used for
device or memory? If so, it may be helpful to customize.

[PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Russell King - ARM Linux]

On Mon, Aug 22, 2011 at 04:47:40PM -0700, Andres Salomon wrote:
> The sram code allocates memory with ioremap, which assumes MT_DEVICE
> for memory protections.  This explodes when we map sram for power
> management purposes and then attempt to execute it (jump_to_lp_sram)
> on the OLPC XO-1.75.  Instead, we want to specify MT_MEMORY, which
> doesn't set the L_PTE_XN bit.
> 
> Signed-off-by: Andres Salomon <dilinger@queued.net>
> ---
>  arch/arm/mach-mmp/sram.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> Eric, this patch is against the devel branch of your pxa tree.
> 
> diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
> index 4304f95..ca4d3c1 100644
> --- a/arch/arm/mach-mmp/sram.c
> +++ b/arch/arm/mach-mmp/sram.c
> @@ -21,6 +21,7 @@
>  #include <linux/err.h>
>  #include <linux/slab.h>
>  #include <linux/genalloc.h>
> +#include <asm/mach/map.h>
>  
>  #include <mach/sram.h>
>  
> @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct platform_device *pdev)
>  
>  	info->sram_phys   = (phys_addr_t)res->start;
>  	info->sram_size   = resource_size(res);
> -	info->sram_virt   = ioremap(info->sram_phys, info->sram_size);
> +	info->sram_virt   = __arm_ioremap(info->sram_phys, info->sram_size,
> +					  MT_MEMORY);

Not a good idea fiddling about under the covers like that.  The reason
that MT_MEMORY is not in asm/io.h is to stop it being used like this -
MT_MEMORY etc are not meant for general purpose use.

It needs to be looked at properly rather than working behind the APIs,
and making my life a misery by doing so, preventing me from making
changes where necessary by this kind of back-door use.

I guess we need a new ioremap_xxx() variant to cope with this.

Re: [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Russell King - ARM Linux]

On Mon, Aug 22, 2011 at 04:47:40PM -0700, Andres Salomon wrote:
> The sram code allocates memory with ioremap, which assumes MT_DEVICE
> for memory protections.  This explodes when we map sram for power
> management purposes and then attempt to execute it (jump_to_lp_sram)
> on the OLPC XO-1.75.  Instead, we want to specify MT_MEMORY, which
> doesn't set the L_PTE_XN bit.
> 
> Signed-off-by: Andres Salomon <dilinger@queued.net>
> ---
>  arch/arm/mach-mmp/sram.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> Eric, this patch is against the devel branch of your pxa tree.
> 
> diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
> index 4304f95..ca4d3c1 100644
> --- a/arch/arm/mach-mmp/sram.c
> +++ b/arch/arm/mach-mmp/sram.c
> @@ -21,6 +21,7 @@
>  #include <linux/err.h>
>  #include <linux/slab.h>
>  #include <linux/genalloc.h>
> +#include <asm/mach/map.h>
>  
>  #include <mach/sram.h>
>  
> @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct platform_device *pdev)
>  
>  	info->sram_phys   = (phys_addr_t)res->start;
>  	info->sram_size   = resource_size(res);
> -	info->sram_virt   = ioremap(info->sram_phys, info->sram_size);
> +	info->sram_virt   = __arm_ioremap(info->sram_phys, info->sram_size,
> +					  MT_MEMORY);

Not a good idea fiddling about under the covers like that.  The reason
that MT_MEMORY is not in asm/io.h is to stop it being used like this -
MT_MEMORY etc are not meant for general purpose use.

It needs to be looked at properly rather than working behind the APIs,
and making my life a misery by doing so, preventing me from making
changes where necessary by this kind of back-door use.

I guess we need a new ioremap_xxx() variant to cope with this.

[PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Andres Salomon]

On Tue, 23 Aug 2011 01:07:55 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
[...]
> > @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct
> > platform_device *pdev) 
> >  	info->sram_phys   = (phys_addr_t)res->start;
> >  	info->sram_size   = resource_size(res);
> > -	info->sram_virt   = ioremap(info->sram_phys,
> > info->sram_size);
> > +	info->sram_virt   = __arm_ioremap(info->sram_phys,
> > info->sram_size,
> > +					  MT_MEMORY);
> 
> Not a good idea fiddling about under the covers like that.  The reason
> that MT_MEMORY is not in asm/io.h is to stop it being used like this -
> MT_MEMORY etc are not meant for general purpose use.
> 
> It needs to be looked at properly rather than working behind the APIs,
> and making my life a misery by doing so, preventing me from making
> changes where necessary by this kind of back-door use.
> 
> I guess we need a new ioremap_xxx() variant to cope with this.

Something like ioremap_exec()?  I have no idea what the related MT_
entry would be (as someone who's new to the ARM world, it's not
entirely clear what the semantic distinctions are between the various
MT_ entries).

Re: [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Andres Salomon]

On Tue, 23 Aug 2011 01:07:55 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
[...]
> > @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct
> > platform_device *pdev) 
> >  	info->sram_phys   = (phys_addr_t)res->start;
> >  	info->sram_size   = resource_size(res);
> > -	info->sram_virt   = ioremap(info->sram_phys,
> > info->sram_size);
> > +	info->sram_virt   = __arm_ioremap(info->sram_phys,
> > info->sram_size,
> > +					  MT_MEMORY);
> 
> Not a good idea fiddling about under the covers like that.  The reason
> that MT_MEMORY is not in asm/io.h is to stop it being used like this -
> MT_MEMORY etc are not meant for general purpose use.
> 
> It needs to be looked at properly rather than working behind the APIs,
> and making my life a misery by doing so, preventing me from making
> changes where necessary by this kind of back-door use.
> 
> I guess we need a new ioremap_xxx() variant to cope with this.

Something like ioremap_exec()?  I have no idea what the related MT_
entry would be (as someone who's new to the ARM world, it's not
entirely clear what the semantic distinctions are between the various
MT_ entries).

[PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Tony Lindgren]

* Andres Salomon <dilinger@queued.net> [110822 18:40]:
> On Tue, 23 Aug 2011 01:07:55 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> [...]
> > > @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct
> > > platform_device *pdev) 
> > >  	info->sram_phys   = (phys_addr_t)res->start;
> > >  	info->sram_size   = resource_size(res);
> > > -	info->sram_virt   = ioremap(info->sram_phys,
> > > info->sram_size);
> > > +	info->sram_virt   = __arm_ioremap(info->sram_phys,
> > > info->sram_size,
> > > +					  MT_MEMORY);
> > 
> > Not a good idea fiddling about under the covers like that.  The reason
> > that MT_MEMORY is not in asm/io.h is to stop it being used like this -
> > MT_MEMORY etc are not meant for general purpose use.
> > 
> > It needs to be looked at properly rather than working behind the APIs,
> > and making my life a misery by doing so, preventing me from making
> > changes where necessary by this kind of back-door use.
> > 
> > I guess we need a new ioremap_xxx() variant to cope with this.
> 
> Something like ioremap_exec()?  I have no idea what the related MT_
> entry would be (as someone who's new to the ARM world, it's not
> entirely clear what the semantic distinctions are between the various
> MT_ entries).

Andres, care to ack this patch:

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7126/1

Looks like that should do what you want. And after the related
SRAM/map_io fixes for omap, it really seems that we could have
a generic SRAM driver..

Regards,

Tony

Re: [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE

[Tony Lindgren]

* Andres Salomon <dilinger@queued.net> [110822 18:40]:
> On Tue, 23 Aug 2011 01:07:55 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> [...]
> > > @@ -87,7 +88,8 @@ static int __devinit sram_probe(struct
> > > platform_device *pdev) 
> > >  	info->sram_phys   = (phys_addr_t)res->start;
> > >  	info->sram_size   = resource_size(res);
> > > -	info->sram_virt   = ioremap(info->sram_phys,
> > > info->sram_size);
> > > +	info->sram_virt   = __arm_ioremap(info->sram_phys,
> > > info->sram_size,
> > > +					  MT_MEMORY);
> > 
> > Not a good idea fiddling about under the covers like that.  The reason
> > that MT_MEMORY is not in asm/io.h is to stop it being used like this -
> > MT_MEMORY etc are not meant for general purpose use.
> > 
> > It needs to be looked at properly rather than working behind the APIs,
> > and making my life a misery by doing so, preventing me from making
> > changes where necessary by this kind of back-door use.
> > 
> > I guess we need a new ioremap_xxx() variant to cope with this.
> 
> Something like ioremap_exec()?  I have no idea what the related MT_
> entry would be (as someone who's new to the ARM world, it's not
> entirely clear what the semantic distinctions are between the various
> MT_ entries).

Andres, care to ack this patch:

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7126/1

Looks like that should do what you want. And after the related
SRAM/map_io fixes for omap, it really seems that we could have
a generic SRAM driver..

Regards,

Tony

[PATCH 2/3] ARM: mmp: register audio sram bank

[Leo Yan]

MMP platform has sram for the audio island;
Add the device structure for the audio sram,
and register the audio sram device at init phase.

Signed-off-by: Leo Yan <leoy@marvell.com>
---
 arch/arm/mach-mmp/brownstone.c        |    5 +++++
 arch/arm/mach-mmp/include/mach/mmp2.h |    7 +++++++
 arch/arm/mach-mmp/mmp2.c              |    1 +
 3 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index c79162a..db4b5fd 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -186,6 +186,10 @@ static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc2 = {
 		| PXA_FLAG_SD_8_BIT_CAPABLE_SLOT,
 };
 
+static struct sram_platdata mmp2_asram_platdata = {
+	.pool_name	= "asram",
+	.granularity	= SRAM_GRANULARITY,
+};
 
 static void __init brownstone_init(void)
 {
@@ -197,6 +201,7 @@ static void __init brownstone_init(void)
 	mmp2_add_twsi(1, NULL, ARRAY_AND_SIZE(brownstone_twsi1_info));
 	mmp2_add_sdhost(0, &mmp2_sdh_platdata_mmc0); /* SD/MMC */
 	mmp2_add_sdhost(2, &mmp2_sdh_platdata_mmc2); /* eMMC */
+	mmp2_add_asram(&mmp2_asram_platdata);
 
 	/* enable 5v regulator */
 	platform_device_register(&brownstone_v_5vp_device);
diff --git a/arch/arm/mach-mmp/include/mach/mmp2.h b/arch/arm/mach-mmp/include/mach/mmp2.h
index de7b888..c227328 100644
--- a/arch/arm/mach-mmp/include/mach/mmp2.h
+++ b/arch/arm/mach-mmp/include/mach/mmp2.h
@@ -13,6 +13,7 @@ extern void mmp2_clear_pmic_int(void);
 #include <linux/i2c.h>
 #include <linux/i2c/pxa-i2c.h>
 #include <mach/devices.h>
+#include <mach/sram.h>
 
 extern struct pxa_device_desc mmp2_device_uart1;
 extern struct pxa_device_desc mmp2_device_uart2;
@@ -28,6 +29,7 @@ extern struct pxa_device_desc mmp2_device_sdh0;
 extern struct pxa_device_desc mmp2_device_sdh1;
 extern struct pxa_device_desc mmp2_device_sdh2;
 extern struct pxa_device_desc mmp2_device_sdh3;
+extern struct pxa_device_desc mmp2_device_asram;
 
 static inline int mmp2_add_uart(int id)
 {
@@ -85,5 +87,10 @@ static inline int mmp2_add_sdhost(int id, struct sdhci_pxa_platdata *data)
 	return pxa_register_device(d, data, sizeof(*data));
 }
 
+static inline int mmp2_add_asram(struct sram_platdata *data)
+{
+	return pxa_register_device(&mmp2_device_asram, data, sizeof(*data));
+}
+
 #endif /* __ASM_MACH_MMP2_H */
 
diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index 079c188..9d00754 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -226,4 +226,5 @@ MMP2_DEVICE(sdh0, "sdhci-pxav3", 0, MMC, 0xd4280000, 0x120);
 MMP2_DEVICE(sdh1, "sdhci-pxav3", 1, MMC2, 0xd4280800, 0x120);
 MMP2_DEVICE(sdh2, "sdhci-pxav3", 2, MMC3, 0xd4281000, 0x120);
 MMP2_DEVICE(sdh3, "sdhci-pxav3", 3, MMC4, 0xd4281800, 0x120);
+MMP2_DEVICE(asram, "asram", -1, NONE, 0xe0000000, 0x4000);
 
-- 
1.7.4.1

[PATCH 2/3] ARM: mmp: register audio sram bank

[Leo Yan]

MMP platform has sram for the audio island;
Add the device structure for the audio sram,
and register the audio sram device at init phase.

Signed-off-by: Leo Yan <leoy@marvell.com>
---
 arch/arm/mach-mmp/brownstone.c        |    5 +++++
 arch/arm/mach-mmp/include/mach/mmp2.h |    7 +++++++
 arch/arm/mach-mmp/mmp2.c              |    1 +
 3 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index c79162a..db4b5fd 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -186,6 +186,10 @@ static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc2 = {
 		| PXA_FLAG_SD_8_BIT_CAPABLE_SLOT,
 };
 
+static struct sram_platdata mmp2_asram_platdata = {
+	.pool_name	= "asram",
+	.granularity	= SRAM_GRANULARITY,
+};
 
 static void __init brownstone_init(void)
 {
@@ -197,6 +201,7 @@ static void __init brownstone_init(void)
 	mmp2_add_twsi(1, NULL, ARRAY_AND_SIZE(brownstone_twsi1_info));
 	mmp2_add_sdhost(0, &mmp2_sdh_platdata_mmc0); /* SD/MMC */
 	mmp2_add_sdhost(2, &mmp2_sdh_platdata_mmc2); /* eMMC */
+	mmp2_add_asram(&mmp2_asram_platdata);
 
 	/* enable 5v regulator */
 	platform_device_register(&brownstone_v_5vp_device);
diff --git a/arch/arm/mach-mmp/include/mach/mmp2.h b/arch/arm/mach-mmp/include/mach/mmp2.h
index de7b888..c227328 100644
--- a/arch/arm/mach-mmp/include/mach/mmp2.h
+++ b/arch/arm/mach-mmp/include/mach/mmp2.h
@@ -13,6 +13,7 @@ extern void mmp2_clear_pmic_int(void);
 #include <linux/i2c.h>
 #include <linux/i2c/pxa-i2c.h>
 #include <mach/devices.h>
+#include <mach/sram.h>
 
 extern struct pxa_device_desc mmp2_device_uart1;
 extern struct pxa_device_desc mmp2_device_uart2;
@@ -28,6 +29,7 @@ extern struct pxa_device_desc mmp2_device_sdh0;
 extern struct pxa_device_desc mmp2_device_sdh1;
 extern struct pxa_device_desc mmp2_device_sdh2;
 extern struct pxa_device_desc mmp2_device_sdh3;
+extern struct pxa_device_desc mmp2_device_asram;
 
 static inline int mmp2_add_uart(int id)
 {
@@ -85,5 +87,10 @@ static inline int mmp2_add_sdhost(int id, struct sdhci_pxa_platdata *data)
 	return pxa_register_device(d, data, sizeof(*data));
 }
 
+static inline int mmp2_add_asram(struct sram_platdata *data)
+{
+	return pxa_register_device(&mmp2_device_asram, data, sizeof(*data));
+}
+
 #endif /* __ASM_MACH_MMP2_H */
 
diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index 079c188..9d00754 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -226,4 +226,5 @@ MMP2_DEVICE(sdh0, "sdhci-pxav3", 0, MMC, 0xd4280000, 0x120);
 MMP2_DEVICE(sdh1, "sdhci-pxav3", 1, MMC2, 0xd4280800, 0x120);
 MMP2_DEVICE(sdh2, "sdhci-pxav3", 2, MMC3, 0xd4281000, 0x120);
 MMP2_DEVICE(sdh3, "sdhci-pxav3", 3, MMC4, 0xd4281800, 0x120);
+MMP2_DEVICE(asram, "asram", -1, NONE, 0xe0000000, 0x4000);
 
-- 
1.7.4.1

[PATCH 3/3] ARM: mmp: register internal sram bank

[Leo Yan]

MMP2 have the internal sram, this sram can be allocated
for video, power management and secure processor.

Now the sram usage is:
0xd1000000 ~ 0xd101ffff (128KB) : reserved for secure processor
0xd1020000 ~ 0xd1037fff (96KB)  : for video and PM

Register the internal sram's second half 96KB buffer,
so that video and PM can dynamically alloc/free from it.

Signed-off-by: Leo Yan <leoy@marvell.com>
---
 arch/arm/mach-mmp/brownstone.c        |    6 ++++++
 arch/arm/mach-mmp/include/mach/mmp2.h |    6 ++++++
 arch/arm/mach-mmp/mmp2.c              |    2 ++
 3 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index db4b5fd..59dcf9d 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -191,6 +191,11 @@ static struct sram_platdata mmp2_asram_platdata = {
 	.granularity	= SRAM_GRANULARITY,
 };
 
+static struct sram_platdata mmp2_isram_platdata = {
+	.pool_name	= "isram",
+	.granularity	= SRAM_GRANULARITY,
+};
+
 static void __init brownstone_init(void)
 {
 	mfp_config(ARRAY_AND_SIZE(brownstone_pin_config));
@@ -202,6 +207,7 @@ static void __init brownstone_init(void)
 	mmp2_add_sdhost(0, &mmp2_sdh_platdata_mmc0); /* SD/MMC */
 	mmp2_add_sdhost(2, &mmp2_sdh_platdata_mmc2); /* eMMC */
 	mmp2_add_asram(&mmp2_asram_platdata);
+	mmp2_add_isram(&mmp2_isram_platdata);
 
 	/* enable 5v regulator */
 	platform_device_register(&brownstone_v_5vp_device);
diff --git a/arch/arm/mach-mmp/include/mach/mmp2.h b/arch/arm/mach-mmp/include/mach/mmp2.h
index c227328..2f7b2d3 100644
--- a/arch/arm/mach-mmp/include/mach/mmp2.h
+++ b/arch/arm/mach-mmp/include/mach/mmp2.h
@@ -30,6 +30,7 @@ extern struct pxa_device_desc mmp2_device_sdh1;
 extern struct pxa_device_desc mmp2_device_sdh2;
 extern struct pxa_device_desc mmp2_device_sdh3;
 extern struct pxa_device_desc mmp2_device_asram;
+extern struct pxa_device_desc mmp2_device_isram;
 
 static inline int mmp2_add_uart(int id)
 {
@@ -92,5 +93,10 @@ static inline int mmp2_add_asram(struct sram_platdata *data)
 	return pxa_register_device(&mmp2_device_asram, data, sizeof(*data));
 }
 
+static inline int mmp2_add_isram(struct sram_platdata *data)
+{
+	return pxa_register_device(&mmp2_device_isram, data, sizeof(*data));
+}
+
 #endif /* __ASM_MACH_MMP2_H */
 
diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index 9d00754..43266c4 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -227,4 +227,6 @@ MMP2_DEVICE(sdh1, "sdhci-pxav3", 1, MMC2, 0xd4280800, 0x120);
 MMP2_DEVICE(sdh2, "sdhci-pxav3", 2, MMC3, 0xd4281000, 0x120);
 MMP2_DEVICE(sdh3, "sdhci-pxav3", 3, MMC4, 0xd4281800, 0x120);
 MMP2_DEVICE(asram, "asram", -1, NONE, 0xe0000000, 0x4000);
+/* 0xd1000000 ~ 0xd101ffff is reserved for secure processor */
+MMP2_DEVICE(isram, "isram", -1, NONE, 0xd1020000, 0x18000);
 
-- 
1.7.4.1

[PATCH 3/3] ARM: mmp: register internal sram bank

[Leo Yan]

MMP2 have the internal sram, this sram can be allocated
for video, power management and secure processor.

Now the sram usage is:
0xd1000000 ~ 0xd101ffff (128KB) : reserved for secure processor
0xd1020000 ~ 0xd1037fff (96KB)  : for video and PM

Register the internal sram's second half 96KB buffer,
so that video and PM can dynamically alloc/free from it.

Signed-off-by: Leo Yan <leoy@marvell.com>
---
 arch/arm/mach-mmp/brownstone.c        |    6 ++++++
 arch/arm/mach-mmp/include/mach/mmp2.h |    6 ++++++
 arch/arm/mach-mmp/mmp2.c              |    2 ++
 3 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index db4b5fd..59dcf9d 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -191,6 +191,11 @@ static struct sram_platdata mmp2_asram_platdata = {
 	.granularity	= SRAM_GRANULARITY,
 };
 
+static struct sram_platdata mmp2_isram_platdata = {
+	.pool_name	= "isram",
+	.granularity	= SRAM_GRANULARITY,
+};
+
 static void __init brownstone_init(void)
 {
 	mfp_config(ARRAY_AND_SIZE(brownstone_pin_config));
@@ -202,6 +207,7 @@ static void __init brownstone_init(void)
 	mmp2_add_sdhost(0, &mmp2_sdh_platdata_mmc0); /* SD/MMC */
 	mmp2_add_sdhost(2, &mmp2_sdh_platdata_mmc2); /* eMMC */
 	mmp2_add_asram(&mmp2_asram_platdata);
+	mmp2_add_isram(&mmp2_isram_platdata);
 
 	/* enable 5v regulator */
 	platform_device_register(&brownstone_v_5vp_device);
diff --git a/arch/arm/mach-mmp/include/mach/mmp2.h b/arch/arm/mach-mmp/include/mach/mmp2.h
index c227328..2f7b2d3 100644
--- a/arch/arm/mach-mmp/include/mach/mmp2.h
+++ b/arch/arm/mach-mmp/include/mach/mmp2.h
@@ -30,6 +30,7 @@ extern struct pxa_device_desc mmp2_device_sdh1;
 extern struct pxa_device_desc mmp2_device_sdh2;
 extern struct pxa_device_desc mmp2_device_sdh3;
 extern struct pxa_device_desc mmp2_device_asram;
+extern struct pxa_device_desc mmp2_device_isram;
 
 static inline int mmp2_add_uart(int id)
 {
@@ -92,5 +93,10 @@ static inline int mmp2_add_asram(struct sram_platdata *data)
 	return pxa_register_device(&mmp2_device_asram, data, sizeof(*data));
 }
 
+static inline int mmp2_add_isram(struct sram_platdata *data)
+{
+	return pxa_register_device(&mmp2_device_isram, data, sizeof(*data));
+}
+
 #endif /* __ASM_MACH_MMP2_H */
 
diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index 9d00754..43266c4 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -227,4 +227,6 @@ MMP2_DEVICE(sdh1, "sdhci-pxav3", 1, MMC2, 0xd4280800, 0x120);
 MMP2_DEVICE(sdh2, "sdhci-pxav3", 2, MMC3, 0xd4281000, 0x120);
 MMP2_DEVICE(sdh3, "sdhci-pxav3", 3, MMC4, 0xd4281800, 0x120);
 MMP2_DEVICE(asram, "asram", -1, NONE, 0xe0000000, 0x4000);
+/* 0xd1000000 ~ 0xd101ffff is reserved for secure processor */
+MMP2_DEVICE(isram, "isram", -1, NONE, 0xd1020000, 0x18000);
 
-- 
1.7.4.1

[PATCH V4 0/3] ARM: mmp: add audio sram support

[Haojian Zhuang]

On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
> On mmp platform, there have two sram banks:
> audio sram bank, and internal sram bank for video and PM.
> So add the sram module to manage these sram banks.
> 
> And register the sram banks so can dynamically alloc/free
> the buffer.
> 
> Leo Yan (3):
>   ARM: mmp: add sram allocator
>   ARM: mmp: register audio sram bank
>   ARM: mmp: register internal sram bank
> 
>  arch/arm/Kconfig                      |    1 +
>  arch/arm/mach-mmp/Makefile            |    2 +-
>  arch/arm/mach-mmp/brownstone.c        |   11 ++
>  arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>  arch/arm/mach-mmp/mmp2.c              |    3 +
>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>  7 files changed, 232 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>  create mode 100644 arch/arm/mach-mmp/sram.c
> 
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>

Re: [PATCH V4 0/3] ARM: mmp: add audio sram support

[Haojian Zhuang]

On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
> On mmp platform, there have two sram banks:
> audio sram bank, and internal sram bank for video and PM.
> So add the sram module to manage these sram banks.
> 
> And register the sram banks so can dynamically alloc/free
> the buffer.
> 
> Leo Yan (3):
>   ARM: mmp: add sram allocator
>   ARM: mmp: register audio sram bank
>   ARM: mmp: register internal sram bank
> 
>  arch/arm/Kconfig                      |    1 +
>  arch/arm/mach-mmp/Makefile            |    2 +-
>  arch/arm/mach-mmp/brownstone.c        |   11 ++
>  arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>  arch/arm/mach-mmp/mmp2.c              |    3 +
>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>  7 files changed, 232 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>  create mode 100644 arch/arm/mach-mmp/sram.c
> 
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>

[PATCH V4 0/3] ARM: mmp: add audio sram support

[Eric Miao]

On Mon, Aug 15, 2011 at 11:11 AM, Haojian Zhuang
<haojian.zhuang@marvell.com> wrote:
> On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
>> On mmp platform, there have two sram banks:
>> audio sram bank, and internal sram bank for video and PM.
>> So add the sram module to manage these sram banks.
>>
>> And register the sram banks so can dynamically alloc/free
>> the buffer.
>>
>> Leo Yan (3):
>> ? ARM: mmp: add sram allocator
>> ? ARM: mmp: register audio sram bank
>> ? ARM: mmp: register internal sram bank
>>
>> ?arch/arm/Kconfig ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
>> ?arch/arm/mach-mmp/Makefile ? ? ? ? ? ?| ? ?2 +-
>> ?arch/arm/mach-mmp/brownstone.c ? ? ? ?| ? 11 ++
>> ?arch/arm/mach-mmp/include/mach/mmp2.h | ? 13 +++
>> ?arch/arm/mach-mmp/include/mach/sram.h | ? 35 +++++++
>> ?arch/arm/mach-mmp/mmp2.c ? ? ? ? ? ? ?| ? ?3 +
>> ?arch/arm/mach-mmp/sram.c ? ? ? ? ? ? ?| ?168 +++++++++++++++++++++++++++++++++
>> ?7 files changed, 232 insertions(+), 1 deletions(-)
>> ?create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>> ?create mode 100644 arch/arm/mach-mmp/sram.c
>>
> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>

Looks good to me. Thanks Haojian. Applied to -devel.

Re: [PATCH V4 0/3] ARM: mmp: add audio sram support

[Eric Miao]

On Mon, Aug 15, 2011 at 11:11 AM, Haojian Zhuang
<haojian.zhuang@marvell.com> wrote:
> On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
>> On mmp platform, there have two sram banks:
>> audio sram bank, and internal sram bank for video and PM.
>> So add the sram module to manage these sram banks.
>>
>> And register the sram banks so can dynamically alloc/free
>> the buffer.
>>
>> Leo Yan (3):
>>   ARM: mmp: add sram allocator
>>   ARM: mmp: register audio sram bank
>>   ARM: mmp: register internal sram bank
>>
>>  arch/arm/Kconfig                      |    1 +
>>  arch/arm/mach-mmp/Makefile            |    2 +-
>>  arch/arm/mach-mmp/brownstone.c        |   11 ++
>>  arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
>>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>>  arch/arm/mach-mmp/mmp2.c              |    3 +
>>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>>  7 files changed, 232 insertions(+), 1 deletions(-)
>>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>>  create mode 100644 arch/arm/mach-mmp/sram.c
>>
> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>

Looks good to me. Thanks Haojian. Applied to -devel.

[PATCH V4 0/3] ARM: mmp: add audio sram support

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:43 Mon 15 Aug     , Eric Miao wrote:
> On Mon, Aug 15, 2011 at 11:11 AM, Haojian Zhuang
> <haojian.zhuang@marvell.com> wrote:
> > On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
> >> On mmp platform, there have two sram banks:
> >> audio sram bank, and internal sram bank for video and PM.
> >> So add the sram module to manage these sram banks.
> >>
> >> And register the sram banks so can dynamically alloc/free
> >> the buffer.
> >>
> >> Leo Yan (3):
> >> ? ARM: mmp: add sram allocator
> >> ? ARM: mmp: register audio sram bank
> >> ? ARM: mmp: register internal sram bank
> >>
> >> ?arch/arm/Kconfig ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> >> ?arch/arm/mach-mmp/Makefile ? ? ? ? ? ?| ? ?2 +-
> >> ?arch/arm/mach-mmp/brownstone.c ? ? ? ?| ? 11 ++
> >> ?arch/arm/mach-mmp/include/mach/mmp2.h | ? 13 +++
> >> ?arch/arm/mach-mmp/include/mach/sram.h | ? 35 +++++++
> >> ?arch/arm/mach-mmp/mmp2.c ? ? ? ? ? ? ?| ? ?3 +
> >> ?arch/arm/mach-mmp/sram.c ? ? ? ? ? ? ?| ?168 +++++++++++++++++++++++++++++++++
> >> ?7 files changed, 232 insertions(+), 1 deletions(-)
> >> ?create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
> >> ?create mode 100644 arch/arm/mach-mmp/sram.c
> >>
> > Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
> 
> Looks good to me. Thanks Haojian. Applied to -devel.
I've some reserve on the named pool they need to be managed at generic level
not here

Best Regards,
J.

Re: [PATCH V4 0/3] ARM: mmp: add audio sram support

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:43 Mon 15 Aug     , Eric Miao wrote:
> On Mon, Aug 15, 2011 at 11:11 AM, Haojian Zhuang
> <haojian.zhuang@marvell.com> wrote:
> > On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
> >> On mmp platform, there have two sram banks:
> >> audio sram bank, and internal sram bank for video and PM.
> >> So add the sram module to manage these sram banks.
> >>
> >> And register the sram banks so can dynamically alloc/free
> >> the buffer.
> >>
> >> Leo Yan (3):
> >>   ARM: mmp: add sram allocator
> >>   ARM: mmp: register audio sram bank
> >>   ARM: mmp: register internal sram bank
> >>
> >>  arch/arm/Kconfig                      |    1 +
> >>  arch/arm/mach-mmp/Makefile            |    2 +-
> >>  arch/arm/mach-mmp/brownstone.c        |   11 ++
> >>  arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
> >>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
> >>  arch/arm/mach-mmp/mmp2.c              |    3 +
> >>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
> >>  7 files changed, 232 insertions(+), 1 deletions(-)
> >>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
> >>  create mode 100644 arch/arm/mach-mmp/sram.c
> >>
> > Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
> 
> Looks good to me. Thanks Haojian. Applied to -devel.
I've some reserve on the named pool they need to be managed at generic level
not here

Best Regards,
J.

[PATCH V4 0/3] ARM: mmp: add audio sram support

[Eric Miao]

On Mon, Aug 15, 2011 at 5:12 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 16:43 Mon 15 Aug ? ? , Eric Miao wrote:
>> On Mon, Aug 15, 2011 at 11:11 AM, Haojian Zhuang
>> <haojian.zhuang@marvell.com> wrote:
>> > On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
>> >> On mmp platform, there have two sram banks:
>> >> audio sram bank, and internal sram bank for video and PM.
>> >> So add the sram module to manage these sram banks.
>> >>
>> >> And register the sram banks so can dynamically alloc/free
>> >> the buffer.
>> >>
>> >> Leo Yan (3):
>> >> ? ARM: mmp: add sram allocator
>> >> ? ARM: mmp: register audio sram bank
>> >> ? ARM: mmp: register internal sram bank
>> >>
>> >> ?arch/arm/Kconfig ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
>> >> ?arch/arm/mach-mmp/Makefile ? ? ? ? ? ?| ? ?2 +-
>> >> ?arch/arm/mach-mmp/brownstone.c ? ? ? ?| ? 11 ++
>> >> ?arch/arm/mach-mmp/include/mach/mmp2.h | ? 13 +++
>> >> ?arch/arm/mach-mmp/include/mach/sram.h | ? 35 +++++++
>> >> ?arch/arm/mach-mmp/mmp2.c ? ? ? ? ? ? ?| ? ?3 +
>> >> ?arch/arm/mach-mmp/sram.c ? ? ? ? ? ? ?| ?168 +++++++++++++++++++++++++++++++++
>> >> ?7 files changed, 232 insertions(+), 1 deletions(-)
>> >> ?create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>> >> ?create mode 100644 arch/arm/mach-mmp/sram.c
>> >>
>> > Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
>>
>> Looks good to me. Thanks Haojian. Applied to -devel.
> I've some reserve on the named pool they need to be managed at generic level
> not here

What are their names? And your suggestions to fix this?

>
> Best Regards,
> J.
>

Re: [PATCH V4 0/3] ARM: mmp: add audio sram support

[Eric Miao]

On Mon, Aug 15, 2011 at 5:12 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 16:43 Mon 15 Aug     , Eric Miao wrote:
>> On Mon, Aug 15, 2011 at 11:11 AM, Haojian Zhuang
>> <haojian.zhuang@marvell.com> wrote:
>> > On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
>> >> On mmp platform, there have two sram banks:
>> >> audio sram bank, and internal sram bank for video and PM.
>> >> So add the sram module to manage these sram banks.
>> >>
>> >> And register the sram banks so can dynamically alloc/free
>> >> the buffer.
>> >>
>> >> Leo Yan (3):
>> >>   ARM: mmp: add sram allocator
>> >>   ARM: mmp: register audio sram bank
>> >>   ARM: mmp: register internal sram bank
>> >>
>> >>  arch/arm/Kconfig                      |    1 +
>> >>  arch/arm/mach-mmp/Makefile            |    2 +-
>> >>  arch/arm/mach-mmp/brownstone.c        |   11 ++
>> >>  arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
>> >>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>> >>  arch/arm/mach-mmp/mmp2.c              |    3 +
>> >>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>> >>  7 files changed, 232 insertions(+), 1 deletions(-)
>> >>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>> >>  create mode 100644 arch/arm/mach-mmp/sram.c
>> >>
>> > Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
>>
>> Looks good to me. Thanks Haojian. Applied to -devel.
> I've some reserve on the named pool they need to be managed at generic level
> not here

What are their names? And your suggestions to fix this?

>
> Best Regards,
> J.
>

[PATCH V4 0/3] ARM: mmp: add audio sram support

[Leo Yan]

On 08/15/2011 05:35 PM, Eric Miao wrote:
> On Mon, Aug 15, 2011 at 5:12 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com>  wrote:
>> On 16:43 Mon 15 Aug     , Eric Miao wrote:
>>> On Mon, Aug 15, 2011 at 11:11 AM, Haojian Zhuang
>>> <haojian.zhuang@marvell.com>  wrote:
>>>> On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
>>>>> On mmp platform, there have two sram banks:
>>>>> audio sram bank, and internal sram bank for video and PM.
>>>>> So add the sram module to manage these sram banks.
>>>>>
>>>>> And register the sram banks so can dynamically alloc/free
>>>>> the buffer.
>>>>>
>>>>> Leo Yan (3):
>>>>>    ARM: mmp: add sram allocator
>>>>>    ARM: mmp: register audio sram bank
>>>>>    ARM: mmp: register internal sram bank
>>>>>
>>>>>   arch/arm/Kconfig                      |    1 +
>>>>>   arch/arm/mach-mmp/Makefile            |    2 +-
>>>>>   arch/arm/mach-mmp/brownstone.c        |   11 ++
>>>>>   arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
>>>>>   arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>>>>>   arch/arm/mach-mmp/mmp2.c              |    3 +
>>>>>   arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>>>>>   7 files changed, 232 insertions(+), 1 deletions(-)
>>>>>   create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>>>>>   create mode 100644 arch/arm/mach-mmp/sram.c
>>>>>
>>>> Acked-by: Haojian Zhuang<haojian.zhuang@gmail.com>
>>>
>>> Looks good to me. Thanks Haojian. Applied to -devel.
>> I've some reserve on the named pool they need to be managed at generic level
>> not here
>
> What are their names? And your suggestions to fix this?
>

For MMP platform have not only one bank, so now named the audio sram 
bank as "asram", and another sram bank as "isram" which is used by 
video/secure processor/pm.
If other modules want to use the sram, just use the name string to
get the gen pool handler, and then just call genalloc APIs.

I just wander if maintain the name in genalloc, then the name string
we should maintain in the pool's structure or chunk's structure?

>>
>> Best Regards,
>> J.
>>

Re: [PATCH V4 0/3] ARM: mmp: add audio sram support

[Leo Yan]

On 08/15/2011 05:35 PM, Eric Miao wrote:
> On Mon, Aug 15, 2011 at 5:12 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com>  wrote:
>> On 16:43 Mon 15 Aug     , Eric Miao wrote:
>>> On Mon, Aug 15, 2011 at 11:11 AM, Haojian Zhuang
>>> <haojian.zhuang@marvell.com>  wrote:
>>>> On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
>>>>> On mmp platform, there have two sram banks:
>>>>> audio sram bank, and internal sram bank for video and PM.
>>>>> So add the sram module to manage these sram banks.
>>>>>
>>>>> And register the sram banks so can dynamically alloc/free
>>>>> the buffer.
>>>>>
>>>>> Leo Yan (3):
>>>>>    ARM: mmp: add sram allocator
>>>>>    ARM: mmp: register audio sram bank
>>>>>    ARM: mmp: register internal sram bank
>>>>>
>>>>>   arch/arm/Kconfig                      |    1 +
>>>>>   arch/arm/mach-mmp/Makefile            |    2 +-
>>>>>   arch/arm/mach-mmp/brownstone.c        |   11 ++
>>>>>   arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
>>>>>   arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
>>>>>   arch/arm/mach-mmp/mmp2.c              |    3 +
>>>>>   arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
>>>>>   7 files changed, 232 insertions(+), 1 deletions(-)
>>>>>   create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
>>>>>   create mode 100644 arch/arm/mach-mmp/sram.c
>>>>>
>>>> Acked-by: Haojian Zhuang<haojian.zhuang@gmail.com>
>>>
>>> Looks good to me. Thanks Haojian. Applied to -devel.
>> I've some reserve on the named pool they need to be managed at generic level
>> not here
>
> What are their names? And your suggestions to fix this?
>

For MMP platform have not only one bank, so now named the audio sram 
bank as "asram", and another sram bank as "isram" which is used by 
video/secure processor/pm.
If other modules want to use the sram, just use the name string to
get the gen pool handler, and then just call genalloc APIs.

I just wander if maintain the name in genalloc, then the name string
we should maintain in the pool's structure or chunk's structure?

>>
>> Best Regards,
>> J.
>>

[PATCH V4 0/3] ARM: mmp: add audio sram support

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:25 Mon 15 Aug     , Leo Yan wrote:
> 
> 
> On 08/15/2011 05:35 PM, Eric Miao wrote:
> >On Mon, Aug 15, 2011 at 5:12 PM, Jean-Christophe PLAGNIOL-VILLARD
> ><plagnioj@jcrosoft.com>  wrote:
> >>On 16:43 Mon 15 Aug     , Eric Miao wrote:
> >>>On Mon, Aug 15, 2011 at 11:11 AM, Haojian Zhuang
> >>><haojian.zhuang@marvell.com>  wrote:
> >>>>On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
> >>>>>On mmp platform, there have two sram banks:
> >>>>>audio sram bank, and internal sram bank for video and PM.
> >>>>>So add the sram module to manage these sram banks.
> >>>>>
> >>>>>And register the sram banks so can dynamically alloc/free
> >>>>>the buffer.
> >>>>>
> >>>>>Leo Yan (3):
> >>>>>   ARM: mmp: add sram allocator
> >>>>>   ARM: mmp: register audio sram bank
> >>>>>   ARM: mmp: register internal sram bank
> >>>>>
> >>>>>  arch/arm/Kconfig                      |    1 +
> >>>>>  arch/arm/mach-mmp/Makefile            |    2 +-
> >>>>>  arch/arm/mach-mmp/brownstone.c        |   11 ++
> >>>>>  arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
> >>>>>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
> >>>>>  arch/arm/mach-mmp/mmp2.c              |    3 +
> >>>>>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
> >>>>>  7 files changed, 232 insertions(+), 1 deletions(-)
> >>>>>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
> >>>>>  create mode 100644 arch/arm/mach-mmp/sram.c
> >>>>>
> >>>>Acked-by: Haojian Zhuang<haojian.zhuang@gmail.com>
> >>>
> >>>Looks good to me. Thanks Haojian. Applied to -devel.
> >>I've some reserve on the named pool they need to be managed at generic level
> >>not here
> >
> >What are their names? And your suggestions to fix this?
> >
> 
> For MMP platform have not only one bank, so now named the audio sram
> bank as "asram", and another sram bank as "isram" which is used by
> video/secure processor/pm.
> If other modules want to use the sram, just use the name string to
> get the gen pool handler, and then just call genalloc APIs.
> 
> I just wander if maintain the name in genalloc, then the name string
> we should maintain in the pool's structure or chunk's structure?
on the chunk

Best Regards,
J.

Re: [PATCH V4 0/3] ARM: mmp: add audio sram support

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:25 Mon 15 Aug     , Leo Yan wrote:
> 
> 
> On 08/15/2011 05:35 PM, Eric Miao wrote:
> >On Mon, Aug 15, 2011 at 5:12 PM, Jean-Christophe PLAGNIOL-VILLARD
> ><plagnioj@jcrosoft.com>  wrote:
> >>On 16:43 Mon 15 Aug     , Eric Miao wrote:
> >>>On Mon, Aug 15, 2011 at 11:11 AM, Haojian Zhuang
> >>><haojian.zhuang@marvell.com>  wrote:
> >>>>On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
> >>>>>On mmp platform, there have two sram banks:
> >>>>>audio sram bank, and internal sram bank for video and PM.
> >>>>>So add the sram module to manage these sram banks.
> >>>>>
> >>>>>And register the sram banks so can dynamically alloc/free
> >>>>>the buffer.
> >>>>>
> >>>>>Leo Yan (3):
> >>>>>   ARM: mmp: add sram allocator
> >>>>>   ARM: mmp: register audio sram bank
> >>>>>   ARM: mmp: register internal sram bank
> >>>>>
> >>>>>  arch/arm/Kconfig                      |    1 +
> >>>>>  arch/arm/mach-mmp/Makefile            |    2 +-
> >>>>>  arch/arm/mach-mmp/brownstone.c        |   11 ++
> >>>>>  arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
> >>>>>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
> >>>>>  arch/arm/mach-mmp/mmp2.c              |    3 +
> >>>>>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
> >>>>>  7 files changed, 232 insertions(+), 1 deletions(-)
> >>>>>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
> >>>>>  create mode 100644 arch/arm/mach-mmp/sram.c
> >>>>>
> >>>>Acked-by: Haojian Zhuang<haojian.zhuang@gmail.com>
> >>>
> >>>Looks good to me. Thanks Haojian. Applied to -devel.
> >>I've some reserve on the named pool they need to be managed at generic level
> >>not here
> >
> >What are their names? And your suggestions to fix this?
> >
> 
> For MMP platform have not only one bank, so now named the audio sram
> bank as "asram", and another sram bank as "isram" which is used by
> video/secure processor/pm.
> If other modules want to use the sram, just use the name string to
> get the gen pool handler, and then just call genalloc APIs.
> 
> I just wander if maintain the name in genalloc, then the name string
> we should maintain in the pool's structure or chunk's structure?
on the chunk

Best Regards,
J.

[PATCH V4 0/3] ARM: mmp: add audio sram support

[Haojian Zhuang]

On Wed, 2011-08-17 at 05:32 -0700, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> On 18:25 Mon 15 Aug     , Leo Yan wrote:
> > 
> > 
> > On 08/15/2011 05:35 PM, Eric Miao wrote:
> > >On Mon, Aug 15, 2011 at 5:12 PM, Jean-Christophe PLAGNIOL-VILLARD
> > ><plagnioj@jcrosoft.com>  wrote:
> > >>On 16:43 Mon 15 Aug     , Eric Miao wrote:
> > >>>On Mon, Aug 15, 2011 at 11:11 AM, Haojian Zhuang
> > >>><haojian.zhuang@marvell.com>  wrote:
> > >>>>On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
> > >>>>>On mmp platform, there have two sram banks:
> > >>>>>audio sram bank, and internal sram bank for video and PM.
> > >>>>>So add the sram module to manage these sram banks.
> > >>>>>
> > >>>>>And register the sram banks so can dynamically alloc/free
> > >>>>>the buffer.
> > >>>>>
> > >>>>>Leo Yan (3):
> > >>>>>   ARM: mmp: add sram allocator
> > >>>>>   ARM: mmp: register audio sram bank
> > >>>>>   ARM: mmp: register internal sram bank
> > >>>>>
> > >>>>>  arch/arm/Kconfig                      |    1 +
> > >>>>>  arch/arm/mach-mmp/Makefile            |    2 +-
> > >>>>>  arch/arm/mach-mmp/brownstone.c        |   11 ++
> > >>>>>  arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
> > >>>>>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
> > >>>>>  arch/arm/mach-mmp/mmp2.c              |    3 +
> > >>>>>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
> > >>>>>  7 files changed, 232 insertions(+), 1 deletions(-)
> > >>>>>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
> > >>>>>  create mode 100644 arch/arm/mach-mmp/sram.c
> > >>>>>
> > >>>>Acked-by: Haojian Zhuang<haojian.zhuang@gmail.com>
> > >>>
> > >>>Looks good to me. Thanks Haojian. Applied to -devel.
> > >>I've some reserve on the named pool they need to be managed at generic level
> > >>not here
> > >
> > >What are their names? And your suggestions to fix this?
> > >
> > 
> > For MMP platform have not only one bank, so now named the audio sram
> > bank as "asram", and another sram bank as "isram" which is used by
> > video/secure processor/pm.
> > If other modules want to use the sram, just use the name string to
> > get the gen pool handler, and then just call genalloc APIs.
> > 
> > I just wander if maintain the name in genalloc, then the name string
> > we should maintain in the pool's structure or chunk's structure?
> on the chunk
> 
> Best Regards,
> J.

Now two sram region are used in one silicon. They are routed for
different functionality. If they're defined into chunks in same gen
pool, driver can't specify memory in which sram region. It's not our
target. And I don't think that we need to change gen pool to support
allocating memory into specified chunk. Since it's unnecessary.

So I think that these two sram region should be defined into two pools,
not two chunks. What's your opinion?

Thanks
Haojian

Re: [PATCH V4 0/3] ARM: mmp: add audio sram support

[Haojian Zhuang]

On Wed, 2011-08-17 at 05:32 -0700, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> On 18:25 Mon 15 Aug     , Leo Yan wrote:
> > 
> > 
> > On 08/15/2011 05:35 PM, Eric Miao wrote:
> > >On Mon, Aug 15, 2011 at 5:12 PM, Jean-Christophe PLAGNIOL-VILLARD
> > ><plagnioj@jcrosoft.com>  wrote:
> > >>On 16:43 Mon 15 Aug     , Eric Miao wrote:
> > >>>On Mon, Aug 15, 2011 at 11:11 AM, Haojian Zhuang
> > >>><haojian.zhuang@marvell.com>  wrote:
> > >>>>On Sun, 2011-08-14 at 20:09 -0700, Leo Yan wrote:
> > >>>>>On mmp platform, there have two sram banks:
> > >>>>>audio sram bank, and internal sram bank for video and PM.
> > >>>>>So add the sram module to manage these sram banks.
> > >>>>>
> > >>>>>And register the sram banks so can dynamically alloc/free
> > >>>>>the buffer.
> > >>>>>
> > >>>>>Leo Yan (3):
> > >>>>>   ARM: mmp: add sram allocator
> > >>>>>   ARM: mmp: register audio sram bank
> > >>>>>   ARM: mmp: register internal sram bank
> > >>>>>
> > >>>>>  arch/arm/Kconfig                      |    1 +
> > >>>>>  arch/arm/mach-mmp/Makefile            |    2 +-
> > >>>>>  arch/arm/mach-mmp/brownstone.c        |   11 ++
> > >>>>>  arch/arm/mach-mmp/include/mach/mmp2.h |   13 +++
> > >>>>>  arch/arm/mach-mmp/include/mach/sram.h |   35 +++++++
> > >>>>>  arch/arm/mach-mmp/mmp2.c              |    3 +
> > >>>>>  arch/arm/mach-mmp/sram.c              |  168 +++++++++++++++++++++++++++++++++
> > >>>>>  7 files changed, 232 insertions(+), 1 deletions(-)
> > >>>>>  create mode 100644 arch/arm/mach-mmp/include/mach/sram.h
> > >>>>>  create mode 100644 arch/arm/mach-mmp/sram.c
> > >>>>>
> > >>>>Acked-by: Haojian Zhuang<haojian.zhuang@gmail.com>
> > >>>
> > >>>Looks good to me. Thanks Haojian. Applied to -devel.
> > >>I've some reserve on the named pool they need to be managed at generic level
> > >>not here
> > >
> > >What are their names? And your suggestions to fix this?
> > >
> > 
> > For MMP platform have not only one bank, so now named the audio sram
> > bank as "asram", and another sram bank as "isram" which is used by
> > video/secure processor/pm.
> > If other modules want to use the sram, just use the name string to
> > get the gen pool handler, and then just call genalloc APIs.
> > 
> > I just wander if maintain the name in genalloc, then the name string
> > we should maintain in the pool's structure or chunk's structure?
> on the chunk
> 
> Best Regards,
> J.

Now two sram region are used in one silicon. They are routed for
different functionality. If they're defined into chunks in same gen
pool, driver can't specify memory in which sram region. It's not our
target. And I don't think that we need to change gen pool to support
allocating memory into specified chunk. Since it's unnecessary.

So I think that these two sram region should be defined into two pools,
not two chunks. What's your opinion?

Thanks
Haojian