* [PATCH 1/3] ARM: mmp: add sram allocator
2011-08-15 3:09 [PATCH V4 0/3] ARM: mmp: add audio sram support Leo Yan
@ 2011-08-15 3:09 ` Leo Yan
2011-08-15 8:59 ` Arnd Bergmann
` (2 more replies)
2011-08-15 3:09 ` [PATCH 2/3] ARM: mmp: register audio sram bank Leo Yan
` (2 subsequent siblings)
3 siblings, 3 replies; 27+ messages in thread
From: Leo Yan @ 2011-08-15 3:09 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH 1/3] ARM: mmp: add sram allocator
2011-08-15 3:09 ` [PATCH 1/3] ARM: mmp: add sram allocator Leo Yan
@ 2011-08-15 8:59 ` Arnd Bergmann
2011-08-15 9:09 ` Jean-Christophe PLAGNIOL-VILLARD
` (2 more replies)
2011-08-15 9:11 ` Jean-Christophe PLAGNIOL-VILLARD
2011-08-22 23:47 ` [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE Andres Salomon
2 siblings, 3 replies; 27+ messages in thread
From: Arnd Bergmann @ 2011-08-15 8:59 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread* [PATCH 1/3] ARM: mmp: add sram allocator
2011-08-15 8:59 ` Arnd Bergmann
@ 2011-08-15 9:09 ` Jean-Christophe PLAGNIOL-VILLARD
2011-08-15 9:30 ` Haojian Zhuang
2011-08-15 9:26 ` Leo Yan
2011-08-15 13:23 ` Nicolas Pitre
2 siblings, 1 reply; 27+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-15 9:09 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 1/3] ARM: mmp: add sram allocator
2011-08-15 9:09 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2011-08-15 9:30 ` Haojian Zhuang
2011-10-07 19:06 ` Tony Lindgren
0 siblings, 1 reply; 27+ messages in thread
From: Haojian Zhuang @ 2011-08-15 9:30 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 1/3] ARM: mmp: add sram allocator
2011-08-15 9:30 ` Haojian Zhuang
@ 2011-10-07 19:06 ` Tony Lindgren
0 siblings, 0 replies; 27+ messages in thread
From: Tony Lindgren @ 2011-10-07 19:06 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 1/3] ARM: mmp: add sram allocator
2011-08-15 8:59 ` Arnd Bergmann
2011-08-15 9:09 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2011-08-15 9:26 ` Leo Yan
2011-08-15 13:23 ` Nicolas Pitre
2 siblings, 0 replies; 27+ messages in thread
From: Leo Yan @ 2011-08-15 9:26 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 1/3] ARM: mmp: add sram allocator
2011-08-15 8:59 ` Arnd Bergmann
2011-08-15 9:09 ` Jean-Christophe PLAGNIOL-VILLARD
2011-08-15 9:26 ` Leo Yan
@ 2011-08-15 13:23 ` Nicolas Pitre
2011-08-15 13:32 ` Russell King - ARM Linux
2 siblings, 1 reply; 27+ messages in thread
From: Nicolas Pitre @ 2011-08-15 13:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 1/3] ARM: mmp: add sram allocator
2011-08-15 13:23 ` Nicolas Pitre
@ 2011-08-15 13:32 ` Russell King - ARM Linux
0 siblings, 0 replies; 27+ messages in thread
From: Russell King - ARM Linux @ 2011-08-15 13:32 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 1/3] ARM: mmp: add sram allocator
2011-08-15 3:09 ` [PATCH 1/3] ARM: mmp: add sram allocator Leo Yan
2011-08-15 8:59 ` Arnd Bergmann
@ 2011-08-15 9:11 ` Jean-Christophe PLAGNIOL-VILLARD
2011-08-22 23:47 ` [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE Andres Salomon
2 siblings, 0 replies; 27+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-15 9:11 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread* [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE
2011-08-15 3:09 ` [PATCH 1/3] ARM: mmp: add sram allocator Leo Yan
2011-08-15 8:59 ` Arnd Bergmann
2011-08-15 9:11 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2011-08-22 23:47 ` Andres Salomon
2011-08-23 0:07 ` Eric Miao
2011-08-23 0:07 ` Russell King - ARM Linux
2 siblings, 2 replies; 27+ messages in thread
From: Andres Salomon @ 2011-08-22 23:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE
2011-08-22 23:47 ` [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE Andres Salomon
@ 2011-08-23 0:07 ` Eric Miao
2011-08-23 2:08 ` Andres Salomon
2011-08-23 0:07 ` Russell King - ARM Linux
1 sibling, 1 reply; 27+ messages in thread
From: Eric Miao @ 2011-08-23 0:07 UTC (permalink / raw)
To: linux-arm-kernel
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
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread* [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE
2011-08-23 0:07 ` Eric Miao
@ 2011-08-23 2:08 ` Andres Salomon
2011-08-23 7:48 ` Leo Yan
0 siblings, 1 reply; 27+ messages in thread
From: Andres Salomon @ 2011-08-23 2:08 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 27+ messages in thread* [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE
2011-08-23 2:08 ` Andres Salomon
@ 2011-08-23 7:48 ` Leo Yan
2011-08-23 8:22 ` Haojian Zhuang
0 siblings, 1 reply; 27+ messages in thread
From: Leo Yan @ 2011-08-23 7:48 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 27+ messages in thread* [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE
2011-08-23 7:48 ` Leo Yan
@ 2011-08-23 8:22 ` Haojian Zhuang
0 siblings, 0 replies; 27+ messages in thread
From: Haojian Zhuang @ 2011-08-23 8:22 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE
2011-08-22 23:47 ` [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE Andres Salomon
2011-08-23 0:07 ` Eric Miao
@ 2011-08-23 0:07 ` Russell King - ARM Linux
2011-08-23 2:13 ` Andres Salomon
1 sibling, 1 reply; 27+ messages in thread
From: Russell King - ARM Linux @ 2011-08-23 0:07 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE
2011-08-23 0:07 ` Russell King - ARM Linux
@ 2011-08-23 2:13 ` Andres Salomon
2011-10-07 19:05 ` Tony Lindgren
0 siblings, 1 reply; 27+ messages in thread
From: Andres Salomon @ 2011-08-23 2:13 UTC (permalink / raw)
To: linux-arm-kernel
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).
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH] ARM: mmp: map sram as MT_MEMORY rather than MT_DEVICE
2011-08-23 2:13 ` Andres Salomon
@ 2011-10-07 19:05 ` Tony Lindgren
0 siblings, 0 replies; 27+ messages in thread
From: Tony Lindgren @ 2011-10-07 19:05 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 2/3] ARM: mmp: register audio sram bank
2011-08-15 3:09 [PATCH V4 0/3] ARM: mmp: add audio sram support Leo Yan
2011-08-15 3:09 ` [PATCH 1/3] ARM: mmp: add sram allocator Leo Yan
@ 2011-08-15 3:09 ` Leo Yan
2011-08-15 3:09 ` [PATCH 3/3] ARM: mmp: register internal " Leo Yan
2011-08-15 3:11 ` [PATCH V4 0/3] ARM: mmp: add audio sram support Haojian Zhuang
3 siblings, 0 replies; 27+ messages in thread
From: Leo Yan @ 2011-08-15 3:09 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH 3/3] ARM: mmp: register internal sram bank
2011-08-15 3:09 [PATCH V4 0/3] ARM: mmp: add audio sram support Leo Yan
2011-08-15 3:09 ` [PATCH 1/3] ARM: mmp: add sram allocator Leo Yan
2011-08-15 3:09 ` [PATCH 2/3] ARM: mmp: register audio sram bank Leo Yan
@ 2011-08-15 3:09 ` Leo Yan
2011-08-15 3:11 ` [PATCH V4 0/3] ARM: mmp: add audio sram support Haojian Zhuang
3 siblings, 0 replies; 27+ messages in thread
From: Leo Yan @ 2011-08-15 3:09 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH V4 0/3] ARM: mmp: add audio sram support
2011-08-15 3:09 [PATCH V4 0/3] ARM: mmp: add audio sram support Leo Yan
` (2 preceding siblings ...)
2011-08-15 3:09 ` [PATCH 3/3] ARM: mmp: register internal " Leo Yan
@ 2011-08-15 3:11 ` Haojian Zhuang
2011-08-15 8:43 ` Eric Miao
3 siblings, 1 reply; 27+ messages in thread
From: Haojian Zhuang @ 2011-08-15 3:11 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 27+ messages in thread* [PATCH V4 0/3] ARM: mmp: add audio sram support
2011-08-15 3:11 ` [PATCH V4 0/3] ARM: mmp: add audio sram support Haojian Zhuang
@ 2011-08-15 8:43 ` Eric Miao
2011-08-15 9:12 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 1 reply; 27+ messages in thread
From: Eric Miao @ 2011-08-15 8:43 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH V4 0/3] ARM: mmp: add audio sram support
2011-08-15 8:43 ` Eric Miao
@ 2011-08-15 9:12 ` Jean-Christophe PLAGNIOL-VILLARD
2011-08-15 9:35 ` Eric Miao
0 siblings, 1 reply; 27+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-15 9:12 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH V4 0/3] ARM: mmp: add audio sram support
2011-08-15 9:12 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2011-08-15 9:35 ` Eric Miao
2011-08-15 10:25 ` Leo Yan
0 siblings, 1 reply; 27+ messages in thread
From: Eric Miao @ 2011-08-15 9:35 UTC (permalink / raw)
To: linux-arm-kernel
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.
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH V4 0/3] ARM: mmp: add audio sram support
2011-08-15 9:35 ` Eric Miao
@ 2011-08-15 10:25 ` Leo Yan
2011-08-17 12:32 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 1 reply; 27+ messages in thread
From: Leo Yan @ 2011-08-15 10:25 UTC (permalink / raw)
To: linux-arm-kernel
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.
>>
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH V4 0/3] ARM: mmp: add audio sram support
2011-08-15 10:25 ` Leo Yan
@ 2011-08-17 12:32 ` Jean-Christophe PLAGNIOL-VILLARD
2011-08-19 8:25 ` Haojian Zhuang
0 siblings, 1 reply; 27+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-17 12:32 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH V4 0/3] ARM: mmp: add audio sram support
2011-08-17 12:32 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2011-08-19 8:25 ` Haojian Zhuang
0 siblings, 0 replies; 27+ messages in thread
From: Haojian Zhuang @ 2011-08-19 8:25 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread