[PATCH v5 0/7] arm: pmu: support pmu/perf on OMAP4

[PATCH v5 0/7] arm: pmu: support pmu/perf on OMAP4

[ming.lei at canonical.com]

Hi,

This patches support pmu irq routed from CTI, such as implemented
on OMAP4:

	- introduce some CTI helpers and registers' definition
	- introduce .enable_irq and .disable_irq into platform_data,
	so perf irq handler can handle irq correctly if it is routed
	from CTI on OMAP4
	- configure CTI on OMAP4 so that perf can work on OMAP4

The patches have been tested Ok on Pandaboard, and 'perf' does work
after applying them.

v5:
	- build pmu device from hwmod
	- support runtime pm

v4:
	- some minor fix(add __iomem, comments, checkpatch warning...)

v3:
	- fix typo of patch 2/3 title, pointed by Will
	- move cti addresses to plat/omap44xx.h, suggested by
	Santosh Shilimkar

v2:
	- move cti related code out of perf_event.c
	- introduce .enable_irq and .disable_irq into platform_data
	as suggested by Will.

v1:
	- rebase the patch set against 2.6.38-rc6-next-20110301, fix
	conflicts, which is pointed out by Will Deacon

 arch/arm/include/asm/cti.h                 |  179 ++++++++++++++++++++++++++++
 arch/arm/include/asm/pmu.h                 |   15 ++-
 arch/arm/kernel/perf_event.c               |   20 +++-
 arch/arm/kernel/pmu.c                      |   12 ++-
 arch/arm/mach-omap2/devices.c              |  126 +++++++++++++++++++-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   26 ++++
 arch/arm/plat-omap/include/plat/omap44xx.h |    3 +
 7 files changed, 367 insertions(+), 14 deletions(-)

thanks,
--
Lei Ming

[PATCH v5 1/7] arm: introduce cross trigger interface helpers

[ming.lei at canonical.com]

From: Ming Lei <ming.lei@canonical.com>

OMAP4 uses cross trigger interface(CTI) to route
performance monitor irq to GIC, so introduce cti
helpers to make access for cti easily.

Acked-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/include/asm/cti.h |  179 ++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 179 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/cti.h

diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
new file mode 100644
index 0000000..a0ada3e
--- /dev/null
+++ b/arch/arm/include/asm/cti.h
@@ -0,0 +1,179 @@
+#ifndef __ASMARM_CTI_H
+#define __ASMARM_CTI_H
+
+#include	<asm/io.h>
+
+/* The registers' definition is from section 3.2 of
+ * Embedded Cross Trigger Revision: r0p0
+ */
+#define		CTICONTROL		0x000
+#define		CTISTATUS		0x004
+#define		CTILOCK			0x008
+#define		CTIPROTECTION		0x00C
+#define		CTIINTACK		0x010
+#define		CTIAPPSET		0x014
+#define		CTIAPPCLEAR		0x018
+#define		CTIAPPPULSE		0x01c
+#define		CTIINEN			0x020
+#define		CTIOUTEN		0x0A0
+#define		CTITRIGINSTATUS		0x130
+#define		CTITRIGOUTSTATUS	0x134
+#define		CTICHINSTATUS		0x138
+#define		CTICHOUTSTATUS		0x13c
+#define		CTIPERIPHID0		0xFE0
+#define		CTIPERIPHID1		0xFE4
+#define		CTIPERIPHID2		0xFE8
+#define		CTIPERIPHID3		0xFEC
+#define		CTIPCELLID0		0xFF0
+#define		CTIPCELLID1		0xFF4
+#define		CTIPCELLID2		0xFF8
+#define		CTIPCELLID3		0xFFC
+
+/* The below are from section 3.6.4 of
+ * CoreSight v1.0 Architecture Specification
+ */
+#define		LOCKACCESS		0xFB0
+#define		LOCKSTATUS		0xFB4
+
+/* write this value to LOCKACCESS will unlock the module, and
+ * other value will lock the module
+ */
+#define		LOCKCODE		0xC5ACCE55
+
+/**
+ * struct cti - cross trigger interface struct
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out_for_irq: triger out number which will cause
+ *	the @irq happen
+ *
+ * cti struct used to operate cti registers.
+ */
+struct cti {
+	void __iomem *base;
+	int irq;
+	int trig_out_for_irq;
+};
+
+/**
+ * cti_init - initialize the cti instance
+ * @cti: cti instance
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out: triger out number which will cause
+ *	the @irq happen
+ *
+ * called by machine code to pass the board dependent
+ * @base, @irq and @trig_out to cti.
+ */
+static inline void cti_init(struct cti *cti,
+	void __iomem *base, int irq, int trig_out)
+{
+	cti->base = base;
+	cti->irq  = irq;
+	cti->trig_out_for_irq = trig_out;
+}
+
+/**
+ * cti_map_trigger - use the @chan to map @trig_in to @trig_out
+ * @cti: cti instance
+ * @trig_in: trigger in number
+ * @trig_out: trigger out number
+ * @channel: channel number
+ *
+ * This function maps one trigger in of @trig_in to one trigger
+ * out of @trig_out using the channel @chan.
+ */
+static inline void cti_map_trigger(struct cti *cti,
+	int trig_in, int trig_out, int chan)
+{
+	void __iomem *base = cti->base;
+	unsigned long val;
+
+	val = __raw_readl(base + CTIINEN + trig_in * 4);
+	val |= BIT(chan);
+	__raw_writel(val, base + CTIINEN + trig_in * 4);
+
+	val = __raw_readl(base + CTIOUTEN + trig_out * 4);
+	val |= BIT(chan);
+	__raw_writel(val, base + CTIOUTEN + trig_out * 4);
+}
+
+/**
+ * cti_enable - enable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_enable(struct cti *cti)
+{
+	__raw_writel(0x1, cti->base + CTICONTROL);
+}
+
+/**
+ * cti_disable - disable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_disable(struct cti *cti)
+{
+	__raw_writel(0, cti->base + CTICONTROL);
+}
+
+/**
+ * cti_irq_ack - clear the cti irq
+ * @cti: cti instance
+ *
+ * clear the cti irq
+ */
+static inline void cti_irq_ack(struct cti *cti)
+{
+	void __iomem *base = cti->base;
+	unsigned long val;
+
+	val = __raw_readl(base + CTIINTACK);
+	val |= BIT(cti->trig_out_for_irq);
+	__raw_writel(val, base + CTIINTACK);
+}
+
+/**
+ * cti_unlock - unlock cti module
+ * @cti: cti instance
+ *
+ * unlock the cti module, or else any writes to the cti
+ * module is not allowed.
+ */
+static inline void cti_unlock(struct cti *cti)
+{
+	void __iomem *base = cti->base;
+	unsigned long val;
+
+	val = __raw_readl(base + LOCKSTATUS);
+
+	if (val & 1) {
+		val = LOCKCODE;
+		__raw_writel(val, base + LOCKACCESS);
+	}
+}
+
+/**
+ * cti_lock - lock cti module
+ * @cti: cti instance
+ *
+ * lock the cti module, so any writes to the cti
+ * module will be not allowed.
+ */
+static inline void cti_lock(struct cti *cti)
+{
+	void __iomem *base = cti->base;
+	unsigned long val;
+
+	val = __raw_readl(base + LOCKSTATUS);
+
+	if (!(val & 1)) {
+		val = ~LOCKCODE;
+		__raw_writel(val, base + LOCKACCESS);
+	}
+}
+#endif
-- 
1.7.5.4

[PATCH v5 2/7] arm: pmu: allow platform specific irq enable/disable handling

[ming.lei at canonical.com]

From: Ming Lei <ming.lei@canonical.com>

This patch introduces .enable_irq and .disable_irq into
struct arm_pmu_platdata, so platform specific irq enablement
can be handled after request_irq, and platform specific irq
disablement can be handled before free_irq.

This patch is for support of  pmu irq routed from CTI on omap4.

Acked-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/include/asm/pmu.h   |   15 ++++++++++++---
 arch/arm/kernel/perf_event.c |   15 ++++++++++++---
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index b7e82c4..3af5e39 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -22,13 +22,22 @@ enum arm_pmu_type {
 /*
  * struct arm_pmu_platdata - ARM PMU platform data
  *
- * @handle_irq: an optional handler which will be called from the interrupt and
- * passed the address of the low level handler, and can be used to implement
- * any platform specific handling before or after calling it.
+ * @handle_irq: an optional handler which will be called from the
+ *	interrupt and passed the address of the low level handler,
+ *	and can be used to implement any platform specific handling
+ *	before or after calling it.
+ * @enable_irq: an optional handler which will be called after
+ *	request_irq and be used to handle some platform specific
+ *	irq enablement
+ * @disable_irq: an optional handler which will be called before
+ *	free_irq and be used to handle some platform specific
+ *	irq disablement
  */
 struct arm_pmu_platdata {
 	irqreturn_t (*handle_irq)(int irq, void *dev,
 				  irq_handler_t pmu_handler);
+	void (*enable_irq)(int irq);
+	void (*disable_irq)(int irq);
 };
 
 #ifdef CONFIG_CPU_HAS_PMU
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 53c9c26..f367780 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -426,14 +426,18 @@ armpmu_reserve_hardware(void)
 			pr_warning("unable to request IRQ%d for ARM perf "
 				"counters\n", irq);
 			break;
-		}
+		} else if (plat && plat->enable_irq)
+			plat->enable_irq(irq);
 	}
 
 	if (err) {
 		for (i = i - 1; i >= 0; --i) {
 			irq = platform_get_irq(pmu_device, i);
-			if (irq >= 0)
+			if (irq >= 0) {
+				if (plat && plat->disable_irq)
+					plat->disable_irq(irq);
 				free_irq(irq, NULL);
+			}
 		}
 		release_pmu(ARM_PMU_DEVICE_CPU);
 		pmu_device = NULL;
@@ -446,11 +450,16 @@ static void
 armpmu_release_hardware(void)
 {
 	int i, irq;
+	struct arm_pmu_platdata *plat =
+		dev_get_platdata(&pmu_device->dev);
 
 	for (i = pmu_device->num_resources - 1; i >= 0; --i) {
 		irq = platform_get_irq(pmu_device, i);
-		if (irq >= 0)
+		if (irq >= 0) {
+			if (plat && plat->disable_irq)
+				plat->disable_irq(irq);
 			free_irq(irq, NULL);
+		}
 	}
 	armpmu->stop();
 
-- 
1.7.5.4

[PATCH v5 2/7] arm: pmu: allow platform specific irq enable/disable handling

[Ming Lei]

Hi,

Attach the patch [PATCH v5 2/7] which is rebased on 3.1 -next.

BTW: The [PATCH v5 3/7] should be dropped as commented before, other patches
are OK against 3.1 -next.

thanks,
--
Ming Lei

--
>From 6125bef1aeee84ef22efdf743077f27f5274b6da Mon Sep 17 00:00:00 2001
From: Ming Lei <ming.lei@canonical.com>
Date: Wed, 2 Mar 2011 15:00:08 +0800
Subject: [PATCH v6 2/6] arm: pmu: allow platform specific irq enable/disable
 handling

This patch introduces .enable_irq and .disable_irq into
struct arm_pmu_platdata, so platform specific irq enablement
can be handled after request_irq, and platform specific irq
disablement can be handled before free_irq.

This patch is for support of  pmu irq routed from CTI on omap4.

Acked-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/include/asm/pmu.h   |   15 ++++++++++++---
 arch/arm/kernel/perf_event.c |   10 ++++++++--
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index 71d99b8..46a96a8 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -27,13 +27,22 @@ enum arm_pmu_type {
 /*
  * struct arm_pmu_platdata - ARM PMU platform data
  *
- * @handle_irq: an optional handler which will be called from the interrupt and
- * passed the address of the low level handler, and can be used to implement
- * any platform specific handling before or after calling it.
+ * @handle_irq: an optional handler which will be called from the
+ *	interrupt and passed the address of the low level handler,
+ *	and can be used to implement any platform specific handling
+ *	before or after calling it.
+ * @enable_irq: an optional handler which will be called after
+ *	request_irq and be used to handle some platform specific
+ *	irq enablement
+ * @disable_irq: an optional handler which will be called before
+ *	free_irq and be used to handle some platform specific
+ *	irq disablement
  */
 struct arm_pmu_platdata {
 	irqreturn_t (*handle_irq)(int irq, void *dev,
 				  irq_handler_t pmu_handler);
+	void (*enable_irq)(int irq);
+	void (*disable_irq)(int irq);
 };
 
 #ifdef CONFIG_CPU_HAS_PMU
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index e6e5d7c..4c4aa83 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -374,6 +374,8 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
 {
 	int i, irq, irqs;
 	struct platform_device *pmu_device = armpmu->plat_device;
+	struct arm_pmu_platdata *plat =
+		dev_get_platdata(&pmu_device->dev);
 
 	irqs = min(pmu_device->num_resources, num_possible_cpus());
 
@@ -381,8 +383,11 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
 		if (!cpumask_test_and_clear_cpu(i, &armpmu->active_irqs))
 			continue;
 		irq = platform_get_irq(pmu_device, i);
-		if (irq >= 0)
+		if (irq >= 0) {
+			if (plat && plat->disable_irq)
+				plat->disable_irq(irq);
 			free_irq(irq, armpmu);
+		}
 	}
 
 	release_pmu(armpmu->type);
@@ -439,7 +444,8 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
 				irq);
 			armpmu_release_hardware(armpmu);
 			return err;
-		}
+		} else if (plat && plat->enable_irq)
+			plat->enable_irq(irq);
 
 		cpumask_set_cpu(i, &armpmu->active_irqs);
 	}
-- 
1.7.5.4





-- 
Ming Lei

[PATCH v5 2/7] arm: pmu: allow platform specific irq enable/disable handling

[Will Deacon]

On Tue, Nov 01, 2011 at 03:26:46AM +0000, Ming Lei wrote:
> Attach the patch [PATCH v5 2/7] which is rebased on 3.1 -next.

Great, thanks for that.

> BTW: The [PATCH v5 3/7] should be dropped as commented before, other patches
> are OK against 3.1 -next.

Ok, I'll pick up patches 1 and 2. The OMAP guys can take the rest as and
when they're happy with them.

Will

[PATCH v5 3/7] arm: perf: support device with other non-irq resources

[ming.lei at canonical.com]

From: Ming Lei <ming.lei@canonical.com>

omap4 may create device via hwmod, which can create resources
automatically, so may include some non-irq resources.

This patch supports device with other non-irq resources.

Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/kernel/perf_event.c |    5 +++--
 arch/arm/kernel/pmu.c        |   12 ++++++++++--
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index f367780..d91dba2 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -19,6 +19,7 @@
 #include <linux/platform_device.h>
 #include <linux/spinlock.h>
 #include <linux/uaccess.h>
+#include <linux/cpumask.h>
 
 #include <asm/cputype.h>
 #include <asm/irq.h>
@@ -414,7 +415,7 @@ armpmu_reserve_hardware(void)
 		return -ENODEV;
 	}
 
-	for (i = 0; i < pmu_device->num_resources; ++i) {
+	for (i = 0; i < nr_cpu_ids; ++i) {
 		irq = platform_get_irq(pmu_device, i);
 		if (irq < 0)
 			continue;
@@ -453,7 +454,7 @@ armpmu_release_hardware(void)
 	struct arm_pmu_platdata *plat =
 		dev_get_platdata(&pmu_device->dev);
 
-	for (i = pmu_device->num_resources - 1; i >= 0; --i) {
+	for (i = nr_cpu_ids - 1; i >= 0; --i) {
 		irq = platform_get_irq(pmu_device, i);
 		if (irq >= 0) {
 			if (plat && plat->disable_irq)
diff --git a/arch/arm/kernel/pmu.c b/arch/arm/kernel/pmu.c
index c53474f..0e9c908 100644
--- a/arch/arm/kernel/pmu.c
+++ b/arch/arm/kernel/pmu.c
@@ -19,6 +19,7 @@
 #include <linux/module.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/cpumask.h>
 
 #include <asm/pmu.h>
 
@@ -172,8 +173,15 @@ init_cpu_pmu(void)
 	if (irqs == 1 && !irq_can_set_affinity(platform_get_irq(pdev, 0)))
 		return 0;
 
-	for (i = 0; i < irqs; ++i) {
-		err = set_irq_affinity(platform_get_irq(pdev, i), i);
+	for (i = 0; i < nr_cpu_ids; ++i) {
+		int irq;
+
+		irq = platform_get_irq(pdev, i);
+
+		if (irq < 0)
+			continue;
+
+		err = set_irq_affinity(irq, i);
 		if (err)
 			break;
 	}
-- 
1.7.5.4

[PATCH v5 3/7] arm: perf: support device with other non-irq resources

[Will Deacon]

Hi Ming Lei,

On Mon, Oct 24, 2011 at 03:45:55PM +0100, ming.lei at canonical.com wrote:
> From: Ming Lei <ming.lei@canonical.com>
> 
> omap4 may create device via hwmod, which can create resources
> automatically, so may include some non-irq resources.
> 
> This patch supports device with other non-irq resources.

I'd rather not do this in the Perf code since we're essentially dealing with
an artifact of the hwmod -> platform_device conversion.

> Signed-off-by: Ming Lei <ming.lei@canonical.com>
> ---
>  arch/arm/kernel/perf_event.c |    5 +++--
>  arch/arm/kernel/pmu.c        |   12 ++++++++++--
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index f367780..d91dba2 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -19,6 +19,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/spinlock.h>
>  #include <linux/uaccess.h>
> +#include <linux/cpumask.h>
>  
>  #include <asm/cputype.h>
>  #include <asm/irq.h>
> @@ -414,7 +415,7 @@ armpmu_reserve_hardware(void)
>  		return -ENODEV;
>  	}
>  
> -	for (i = 0; i < pmu_device->num_resources; ++i) {
> +	for (i = 0; i < nr_cpu_ids; ++i) {
>  		irq = platform_get_irq(pmu_device, i);
>  		if (irq < 0)
>  			continue;

Hmm, I actually changed this code recently. Take a look:

https://github.com/wdeacon/linux-wd/blob/perf/system-pmus/arch/arm/kernel/perf_event.c

This should all be in for 3.2-rc1, so you can rebase then. If you still have
hwmod issues, please solve them outside of perf_event.c

> diff --git a/arch/arm/kernel/pmu.c b/arch/arm/kernel/pmu.c
> index c53474f..0e9c908 100644
> --- a/arch/arm/kernel/pmu.c
> +++ b/arch/arm/kernel/pmu.c
> @@ -19,6 +19,7 @@
>  #include <linux/module.h>
>  #include <linux/of_device.h>
>  #include <linux/platform_device.h>
> +#include <linux/cpumask.h>

'fraid I've changed this file too!

https://github.com/wdeacon/linux-wd/blob/perf/system-pmus/arch/arm/kernel/pmu.c

Will

[PATCH v5 3/7] arm: perf: support device with other non-irq resources

[Ming Lei]

Hi,

On Mon, Oct 24, 2011 at 11:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Ming Lei,
>
> On Mon, Oct 24, 2011 at 03:45:55PM +0100, ming.lei at canonical.com wrote:
>> From: Ming Lei <ming.lei@canonical.com>
>>
>> omap4 may create device via hwmod, which can create resources
>> automatically, so may include some non-irq resources.
>>
>> This patch supports device with other non-irq resources.
>
> I'd rather not do this in the Perf code since we're essentially dealing with
> an artifact of the hwmod -> platform_device conversion.
>
>> Signed-off-by: Ming Lei <ming.lei@canonical.com>
>> ---
>> ?arch/arm/kernel/perf_event.c | ? ?5 +++--
>> ?arch/arm/kernel/pmu.c ? ? ? ?| ? 12 ++++++++++--
>> ?2 files changed, 13 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
>> index f367780..d91dba2 100644
>> --- a/arch/arm/kernel/perf_event.c
>> +++ b/arch/arm/kernel/perf_event.c
>> @@ -19,6 +19,7 @@
>> ?#include <linux/platform_device.h>
>> ?#include <linux/spinlock.h>
>> ?#include <linux/uaccess.h>
>> +#include <linux/cpumask.h>
>>
>> ?#include <asm/cputype.h>
>> ?#include <asm/irq.h>
>> @@ -414,7 +415,7 @@ armpmu_reserve_hardware(void)
>> ? ? ? ? ? ? ? return -ENODEV;
>> ? ? ? }
>>
>> - ? ? for (i = 0; i < pmu_device->num_resources; ++i) {
>> + ? ? for (i = 0; i < nr_cpu_ids; ++i) {
>> ? ? ? ? ? ? ? irq = platform_get_irq(pmu_device, i);
>> ? ? ? ? ? ? ? if (irq < 0)
>> ? ? ? ? ? ? ? ? ? ? ? continue;
>
> Hmm, I actually changed this code recently. Take a look:
>
> https://github.com/wdeacon/linux-wd/blob/perf/system-pmus/arch/arm/kernel/perf_event.c
>
> This should all be in for 3.2-rc1, so you can rebase then. If you still have
> hwmod issues, please solve them outside of perf_event.c

Looks your patch has solved the problem, so the patch is not needed
any more.

I will try to rebase the patchset on your tree first.

>> diff --git a/arch/arm/kernel/pmu.c b/arch/arm/kernel/pmu.c
>> index c53474f..0e9c908 100644
>> --- a/arch/arm/kernel/pmu.c
>> +++ b/arch/arm/kernel/pmu.c
>> @@ -19,6 +19,7 @@
>> ?#include <linux/module.h>
>> ?#include <linux/of_device.h>
>> ?#include <linux/platform_device.h>
>> +#include <linux/cpumask.h>
>
> 'fraid I've changed this file too!
>
> https://github.com/wdeacon/linux-wd/blob/perf/system-pmus/arch/arm/kernel/pmu.c
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>

thanks,
--
Ming Lei

[PATCH v5 3/7] arm: perf: support device with other non-irq resources

[Will Deacon]

On Tue, Oct 25, 2011 at 02:09:22AM +0100, Ming Lei wrote:
> >> - ? ? for (i = 0; i < pmu_device->num_resources; ++i) {
> >> + ? ? for (i = 0; i < nr_cpu_ids; ++i) {
> >> ? ? ? ? ? ? ? irq = platform_get_irq(pmu_device, i);
> >> ? ? ? ? ? ? ? if (irq < 0)
> >> ? ? ? ? ? ? ? ? ? ? ? continue;
> >
> > Hmm, I actually changed this code recently. Take a look:
> >
> > https://github.com/wdeacon/linux-wd/blob/perf/system-pmus/arch/arm/kernel/perf_event.c
> >
> > This should all be in for 3.2-rc1, so you can rebase then. If you still have
> > hwmod issues, please solve them outside of perf_event.c
> 
> Looks your patch has solved the problem, so the patch is not needed
> any more.

Hurrah! If you can get the OMAP / hwmod bits acked by the OMAP guys then I'm
happy to take the perf and PMU changes into my tree.

> I will try to rebase the patchset on your tree first.

Well that stuff should be in for -rc1, so you're probably better off
rebasing onto that when it lands. You could always use -next in the
meantime.

Cheers,

Will

[PATCH v5 3/7] arm: perf: support device with other non-irq resources

[Paul Walmsley]

On Tue, 25 Oct 2011, Will Deacon wrote:

> Hurrah! If you can get the OMAP / hwmod bits acked by the OMAP guys then I'm
> happy to take the perf and PMU changes into my tree.

I'd suggest that you take the perf/PMU stuff yourself if you are happy 
with it, and then we'll deal with the OMAP bits ourselves, since it looks 
like they aren't dependent on each other, and the OMAP parts will need 
changes.


- Paul

[PATCH v5 3/7] arm: perf: support device with other non-irq resources

[Ming Lei]

Hi,

On Tue, Oct 25, 2011 at 4:44 PM, Paul Walmsley <paul@pwsan.com> wrote:
> On Tue, 25 Oct 2011, Will Deacon wrote:
>
>> Hurrah! If you can get the OMAP / hwmod bits acked by the OMAP guys then I'm
>> happy to take the perf and PMU changes into my tree.
>
> I'd suggest that you take the perf/PMU stuff yourself if you are happy
> with it, and then we'll deal with the OMAP bits ourselves, since it looks
> like they aren't dependent on each other, and the OMAP parts will need
> changes.

One omap4 patch(struct arm_pmu_platdata related) depends on 2/7, which
need to be rebased. But I still suggest that arm perf/PMU stuff may be
merged first.

Paul, expect your comments on OMAP4 parts.

thanks,
--
Ming Lei

[PATCH v5 3/7] arm: perf: support device with other non-irq resources

[Paul Walmsley]

+ Beno?t

Hi

On Tue, 25 Oct 2011, Ming Lei wrote:

> On Tue, Oct 25, 2011 at 4:44 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Tue, 25 Oct 2011, Will Deacon wrote:
> >
> >> Hurrah! If you can get the OMAP / hwmod bits acked by the OMAP guys then I'm
> >> happy to take the perf and PMU changes into my tree.
> >
> > I'd suggest that you take the perf/PMU stuff yourself if you are happy
> > with it, and then we'll deal with the OMAP bits ourselves, since it looks
> > like they aren't dependent on each other, and the OMAP parts will need
> > changes.
> 
> One omap4 patch(struct arm_pmu_platdata related) depends on 2/7, which
> need to be rebased. But I still suggest that arm perf/PMU stuff may be
> merged first.
> 
> Paul, expect your comments on OMAP4 parts.

Beno?t is the right person to review OMAP4 hwmod data.

- Paul

[PATCH v5 3/7] arm: perf: support device with other non-irq resources

[Ming Lei]

On Tue, Oct 25, 2011 at 7:00 PM, Paul Walmsley <paul@pwsan.com> wrote:
> + Beno?t
>
> Hi
>
> On Tue, 25 Oct 2011, Ming Lei wrote:
>
>> On Tue, Oct 25, 2011 at 4:44 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> > On Tue, 25 Oct 2011, Will Deacon wrote:
>> >
>> >> Hurrah! If you can get the OMAP / hwmod bits acked by the OMAP guys then I'm
>> >> happy to take the perf and PMU changes into my tree.
>> >
>> > I'd suggest that you take the perf/PMU stuff yourself if you are happy
>> > with it, and then we'll deal with the OMAP bits ourselves, since it looks
>> > like they aren't dependent on each other, and the OMAP parts will need
>> > changes.
>>
>> One omap4 patch(struct arm_pmu_platdata related) depends on 2/7, which
>> need to be rebased. But I still suggest that arm perf/PMU stuff may be
>> merged first.
>>
>> Paul, expect your comments on OMAP4 parts.
>
> Beno?t is the right person to review OMAP4 hwmod data.

Beno?t, gentle ping, :-)

thanks,
--
Ming Lei

[PATCH v5 3/7] arm: perf: support device with other non-irq resources

[Will Deacon]

On Tue, Nov 08, 2011 at 09:25:52AM +0000, Ming Lei wrote:
> On Tue, Oct 25, 2011 at 7:00 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > Beno?t is the right person to review OMAP4 hwmod data.
> 
> Beno?t, gentle ping, :-)

Note that I've taken the two perf patches into my perf/omap4 branch now:

http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=shortlog;h=refs/heads/perf/omap4

so it would be really good to see the platform parts getting picked up too.

Will

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[ming.lei at canonical.com]

From: Ming Lei <ming.lei@canonical.com>

So that access to cross trigger interface can be allowed, which
will be introduce in later patches.

Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 393afac..c7289a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5276,6 +5276,30 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
 	.slaves_cnt	= ARRAY_SIZE(omap44xx_wd_timer3_slaves),
 };
 
+static struct omap_hwmod_class omap44xx_emu_hwmod_class = {
+	.name	= "emu",
+};
+
+static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
+	{ .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
+	{ .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
+	{ .irq = -1 }
+};
+
+/*emu hwmod*/
+static struct omap_hwmod omap44xx_emu_hwmod = {
+	.name		= "emu",
+	.class		= &omap44xx_emu_hwmod_class,
+	.clkdm_name	= "emu_sys_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.mpu_irqs	= omap44xx_emu_irqs,
+};
+
 static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 
 	/* dmm class */
@@ -5422,6 +5446,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 	&omap44xx_wd_timer2_hwmod,
 	&omap44xx_wd_timer3_hwmod,
 
+	/*emu class*/
+	&omap44xx_emu_hwmod,
 	NULL,
 };
 
-- 
1.7.5.4

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Paul Walmsley]

Hi

some comments

On Mon, 24 Oct 2011, ming.lei at canonical.com wrote:

> From: Ming Lei <ming.lei@canonical.com>
> 
> So that access to cross trigger interface can be allowed, which
> will be introduce in later patches.
> 
> Signed-off-by: Ming Lei <ming.lei@canonical.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   26 ++++++++++++++++++++++++++
>  1 files changed, 26 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 393afac..c7289a8 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -5276,6 +5276,30 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
>  	.slaves_cnt	= ARRAY_SIZE(omap44xx_wd_timer3_slaves),
>  };
>  
> +static struct omap_hwmod_class omap44xx_emu_hwmod_class = {
> +	.name	= "emu",
> +};
> +
> +static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
> +	{ .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
> +	{ .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
> +	{ .irq = -1 }
> +};

Are you sure these are part of the emulation IP?  We already have those 
IRQs in the MPU hwmod, see omap44xx_mpu_irqs[] in the same file.

> +/*emu hwmod*/
> +static struct omap_hwmod omap44xx_emu_hwmod = {
> +	.name		= "emu",
> +	.class		= &omap44xx_emu_hwmod_class,
> +	.clkdm_name	= "emu_sys_clkdm",
> +	.prcm = {
> +		.omap4 = {
> +			.clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,

This doesn't look right either: EMU is a clockdomain, not an IP block.

> +			.modulemode   = MODULEMODE_HWCTRL,
> +		},
> +	},
> +	.mpu_irqs	= omap44xx_emu_irqs,
> +};
> +
>  static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
>  
>  	/* dmm class */



- Paul

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Ming Lei]

Hi,

Thanks for your comments.

On Tue, Nov 8, 2011 at 11:26 PM, Paul Walmsley <paul@pwsan.com> wrote:

>> +static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
>> + ? ? { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
>> + ? ? { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
>> + ? ? { .irq = -1 }
>> +};
>
> Are you sure these are part of the emulation IP? ?We already have those

I am not sure, I just figure out one way to make omap4 pmu work. Since there
are few descriptions in TRM about it, it is a hacking based on [1], :-)

> IRQs in the MPU hwmod, see omap44xx_mpu_irqs[] in the same file.

I just see it, but looks like the "mpu" hwmod isn't populated as omap_device,
so the CTI irqs aren't requested now. Also, current arm perf code don't handle
three IRQs(one pl310 irq and two CTI irq) inside one device correctly.

So any suggestion about CTI IRQs connecting to which hwmod, so that they can
be found by pmu driver?

>> +/*emu hwmod*/
>> +static struct omap_hwmod omap44xx_emu_hwmod = {
>> + ? ? .name ? ? ? ? ? = "emu",
>> + ? ? .class ? ? ? ? ?= &omap44xx_emu_hwmod_class,
>> + ? ? .clkdm_name ? ? = "emu_sys_clkdm",
>> + ? ? .prcm = {
>> + ? ? ? ? ? ? .omap4 = {
>> + ? ? ? ? ? ? ? ? ? ? .clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,
>
> This doesn't look right either: EMU is a clockdomain, not an IP block.

I defined the 'emu' hwmod to control the clock state transition of the EMU
clock domain by writing to CLKTRCTRL.CM_EMU_CLKSTCTRL with standard
hwmod interface(_enable / _idle). Is there any other neat way to do it?

>
>> + ? ? ? ? ? ? ? ? ? ? .modulemode ? = MODULEMODE_HWCTRL,
>> + ? ? ? ? ? ? },
>> + ? ? },
>> + ? ? .mpu_irqs ? ? ? = omap44xx_emu_irqs,
>> +};
>> +
>> ?static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
>>
>> ? ? ? /* dmm class */
c
>
>

[1], http://comments.gmane.org/gmane.comp.embedded.pandaboard/168

thanks,
--
Ming Lei

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Paul Walmsley]

Hello Ming Lei,

just a few quick comments for now -

On Wed, 9 Nov 2011, Ming Lei wrote:

> On Tue, Nov 8, 2011 at 11:26 PM, Paul Walmsley <paul@pwsan.com> wrote:
> 
> >> +static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
> >> + ? ? { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
> >> + ? ? { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
> >> + ? ? { .irq = -1 }
> >> +};
> >
> > Are you sure these are part of the emulation IP? ?We already have those
> 
> I am not sure, I just figure out one way to make omap4 pmu work. Since there
> are few descriptions in TRM about it, it is a hacking based on [1], :-)
> 
> > IRQs in the MPU hwmod, see omap44xx_mpu_irqs[] in the same file.
> 
> I just see it, but looks like the "mpu" hwmod isn't populated as omap_device,
> so the CTI irqs aren't requested now.

Okay.  Maybe you can probably add some code in mach-omap2/devices.c to 
build an omap_device for this for right now?  I am not 100% sure whether 
those cti0/1 interrupts should be associated with the MPU or with the 
DEBUGSS but Beno?t might be able to answer this.

> Also, current arm perf code don't handle three IRQs(one pl310 irq and 
> two CTI irq) inside one device correctly.

To fix this, that ARM perf code should either be using 
platform_get_irq_byname(), or the hwmod hardware data will need to be 
rearranged to meet the arbitrary ordering requirement.  I'd suggest 
pinging Will on this issue to see what he wants to do.

> So any suggestion about CTI IRQs connecting to which hwmod, so that they can
> be found by pmu driver?
> 
> >> +/*emu hwmod*/
> >> +static struct omap_hwmod omap44xx_emu_hwmod = {
> >> + ? ? .name ? ? ? ? ? = "emu",
> >> + ? ? .class ? ? ? ? ?= &omap44xx_emu_hwmod_class,
> >> + ? ? .clkdm_name ? ? = "emu_sys_clkdm",
> >> + ? ? .prcm = {
> >> + ? ? ? ? ? ? .omap4 = {
> >> + ? ? ? ? ? ? ? ? ? ? .clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,
> >
> > This doesn't look right either: EMU is a clockdomain, not an IP block.
> 
> I defined the 'emu' hwmod to control the clock state transition of the EMU
> clock domain by writing to CLKTRCTRL.CM_EMU_CLKSTCTRL with standard
> hwmod interface(_enable / _idle). Is there any other neat way to do it?

So the clockdomain is already defined in 
mach-omap2/clockdomains44xx_data.c and there's code to control it - see 
for example clkdm_enable_idle().  But this code should not be called 
directly by any device driver code or driver integration code.  The thing 
to do here is to ask Beno?t to release the hwmod data for the DEBUGSS 
hwmod, then someone will need to write an MFD driver for that which 
exposes the PMU address space to the PMU platform driver.

But also proper dependency support in hwmod enable/idle operations will be 
needed to enable the instrumentation and emulation interconnects when the 
DEBUGSS is enabled.  This has been on my plate for a few months, it's good 
to have another reason to prioritize it.  


- Paul

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Will Deacon]

[Adding Benoit to CC].

On Thu, Nov 10, 2011 at 09:02:14AM +0000, Paul Walmsley wrote:
> On Wed, 9 Nov 2011, Ming Lei wrote:
> > Also, current arm perf code don't handle three IRQs(one pl310 irq and 
> > two CTI irq) inside one device correctly.
> 
> To fix this, that ARM perf code should either be using 
> platform_get_irq_byname(), or the hwmod hardware data will need to be 
> rearranged to meet the arbitrary ordering requirement.  I'd suggest 
> pinging Will on this issue to see what he wants to do.

The issue stems from the fact that we have to route the PMU interrupts to
the correct CPU manually (I think only MSM routes them as PPIs, which is
clearly the correct thing to do). To do this, we expect the IRQ resources to
be laid out in CPU order. In hindsight, maybe naming the resources might
have been a good idea, but them we'd still have to generate the names using
CPU numbers when iterating through the platform device.

So although the ordering requirements are a bit of a pain, I do think it's
reasonable for perf to expect that it's not being handed some random other
interrupts along with those for the PMU.

> So the clockdomain is already defined in 
> mach-omap2/clockdomains44xx_data.c and there's code to control it - see 
> for example clkdm_enable_idle().  But this code should not be called 
> directly by any device driver code or driver integration code.  The thing 
> to do here is to ask Beno?t to release the hwmod data for the DEBUGSS 
> hwmod, then someone will need to write an MFD driver for that which 
> exposes the PMU address space to the PMU platform driver.

Benoit? Please can you chime in here?

Will

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Jamie Iles]

On Fri, Nov 11, 2011 at 11:41:47AM +0000, Will Deacon wrote:
> [Adding Benoit to CC].
> 
> On Thu, Nov 10, 2011 at 09:02:14AM +0000, Paul Walmsley wrote:
> > On Wed, 9 Nov 2011, Ming Lei wrote:
> > > Also, current arm perf code don't handle three IRQs(one pl310 irq and 
> > > two CTI irq) inside one device correctly.
> > 
> > To fix this, that ARM perf code should either be using 
> > platform_get_irq_byname(), or the hwmod hardware data will need to be 
> > rearranged to meet the arbitrary ordering requirement.  I'd suggest 
> > pinging Will on this issue to see what he wants to do.
> 
> The issue stems from the fact that we have to route the PMU interrupts to
> the correct CPU manually (I think only MSM routes them as PPIs, which is
> clearly the correct thing to do). To do this, we expect the IRQ resources to
> be laid out in CPU order. In hindsight, maybe naming the resources might
> have been a good idea, but them we'd still have to generate the names using
> CPU numbers when iterating through the platform device.

There isn't yet a way to do naming of resources with DT, and although I 
think there was a proposal for doing named register resources I don't 
think this has been accepted and there wasn't anything for IRQ 
resources...

Jamie

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Will Deacon]

On Fri, Nov 11, 2011 at 11:47:35AM +0000, Jamie Iles wrote:
> On Fri, Nov 11, 2011 at 11:41:47AM +0000, Will Deacon wrote:
> > The issue stems from the fact that we have to route the PMU interrupts to
> > the correct CPU manually (I think only MSM routes them as PPIs, which is
> > clearly the correct thing to do). To do this, we expect the IRQ resources to
> > be laid out in CPU order. In hindsight, maybe naming the resources might
> > have been a good idea, but them we'd still have to generate the names using
> > CPU numbers when iterating through the platform device.
> 
> There isn't yet a way to do naming of resources with DT, and although I 
> think there was a proposal for doing named register resources I don't 
> think this has been accepted and there wasn't anything for IRQ 
> resources...

That's good news - means I have an excuse other than laziness for not
implementing this for perf :)

Will

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Cousson, Benoit]

On 11/11/2011 12:47 PM, Jamie Iles wrote:
> On Fri, Nov 11, 2011 at 11:41:47AM +0000, Will Deacon wrote:
>> [Adding Benoit to CC].
>>
>> On Thu, Nov 10, 2011 at 09:02:14AM +0000, Paul Walmsley wrote:
>>> On Wed, 9 Nov 2011, Ming Lei wrote:
>>>> Also, current arm perf code don't handle three IRQs(one pl310 irq and
>>>> two CTI irq) inside one device correctly.
>>>
>>> To fix this, that ARM perf code should either be using
>>> platform_get_irq_byname(), or the hwmod hardware data will need to be
>>> rearranged to meet the arbitrary ordering requirement.  I'd suggest
>>> pinging Will on this issue to see what he wants to do.
>>
>> The issue stems from the fact that we have to route the PMU interrupts to
>> the correct CPU manually (I think only MSM routes them as PPIs, which is
>> clearly the correct thing to do). To do this, we expect the IRQ resources to
>> be laid out in CPU order. In hindsight, maybe naming the resources might
>> have been a good idea, but them we'd still have to generate the names using
>> CPU numbers when iterating through the platform device.
>
> There isn't yet a way to do naming of resources with DT, and although I
> think there was a proposal for doing named register resources I don't
> think this has been accepted and there wasn't anything for IRQ
> resources...

It will come soon... along with the updated patch for reg-names support.

Regards,
Benoit

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Will Deacon]

Hi Benoit,

On Fri, Nov 11, 2011 at 02:56:05PM +0000, Cousson, Benoit wrote:
> It will come soon... along with the updated patch for reg-names support.

Actually, I was hoping you could help Ming Lei with the hwmod stuff :)

Will

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Cousson, Benoit]

Hi Will,

On 11/11/2011 3:58 PM, Will Deacon wrote:
> Hi Benoit,
>
> On Fri, Nov 11, 2011 at 02:56:05PM +0000, Cousson, Benoit wrote:
>> It will come soon... along with the updated patch for reg-names support.
>
> Actually, I was hoping you could help Ming Lei with the hwmod stuff :)

And I'll do :-)

We already started looking at that with Paul a couple of days ago, but 
the organization of the debugss IPs inside MPUSS is a little bit messy 
in OMAP :-)

For the moment the cti IRQs are attached to the MPU subsystem which make 
sense for the HW partitioning point of view.
Unfortunately, these debug IPs are accessed through an external L3_EMU 
configuration bus and not using some internal bus inside the MPUSS.
In the memory maps they are thus all located inside the 
0x54000000-0x54164FFF.

So for the driver point of view, it might be better to assign these IRQs 
to the debugss IP instead of the MPUSS IP.

The MPU will then only have the PL310 IRQ.

static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = {
	{ .name = "pl310", .irq = 0 + OMAP44XX_IRQ_GIC_START },
	{ .irq = -1 }
};

The debugss one will have the cti ones, that will start at 0 and thus 
will make them even accessible using the index.

static struct omap_hwmod_irq_info omap44xx_debugss_irqs[] = {
	{ .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
	{ .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
	{ .irq = -1 }
};

I need to fix this IRQ mapping and then I'll be able to send a hwmod 
version of this debugss virtual IP that should help Ming.

Regards,
Benoit

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Will Deacon]

On Fri, Nov 11, 2011 at 03:12:49PM +0000, Cousson, Benoit wrote:
> Hi Will,

Hello,

> On 11/11/2011 3:58 PM, Will Deacon wrote:
> > Actually, I was hoping you could help Ming Lei with the hwmod stuff :)
> 
> And I'll do :-)

Cheers!

> We already started looking at that with Paul a couple of days ago, but 
> the organization of the debugss IPs inside MPUSS is a little bit messy 
> in OMAP :-)

Ok, I'm not familiar with it so that's why I've been pestering.

> For the moment the cti IRQs are attached to the MPU subsystem which make 
> sense for the HW partitioning point of view.
> Unfortunately, these debug IPs are accessed through an external L3_EMU 
> configuration bus and not using some internal bus inside the MPUSS.
> In the memory maps they are thus all located inside the 
> 0x54000000-0x54164FFF.
> 
> So for the driver point of view, it might be better to assign these IRQs 
> to the debugss IP instead of the MPUSS IP.
> 
> The MPU will then only have the PL310 IRQ.
> 
> static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = {
> 	{ .name = "pl310", .irq = 0 + OMAP44XX_IRQ_GIC_START },
> 	{ .irq = -1 }
> };

At some point I'd like to add support for the PL310 PMU, which will want to
use that IRQ. That would need to be passed to the PL310 driver though, which
will then register it's own PMU device with perf.

> The debugss one will have the cti ones, that will start at 0 and thus 
> will make them even accessible using the index.
> 
> static struct omap_hwmod_irq_info omap44xx_debugss_irqs[] = {
> 	{ .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
> 	{ .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
> 	{ .irq = -1 }
> };
> 
> I need to fix this IRQ mapping and then I'll be able to send a hwmod 
> version of this debugss virtual IP that should help Ming.

That looks cracking and should work out of the box.

Thanks,

Will

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Cousson, Benoit]

Hi Ming Lei,

Sorry, for the delay, it took me some time to gather the exhaustive data for that block. 

On 11/10/2011 10:02 AM, Paul Walmsley wrote:
> Hello Ming Lei,
> 
> just a few quick comments for now -
> 
> On Wed, 9 Nov 2011, Ming Lei wrote:
> 
>> On Tue, Nov 8, 2011 at 11:26 PM, Paul Walmsley<paul@pwsan.com>  wrote:
>>
>>>> +static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
>>>> +     { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
>>>> +     { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
>>>> +     { .irq = -1 }
>>>> +};
>>>
>>> Are you sure these are part of the emulation IP?  We already have those
>>
>> I am not sure, I just figure out one way to make omap4 pmu work. Since there
>> are few descriptions in TRM about it, it is a hacking based on [1], :-)
>>
>>> IRQs in the MPU hwmod, see omap44xx_mpu_irqs[] in the same file.
>>
>> I just see it, but looks like the "mpu" hwmod isn't populated as omap_device,
>> so the CTI irqs aren't requested now.
> 
> Okay.  Maybe you can probably add some code in mach-omap2/devices.c to
> build an omap_device for this for right now?  I am not 100% sure whether
> those cti0/1 interrupts should be associated with the MPU or with the
> DEBUGSS but Beno?t might be able to answer this.
> 
>> Also, current arm perf code don't handle three IRQs(one pl310 irq and
>> two CTI irq) inside one device correctly.
> 
> To fix this, that ARM perf code should either be using
> platform_get_irq_byname(), or the hwmod hardware data will need to be
> rearranged to meet the arbitrary ordering requirement.  I'd suggest
> pinging Will on this issue to see what he wants to do.
> 
>> So any suggestion about CTI IRQs connecting to which hwmod, so that they can
>> be found by pmu driver?
>>
>>>> +/*emu hwmod*/
>>>> +static struct omap_hwmod omap44xx_emu_hwmod = {
>>>> +     .name           = "emu",
>>>> +     .class          =&omap44xx_emu_hwmod_class,
>>>> +     .clkdm_name     = "emu_sys_clkdm",
>>>> +     .prcm = {
>>>> +             .omap4 = {
>>>> +                     .clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,
>>>
>>> This doesn't look right either: EMU is a clockdomain, not an IP block.
>>
>> I defined the 'emu' hwmod to control the clock state transition of the EMU
>> clock domain by writing to CLKTRCTRL.CM_EMU_CLKSTCTRL with standard
>> hwmod interface(_enable / _idle). Is there any other neat way to do it?
> 
> So the clockdomain is already defined in
> mach-omap2/clockdomains44xx_data.c and there's code to control it - see
> for example clkdm_enable_idle().  But this code should not be called
> directly by any device driver code or driver integration code.  The thing
> to do here is to ask Beno?t to release the hwmod data for the DEBUGSS
> hwmod, then someone will need to write an MFD driver for that which
> exposes the PMU address space to the PMU platform driver.

Following that discussion, here is the patch to expose debugss hwmod.

I have moved the CTIs irq from MPU to debugss and exposed all the internals IP that are part of the OMAP debug subsystem.

Since the DEBUGSS cannot be accessed at boot time if the l3_main_3 and the l3_instr interconnects are not enable, you will have some warnings.

[    0.416992] omap_hwmod: debugss: softreset failed (waited 10000 usec)
[    0.426727] omap_hwmod: debugss: _wait_target_disable failed

Just let me know if you have any issue with that patch.

Please note that will will need the fix "ARM: OMAP: hwmod: Fix the addr space, irq, dma count APIs" to avoid hwmod core messing up with the resources.

I've just posted a pull request for Tony to get it for -rc3.
http://comments.gmane.org/gmane.linux.ports.arm.kernel/140458

I pushed these two patches on a branch based on mainline for your convenience.

git://gitorious.org/omap-pm/linux.git wip-emu/debuss_hwmod

Regards,
Benoit 

---
From: Benoit Cousson <b-cousson@ti.com>
Date: Fri, 18 Nov 2011 11:42:12 +0100
Subject: [PATCH] ARM: OMAP4: hwmod data: Add support for the debug modules

The OMAP4 DEBUG subsystem contains all the IPs used for emulation,
included the ones from the CortexA9 MPU.
Expose the individual modules base address.

Re-map the CTIs IRQs from MPU to DEBUGSS.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  177 +++++++++++++++++++++++++++-
 1 files changed, 174 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7695e5d..6cf21ee 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -47,6 +47,7 @@
 
 /* Backward references (IPs with Bus Master capability) */
 static struct omap_hwmod omap44xx_aess_hwmod;
+static struct omap_hwmod omap44xx_debugss_hwmod;
 static struct omap_hwmod omap44xx_dma_system_hwmod;
 static struct omap_hwmod omap44xx_dmm_hwmod;
 static struct omap_hwmod omap44xx_dsp_hwmod;
@@ -337,6 +338,14 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
 };
 
 /* l3_main_2 */
+/* debugss -> l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_debugss__l3_main_2 = {
+	.master		= &omap44xx_debugss_hwmod,
+	.slave		= &omap44xx_l3_main_2_hwmod,
+	.clk		= "dbgclk_mux_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* dma_system -> l3_main_2 */
 static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
 	.master		= &omap44xx_dma_system_hwmod,
@@ -686,7 +695,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
  *  ctrl_module_pad_core
  *  ctrl_module_pad_wkup
  *  ctrl_module_wkup
- *  debugss
  *  efuse_ctrl_cust
  *  efuse_ctrl_std
  *  elm
@@ -908,6 +916,168 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
 };
 
 /*
+ * 'debugss' class
+ * debug and emulation sub system
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_debugss_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_debugss_hwmod_class = {
+	.name	= "debugss",
+	.sysc	= &omap44xx_debugss_sysc,
+};
+
+/* debugss */
+static struct omap_hwmod_irq_info omap44xx_debugss_irqs[] = {
+	{ .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
+	{ .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
+	{ .irq = -1 }
+};
+
+/* debugss master ports */
+static struct omap_hwmod_ocp_if *omap44xx_debugss_masters[] = {
+	&omap44xx_debugss__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_debugss_addrs[] = {
+	{
+		.name		= "mipi_stm_add_sp_0",
+		.pa_start	= 0x54000000,
+		.pa_end		= 0x540fffff,
+	},
+	{
+		.name		= "mipi_stm_add_sp_1",
+		.pa_start	= 0x54100000,
+		.pa_end		= 0x5413ffff,
+	},
+	{
+		.name		= "mpu_c0_debug",
+		.pa_start	= 0x54140000,
+		.pa_end		= 0x54141fff,
+	},
+	{
+		.name		= "mpu_c1_debug",
+		.pa_start	= 0x54142000,
+		.pa_end		= 0x54143fff,
+	},
+	{
+		.name		= "cti0_mpu",
+		.pa_start	= 0x54148000,
+		.pa_end		= 0x54148fff,
+	},
+	{
+		.name		= "cti1_mpu",
+		.pa_start	= 0x54149000,
+		.pa_end		= 0x54149fff,
+	},
+	{
+		.name		= "ptm0_mpu",
+		.pa_start	= 0x5414c000,
+		.pa_end		= 0x5414cfff,
+	},
+	{
+		.name		= "ptm1_mpu",
+		.pa_start	= 0x5414d000,
+		.pa_end		= 0x5414dfff,
+	},
+	{
+		.name		= "tf_mpu",
+		.pa_start	= 0x54158000,
+		.pa_end		= 0x54158fff,
+	},
+	{
+		.name		= "dap_pc_mpu",
+		.pa_start	= 0x54159000,
+		.pa_end		= 0x54159fff,
+	},
+	{
+		.name		= "apb_bridge_a_ctrl_time_out",
+		.pa_start	= 0x5415f000,
+		.pa_end		= 0x5415ffff,
+	},
+	{
+		.name		= "drm",
+		.pa_start	= 0x54160000,
+		.pa_end		= 0x54160fff,
+	},
+	{
+		.name		= "mipi_stm",
+		.pa_start	= 0x54161000,
+		.pa_end		= 0x54161fff,
+		.flags		= ADDR_TYPE_RT
+	},
+	{
+		.name		= "csetb",
+		.pa_start	= 0x54162000,
+		.pa_end		= 0x54162fff,
+	},
+	{
+		.name		= "cstpiu",
+		.pa_start	= 0x54163000,
+		.pa_end		= 0x54163fff,
+	},
+	{
+		.name		= "cstf1",
+		.pa_start	= 0x54164000,
+		.pa_end		= 0x54164fff,
+	},
+	{
+		.name		= "cstf2",
+		.pa_start	= 0x54165000,
+		.pa_end		= 0x54165fff,
+	},
+	{
+		.name		= "l4_cfg_emu_conf_regs",
+		.pa_start	= 0x54167000,
+		.pa_end		= 0x54167fff,
+	},
+	{
+		.name		= "l3_instr_emu_conf_regs",
+		.pa_start	= 0x54180000,
+		.pa_end		= 0x54180fff,
+	},
+	{ }
+};
+
+/* l3_instr -> debugss */
+static struct omap_hwmod_ocp_if omap44xx_l3_instr__debugss = {
+	.master		= &omap44xx_l3_instr_hwmod,
+	.slave		= &omap44xx_debugss_hwmod,
+	.clk		= "l3_div_ck",
+	.addr		= omap44xx_debugss_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* debugss slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_debugss_slaves[] = {
+	&omap44xx_l3_instr__debugss,
+};
+
+static struct omap_hwmod omap44xx_debugss_hwmod = {
+	.name		= "debugss",
+	.class		= &omap44xx_debugss_hwmod_class,
+	.clkdm_name	= "emu_sys_clkdm",
+	.mpu_irqs	= omap44xx_debugss_irqs,
+	.main_clk	= "trace_clk_div_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP4_CM_EMU_DEBUGSS_CLKCTRL_OFFSET,
+			.context_offs = OMAP4_RM_EMU_DEBUGSS_CONTEXT_OFFSET,
+		},
+	},
+	.slaves		= omap44xx_debugss_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap44xx_debugss_slaves),
+	.masters	= omap44xx_debugss_masters,
+	.masters_cnt	= ARRAY_SIZE(omap44xx_debugss_masters),
+};
+
+/*
  * 'dma' class
  * dma controller for data exchange between memory to memory (i.e. internal or
  * external memory) and gp peripherals to memory or memory to gp peripherals
@@ -3902,8 +4072,6 @@ static struct omap_hwmod_class omap44xx_mpu_hwmod_class = {
 /* mpu */
 static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = {
 	{ .name = "pl310", .irq = 0 + OMAP44XX_IRQ_GIC_START },
-	{ .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
-	{ .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
 	{ .irq = -1 }
 };
 
@@ -5308,6 +5476,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 	/* counter class */
 /*	&omap44xx_counter_32k_hwmod, */
 
+	/* debugss class */
+	&omap44xx_debugss_hwmod,
+
 	/* dma class */
 	&omap44xx_dma_system_hwmod,
 
-- 
1.7.0.4

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Will Deacon]

Hi Benoit,

On Fri, Nov 18, 2011 at 12:58:20PM +0000, Cousson, Benoit wrote:
> Hi Ming Lei,
> 
> Sorry, for the delay, it took me some time to gather the exhaustive data for that block. 

Thanks for looking at this! I don't think we'd have managed to get all of
the magic numbers in the right place ourselves :)

Ming Lei - can you take this into your patch series please?

Then we'll have:

	- The two perf patches in my tree
	- The hwmod fix in Tony's tree (pending pull)
	- Your patches plus this one for hooking everything together

The sooner we can push these into -next, the better.

Cheers,

Will

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Ming Lei]

Hi Will,

On Fri, Nov 18, 2011 at 10:56 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Benoit,
>
> On Fri, Nov 18, 2011 at 12:58:20PM +0000, Cousson, Benoit wrote:
>> Hi Ming Lei,
>>
>> Sorry, for the delay, it took me some time to gather the exhaustive data for that block.
>
> Thanks for looking at this! I don't think we'd have managed to get all of
> the magic numbers in the right place ourselves :)
>
> Ming Lei - can you take this into your patch series please?

Yes, I have made omap4 pmu work already with Benoit's patch,
and if no one has objections on other patches(5/7, 6/7, 7/7), I
can post out the next version for -next tree.

>
> Then we'll have:
>
> ? ? ? ?- The two perf patches in my tree
> ? ? ? ?- The hwmod fix in Tony's tree (pending pull)
> ? ? ? ?- Your patches plus this one for hooking everything together
>
> The sooner we can push these into -next, the better.
>
> Cheers,
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>

thanks,
--
Ming Lei

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Paul Walmsley]

Hi

On Sat, 19 Nov 2011, Ming Lei wrote:

> On Fri, Nov 18, 2011 at 10:56 PM, Will Deacon <will.deacon@arm.com> wrote:
>
> > Ming Lei - can you take this into your patch series please?
> 
> Yes, I have made omap4 pmu work already with Benoit's patch,
> and if no one has objections on other patches(5/7, 6/7, 7/7), I
> can post out the next version for -next tree.
> 
> > Then we'll have:
> >
> > ? ? ? ?- The two perf patches in my tree
> > ? ? ? ?- The hwmod fix in Tony's tree (pending pull)
> > ? ? ? ?- Your patches plus this one for hooking everything together
> >
> > The sooner we can push these into -next, the better.

The OMAP-specific parts should be queued up in my/Beno?t's/Tony's trees, 
rather than placed directly into -next.  Otherwise they are likely to 
generate merge conflicts with other OMAP changes that we may generate.

So I'd suggest splitting patches 1-3 off into a separate series that Will 
can pass on to -next if he wishes.


- Paul

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Will Deacon]

On Sun, Nov 20, 2011 at 03:27:19AM +0000, Paul Walmsley wrote:
> The OMAP-specific parts should be queued up in my/Beno?t's/Tony's trees, 
> rather than placed directly into -next.  Otherwise they are likely to 
> generate merge conflicts with other OMAP changes that we may generate.
> 
> So I'd suggest splitting patches 1-3 off into a separate series that Will 
> can pass on to -next if he wishes.

Fine by me. If Ming Lei posts a new series so that everything is in one
thread then I can pick out the bits I want.

Cheers,

Will

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Ming Lei]

Hi,

On Mon, Nov 21, 2011 at 9:58 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Sun, Nov 20, 2011 at 03:27:19AM +0000, Paul Walmsley wrote:
>> The OMAP-specific parts should be queued up in my/Beno?t's/Tony's trees,
>> rather than placed directly into -next. ?Otherwise they are likely to
>> generate merge conflicts with other OMAP changes that we may generate.
>>
>> So I'd suggest splitting patches 1-3 off into a separate series that Will
>> can pass on to -next if he wishes.
>
> Fine by me. If Ming Lei posts a new series so that everything is in one
> thread then I can pick out the bits I want.

You mean the 3rd patch is the debugss patch posted by Benoit?
The original 3rd patch is not needed any more once the debugss patch
is taken.

thanks,
--
Ming Lei

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Will Deacon]

On Mon, Nov 21, 2011 at 02:53:54PM +0000, Ming Lei wrote:
> On Mon, Nov 21, 2011 at 9:58 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Sun, Nov 20, 2011 at 03:27:19AM +0000, Paul Walmsley wrote:
> >> The OMAP-specific parts should be queued up in my/Beno?t's/Tony's trees,
> >> rather than placed directly into -next. ?Otherwise they are likely to
> >> generate merge conflicts with other OMAP changes that we may generate.
> >>
> >> So I'd suggest splitting patches 1-3 off into a separate series that Will
> >> can pass on to -next if he wishes.
> >
> > Fine by me. If Ming Lei posts a new series so that everything is in one
> > thread then I can pick out the bits I want.
> 
> You mean the 3rd patch is the debugss patch posted by Benoit?
> The original 3rd patch is not needed any more once the debugss patch
> is taken.

Ah sorry, I lost track a bit. In that case, I'll just keep hold of the two
patches I have and deal with them appropriately.

Will

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Ming Lei]

On Mon, Nov 21, 2011 at 11:16 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Nov 21, 2011 at 02:53:54PM +0000, Ming Lei wrote:
>> On Mon, Nov 21, 2011 at 9:58 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > On Sun, Nov 20, 2011 at 03:27:19AM +0000, Paul Walmsley wrote:
>> >> The OMAP-specific parts should be queued up in my/Beno?t's/Tony's trees,
>> >> rather than placed directly into -next. ?Otherwise they are likely to
>> >> generate merge conflicts with other OMAP changes that we may generate.
>> >>
>> >> So I'd suggest splitting patches 1-3 off into a separate series that Will
>> >> can pass on to -next if he wishes.
>> >
>> > Fine by me. If Ming Lei posts a new series so that everything is in one
>> > thread then I can pick out the bits I want.
>>
>> You mean the 3rd patch is the debugss patch posted by Benoit?
>> The original 3rd patch is not needed any more once the debugss patch
>> is taken.
>
> Ah sorry, I lost track a bit. In that case, I'll just keep hold of the two
> patches I have and deal with them appropriately.

Sorry too, :-)

It should be that both 3/7 and 4/7 are not needed any more.
Benoit's debugss patch will replace the 4/7 patch(introduce emu hwmod).

thanks,
--
Ming Lei

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Ming Lei]

Hi Benoit,

On Fri, Nov 18, 2011 at 8:58 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> Hi Ming Lei,
>
> Sorry, for the delay, it took me some time to gather the exhaustive data for that block.

The work is really great.

> On 11/10/2011 10:02 AM, Paul Walmsley wrote:
>> Hello Ming Lei,
>>
>> just a few quick comments for now -
>>
>> On Wed, 9 Nov 2011, Ming Lei wrote:
>>
>>> On Tue, Nov 8, 2011 at 11:26 PM, Paul Walmsley<paul@pwsan.com> ?wrote:
>>>
>>>>> +static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
>>>>> + ? ? { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
>>>>> + ? ? { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
>>>>> + ? ? { .irq = -1 }
>>>>> +};
>>>>
>>>> Are you sure these are part of the emulation IP? ?We already have those
>>>
>>> I am not sure, I just figure out one way to make omap4 pmu work. Since there
>>> are few descriptions in TRM about it, it is a hacking based on [1], :-)
>>>
>>>> IRQs in the MPU hwmod, see omap44xx_mpu_irqs[] in the same file.
>>>
>>> I just see it, but looks like the "mpu" hwmod isn't populated as omap_device,
>>> so the CTI irqs aren't requested now.
>>
>> Okay. ?Maybe you can probably add some code in mach-omap2/devices.c to
>> build an omap_device for this for right now? ?I am not 100% sure whether
>> those cti0/1 interrupts should be associated with the MPU or with the
>> DEBUGSS but Beno?t might be able to answer this.
>>
>>> Also, current arm perf code don't handle three IRQs(one pl310 irq and
>>> two CTI irq) inside one device correctly.
>>
>> To fix this, that ARM perf code should either be using
>> platform_get_irq_byname(), or the hwmod hardware data will need to be
>> rearranged to meet the arbitrary ordering requirement. ?I'd suggest
>> pinging Will on this issue to see what he wants to do.
>>
>>> So any suggestion about CTI IRQs connecting to which hwmod, so that they can
>>> be found by pmu driver?
>>>
>>>>> +/*emu hwmod*/
>>>>> +static struct omap_hwmod omap44xx_emu_hwmod = {
>>>>> + ? ? .name ? ? ? ? ? = "emu",
>>>>> + ? ? .class ? ? ? ? ?=&omap44xx_emu_hwmod_class,
>>>>> + ? ? .clkdm_name ? ? = "emu_sys_clkdm",
>>>>> + ? ? .prcm = {
>>>>> + ? ? ? ? ? ? .omap4 = {
>>>>> + ? ? ? ? ? ? ? ? ? ? .clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,
>>>>
>>>> This doesn't look right either: EMU is a clockdomain, not an IP block.
>>>
>>> I defined the 'emu' hwmod to control the clock state transition of the EMU
>>> clock domain by writing to CLKTRCTRL.CM_EMU_CLKSTCTRL with standard
>>> hwmod interface(_enable / _idle). Is there any other neat way to do it?
>>
>> So the clockdomain is already defined in
>> mach-omap2/clockdomains44xx_data.c and there's code to control it - see
>> for example clkdm_enable_idle(). ?But this code should not be called
>> directly by any device driver code or driver integration code. ?The thing
>> to do here is to ask Beno?t to release the hwmod data for the DEBUGSS
>> hwmod, then someone will need to write an MFD driver for that which
>> exposes the PMU address space to the PMU platform driver.
>
> Following that discussion, here is the patch to expose debugss hwmod.
>
> I have moved the CTIs irq from MPU to debugss and exposed all the internals IP that are part of the OMAP debug subsystem.
>
> Since the DEBUGSS cannot be accessed at boot time if the l3_main_3 and the l3_instr interconnects are not enable, you will have some warnings.
>

Currently these two modules are enabled in my patch 5/7 and 6/7, and the
pmu omap device is built from the three IPs: debugss, l3_main_3 and
the l3_instr,
so that these two modules can be enabled in omap_device_enable().

I don't know how to enable the two IPs in other ways, also I am not
sure if the way
is suitable, but it does work, could you help to review the two patches?

> [ ? ?0.416992] omap_hwmod: debugss: softreset failed (waited 10000 usec)
> [ ? ?0.426727] omap_hwmod: debugss: _wait_target_disable failed
>
> Just let me know if you have any issue with that patch.

In fact, now it is very easy to enable pmu on omap with your patch,
I have made omap4 pmu work already using debugss:

     - replace the patch 3/7 with your debugss patch(replace 'emu'
with 'debugss')
     - modify the patch  5/7 to create pmu omap device from 'debugss'
instead of 'emu'

thanks,
--
Ming Lei

>
> Please note that will will need the fix "ARM: OMAP: hwmod: Fix the addr space, irq, dma count APIs" to avoid hwmod core messing up with the resources.
>
> I've just posted a pull request for Tony to get it for -rc3.
> http://comments.gmane.org/gmane.linux.ports.arm.kernel/140458
>
> I pushed these two patches on a branch based on mainline for your convenience.
>
> git://gitorious.org/omap-pm/linux.git wip-emu/debuss_hwmod
>
> Regards,
> Benoit
>
> ---
> From: Benoit Cousson <b-cousson@ti.com>
> Date: Fri, 18 Nov 2011 11:42:12 +0100
> Subject: [PATCH] ARM: OMAP4: hwmod data: Add support for the debug modules
>
> The OMAP4 DEBUG subsystem contains all the IPs used for emulation,
> included the ones from the CortexA9 MPU.
> Expose the individual modules base address.
>
> Re-map the CTIs IRQs from MPU to DEBUGSS.
>
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Ming Lei <ming.lei@canonical.com>
> ---
> ?arch/arm/mach-omap2/omap_hwmod_44xx_data.c | ?177 +++++++++++++++++++++++++++-
> ?1 files changed, 174 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 7695e5d..6cf21ee 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -47,6 +47,7 @@
>
> ?/* Backward references (IPs with Bus Master capability) */
> ?static struct omap_hwmod omap44xx_aess_hwmod;
> +static struct omap_hwmod omap44xx_debugss_hwmod;
> ?static struct omap_hwmod omap44xx_dma_system_hwmod;
> ?static struct omap_hwmod omap44xx_dmm_hwmod;
> ?static struct omap_hwmod omap44xx_dsp_hwmod;
> @@ -337,6 +338,14 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
> ?};
>
> ?/* l3_main_2 */
> +/* debugss -> l3_main_2 */
> +static struct omap_hwmod_ocp_if omap44xx_debugss__l3_main_2 = {
> + ? ? ? .master ? ? ? ? = &omap44xx_debugss_hwmod,
> + ? ? ? .slave ? ? ? ? ?= &omap44xx_l3_main_2_hwmod,
> + ? ? ? .clk ? ? ? ? ? ?= "dbgclk_mux_ck",
> + ? ? ? .user ? ? ? ? ? = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> ?/* dma_system -> l3_main_2 */
> ?static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
> ? ? ? ?.master ? ? ? ? = &omap44xx_dma_system_hwmod,
> @@ -686,7 +695,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
> ?* ?ctrl_module_pad_core
> ?* ?ctrl_module_pad_wkup
> ?* ?ctrl_module_wkup
> - * ?debugss
> ?* ?efuse_ctrl_cust
> ?* ?efuse_ctrl_std
> ?* ?elm
> @@ -908,6 +916,168 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
> ?};
>
> ?/*
> + * 'debugss' class
> + * debug and emulation sub system
> + */
> +
> +static struct omap_hwmod_class_sysconfig omap44xx_debugss_sysc = {
> + ? ? ? .rev_offs ? ? ? = 0x0000,
> + ? ? ? .sysc_offs ? ? ?= 0x0010,
> + ? ? ? .syss_offs ? ? ?= 0x0014,
> + ? ? ? .sysc_flags ? ? = (SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
> + ? ? ? .sysc_fields ? ?= &omap_hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class omap44xx_debugss_hwmod_class = {
> + ? ? ? .name ? = "debugss",
> + ? ? ? .sysc ? = &omap44xx_debugss_sysc,
> +};
> +
> +/* debugss */
> +static struct omap_hwmod_irq_info omap44xx_debugss_irqs[] = {
> + ? ? ? { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
> + ? ? ? { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
> + ? ? ? { .irq = -1 }
> +};
> +
> +/* debugss master ports */
> +static struct omap_hwmod_ocp_if *omap44xx_debugss_masters[] = {
> + ? ? ? &omap44xx_debugss__l3_main_2,
> +};
> +
> +static struct omap_hwmod_addr_space omap44xx_debugss_addrs[] = {
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "mipi_stm_add_sp_0",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54000000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x540fffff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "mipi_stm_add_sp_1",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54100000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x5413ffff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "mpu_c0_debug",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54140000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54141fff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "mpu_c1_debug",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54142000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54143fff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "cti0_mpu",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54148000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54148fff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "cti1_mpu",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54149000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54149fff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "ptm0_mpu",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x5414c000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x5414cfff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "ptm1_mpu",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x5414d000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x5414dfff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "tf_mpu",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54158000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54158fff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "dap_pc_mpu",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54159000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54159fff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "apb_bridge_a_ctrl_time_out",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x5415f000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x5415ffff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "drm",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54160000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54160fff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "mipi_stm",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54161000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54161fff,
> + ? ? ? ? ? ? ? .flags ? ? ? ? ?= ADDR_TYPE_RT
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "csetb",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54162000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54162fff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "cstpiu",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54163000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54163fff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "cstf1",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54164000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54164fff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "cstf2",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54165000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54165fff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "l4_cfg_emu_conf_regs",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54167000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54167fff,
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .name ? ? ? ? ? = "l3_instr_emu_conf_regs",
> + ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54180000,
> + ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54180fff,
> + ? ? ? },
> + ? ? ? { }
> +};
> +
> +/* l3_instr -> debugss */
> +static struct omap_hwmod_ocp_if omap44xx_l3_instr__debugss = {
> + ? ? ? .master ? ? ? ? = &omap44xx_l3_instr_hwmod,
> + ? ? ? .slave ? ? ? ? ?= &omap44xx_debugss_hwmod,
> + ? ? ? .clk ? ? ? ? ? ?= "l3_div_ck",
> + ? ? ? .addr ? ? ? ? ? = omap44xx_debugss_addrs,
> + ? ? ? .user ? ? ? ? ? = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +/* debugss slave ports */
> +static struct omap_hwmod_ocp_if *omap44xx_debugss_slaves[] = {
> + ? ? ? &omap44xx_l3_instr__debugss,
> +};
> +
> +static struct omap_hwmod omap44xx_debugss_hwmod = {
> + ? ? ? .name ? ? ? ? ? = "debugss",
> + ? ? ? .class ? ? ? ? ?= &omap44xx_debugss_hwmod_class,
> + ? ? ? .clkdm_name ? ? = "emu_sys_clkdm",
> + ? ? ? .mpu_irqs ? ? ? = omap44xx_debugss_irqs,
> + ? ? ? .main_clk ? ? ? = "trace_clk_div_ck",
> + ? ? ? .prcm = {
> + ? ? ? ? ? ? ? .omap4 = {
> + ? ? ? ? ? ? ? ? ? ? ? .clkctrl_offs = OMAP4_CM_EMU_DEBUGSS_CLKCTRL_OFFSET,
> + ? ? ? ? ? ? ? ? ? ? ? .context_offs = OMAP4_RM_EMU_DEBUGSS_CONTEXT_OFFSET,
> + ? ? ? ? ? ? ? },
> + ? ? ? },
> + ? ? ? .slaves ? ? ? ? = omap44xx_debugss_slaves,
> + ? ? ? .slaves_cnt ? ? = ARRAY_SIZE(omap44xx_debugss_slaves),
> + ? ? ? .masters ? ? ? ?= omap44xx_debugss_masters,
> + ? ? ? .masters_cnt ? ?= ARRAY_SIZE(omap44xx_debugss_masters),
> +};
> +
> +/*
> ?* 'dma' class
> ?* dma controller for data exchange between memory to memory (i.e. internal or
> ?* external memory) and gp peripherals to memory or memory to gp peripherals
> @@ -3902,8 +4072,6 @@ static struct omap_hwmod_class omap44xx_mpu_hwmod_class = {
> ?/* mpu */
> ?static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = {
> ? ? ? ?{ .name = "pl310", .irq = 0 + OMAP44XX_IRQ_GIC_START },
> - ? ? ? { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
> - ? ? ? { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
> ? ? ? ?{ .irq = -1 }
> ?};
>
> @@ -5308,6 +5476,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
> ? ? ? ?/* counter class */
> ?/* ? ? &omap44xx_counter_32k_hwmod, */
>
> + ? ? ? /* debugss class */
> + ? ? ? &omap44xx_debugss_hwmod,
> +
> ? ? ? ?/* dma class */
> ? ? ? ?&omap44xx_dma_system_hwmod,
>
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Paul Walmsley]

Hi Beno?t,

a question about this patch.

On Fri, 18 Nov 2011, Cousson, Benoit wrote:

> From: Benoit Cousson <b-cousson@ti.com>
> Date: Fri, 18 Nov 2011 11:42:12 +0100
> Subject: [PATCH] ARM: OMAP4: hwmod data: Add support for the debug modules
> 
> The OMAP4 DEBUG subsystem contains all the IPs used for emulation,
> included the ones from the CortexA9 MPU.
> Expose the individual modules base address.
> 
> Re-map the CTIs IRQs from MPU to DEBUGSS.
> 
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Ming Lei <ming.lei@canonical.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  177 +++++++++++++++++++++++++++-
>  1 files changed, 174 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 7695e5d..6cf21ee 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -47,6 +47,7 @@
>  
>  /* Backward references (IPs with Bus Master capability) */
>  static struct omap_hwmod omap44xx_aess_hwmod;
> +static struct omap_hwmod omap44xx_debugss_hwmod;
>  static struct omap_hwmod omap44xx_dma_system_hwmod;
>  static struct omap_hwmod omap44xx_dmm_hwmod;
>  static struct omap_hwmod omap44xx_dsp_hwmod;
> @@ -337,6 +338,14 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
>  };
>  
>  /* l3_main_2 */
> +/* debugss -> l3_main_2 */
> +static struct omap_hwmod_ocp_if omap44xx_debugss__l3_main_2 = {
> +	.master		= &omap44xx_debugss_hwmod,
> +	.slave		= &omap44xx_l3_main_2_hwmod,
> +	.clk		= "dbgclk_mux_ck",
> +	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
>  /* dma_system -> l3_main_2 */
>  static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
>  	.master		= &omap44xx_dma_system_hwmod,
> @@ -686,7 +695,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
>   *  ctrl_module_pad_core
>   *  ctrl_module_pad_wkup
>   *  ctrl_module_wkup
> - *  debugss
>   *  efuse_ctrl_cust
>   *  efuse_ctrl_std
>   *  elm
> @@ -908,6 +916,168 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
>  };
>  
>  /*
> + * 'debugss' class
> + * debug and emulation sub system
> + */
> +
> +static struct omap_hwmod_class_sysconfig omap44xx_debugss_sysc = {
> +	.rev_offs	= 0x0000,
> +	.sysc_offs	= 0x0010,
> +	.syss_offs	= 0x0014,
> +	.sysc_flags	= (SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
> +	.sysc_fields	= &omap_hwmod_sysc_type1,
> +};

This defines the OCP register offsets for the DEBUGSS, but ...

> +static struct omap_hwmod_class omap44xx_debugss_hwmod_class = {
> +	.name	= "debugss",
> +	.sysc	= &omap44xx_debugss_sysc,
> +};
> +
> +/* debugss */
> +static struct omap_hwmod_irq_info omap44xx_debugss_irqs[] = {
> +	{ .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
> +	{ .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
> +	{ .irq = -1 }
> +};
> +
> +/* debugss master ports */
> +static struct omap_hwmod_ocp_if *omap44xx_debugss_masters[] = {
> +	&omap44xx_debugss__l3_main_2,
> +};
> +
> +static struct omap_hwmod_addr_space omap44xx_debugss_addrs[] = {
> +	{
> +		.name		= "mipi_stm_add_sp_0",
> +		.pa_start	= 0x54000000,
> +		.pa_end		= 0x540fffff,
> +	},
> +	{
> +		.name		= "mipi_stm_add_sp_1",
> +		.pa_start	= 0x54100000,
> +		.pa_end		= 0x5413ffff,
> +	},
> +	{
> +		.name		= "mpu_c0_debug",
> +		.pa_start	= 0x54140000,
> +		.pa_end		= 0x54141fff,
> +	},
> +	{
> +		.name		= "mpu_c1_debug",
> +		.pa_start	= 0x54142000,
> +		.pa_end		= 0x54143fff,
> +	},
> +	{
> +		.name		= "cti0_mpu",
> +		.pa_start	= 0x54148000,
> +		.pa_end		= 0x54148fff,
> +	},
> +	{
> +		.name		= "cti1_mpu",
> +		.pa_start	= 0x54149000,
> +		.pa_end		= 0x54149fff,
> +	},
> +	{
> +		.name		= "ptm0_mpu",
> +		.pa_start	= 0x5414c000,
> +		.pa_end		= 0x5414cfff,
> +	},
> +	{
> +		.name		= "ptm1_mpu",
> +		.pa_start	= 0x5414d000,
> +		.pa_end		= 0x5414dfff,
> +	},
> +	{
> +		.name		= "tf_mpu",
> +		.pa_start	= 0x54158000,
> +		.pa_end		= 0x54158fff,
> +	},
> +	{
> +		.name		= "dap_pc_mpu",
> +		.pa_start	= 0x54159000,
> +		.pa_end		= 0x54159fff,
> +	},
> +	{
> +		.name		= "apb_bridge_a_ctrl_time_out",
> +		.pa_start	= 0x5415f000,
> +		.pa_end		= 0x5415ffff,
> +	},
> +	{
> +		.name		= "drm",
> +		.pa_start	= 0x54160000,
> +		.pa_end		= 0x54160fff,
> +	},
> +	{
> +		.name		= "mipi_stm",
> +		.pa_start	= 0x54161000,
> +		.pa_end		= 0x54161fff,
> +		.flags		= ADDR_TYPE_RT
> +	},
> +	{
> +		.name		= "csetb",
> +		.pa_start	= 0x54162000,
> +		.pa_end		= 0x54162fff,
> +	},
> +	{
> +		.name		= "cstpiu",
> +		.pa_start	= 0x54163000,
> +		.pa_end		= 0x54163fff,
> +	},
> +	{
> +		.name		= "cstf1",
> +		.pa_start	= 0x54164000,
> +		.pa_end		= 0x54164fff,
> +	},
> +	{
> +		.name		= "cstf2",
> +		.pa_start	= 0x54165000,
> +		.pa_end		= 0x54165fff,
> +	},
> +	{
> +		.name		= "l4_cfg_emu_conf_regs",
> +		.pa_start	= 0x54167000,
> +		.pa_end		= 0x54167fff,
> +	},
> +	{
> +		.name		= "l3_instr_emu_conf_regs",
> +		.pa_start	= 0x54180000,
> +		.pa_end		= 0x54180fff,
> +	},
> +	{ }
> +};

... none of the address spaces above have the ADDR_TYPE_RT flag set.
Without this flag set, the hwmod code won't know where to access the OCP 
registers.

>From the basic documentation that I have here, it's not clear to me where 
the SYSCONFIG registers are located?


- Paul

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Paul Walmsley]

On Sat, 26 Nov 2011, Paul Walmsley wrote:

> Hi Beno?t,
> 
> a question about this patch.

...

> > +		.name		= "mipi_stm",
> > +		.pa_start	= 0x54161000,
> > +		.pa_end		= 0x54161fff,
> > +		.flags		= ADDR_TYPE_RT

> ... none of the address spaces above have the ADDR_TYPE_RT flag set.
> Without this flag set, the hwmod code won't know where to access the OCP 
> registers.

Ugh, it's above; I just missed it.  Sorry about that.

So just out of curiosity, do those SYSCONFIG registers in the STM address 
space apply to the entire DEBUGSS, or just the STM IP block?


- Paul

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Cousson, Benoit]

Hi Paul,

On 11/27/2011 3:07 AM, Paul Walmsley wrote:
> On Sat, 26 Nov 2011, Paul Walmsley wrote:
>
>> Hi Beno?t,
>>
>> a question about this patch.
>
> ...
>
>>> +		.name		= "mipi_stm",
>>> +		.pa_start	= 0x54161000,
>>> +		.pa_end		= 0x54161fff,
>>> +		.flags		= ADDR_TYPE_RT
>
>> ... none of the address spaces above have the ADDR_TYPE_RT flag set.
>> Without this flag set, the hwmod code won't know where to access the OCP
>> registers.
>
> Ugh, it's above; I just missed it.  Sorry about that.
>
> So just out of curiosity, do those SYSCONFIG registers in the STM address
> space apply to the entire DEBUGSS, or just the STM IP block?

The STM IP is the only one to have the TI generic wrapper to be 
compliant with TI standards.
But in term of PRCM, there is only one IP, the DEBUGSS.
There are probably a bunch of internal clock management inside it that 
are not exposed to PRCM.

The confusing part is that in theory all these entries can be accessed 
by the same OCP port, and should potentially have this flags.
The point is that for the moment, we are mainly using that flag to get 
the SYSCONFIG.
We already discussed that, but I think we should modify this flag to 
highlight the SYSCONFIG / SYSSTATUS availability.
Maybe with something like ADDR_SYSCONFIG?

Any thought?

Regards,
Benoit

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Paul Walmsley]

On Tue, 29 Nov 2011, Cousson, Benoit wrote:

> On 11/27/2011 3:07 AM, Paul Walmsley wrote:
> 
> > So just out of curiosity, do those SYSCONFIG registers in the STM address
> > space apply to the entire DEBUGSS, or just the STM IP block?
> 
> The STM IP is the only one to have the TI generic wrapper to be compliant with
> TI standards.
> But in term of PRCM, there is only one IP, the DEBUGSS.
> There are probably a bunch of internal clock management inside it that are not
> exposed to PRCM.
> 
> The confusing part is that in theory all these entries can be accessed by the
> same OCP port, and should potentially have this flags.
> The point is that for the moment, we are mainly using that flag to get the
> SYSCONFIG.
> We already discussed that, but I think we should modify this flag to highlight
> the SYSCONFIG / SYSSTATUS availability.
> Maybe with something like ADDR_SYSCONFIG?
> 
> Any thought?

Well, the ADDR_TYPE_RT flag in this hwmod would indicate the address space 
of the DEBUGSS's OCP header registers, not the MIPI STM's OCP header 
registers.

So if the MIPI STM's OCP header registers also control the entire DEBUGSS 
power management, then the current layout makes sense.  Otherwise, the 
MIPI STM should be created as a separate hwmod.

It appears to me that the DEBUGSS has no OCP header registers of its own.  
Upon reflection, rather than creating a macro hwmod for the DEBUGSS, it 
seems to make more sense to add hwmods for its two internal interconnects, 
then to create another hwmod for the MIPI STM device.


- Paul

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Cousson, Benoit]

Hi Paul,

On 11/29/2011 7:11 PM, Paul Walmsley wrote:
> On Tue, 29 Nov 2011, Cousson, Benoit wrote:
>
>> On 11/27/2011 3:07 AM, Paul Walmsley wrote:
>>
>>> So just out of curiosity, do those SYSCONFIG registers in the STM address
>>> space apply to the entire DEBUGSS, or just the STM IP block?
>>
>> The STM IP is the only one to have the TI generic wrapper to be compliant with
>> TI standards.
>> But in term of PRCM, there is only one IP, the DEBUGSS.
>> There are probably a bunch of internal clock management inside it that are not
>> exposed to PRCM.
>>
>> The confusing part is that in theory all these entries can be accessed by the
>> same OCP port, and should potentially have this flags.
>> The point is that for the moment, we are mainly using that flag to get the
>> SYSCONFIG.
>> We already discussed that, but I think we should modify this flag to highlight
>> the SYSCONFIG / SYSSTATUS availability.
>> Maybe with something like ADDR_SYSCONFIG?
>>
>> Any thought?
>
> Well, the ADDR_TYPE_RT flag in this hwmod would indicate the address space
> of the DEBUGSS's OCP header registers, not the MIPI STM's OCP header
> registers.
>
> So if the MIPI STM's OCP header registers also control the entire DEBUGSS
> power management, then the current layout makes sense.  Otherwise, the
> MIPI STM should be created as a separate hwmod.

There is no OCP TA registers in this case, so finding the SYSCONFIG is 
the only important thing to do to set them properly at boot time.

> It appears to me that the DEBUGSS has no OCP header registers of its own.

Yes, indeed.

> Upon reflection, rather than creating a macro hwmod for the DEBUGSS, it
> seems to make more sense to add hwmods for its two internal interconnects,
> then to create another hwmod for the MIPI STM device.

Mmm, I'm not sure it makes sense to do that. There is only one PRCM 
control entry for all these IPs inside the debugss "module". The diagram 
28.9 seems to indicate that the STM is accessed through L3_INSTR using 
some internals L4_CFG_EMU and L3_INSTR_EMU buses.

So for the hwmod / driver point of view having only one node for the 
debugss IPs connected to L3_INSTR is accurate enough. This is as well 
how the memory mapping is represented in the 28-42 table (28.11$).

Moreover, having two different nodes controlled by a single PRCM entry 
will raise some dependency issue with STM and DEBUGSS.

Splitting them will add some extra complexity that is not necessary in 
our case.

Regards,
Benoit

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Paul Walmsley]

Hi

I just read 

http://comments.gmane.org/gmane.comp.embedded.pandaboard/168

Looks to me that the L3_EMU interconnect and the emulation IP blocks need 
to be added to the OMAP4 hwmod data, based on Section 2.2.1 "L3_EMU Memory 
Space Mapping" in the OMAP4460 TRM Rev. I.  If the clockdomain & 
powerdomain are correctly defined then the OMAP framework code will 
automatically enable these too.



- Paul

[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod

[Ming Lei]

Hi,

On Tue, Nov 8, 2011 at 11:42 PM, Paul Walmsley <paul@pwsan.com> wrote:
>
> Hi
>
> I just read
>
> http://comments.gmane.org/gmane.comp.embedded.pandaboard/168
>
> Looks to me that the L3_EMU interconnect and the emulation IP blocks need

You mean the "emu" hwmod in the patch should be kept and a new "l3_emu" hwmod
need to be added? and make the clkdm_name of 'l3_emu' points to CD_L3_2?

But in the link above, looks like the hwmod of "l3_main_3" and "l3_instr" need
to be enabled for routing IRQs of pmu on omap4.

> to be added to the OMAP4 hwmod data, based on Section 2.2.1 "L3_EMU Memory
> Space Mapping" in the OMAP4460 TRM Rev. I. ?If the clockdomain &
> powerdomain are correctly defined then the OMAP framework code will
> automatically enable these too.

thanks,
--
Ming Lei

[PATCH v5 5/7] arm: omap4: create pmu device via hwmod

[ming.lei at canonical.com]

From: Ming Lei <ming.lei@canonical.com>

The following modules is required to be enabled before configuring
cross trigger interface for enabling pmu irq:

        emu, l3_instr, l3_main_3

so build the arm-pmu device via the three hwmods.

Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/mach-omap2/devices.c |   61 ++++++++++++++++++++++++++++++++++++++---
 1 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 0f8e0eb..6e16274 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -384,14 +384,67 @@ static struct platform_device omap_pmu_device = {
 	.num_resources	= 1,
 };
 
-static void omap_init_pmu(void)
+static struct arm_pmu_platdata omap4_pmu_data;
+static struct omap_device_pm_latency omap_pmu_latency[] = {
+	[0] = {
+		.deactivate_func = omap_device_idle_hwmods,
+		.activate_func   = omap_device_enable_hwmods,
+		.flags		 = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+	},
+};
+
+static struct platform_device* __init omap4_init_pmu(void)
 {
-	if (cpu_is_omap24xx())
+	int id = -1;
+	const char *hw;
+	struct platform_device *pd;
+	struct omap_hwmod* oh[3];
+	char *dev_name = "arm-pmu";
+
+	hw = "l3_main_3";
+	oh[0] = omap_hwmod_lookup(hw);
+	if (!oh[0]) {
+		pr_err("Could not look up %s hwmod\n", hw);
+		return NULL;
+	}
+	hw = "l3_instr";
+	oh[1] = omap_hwmod_lookup(hw);
+	if (!oh[1]) {
+		pr_err("Could not look up %s hwmod\n", hw);
+		return NULL;
+	}
+	hw = "emu";
+	oh[2] = omap_hwmod_lookup(hw);
+	if (!oh[2]) {
+		pr_err("Could not look up %s hwmod\n", hw);
+		return NULL;
+	}
+
+	pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
+				sizeof(omap4_pmu_data),
+				omap_pmu_latency,
+				ARRAY_SIZE(omap_pmu_latency), 0);
+	WARN(IS_ERR(pd), "Can't build omap_device for %s.\n",
+				dev_name);
+	return pd;
+}
+static void __init omap_init_pmu(void)
+{
+	if (cpu_is_omap24xx()) {
 		omap_pmu_device.resource = &omap2_pmu_resource;
-	else if (cpu_is_omap34xx())
+	} else if (cpu_is_omap34xx()) {
 		omap_pmu_device.resource = &omap3_pmu_resource;
-	else
+	} else if (cpu_is_omap44xx()) {
+		struct platform_device *pd;
+
+		pd = omap4_init_pmu();
+		if (!pd)
+			return;
+		omap_device_enable(pd);
+		return;
+	} else {
 		return;
+	}
 
 	platform_device_register(&omap_pmu_device);
 }
-- 
1.7.5.4

[PATCH v5 6/7] arm: omap4: support pmu

[ming.lei at canonical.com]

From: Ming Lei <ming.lei@canonical.com>

This patch supports pmu irq routed from CTI, so
make pmu/perf working on OMAP4.

The idea is from Woodruff Richard in the disscussion
about "Oprofile on Pandaboard / Omap4" on pandaboard at googlegroups.com.

Acked-by: Jean Pihet <j-pihet@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Woodruff Richard <r-woodruff2@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/mach-omap2/devices.c              |   60 +++++++++++++++++++++++++++-
 arch/arm/plat-omap/include/plat/omap44xx.h |    3 +
 2 files changed, 62 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 6e16274..bc791e0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -23,6 +23,7 @@
 #include <asm/mach-types.h>
 #include <asm/mach/map.h>
 #include <asm/pmu.h>
+#include <asm/cti.h>
 
 #include <plat/tc.h>
 #include <plat/board.h>
@@ -393,6 +394,57 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
 	},
 };
 
+static struct cti omap4_cti[2];
+
+static void omap4_enable_cti(int irq)
+{
+	if (irq == OMAP44XX_IRQ_CTI0)
+		cti_enable(&omap4_cti[0]);
+	else if (irq == OMAP44XX_IRQ_CTI1)
+		cti_enable(&omap4_cti[1]);
+}
+
+static void omap4_disable_cti(int irq)
+{
+	if (irq == OMAP44XX_IRQ_CTI0)
+		cti_disable(&omap4_cti[0]);
+	else if (irq == OMAP44XX_IRQ_CTI1)
+		cti_disable(&omap4_cti[1]);
+}
+
+static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t handler)
+{
+	if (irq == OMAP44XX_IRQ_CTI0)
+		cti_irq_ack(&omap4_cti[0]);
+	else if (irq == OMAP44XX_IRQ_CTI1)
+		cti_irq_ack(&omap4_cti[1]);
+
+	return handler(irq, dev);
+}
+
+static void __init omap4_configure_pmu_irq(void)
+{
+	void __iomem *base0;
+	void __iomem *base1;
+
+	base0 = ioremap(OMAP44XX_CTI0_BASE, SZ_4K);
+	base1 = ioremap(OMAP44XX_CTI1_BASE, SZ_4K);
+	if (!base0 && !base1) {
+		pr_err("ioremap for OMAP4 CTI failed\n");
+		return;
+	}
+
+	/*configure CTI0 for pmu irq routing*/
+	cti_init(&omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
+	cti_unlock(&omap4_cti[0]);
+	cti_map_trigger(&omap4_cti[0], 1, 6, 2);
+
+	/*configure CTI1 for pmu irq routing*/
+	cti_init(&omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6);
+	cti_unlock(&omap4_cti[1]);
+	cti_map_trigger(&omap4_cti[1], 1, 6, 2);
+}
+
 static struct platform_device* __init omap4_init_pmu(void)
 {
 	int id = -1;
@@ -420,6 +472,10 @@ static struct platform_device* __init omap4_init_pmu(void)
 		return NULL;
 	}
 
+	omap4_pmu_data.handle_irq = omap4_pmu_handler;
+	omap4_pmu_data.enable_irq = omap4_enable_cti;
+	omap4_pmu_data.disable_irq = omap4_disable_cti;
+
 	pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
 				sizeof(omap4_pmu_data),
 				omap_pmu_latency,
@@ -440,7 +496,9 @@ static void __init omap_init_pmu(void)
 		pd = omap4_init_pmu();
 		if (!pd)
 			return;
-		omap_device_enable(pd);
+
+		omap_device_enable(&od->pdev);
+		omap4_configure_pmu_irq();
 		return;
 	} else {
 		return;
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h
index ea2b8a6..4637980 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -57,5 +57,8 @@
 #define OMAP44XX_HSUSB_OHCI_BASE	(L4_44XX_BASE + 0x64800)
 #define OMAP44XX_HSUSB_EHCI_BASE	(L4_44XX_BASE + 0x64C00)
 
+#define OMAP44XX_CTI0_BASE		0x54148000
+#define OMAP44XX_CTI1_BASE		0x54149000
+
 #endif /* __ASM_ARCH_OMAP44XX_H */
 
-- 
1.7.5.4

[PATCH v5 6/7] arm: omap4: support pmu

[Rabin Vincent]

On Mon, Oct 24, 2011 at 20:15,  <ming.lei@canonical.com> wrote:
> ?static struct platform_device* __init omap4_init_pmu(void)
> ?{
> ? ? ? ?int id = -1;
> @@ -420,6 +472,10 @@ static struct platform_device* __init omap4_init_pmu(void)
> ? ? ? ? ? ? ? ?return NULL;
> ? ? ? ?}
>
> + ? ? ? omap4_pmu_data.handle_irq = omap4_pmu_handler;
> + ? ? ? omap4_pmu_data.enable_irq = omap4_enable_cti;
> + ? ? ? omap4_pmu_data.disable_irq = omap4_disable_cti;
> +
> ? ? ? ?pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sizeof(omap4_pmu_data),
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?omap_pmu_latency,
> @@ -440,7 +496,9 @@ static void __init omap_init_pmu(void)
> ? ? ? ? ? ? ? ?pd = omap4_init_pmu();
> ? ? ? ? ? ? ? ?if (!pd)
> ? ? ? ? ? ? ? ? ? ? ? ?return;
> - ? ? ? ? ? ? ? omap_device_enable(pd);
> +
> + ? ? ? ? ? ? ? omap_device_enable(&od->pdev);
> + ? ? ? ? ? ? ? omap4_configure_pmu_irq();

This doesn't build, because there's no "od" in this function.  I guess
you shouldn't be changing the omap_device_enable() call.

[PATCH v5 6/7] arm: omap4: support pmu

[Ming Lei]

Hi,

On Thu, Nov 24, 2011 at 1:47 AM, Rabin Vincent <rabin@rab.in> wrote:
> On Mon, Oct 24, 2011 at 20:15, ?<ming.lei@canonical.com> wrote:
>> ?static struct platform_device* __init omap4_init_pmu(void)
>> ?{
>> ? ? ? ?int id = -1;
>> @@ -420,6 +472,10 @@ static struct platform_device* __init omap4_init_pmu(void)
>> ? ? ? ? ? ? ? ?return NULL;
>> ? ? ? ?}
>>
>> + ? ? ? omap4_pmu_data.handle_irq = omap4_pmu_handler;
>> + ? ? ? omap4_pmu_data.enable_irq = omap4_enable_cti;
>> + ? ? ? omap4_pmu_data.disable_irq = omap4_disable_cti;
>> +
>> ? ? ? ?pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sizeof(omap4_pmu_data),
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?omap_pmu_latency,
>> @@ -440,7 +496,9 @@ static void __init omap_init_pmu(void)
>> ? ? ? ? ? ? ? ?pd = omap4_init_pmu();
>> ? ? ? ? ? ? ? ?if (!pd)
>> ? ? ? ? ? ? ? ? ? ? ? ?return;
>> - ? ? ? ? ? ? ? omap_device_enable(pd);
>> +
>> + ? ? ? ? ? ? ? omap_device_enable(&od->pdev);
>> + ? ? ? ? ? ? ? omap4_configure_pmu_irq();
>
> This doesn't build, because there's no "od" in this function. ?I guess
> you shouldn't be changing the omap_device_enable() call.

Yes, you are right. Looks like this version is against linus tree, and
I have another version against -next tree, which uses the latest
'debugss' module and will be sent out later.


thanks,
--
Ming Lei

[PATCH v5 7/7] arm: omap4: pmu: support runtime pm

[ming.lei at canonical.com]

From: Ming Lei <ming.lei@canonical.com>

Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 arch/arm/mach-omap2/devices.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index bc791e0..ab4de0d 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -17,6 +17,7 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <linux/of.h>
+#include <linux/pm_runtime.h>
 
 #include <mach/hardware.h>
 #include <mach/irqs.h>
@@ -395,9 +396,11 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
 };
 
 static struct cti omap4_cti[2];
+static struct platform_device *pmu_dev;
 
 static void omap4_enable_cti(int irq)
 {
+	pm_runtime_get_sync(&pmu_dev->dev);
 	if (irq == OMAP44XX_IRQ_CTI0)
 		cti_enable(&omap4_cti[0]);
 	else if (irq == OMAP44XX_IRQ_CTI1)
@@ -410,6 +413,7 @@ static void omap4_disable_cti(int irq)
 		cti_disable(&omap4_cti[0]);
 	else if (irq == OMAP44XX_IRQ_CTI1)
 		cti_disable(&omap4_cti[1]);
+	pm_runtime_put(&pmu_dev->dev);
 }
 
 static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t handler)
@@ -497,8 +501,11 @@ static void __init omap_init_pmu(void)
 		if (!pd)
 			return;
 
-		omap_device_enable(&od->pdev);
+		pmu_dev= pd;
+		pm_runtime_enable(&pd->dev);
+		pm_runtime_get_sync(&pd->dev);
 		omap4_configure_pmu_irq();
+		pm_runtime_put(&pd->dev);
 		return;
 	} else {
 		return;
-- 
1.7.5.4