[PATCH v2 0/7] uio_pruss cleanup and platform support

[PATCH v2 0/7] uio_pruss cleanup and platform support

[Matt Porter]

Changes since v1:
	- Replaced uio_pruss private SRAM API use with genalloc
	- Added DA850 platform device and clock support
	- Added DA850 L3 RAM gen_pool support
	- Split out DT binding

This series enables uio_pruss on both DA850 and AM33xx. The driver
previously was not enabled by any platform and the private SRAM API
was accessing an invalid SRAM bank for use on DA850. For AM33xx,
DT, pinctrl, and runtime PM support are added since AM33xx only
boots via DT.

The AM33xx support requires some help in hwmod due to the following
comment in arch/arm/mach-omap2/omap_hwmod.c:
	/*
	 * If an IP block contains HW reset lines and any of them are
	 * asserted, we let integration code associated with that
	 * block handle the enable.  We've received very little
	 * information on what those driver authors need, and until
	 * detailed information is provided and the driver code is
	 * posted to the public lists, this is probably the best we
	 * can do.
	 */

The approach to deal with the hardware reset (for at least the pruss
hwmod) was to add a generic omap property to properly define this
hardware. The implementation simply deasserts any rst lines that
are called out in the property when the omap_device is
instantiated. This is not the ideal implementation as the sequence is
a bit wrong for pruss since the busy check during the hard reset
will fail, even though it fails in a benign manner. Ideally, we would
want the implementation to observe the ti,deassert-hard-reset property
and use that in omap_hwmod.c:_enable() *after* the module is unidled
and the clocks active. However, this is actually functional for purposes
of getting the uio_pruss driver up and running.

Matt Porter (7):
  uio: uio_pruss: replace private SRAM API with genalloc
  uio: uio_pruss: add support for am33xx
  uio: dt: add TI PRUSS binding
  ARM: davinci: Add support for an L3RAM gen_pool
  ARM: davinci: Add support for PRUSS on DA850
  ARM: omap: add DT support for deasserting hardware reset lines
  ARM: dts: AM33xx PRUSS support

 .../devicetree/bindings/arm/omap/omap.txt          |    2 +
 Documentation/devicetree/bindings/uio/pruss.txt    |   17 +++
 arch/arm/boot/dts/am335x-bone.dts                  |    4 +
 arch/arm/boot/dts/am33xx.dtsi                      |   11 ++
 arch/arm/mach-davinci/board-da850-evm.c            |   12 +++
 arch/arm/mach-davinci/da850.c                      |    9 ++
 arch/arm/mach-davinci/devices-da8xx.c              |   66 ++++++++++++
 arch/arm/mach-davinci/include/mach/common.h        |    2 +
 arch/arm/mach-davinci/include/mach/da8xx.h         |    3 +
 arch/arm/mach-davinci/include/mach/sram.h          |    3 +
 arch/arm/mach-davinci/sram.c                       |   28 ++++-
 arch/arm/plat-omap/omap_device.c                   |   25 ++++-
 drivers/uio/Kconfig                                |    5 +-
 drivers/uio/uio_pruss.c                            |  108 +++++++++++++++-----
 include/linux/platform_data/uio_pruss.h            |    3 +-
 15 files changed, 269 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/uio/pruss.txt

-- 
1.7.9.5

[PATCH v2 1/7] uio: uio_pruss: replace private SRAM API with genalloc

[Matt Porter]

Remove the use of the private DaVinci SRAM API in favor
of genalloc. The pool to be used is provided by platform
data.

Signed-off-by: Matt Porter <mporter@ti.com>
---
 drivers/uio/Kconfig                     |    1 +
 drivers/uio/uio_pruss.c                 |   24 +++++++++++++++++-------
 include/linux/platform_data/uio_pruss.h |    3 ++-
 3 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 6f3ea9b..c48b938 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -97,6 +97,7 @@ config UIO_NETX
 config UIO_PRUSS
 	tristate "Texas Instruments PRUSS driver"
 	depends on ARCH_DAVINCI_DA850
+	select GENERIC_ALLOCATOR
 	help
 	  PRUSS driver for OMAPL138/DA850/AM18XX devices
 	  PRUSS driver requires user space components, examples and user space
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index 33a7a27..1b55db3 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -25,7 +25,7 @@
 #include <linux/clk.h>
 #include <linux/dma-mapping.h>
 #include <linux/slab.h>
-#include <mach/sram.h>
+#include <linux/genalloc.h>
 
 #define DRV_NAME "pruss_uio"
 #define DRV_VERSION "1.0"
@@ -65,10 +65,11 @@ struct uio_pruss_dev {
 	dma_addr_t sram_paddr;
 	dma_addr_t ddr_paddr;
 	void __iomem *prussio_vaddr;
-	void *sram_vaddr;
+	unsigned long sram_vaddr;
 	void *ddr_vaddr;
 	unsigned int hostirq_start;
 	unsigned int pintc_base;
+	struct gen_pool *sram_pool;
 };
 
 static irqreturn_t pruss_handler(int irq, struct uio_info *info)
@@ -106,7 +107,9 @@ static void pruss_cleanup(struct platform_device *dev,
 			gdev->ddr_paddr);
 	}
 	if (gdev->sram_vaddr)
-		sram_free(gdev->sram_vaddr, sram_pool_sz);
+		gen_pool_free(gdev->sram_pool,
+			      gdev->sram_vaddr,
+			      sram_pool_sz);
 	kfree(gdev->info);
 	clk_put(gdev->pruss_clk);
 	kfree(gdev);
@@ -152,10 +155,17 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
-	if (!gdev->sram_vaddr) {
-		dev_err(&dev->dev, "Could not allocate SRAM pool\n");
-		goto out_free;
+	if (pdata->l3ram_pool) {
+		gdev->sram_pool = pdata->l3ram_pool;
+		gdev->sram_vaddr =
+			gen_pool_alloc(gdev->sram_pool, sram_pool_sz);
+		if (!gdev->sram_vaddr) {
+			dev_err(&dev->dev, "Could not allocate SRAM pool\n");
+			goto out_free;
+		}
+		gdev->sram_paddr =
+			gen_pool_virt_to_phys(gdev->sram_pool,
+					      gdev->sram_vaddr);
 	}
 
 	gdev->ddr_vaddr = dma_alloc_coherent(&dev->dev, extram_pool_sz,
diff --git a/include/linux/platform_data/uio_pruss.h b/include/linux/platform_data/uio_pruss.h
index f39140a..e500fe6 100644
--- a/include/linux/platform_data/uio_pruss.h
+++ b/include/linux/platform_data/uio_pruss.h
@@ -20,6 +20,7 @@
 
 /* To configure the PRUSS INTC base offset for UIO driver */
 struct uio_pruss_pdata {
-	u32	pintc_base;
+	u32		pintc_base;
+	struct gen_pool *l3ram_pool;
 };
 #endif /* _UIO_PRUSS_H_ */
-- 
1.7.9.5

[PATCH v2 2/7] uio: uio_pruss: add support for am33xx

[Matt Porter]

Adds DT, pinctrl, and runtime PM support to enable AM33xx.

Signed-off-by: Matt Porter <mporter@ti.com>
---
 drivers/uio/Kconfig     |    4 +--
 drivers/uio/uio_pruss.c |   90 +++++++++++++++++++++++++++++++++++++----------
 2 files changed, 73 insertions(+), 21 deletions(-)

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index c48b938..5db1f34 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -96,10 +96,10 @@ config UIO_NETX
 
 config UIO_PRUSS
 	tristate "Texas Instruments PRUSS driver"
-	depends on ARCH_DAVINCI_DA850
+	depends on ARCH_DAVINCI_DA850 || SOC_AM33XX
 	select GENERIC_ALLOCATOR
 	help
-	  PRUSS driver for OMAPL138/DA850/AM18XX devices
+	  PRUSS driver for OMAPL138/DA850/AM18XX and AM33XX devices
 	  PRUSS driver requires user space components, examples and user space
 	  driver is available from below SVN repo - you may use anonymous login
 
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index 1b55db3..8560958 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -26,6 +26,11 @@
 #include <linux/dma-mapping.h>
 #include <linux/slab.h>
 #include <linux/genalloc.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/err.h>
+#include <linux/pm_runtime.h>
 
 #define DRV_NAME "pruss_uio"
 #define DRV_VERSION "1.0"
@@ -120,8 +125,10 @@ static int __devinit pruss_probe(struct platform_device *dev)
 	struct uio_info *p;
 	struct uio_pruss_dev *gdev;
 	struct resource *regs_prussio;
+	struct resource res;
 	int ret = -ENODEV, cnt = 0, len;
 	struct uio_pruss_pdata *pdata = dev->dev.platform_data;
+	struct pinctrl *pinctrl;
 
 	gdev = kzalloc(sizeof(struct uio_pruss_dev), GFP_KERNEL);
 	if (!gdev)
@@ -132,18 +139,51 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		kfree(gdev);
 		return -ENOMEM;
 	}
-	/* Power on PRU in case its not done as part of boot-loader */
-	gdev->pruss_clk = clk_get(&dev->dev, "pruss");
-	if (IS_ERR(gdev->pruss_clk)) {
-		dev_err(&dev->dev, "Failed to get clock\n");
-		kfree(gdev->info);
-		kfree(gdev);
-		ret = PTR_ERR(gdev->pruss_clk);
-		return ret;
+
+	if (dev->dev.of_node) {
+		pm_runtime_enable(&dev->dev);
+		ret = pm_runtime_get_sync(&dev->dev);
+		if (IS_ERR_VALUE(ret)) {
+			dev_err(&dev->dev, "pm_runtime_get_sync() failed\n");
+			return ret;
+		}
+
+		ret = of_address_to_resource(dev->dev.of_node, 0, &res);
+		if (IS_ERR_VALUE(ret)) {
+			dev_err(&dev->dev, "failed to parse DT reg\n");
+			return ret;
+		}
+		regs_prussio = &res;
+
+		ret = of_property_read_u32(dev->dev.of_node,
+					   "ti,pintc-offset",
+					   &gdev->pintc_base);
+		if (ret < 0) {
+			dev_err(&dev->dev,
+				"Can't parse ti,pintc-offset property\n");
+			goto out_free;
+		}
 	} else {
-		clk_enable(gdev->pruss_clk);
+		/* Power on PRU in case its not done as part of boot-loader */
+		gdev->pruss_clk = clk_get(&dev->dev, "pruss");
+		if (IS_ERR(gdev->pruss_clk)) {
+			dev_err(&dev->dev, "Failed to get clock\n");
+			kfree(gdev->info);
+			kfree(gdev);
+			ret = PTR_ERR(gdev->pruss_clk);
+			return ret;
+		} else {
+			clk_enable(gdev->pruss_clk);
+		}
+		gdev->pintc_base = pdata->pintc_base;
+		gdev->sram_pool = pdata->l3ram_pool;
 	}
 
+	pinctrl = devm_pinctrl_get_select_default(&dev->dev);
+	if (IS_ERR(pinctrl))
+		dev_warn(&dev->dev,
+			"pins are not configured from the driver\n");
+
 	regs_prussio = platform_get_resource(dev, IORESOURCE_MEM, 0);
 	if (!regs_prussio) {
 		dev_err(&dev->dev, "No PRUSS I/O resource specified\n");
@@ -155,8 +195,7 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	if (pdata->l3ram_pool) {
-		gdev->sram_pool = pdata->l3ram_pool;
+	if (gdev->sram_pool) {
 		gdev->sram_vaddr =
 			gen_pool_alloc(gdev->sram_pool, sram_pool_sz);
 		if (!gdev->sram_vaddr) {
@@ -182,7 +221,6 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		goto out_free;
 	}
 
-	gdev->pintc_base = pdata->pintc_base;
 	gdev->hostirq_start = platform_get_irq(dev, 0);
 
 	for (cnt = 0, p = gdev->info; cnt < MAX_PRUSS_EVT; cnt++, p++) {
@@ -190,13 +228,19 @@ static int __devinit pruss_probe(struct platform_device *dev)
 		p->mem[0].size = resource_size(regs_prussio);
 		p->mem[0].memtype = UIO_MEM_PHYS;
 
-		p->mem[1].addr = gdev->sram_paddr;
-		p->mem[1].size = sram_pool_sz;
-		p->mem[1].memtype = UIO_MEM_PHYS;
-
-		p->mem[2].addr = gdev->ddr_paddr;
-		p->mem[2].size = extram_pool_sz;
-		p->mem[2].memtype = UIO_MEM_PHYS;
+		if (gdev->sram_vaddr) {
+			p->mem[1].addr = gdev->sram_paddr;
+			p->mem[1].size = sram_pool_sz;
+			p->mem[1].memtype = UIO_MEM_PHYS;
+
+			p->mem[2].addr = gdev->ddr_paddr;
+			p->mem[2].size = extram_pool_sz;
+			p->mem[2].memtype = UIO_MEM_PHYS;
+		} else {
+			p->mem[1].addr = gdev->ddr_paddr;
+			p->mem[1].size = extram_pool_sz;
+			p->mem[1].memtype = UIO_MEM_PHYS;
+		}
 
 		p->name = kasprintf(GFP_KERNEL, "pruss_evt%d", cnt);
 		p->version = DRV_VERSION;
@@ -228,12 +272,20 @@ static int __devexit pruss_remove(struct platform_device *dev)
 	return 0;
 }
 
+static const struct of_device_id pruss_dt_ids[] = {
+	{ .compatible = "ti,pruss-v1", .data = NULL, },
+	{ .compatible = "ti,pruss-v2", .data = NULL, },
+	{},
+};
+MODULE_DEVICE_TABLE(of, pruss_dt_ids);
+
 static struct platform_driver pruss_driver = {
 	.probe = pruss_probe,
 	.remove = __devexit_p(pruss_remove),
 	.driver = {
 		   .name = DRV_NAME,
 		   .owner = THIS_MODULE,
+		   .of_match_table = pruss_dt_ids,
 		   },
 };
 
-- 
1.7.9.5

[PATCH v2 3/7] uio: dt: add TI PRUSS binding

[Matt Porter]

Adds a DT binding definition for the TI PRUSS.

Signed-off-by: Matt Porter <mporter@ti.com>
---
 Documentation/devicetree/bindings/uio/pruss.txt |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/uio/pruss.txt

diff --git a/Documentation/devicetree/bindings/uio/pruss.txt b/Documentation/devicetree/bindings/uio/pruss.txt
new file mode 100644
index 0000000..2ac45c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/pruss.txt
@@ -0,0 +1,17 @@
+TI PRUSS device
+
+Required properties:
+- compatible :
+  - "ti,pruss-v1" for AM18xx/OMAP-L138/DA850
+  - "ti,pruss-v2" for AM33xx.
+- ti,pintc-offset : Offset of the PINTC from the PRUSS address base
+- ti,hwmods: Name of the hwmod associated to the PRUSS
+
+Example:
+
+pruss: pruss@4a300000 {
+	compatible = "ti,pruss-v2";
+	ti,hwmods = "pruss";
+	reg = <0x4a300000 0x080000>;
+	ti,pintc-offset = <0x20000>;
+};
-- 
1.7.9.5

[PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Matt Porter]

L3RAM (shared SRAM) is needed for use by several drivers.
This creates a genalloc pool and a hook for the platform code
to provide the struct gen_pool * in platform data.

Signed-off-by: Matt Porter <mporter@ti.com>
---
 arch/arm/mach-davinci/include/mach/common.h |    2 ++
 arch/arm/mach-davinci/include/mach/sram.h   |    3 +++
 arch/arm/mach-davinci/sram.c                |   28 ++++++++++++++++++++++++++-
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index bdc4aa8..5a2ea37 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -77,6 +77,8 @@ struct davinci_soc_info {
 	struct emac_platform_data	*emac_pdata;
 	dma_addr_t			sram_dma;
 	unsigned			sram_len;
+	dma_addr_t			l3ram_dma;
+	unsigned			l3ram_len;
 };
 
 extern struct davinci_soc_info davinci_soc_info;
diff --git a/arch/arm/mach-davinci/include/mach/sram.h b/arch/arm/mach-davinci/include/mach/sram.h
index 111f7cc..1a81e5b 100644
--- a/arch/arm/mach-davinci/include/mach/sram.h
+++ b/arch/arm/mach-davinci/include/mach/sram.h
@@ -24,4 +24,7 @@
 extern void *sram_alloc(size_t len, dma_addr_t *dma);
 extern void sram_free(void *addr, size_t len);
 
+/* Get the l3ram struct gen_pool * for use in platform data */
+extern struct gen_pool *sram_get_l3ram_pool(void);
+
 #endif /* __MACH_SRAM_H */
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index db0f778..e609fa3 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -15,7 +15,12 @@
 #include <mach/common.h>
 #include <mach/sram.h>
 
-static struct gen_pool *sram_pool;
+static struct gen_pool *sram_pool, *l3ram_pool;
+
+struct gen_pool *sram_get_l3ram_pool(void)
+{
+	return l3ram_pool;
+}
 
 void *sram_alloc(size_t len, dma_addr_t *dma)
 {
@@ -54,6 +59,9 @@ EXPORT_SYMBOL(sram_free);
 static int __init sram_init(void)
 {
 	unsigned len = davinci_soc_info.sram_len;
+	unsigned l3ram_dma = davinci_soc_info.l3ram_dma;
+	unsigned l3ram_len = davinci_soc_info.l3ram_len;
+	void *l3ram_virt;
 	int status = 0;
 
 	if (len) {
@@ -65,6 +73,24 @@ static int __init sram_init(void)
 	if (sram_pool)
 		status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
 	WARN_ON(status < 0);
+
+	if (l3ram_dma) {
+		l3ram_pool =
+			gen_pool_create(ilog2(SRAM_GRANULARITY), -1);
+		if (!l3ram_pool)
+			status = -ENOMEM;
+	}
+
+	if (l3ram_pool) {
+		l3ram_virt = ioremap(l3ram_dma, l3ram_len);
+		if (l3ram_virt)
+			status = gen_pool_add_virt(l3ram_pool,
+						   (unsigned long)l3ram_virt,
+						   l3ram_dma, l3ram_len, -1);
+		else
+			status = -ENOMEM;
+	}
+
 	return status;
 }
 core_initcall(sram_init);
-- 
1.7.9.5

[PATCH v2 5/7] ARM: davinci: Add support for PRUSS on DA850

[Matt Porter]

Adds PRUSS clock, registers the L3RAM pool, and registers the
platform device for uio_pruss on DA850.

Signed-off-by: Matt Porter <mporter@ti.com>
---
 arch/arm/mach-davinci/board-da850-evm.c    |   12 +++++
 arch/arm/mach-davinci/da850.c              |    9 ++++
 arch/arm/mach-davinci/devices-da8xx.c      |   66 ++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |    3 ++
 4 files changed, 90 insertions(+)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 1295e61..d4f1720 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -29,6 +29,7 @@
 #include <linux/regulator/machine.h>
 #include <linux/regulator/tps6507x.h>
 #include <linux/input/tps6507x-ts.h>
+#include <linux/platform_data/uio_pruss.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/flash.h>
 #include <linux/delay.h>
@@ -42,6 +43,7 @@
 #include <mach/da8xx.h>
 #include <linux/platform_data/mtd-davinci.h>
 #include <mach/mux.h>
+#include <mach/sram.h>
 #include <linux/platform_data/mtd-davinci-aemif.h>
 #include <linux/platform_data/spi-davinci.h>
 
@@ -1253,6 +1255,10 @@ static __init int da850_wl12xx_init(void)
 
 #endif /* CONFIG_DA850_WL12XX */
 
+struct uio_pruss_pdata da8xx_pruss_uio_pdata = {
+	.pintc_base	= 0x4000,
+};
+
 #define DA850EVM_SATA_REFCLKPN_RATE	(100 * 1000 * 1000)
 
 static __init void da850_evm_init(void)
@@ -1339,6 +1345,12 @@ static __init void da850_evm_init(void)
 		pr_warning("da850_evm_init: lcdcntl mux setup failed: %d\n",
 				ret);
 
+	da8xx_pruss_uio_pdata.l3ram_pool = sram_get_l3ram_pool();
+	ret = da8xx_register_pruss_uio(&da8xx_pruss_uio_pdata);
+	if (ret)
+		pr_warning("pruss_uio initialization failed: %d\n",
+				ret);
+
 	/* Handle board specific muxing for LCD here */
 	ret = davinci_cfg_reg_list(da850_evm_lcdc_pins);
 	if (ret)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 6676dee..131c175 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -212,6 +212,12 @@ static struct clk tptc2_clk = {
 	.flags		= ALWAYS_ENABLED,
 };
 
+static struct clk pruss_clk = {
+	.name		= "pruss",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC0_PRUSS,
+};
+
 static struct clk uart0_clk = {
 	.name		= "uart0",
 	.parent		= &pll0_sysclk2,
@@ -378,6 +384,7 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"tptc1",	&tptc1_clk),
 	CLK(NULL,		"tpcc1",	&tpcc1_clk),
 	CLK(NULL,		"tptc2",	&tptc2_clk),
+	CLK(NULL,		"pruss",	&pruss_clk),
 	CLK(NULL,		"uart0",	&uart0_clk),
 	CLK(NULL,		"uart1",	&uart1_clk),
 	CLK(NULL,		"uart2",	&uart2_clk),
@@ -1089,6 +1096,8 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.emac_pdata		= &da8xx_emac_pdata,
 	.sram_dma		= DA8XX_ARM_RAM_BASE,
 	.sram_len		= SZ_8K,
+	.l3ram_dma		= DA8XX_SHARED_RAM_BASE,
+	.l3ram_len		= SZ_128K,
 };
 
 void __init da850_init(void)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index bd2f72b..7c2e0d2 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -518,6 +518,72 @@ void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata)
 	}
 }
 
+#define DA8XX_PRUSS_MEM_BASE		0x01C30000
+
+static struct resource da8xx_pruss_resources[] = {
+	{
+		.start	= DA8XX_PRUSS_MEM_BASE,
+		.end	= DA8XX_PRUSS_MEM_BASE + 0xFFFF,
+		.flags	= IORESOURCE_MEM,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT0,
+		.end	= IRQ_DA8XX_EVTOUT0,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT1,
+		.end	= IRQ_DA8XX_EVTOUT1,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT2,
+		.end	= IRQ_DA8XX_EVTOUT2,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT3,
+		.end	= IRQ_DA8XX_EVTOUT3,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT4,
+		.end	= IRQ_DA8XX_EVTOUT4,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT5,
+		.end	= IRQ_DA8XX_EVTOUT5,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT6,
+		.end	= IRQ_DA8XX_EVTOUT6,
+		.flags	= IORESOURCE_IRQ,
+	},
+	{
+		.start	= IRQ_DA8XX_EVTOUT7,
+		.end	= IRQ_DA8XX_EVTOUT7,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device da8xx_pruss_uio_dev = {
+	.name		= "pruss_uio",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(da8xx_pruss_resources),
+	.resource	= da8xx_pruss_resources,
+	.dev	 =	{
+		.coherent_dma_mask = 0xffffffff,
+	}
+};
+
+int __init da8xx_register_pruss_uio(struct uio_pruss_pdata *config)
+{
+	da8xx_pruss_uio_dev.dev.platform_data = config;
+	return platform_device_register(&da8xx_pruss_uio_dev);
+}
+
 static const struct display_panel disp_panel = {
 	QVGA,
 	16,
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index c9ee723..5320e12 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -25,6 +25,7 @@
 #include <linux/platform_data/mmc-davinci.h>
 #include <linux/platform_data/usb-davinci.h>
 #include <linux/platform_data/spi-davinci.h>
+#include <linux/platform_data/uio_pruss.h>
 
 extern void __iomem *da8xx_syscfg0_base;
 extern void __iomem *da8xx_syscfg1_base;
@@ -69,6 +70,7 @@ extern unsigned int da850_max_speed;
 #define DA8XX_AEMIF_CS3_BASE	0x62000000
 #define DA8XX_AEMIF_CTL_BASE	0x68000000
 #define DA8XX_ARM_RAM_BASE	0xffff0000
+#define DA8XX_SHARED_RAM_BASE	0x80000000
 
 void __init da830_init(void);
 void __init da850_init(void);
@@ -82,6 +84,7 @@ int da8xx_register_watchdog(void);
 int da8xx_register_usb20(unsigned mA, unsigned potpgt);
 int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
 int da8xx_register_emac(void);
+int da8xx_register_pruss_uio(struct uio_pruss_pdata *config);
 int da8xx_register_lcdc(struct da8xx_lcdc_platform_data *pdata);
 int da8xx_register_mmcsd0(struct davinci_mmc_config *config);
 int da850_register_mmcsd1(struct davinci_mmc_config *config);
-- 
1.7.9.5

[PATCH v2 6/7] ARM: omap: add DT support for deasserting hardware reset lines

[Matt Porter]

This optional binding extension allows specification of a hwmod
and associate hardware reset line which should be deasserted for
the device to be functional.

The implementation works for reference as to the problem that
exists for utilizing uio_pruss on AM33xx but is suboptimal. The
problem is that this deassertion occurs before clocks are enabled
and we are warned that the hard reset failed. Ideally the list of
rst lines requested to be deasserted would be cached and used within
the hwmod enable sequencing (instead of it just returning if any
hardware reset line is asserted).

Signed-off-by: Matt Porter <mporter@ti.com>
---
 .../devicetree/bindings/arm/omap/omap.txt          |    2 ++
 arch/arm/plat-omap/omap_device.c                   |   25 ++++++++++++++++++--
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index d0051a7..3133a4b 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -21,6 +21,8 @@ Required properties:
 Optional properties:
 - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
   during suspend.
+- ti,deassert-hard-reset: list of hwmod and hardware reset line name pairs
+  (ascii strings) to be deasserted upon device instantiation.
 
 
 Example:
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d5f617c..d1ae68c 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -330,8 +330,8 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
 	struct omap_device *od;
 	struct omap_hwmod *oh;
 	struct device_node *node = pdev->dev.of_node;
-	const char *oh_name;
-	int oh_cnt, i, ret = 0;
+	const char *oh_name, *rst_name;
+	int oh_cnt, dstr_cnt, i, ret = 0;
 
 	oh_cnt = of_property_count_strings(node, "ti,hwmods");
 	if (!oh_cnt || IS_ERR_VALUE(oh_cnt)) {
@@ -376,6 +376,27 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
 	if (of_get_property(node, "ti,no_idle_on_suspend", NULL))
 		omap_device_disable_idle_on_suspend(pdev);
 
+	dstr_cnt =
+		of_property_count_strings(node, "ti,deassert-hard-reset");
+	if (dstr_cnt > 0) {
+		for (i = 0; i < dstr_cnt; i += 2) {
+			of_property_read_string_index(
+				node, "ti,deassert-hard-reset", i,
+				&oh_name);
+			of_property_read_string_index(
+				node, "ti,deassert-hard-reset", i+1,
+				&rst_name);
+			oh = omap_hwmod_lookup(oh_name);
+			if (!oh) {
+				dev_warn(&pdev->dev,
+				"Cannot parse deassert property for '%s'\n",
+				oh_name);
+				break;
+			}
+			omap_hwmod_deassert_hardreset(oh, rst_name);
+		}
+	}
+
 	pdev->dev.pm_domain = &omap_device_pm_domain;
 
 odbfd_exit1:
-- 
1.7.9.5

[PATCH v2 7/7] ARM: dts: AM33xx PRUSS support

[Matt Porter]

Adds a pruss node and an example of use on Beaglebone.

Signed-off-by: Matt Porter <mporter@ti.com>
---
 arch/arm/boot/dts/am335x-bone.dts |    4 ++++
 arch/arm/boot/dts/am33xx.dtsi     |   11 +++++++++++
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..9e070c2 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -78,3 +78,7 @@
 		};
 	};
 };
+
+&pruss {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..399feb3 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,16 @@
 			interrupt-parent = <&intc>;
 			interrupts = <91>;
 		};
+
+		pruss: pruss@4a300000 {
+			compatible = "ti,pruss-v2";
+			ti,hwmods = "pruss";
+			ti,deassert-hard-reset = "pruss", "pruss";
+			reg = <0x4a300000 0x080000>;
+			ti,pintc-offset = <0x20000>;
+			interrupt-parent = <&intc>;
+			interrupts = <20 21 22 23 24 25 26 27>;
+			status = "disabled";
+		};
 	};
 };
-- 
1.7.9.5

Re: [PATCH v2 0/7] uio_pruss cleanup and platform support

[Paul Walmsley]

cc Omar

Hi Matt

On Fri, 28 Sep 2012, Matt Porter wrote:

> The AM33xx support requires some help in hwmod due to the following
> comment in arch/arm/mach-omap2/omap_hwmod.c:
> 	/*
> 	 * If an IP block contains HW reset lines and any of them are
> 	 * asserted, we let integration code associated with that
> 	 * block handle the enable.  We've received very little
> 	 * information on what those driver authors need, and until
> 	 * detailed information is provided and the driver code is
> 	 * posted to the public lists, this is probably the best we
> 	 * can do.
> 	 */
> 
> The approach to deal with the hardware reset (for at least the pruss
> hwmod) was to add a generic omap property to properly define this
> hardware. The implementation simply deasserts any rst lines that
> are called out in the property when the omap_device is
> instantiated. This is not the ideal implementation as the sequence is
> a bit wrong for pruss since the busy check during the hard reset
> will fail, even though it fails in a benign manner. Ideally, we would
> want the implementation to observe the ti,deassert-hard-reset property
> and use that in omap_hwmod.c:_enable() *after* the module is unidled
> and the clocks active. However, this is actually functional for purposes
> of getting the uio_pruss driver up and running.

Could you please sync with Omar on the hard reset handling?  He posted 
some patches that change the hard reset code.  Perhaps you can align on an 
approach with him?

A few general comments: if some new per-IP block flag is needed to control 
this, the best place for it right now would be the hwmod data in 
arch/arm/mach-omap2/omap_hwmod_*_data.c, rather than DT.  At some point 
soon, the hard reset handling will be split between a PRM driver and some 
hwmod bus driver, and it seems best to deal with the DT binding question 
at that time.  That way we don't wind up with a legacy binding that has to 
be supported over the long term.


- Paul

Re: [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Sekhar Nori]

Hi Matt,

On 9/29/2012 1:07 AM, Matt Porter wrote:
> L3RAM (shared SRAM) is needed for use by several drivers.
> This creates a genalloc pool and a hook for the platform code
> to provide the struct gen_pool * in platform data.
> 
> Signed-off-by: Matt Porter <mporter@ti.com>

I am not sure if any of the DaVinci devices have a need to allocate from
*both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
if there is much point in trying to allocate from there.

Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
allocation on DA850 makes sense for your case? If yes, can you repost
with Ben's patch included in your series instead of this patch? I would
prefer that over creating a new pool for shared RAM.

Thanks,
Sekhar

[1] https://patchwork.kernel.org/patch/840552/

Thanks,
Sekhar

Re: [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Matt Porter]

On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> Hi Matt,
> 
> On 9/29/2012 1:07 AM, Matt Porter wrote:
> > L3RAM (shared SRAM) is needed for use by several drivers.
> > This creates a genalloc pool and a hook for the platform code
> > to provide the struct gen_pool * in platform data.
> > 
> > Signed-off-by: Matt Porter <mporter@ti.com>
> 
> I am not sure if any of the DaVinci devices have a need to allocate from
> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
> if there is much point in trying to allocate from there.
> 
> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
> allocation on DA850 makes sense for your case? If yes, can you repost
> with Ben's patch included in your series instead of this patch? I would
> prefer that over creating a new pool for shared RAM.

Hrm, I did look at Ben's earlier patch. The reason I added a separate
pool mostly was so I didn't have to touch the PM code at all. That can
continue using the private SRAM API with the ARM RAM as it is now. The
idea here was to allow that to be separate since no other bus masters
can access the ARM RAM anyway and do something that didn't require
regression testing PM. Also, I figured there's really no reason to use
even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
and working fine for that use case.

The other thing is that Ben's patch needs to be rewritten to at least
have the hook I added so we can provide the gen_pool in platform data.
If you prefer this path still, I can add the needed hook on top of his
original patch. Ultimately, I only *need* genalloc support for the
shared sram so I can remove the private SRAM API from uio_pruss...so I'm
happy with any way to get at it.

Oh, and to be honest...it's not just for uio_pruss, but also to cleanly
remove the private SRAM API usage from the davinci ASoC driver too.

Thanks,
Matt

Re: [PATCH v2 0/7] uio_pruss cleanup and platform support

[Matt Porter]

On Sat, Sep 29, 2012 at 06:34:54PM +0000, Paul Walmsley wrote:
> 
> cc Omar
> 
> Hi Matt
> 
> On Fri, 28 Sep 2012, Matt Porter wrote:
> 
> > The AM33xx support requires some help in hwmod due to the following
> > comment in arch/arm/mach-omap2/omap_hwmod.c:
> > 	/*
> > 	 * If an IP block contains HW reset lines and any of them are
> > 	 * asserted, we let integration code associated with that
> > 	 * block handle the enable.  We've received very little
> > 	 * information on what those driver authors need, and until
> > 	 * detailed information is provided and the driver code is
> > 	 * posted to the public lists, this is probably the best we
> > 	 * can do.
> > 	 */
> > 
> > The approach to deal with the hardware reset (for at least the pruss
> > hwmod) was to add a generic omap property to properly define this
> > hardware. The implementation simply deasserts any rst lines that
> > are called out in the property when the omap_device is
> > instantiated. This is not the ideal implementation as the sequence is
> > a bit wrong for pruss since the busy check during the hard reset
> > will fail, even though it fails in a benign manner. Ideally, we would
> > want the implementation to observe the ti,deassert-hard-reset property
> > and use that in omap_hwmod.c:_enable() *after* the module is unidled
> > and the clocks active. However, this is actually functional for purposes
> > of getting the uio_pruss driver up and running.
> 
> Could you please sync with Omar on the hard reset handling?  He posted 
> some patches that change the hard reset code.  Perhaps you can align on an 
> approach with him?

Ok, yes, I looked over his series now and it goes some way to solving
the problem on PRUSS. My only concern is that the approach of loading up
function pointers in pdata for the assert/deassert calls gets a bit ugly on a
DT-only platform like AM33xx. I'll work with Omar on that.
 
> A few general comments: if some new per-IP block flag is needed to control 
> this, the best place for it right now would be the hwmod data in 
> arch/arm/mach-omap2/omap_hwmod_*_data.c, rather than DT.  At some point 
> soon, the hard reset handling will be split between a PRM driver and some 
> hwmod bus driver, and it seems best to deal with the DT binding question 
> at that time.  That way we don't wind up with a legacy binding that has to 
> be supported over the long term.

Ok, make sense.

Thanks,
Matt

Re: [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Ben Gardiner]

On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter <mporter@ti.com> wrote:
> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
>> Hi Matt,
>>
>> On 9/29/2012 1:07 AM, Matt Porter wrote:
>> > L3RAM (shared SRAM) is needed for use by several drivers.
>> > This creates a genalloc pool and a hook for the platform code
>> > to provide the struct gen_pool * in platform data.
>> >
>> > Signed-off-by: Matt Porter <mporter@ti.com>
>>
>> I am not sure if any of the DaVinci devices have a need to allocate from
>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
>> if there is much point in trying to allocate from there.
>>
>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
>> allocation on DA850 makes sense for your case? If yes, can you repost
>> with Ben's patch included in your series instead of this patch? I would
>> prefer that over creating a new pool for shared RAM.
>
> Hrm, I did look at Ben's earlier patch. The reason I added a separate
> pool mostly was so I didn't have to touch the PM code at all. That can
> continue using the private SRAM API with the ARM RAM as it is now. The
> idea here was to allow that to be separate since no other bus masters
> can access the ARM RAM anyway and do something that didn't require
> regression testing PM. Also, I figured there's really no reason to use
> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> and working fine for that use case.
> [...]

I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as
you said, Sekhar) in any fashion is preferable to moving suspend
support into shared RAM. There is more of it (128K on L138) but also
more pressure on allocations there since there are more clients.

I appreciate that you are trying to preserve prior efforts in
attempted merging of SRAM support -- thank you for that; however, that
patch [1] was just an import of Subashish Ghosh's patch [2]  -- I
chose _that_ implementation option then mainly because I imagined it
would be the least risky to get accepted upstream and not because of
any particular technical merits.

Best Regards,
Ben Gardiner

[1] https://patchwork.kernel.org/patch/840552/
[2] https://patchwork.kernel.org/patch/549351/

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

Re: [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Matt Porter]

On Mon, Oct 01, 2012 at 08:32:42AM -0400, Matt Porter wrote:
> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> > Hi Matt,
> > 
> > On 9/29/2012 1:07 AM, Matt Porter wrote:
> > > L3RAM (shared SRAM) is needed for use by several drivers.
> > > This creates a genalloc pool and a hook for the platform code
> > > to provide the struct gen_pool * in platform data.
> > > 
> > > Signed-off-by: Matt Porter <mporter@ti.com>
> > 
> > I am not sure if any of the DaVinci devices have a need to allocate from
> > *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
> > devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
> > if there is much point in trying to allocate from there.
> > 
> > Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
> > allocation on DA850 makes sense for your case? If yes, can you repost
> > with Ben's patch included in your series instead of this patch? I would
> > prefer that over creating a new pool for shared RAM.
> 
> Hrm, I did look at Ben's earlier patch. The reason I added a separate
> pool mostly was so I didn't have to touch the PM code at all. That can
> continue using the private SRAM API with the ARM RAM as it is now. The
> idea here was to allow that to be separate since no other bus masters
> can access the ARM RAM anyway and do something that didn't require
> regression testing PM. Also, I figured there's really no reason to use
> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> and working fine for that use case.
> 
> The other thing is that Ben's patch needs to be rewritten to at least
> have the hook I added so we can provide the gen_pool in platform data.
> If you prefer this path still, I can add the needed hook on top of his
> original patch. Ultimately, I only *need* genalloc support for the
> shared sram so I can remove the private SRAM API from uio_pruss...so I'm
> happy with any way to get at it.
> 
> Oh, and to be honest...it's not just for uio_pruss, but also to cleanly
> remove the private SRAM API usage from the davinci ASoC driver too.

[and replying to myself :)]

Looking at the older parts (DM355/365/DM64xx) in more detail now, I see
that to get rid of SRAM API in davinci ASoC, we'll have a similar hook
to get the local ARM RAM gen_pool pointer necessary to support ping-pong
to that pool since that's able to be accessed from EDMA on those parts.
Ultimately, the approach is the same, it's just a matter of if we want
to fully leverage both SRAM pools on DA850 and friends.

-Matt

Re: [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Sekhar Nori]

On 10/1/2012 6:02 PM, Matt Porter wrote:
> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
>> Hi Matt,
>>
>> On 9/29/2012 1:07 AM, Matt Porter wrote:
>>> L3RAM (shared SRAM) is needed for use by several drivers.
>>> This creates a genalloc pool and a hook for the platform code
>>> to provide the struct gen_pool * in platform data.
>>>
>>> Signed-off-by: Matt Porter <mporter@ti.com>
>>
>> I am not sure if any of the DaVinci devices have a need to allocate from
>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
>> if there is much point in trying to allocate from there.
>>
>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
>> allocation on DA850 makes sense for your case? If yes, can you repost
>> with Ben's patch included in your series instead of this patch? I would
>> prefer that over creating a new pool for shared RAM.
> 
> Hrm, I did look at Ben's earlier patch. The reason I added a separate
> pool mostly was so I didn't have to touch the PM code at all. That can
> continue using the private SRAM API with the ARM RAM as it is now. The

But you dont have to touch the PM code. PM code can continue using SRAM
API. I have verified in the past that PM can work using shared RAM.

> idea here was to allow that to be separate since no other bus masters
> can access the ARM RAM anyway and do something that didn't require
> regression testing PM. Also, I figured there's really no reason to use
> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> and working fine for that use case.

I see no reason why PM would break with shared RAM. I have not even seen
reports of shared RAM being short of size so we need to save space by
having PM code in ARM RAM. I can test the changes before the code is
committed and it will get tested in linux-next as well.

> The other thing is that Ben's patch needs to be rewritten to at least
> have the hook I added so we can provide the gen_pool in platform data.
> If you prefer this path still, I can add the needed hook on top of his
> original patch. Ultimately, I only *need* genalloc support for the
> shared sram so I can remove the private SRAM API from uio_pruss...so I'm
> happy with any way to get at it.

Right, I prefer just adding the hook so that genalloc can be used along
with SRAM API.

> Oh, and to be honest...it's not just for uio_pruss, but also to cleanly
> remove the private SRAM API usage from the davinci ASoC driver too.

Audio can use the shared RAM too. And once all users of the SRAM API are
gone, only the hook to help pass the gen_pool as platform data needs to
remain.

Thanks,
Sekhar

Re: [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Sekhar Nori]

On 10/1/2012 7:20 PM, Ben Gardiner wrote:
> On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter <mporter@ti.com> wrote:
>> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
>>> Hi Matt,
>>>
>>> On 9/29/2012 1:07 AM, Matt Porter wrote:
>>>> L3RAM (shared SRAM) is needed for use by several drivers.
>>>> This creates a genalloc pool and a hook for the platform code
>>>> to provide the struct gen_pool * in platform data.
>>>>
>>>> Signed-off-by: Matt Porter <mporter@ti.com>
>>>
>>> I am not sure if any of the DaVinci devices have a need to allocate from
>>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
>>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
>>> if there is much point in trying to allocate from there.
>>>
>>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
>>> allocation on DA850 makes sense for your case? If yes, can you repost
>>> with Ben's patch included in your series instead of this patch? I would
>>> prefer that over creating a new pool for shared RAM.
>>
>> Hrm, I did look at Ben's earlier patch. The reason I added a separate
>> pool mostly was so I didn't have to touch the PM code at all. That can
>> continue using the private SRAM API with the ARM RAM as it is now. The
>> idea here was to allow that to be separate since no other bus masters
>> can access the ARM RAM anyway and do something that didn't require
>> regression testing PM. Also, I figured there's really no reason to use
>> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
>> and working fine for that use case.
>> [...]
> 
> I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as
> you said, Sekhar) in any fashion is preferable to moving suspend
> support into shared RAM. There is more of it (128K on L138) but also
> more pressure on allocations there since there are more clients.

There is where I would like to see more information on who the potential
clients are. Even if DSP takes away 64K of the shared RAM on OMAP-L138,
there should be more than enough for PM, Audio and PRU. I haven't
checked the PM code size lately but it should be fairly small and I can
check the actual number if that helps. So, adding a new pool just to
save on those bytes doesn't sound like helping a lot.

> I appreciate that you are trying to preserve prior efforts in
> attempted merging of SRAM support -- thank you for that; however, that
> patch [1] was just an import of Subashish Ghosh's patch [2]  -- I
> chose _that_ implementation option then mainly because I imagined it
> would be the least risky to get accepted upstream and not because of
> any particular technical merits.

Its not a question of prior effort since Matt has already put in the
effort too. I am yet unconvinced that we need to add support to manage
two blocks of SoC internal RAM on DA850 in the kernel today. That's all.

Thanks,
Sekhar

Re: [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Ben Gardiner]

On Tue, Oct 2, 2012 at 7:13 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> On 10/1/2012 7:20 PM, Ben Gardiner wrote:
>> On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter <mporter@ti.com> wrote:
>>> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
>>>> Hi Matt,
>>>>
>>>> On 9/29/2012 1:07 AM, Matt Porter wrote:
>>>>> L3RAM (shared SRAM) is needed for use by several drivers.
>>>>> This creates a genalloc pool and a hook for the platform code
>>>>> to provide the struct gen_pool * in platform data.
>>>>>
>>>>> Signed-off-by: Matt Porter <mporter@ti.com>
>>>>
>>>> I am not sure if any of the DaVinci devices have a need to allocate from
>>>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
>>>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
>>>> if there is much point in trying to allocate from there.
>>>>
>>>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
>>>> allocation on DA850 makes sense for your case? If yes, can you repost
>>>> with Ben's patch included in your series instead of this patch? I would
>>>> prefer that over creating a new pool for shared RAM.
>>>
>>> Hrm, I did look at Ben's earlier patch. The reason I added a separate
>>> pool mostly was so I didn't have to touch the PM code at all. That can
>>> continue using the private SRAM API with the ARM RAM as it is now. The
>>> idea here was to allow that to be separate since no other bus masters
>>> can access the ARM RAM anyway and do something that didn't require
>>> regression testing PM. Also, I figured there's really no reason to use
>>> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
>>> and working fine for that use case.
>>> [...]
>>
>> I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as
>> you said, Sekhar) in any fashion is preferable to moving suspend
>> support into shared RAM. There is more of it (128K on L138) but also
>> more pressure on allocations there since there are more clients.
>
> There is where I would like to see more information on who the potential
> clients are. Even if DSP takes away 64K of the shared RAM on OMAP-L138,
> there should be more than enough for PM, Audio and PRU. I haven't
> checked the PM code size lately but it should be fairly small and I can
> check the actual number if that helps. So, adding a new pool just to
> save on those bytes doesn't sound like helping a lot.

Good points. I suppose that the list would decrease also on L138 if
davinci-pcm ping-pong buffers were removed from SRAM.

>> I appreciate that you are trying to preserve prior efforts in
>> attempted merging of SRAM support -- thank you for that; however, that
>> patch [1] was just an import of Subashish Ghosh's patch [2]  -- I
>> chose _that_ implementation option then mainly because I imagined it
>> would be the least risky to get accepted upstream and not because of
>> any particular technical merits.
>
> Its not a question of prior effort since Matt has already put in the
> effort too. I am yet unconvinced that we need to add support to manage
> two blocks of SoC internal RAM on DA850 in the kernel today. That's all.

Understood. Thank you, Sekhar.

Best Regards,
Ben Gardiner

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

Re: [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Matt Porter]

On Tue, Oct 02, 2012 at 03:32:55PM +0530, Sekhar Nori wrote:
> On 10/1/2012 6:02 PM, Matt Porter wrote:
> > On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> >> Hi Matt,
> >>
> >> On 9/29/2012 1:07 AM, Matt Porter wrote:
> >>> L3RAM (shared SRAM) is needed for use by several drivers.
> >>> This creates a genalloc pool and a hook for the platform code
> >>> to provide the struct gen_pool * in platform data.
> >>>
> >>> Signed-off-by: Matt Porter <mporter@ti.com>
> >>
> >> I am not sure if any of the DaVinci devices have a need to allocate from
> >> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
> >> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
> >> if there is much point in trying to allocate from there.
> >>
> >> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
> >> allocation on DA850 makes sense for your case? If yes, can you repost
> >> with Ben's patch included in your series instead of this patch? I would
> >> prefer that over creating a new pool for shared RAM.
> > 
> > Hrm, I did look at Ben's earlier patch. The reason I added a separate
> > pool mostly was so I didn't have to touch the PM code at all. That can
> > continue using the private SRAM API with the ARM RAM as it is now. The
> 
> But you dont have to touch the PM code. PM code can continue using SRAM
> API. I have verified in the past that PM can work using shared RAM.
> 
> > idea here was to allow that to be separate since no other bus masters
> > can access the ARM RAM anyway and do something that didn't require
> > regression testing PM. Also, I figured there's really no reason to use
> > even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> > and working fine for that use case.
> 
> I see no reason why PM would break with shared RAM. I have not even seen
> reports of shared RAM being short of size so we need to save space by
> having PM code in ARM RAM. I can test the changes before the code is
> committed and it will get tested in linux-next as well.

Ok, sounds good to me.

> > The other thing is that Ben's patch needs to be rewritten to at least
> > have the hook I added so we can provide the gen_pool in platform data.
> > If you prefer this path still, I can add the needed hook on top of his
> > original patch. Ultimately, I only *need* genalloc support for the
> > shared sram so I can remove the private SRAM API from uio_pruss...so I'm
> > happy with any way to get at it.
> 
> Right, I prefer just adding the hook so that genalloc can be used along
> with SRAM API.
 
Ok.

> > Oh, and to be honest...it's not just for uio_pruss, but also to cleanly
> > remove the private SRAM API usage from the davinci ASoC driver too.
> 
> Audio can use the shared RAM too. And once all users of the SRAM API are
> gone, only the hook to help pass the gen_pool as platform data needs to
> remain.

Right, I think we are on the same page now. I'll post an update to Ben's
original patch with required gen_pool hook for pdata use.

I noticed the beginning of DT support for davinci and the DT-based
genalloc driver, https://patchwork.kernel.org/patch/1421961/, fits
into that well.

-Matt

Re: [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

[Matt Porter]

On Tue, Oct 02, 2012 at 04:43:59PM +0530, Sekhar Nori wrote:
> On 10/1/2012 7:20 PM, Ben Gardiner wrote:
> > On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter <mporter@ti.com> wrote:
> >> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> >>> Hi Matt,
> >>>
> >>> On 9/29/2012 1:07 AM, Matt Porter wrote:
> >>>> L3RAM (shared SRAM) is needed for use by several drivers.
> >>>> This creates a genalloc pool and a hook for the platform code
> >>>> to provide the struct gen_pool * in platform data.
> >>>>
> >>>> Signed-off-by: Matt Porter <mporter@ti.com>
> >>>
> >>> I am not sure if any of the DaVinci devices have a need to allocate from
> >>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
> >>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
> >>> if there is much point in trying to allocate from there.
> >>>
> >>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
> >>> allocation on DA850 makes sense for your case? If yes, can you repost
> >>> with Ben's patch included in your series instead of this patch? I would
> >>> prefer that over creating a new pool for shared RAM.
> >>
> >> Hrm, I did look at Ben's earlier patch. The reason I added a separate
> >> pool mostly was so I didn't have to touch the PM code at all. That can
> >> continue using the private SRAM API with the ARM RAM as it is now. The
> >> idea here was to allow that to be separate since no other bus masters
> >> can access the ARM RAM anyway and do something that didn't require
> >> regression testing PM. Also, I figured there's really no reason to use
> >> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> >> and working fine for that use case.
> >> [...]
> > 
> > I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as
> > you said, Sekhar) in any fashion is preferable to moving suspend
> > support into shared RAM. There is more of it (128K on L138) but also
> > more pressure on allocations there since there are more clients.
> 
> There is where I would like to see more information on who the potential
> clients are. Even if DSP takes away 64K of the shared RAM on OMAP-L138,
> there should be more than enough for PM, Audio and PRU. I haven't
> checked the PM code size lately but it should be fairly small and I can
> check the actual number if that helps. So, adding a new pool just to
> save on those bytes doesn't sound like helping a lot.

The only wildcard is PRU usage due to the small per-PRU memory on PRUss
v1...though no sense in speculating further until somebody demonstrates a
need.

> > I appreciate that you are trying to preserve prior efforts in
> > attempted merging of SRAM support -- thank you for that; however, that
> > patch [1] was just an import of Subashish Ghosh's patch [2]  -- I
> > chose _that_ implementation option then mainly because I imagined it
> > would be the least risky to get accepted upstream and not because of
> > any particular technical merits.
> 
> Its not a question of prior effort since Matt has already put in the
> effort too. I am yet unconvinced that we need to add support to manage
> two blocks of SoC internal RAM on DA850 in the kernel today. That's all.

Yeah, I've come to agree with that. If somebody ends up needing that
extra 8K of local ram on L138 then they can add support.

-Matt

Re: [PATCH v2 0/7] uio_pruss cleanup and platform support

[Matt Porter]

On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote:
> Changes since v1:
> 	- Replaced uio_pruss private SRAM API use with genalloc
> 	- Added DA850 platform device and clock support
> 	- Added DA850 L3 RAM gen_pool support
> 	- Split out DT binding
> 
> This series enables uio_pruss on both DA850 and AM33xx. The driver
> previously was not enabled by any platform and the private SRAM API
> was accessing an invalid SRAM bank for use on DA850. For AM33xx,
> DT, pinctrl, and runtime PM support are added since AM33xx only
> boots via DT.

I'm dropping AM33xx/OMAP support from v3 for this series since the
focus has turned to fixing Davinci SRAM to provide genalloc support
and the associated use of that in the driver.

I'll have a separate series with AM33xx support since dealing cleanly
with external resets on OMAP is a bigger issue.

-Matt

RE: [PATCH v2 0/7] uio_pruss cleanup and platform support

[Hebbar, Gururaja]

Matt,

On Wed, Oct 03, 2012 at 20:30:58, Porter, Matt wrote:
> On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote:
> > Changes since v1:
> > 	- Replaced uio_pruss private SRAM API use with genalloc
> > 	- Added DA850 platform device and clock support
> > 	- Added DA850 L3 RAM gen_pool support
> > 	- Split out DT binding
> > 
> > This series enables uio_pruss on both DA850 and AM33xx. The driver
> > previously was not enabled by any platform and the private SRAM API
> > was accessing an invalid SRAM bank for use on DA850. For AM33xx,
> > DT, pinctrl, and runtime PM support are added since AM33xx only
> > boots via DT.
> 
> I'm dropping AM33xx/OMAP support from v3 for this series 

Just for my clarification, I believe you will be taking up AM33xx/OMAP 
SRAM support later once you have completed supporting DaVinci. Right?

> since the
> focus has turned to fixing Davinci SRAM to provide genalloc support
> and the associated use of that in the driver.
> 
> I'll have a separate series with AM33xx support since dealing cleanly
> with external resets on OMAP is a bigger issue.
> 
> -Matt
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 


Regards, 
Gururaja

Re: [PATCH v2 0/7] uio_pruss cleanup and platform support

[Matt Porter]

On Fri, Oct 05, 2012 at 04:43:56AM +0000, Hebbar, Gururaja wrote:
> Matt,
> 
> On Wed, Oct 03, 2012 at 20:30:58, Porter, Matt wrote:
> > On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote:
> > > Changes since v1:
> > > 	- Replaced uio_pruss private SRAM API use with genalloc
> > > 	- Added DA850 platform device and clock support
> > > 	- Added DA850 L3 RAM gen_pool support
> > > 	- Split out DT binding
> > > 
> > > This series enables uio_pruss on both DA850 and AM33xx. The driver
> > > previously was not enabled by any platform and the private SRAM API
> > > was accessing an invalid SRAM bank for use on DA850. For AM33xx,
> > > DT, pinctrl, and runtime PM support are added since AM33xx only
> > > boots via DT.
> > 
> > I'm dropping AM33xx/OMAP support from v3 for this series 
> 
> Just for my clarification, I believe you will be taking up AM33xx/OMAP 
> SRAM support later once you have completed supporting DaVinci. Right?

There's no SRAM support for uio_pruss to be handled for AM33xx, but I
will be posting a separate series with the DT portion and some alternate
hard reset handling implementation. I find the private OMAP reset api to
be very ugly but we might have to go with that for now. I didn't want
the OMAP hard reset portion to hold up the more important part of this
cleanup.

-Matt

> > since the
> > focus has turned to fixing Davinci SRAM to provide genalloc support
> > and the associated use of that in the driver.
> > 
> > I'll have a separate series with AM33xx support since dealing cleanly
> > with external resets on OMAP is a bigger issue.
> > 
> > -Matt
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > Davinci-linux-open-source@linux.davincidsp.com
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> > 
> 
> 
> Regards, 
> Gururaja
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

RE: [PATCH v2 0/7] uio_pruss cleanup and platform support

[Hebbar, Gururaja]

On Sat, Oct 06, 2012 at 02:58:26, Porter, Matt wrote:
> On Fri, Oct 05, 2012 at 04:43:56AM +0000, Hebbar, Gururaja wrote:
> > Matt,
> > 
> > On Wed, Oct 03, 2012 at 20:30:58, Porter, Matt wrote:
> > > On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote:
> > > > Changes since v1:
> > > > 	- Replaced uio_pruss private SRAM API use with genalloc
> > > > 	- Added DA850 platform device and clock support
> > > > 	- Added DA850 L3 RAM gen_pool support
> > > > 	- Split out DT binding
> > > > 
> > > > This series enables uio_pruss on both DA850 and AM33xx. The driver
> > > > previously was not enabled by any platform and the private SRAM API
> > > > was accessing an invalid SRAM bank for use on DA850. For AM33xx,
> > > > DT, pinctrl, and runtime PM support are added since AM33xx only
> > > > boots via DT.
> > > 
> > > I'm dropping AM33xx/OMAP support from v3 for this series 
> > 
> > Just for my clarification, I believe you will be taking up AM33xx/OMAP 
> > SRAM support later once you have completed supporting DaVinci. Right?
> 
> There's no SRAM support for uio_pruss to be handled for AM33xx, 

Sorry for not being clearer.

I was referring to adding SRAM support for McASP module on AM335x platform.


> but I
> will be posting a separate series with the DT portion and some alternate
> hard reset handling implementation. I find the private OMAP reset api to
> be very ugly but we might have to go with that for now. I didn't want
> the OMAP hard reset portion to hold up the more important part of this
> cleanup.
> 
> -Matt
> 
> > > since the
> > > focus has turned to fixing Davinci SRAM to provide genalloc support
> > > and the associated use of that in the driver.
> > > 
> > > I'll have a separate series with AM33xx support since dealing cleanly
> > > with external resets on OMAP is a bigger issue.
> > > 
> > > -Matt
> > > _______________________________________________
> > > Davinci-linux-open-source mailing list
> > > Davinci-linux-open-source@linux.davincidsp.com
> > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> > > 
> > 
> > 
> > Regards, 
> > Gururaja
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > Davinci-linux-open-source@linux.davincidsp.com
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 


Regards, 
Gururaja

Re: [PATCH v2 0/7] uio_pruss cleanup and platform support

[Matwey V. Kornilov]

2012-10-03 19:00 GMT+04:00 Matt Porter <mporter@ti.com>:
> On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote:
>> Changes since v1:
>>       - Replaced uio_pruss private SRAM API use with genalloc
>>       - Added DA850 platform device and clock support
>>       - Added DA850 L3 RAM gen_pool support
>>       - Split out DT binding
>>
>> This series enables uio_pruss on both DA850 and AM33xx. The driver
>> previously was not enabled by any platform and the private SRAM API
>> was accessing an invalid SRAM bank for use on DA850. For AM33xx,
>> DT, pinctrl, and runtime PM support are added since AM33xx only
>> boots via DT.
>
> I'm dropping AM33xx/OMAP support from v3 for this series since the
> focus has turned to fixing Davinci SRAM to provide genalloc support
> and the associated use of that in the driver.
>
> I'll have a separate series with AM33xx support since dealing cleanly
> with external resets on OMAP is a bigger issue.

Hello Matt,

Any news on AM33xx support here?

I would even try to implement it by myself, but at the moment stuff
about external resets is too complicated to me, I even can not
understand where problem is. Fetching config from DT instead of
platform in pruss_probe seems to be trivial.

>
> -Matt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>



-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2207@jabber.ru