[PATCH V3 0/8] ARM: OMAP4: Add PMU Support

[PATCH V3 0/8] ARM: OMAP4: Add PMU Support

[Jon Hunter]

This series adds PMU support for OMAP4 devices. This is based upon Will Deacons
series [1] and re-based upon the latest arm-soc next/cleanup branch (3.6-rc3)
that includes Will's series. It has been re-based upon this series because
of the dependency on Sudeep KarkadaNagesha's change (ARM: pmu: remove
arm_pmu_type enumeration) [2] that modifies the OMAP PMU code.

This series is also dependent upon some clock fixes for OMAP3 [3] and OMAP4 [4]
for PMU to operate correctly on OMAP3 and OMAP4.

This series also converts OMAP2/3 devices to use HWMOD to create the PMU device
and add a new file to mach-omap2 directory called pmu.c where the PMU devices
are created.

Testing:
- Verified that PMU is working on OMAP2420 H4, OMAP3430 Beagle Board, OMAP4430
  Panda and OMAP4460 Panda.
- Tested on the above boards with CPU-idle enabled to ensure that PMU is working
  with power management. For OMAP3430 verified that CORE retention state is
  entered again after stopping PMU events.

V3 changes:
- Will Deacon has taken the PMU runtime PM adaption patch in his series and so
  not included here [1].
- Dropped my fix for managing the EMU power domain on OMAP4 in favour of Paul's
  implementation [4]. Paul is planning to submit for v3.7.
- Added HWMOD data for OMAP3 DEBUG sub-system. The DEBUG sub-system was always
  being enabled on OMAP3 devices when using PMU and hence, hinding the fact
  that PMU is dependent upon the DEBUG sub-system on OMAP3 for it to work.

[1] git://git.kernel.org/pub/sicm/linux/kernel/git/will/linux.git perf/updates
[2] http://www.spinics.net/lists/arm-kernel/msg188726.html
[3] http://marc.info/?l=linux-omap&m=134333691309305&w=2
[4] http://marc.info/?l=linux-arm-kernel&m=134383567112518&w=2

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>

Jon Hunter (6):
  ARM: OMAP3: Add debugss HWMOD data
  ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD
  ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS
  ARM: OMAP2+: PMU: Add runtime PM support
  ARM: OMAP4: Enable PMU for OMAP4460/70
  ARM: OMAP2+: PMU: Add QoS constraint

Ming Lei (2):
  ARM: OMAP4430: Create PMU device via HWMOD
  ARM: OMAP4: Route PMU IRQs to CTI IRQs

 arch/arm/mach-omap2/Makefile                       |    1 +
 arch/arm/mach-omap2/devices.c                      |   32 ---
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |    6 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |   32 +++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |   11 +-
 arch/arm/mach-omap2/pmu.c                          |  233 ++++++++++++++++++++
 arch/arm/plat-omap/include/plat/irqs.h             |    1 +
 arch/arm/plat-omap/include/plat/omap44xx.h         |    3 +
 8 files changed, 285 insertions(+), 34 deletions(-)
 create mode 100644 arch/arm/mach-omap2/pmu.c

-- 
1.7.9.5

[PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data

[Jon Hunter]

To enable PMU with runtime PM support on OMAP3 devices we need to be able to
dynamically enable and disable the debug sub-system at runtime. By adding HWMOD
data for the debug sub-system for OMAP3, we can build the PMU device using the
debug sub-system HWMOD and control this power domain using runtime PM.

Reviewed-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c9e3820..78a0c2d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -114,6 +114,24 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
 	.main_clk	= "iva2_ck",
 };
 
+/*
+ * 'debugss' class
+ * debug and emulation sub system
+ */
+
+static struct omap_hwmod_class omap3xxx_debugss_hwmod_class = {
+	.name	= "debugss",
+};
+
+/* debugss */
+static struct omap_hwmod omap3xxx_debugss_hwmod = {
+	.name		= "debugss",
+	.class		= &omap3xxx_debugss_hwmod_class,
+	.clkdm_name	= "emu_clkdm",
+	.main_clk	= "emu_src_ck",
+	.flags		= HWMOD_NO_IDLEST,
+};
+
 /* timer class */
 static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = {
 	.rev_offs	= 0x0000,
@@ -2093,6 +2111,13 @@ static struct omap_hwmod_ocp_if omap3xxx_mpu__l3_main = {
 	.user	= OCP_USER_MPU,
 };
 
+/* l3 -> debugss */
+static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_debugss = {
+	.master		= &omap3xxx_l3_main_hwmod,
+	.slave		= &omap3xxx_debugss_hwmod,
+	.user		= OCP_USER_MPU,
+};
+
 /* DSS -> l3 */
 static struct omap_hwmod_ocp_if omap3430es1_dss__l3 = {
 	.master		= &omap3430es1_dss_core_hwmod,
@@ -3272,6 +3297,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[] __initdata = {
 	&omap3xxx_l3_main__l4_core,
 	&omap3xxx_l3_main__l4_per,
 	&omap3xxx_mpu__l3_main,
+	&omap3xxx_l3_main__l4_debugss,
 	&omap3xxx_l4_core__l4_wkup,
 	&omap3xxx_l4_core__mmc3,
 	&omap3_l4_core__uart1,
-- 
1.7.9.5

Re: [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data

[Jon Hunter]

Oops meant to have Paul on the TO! Jon

On 09/10/2012 10:23 AM, Jon Hunter wrote:
> To enable PMU with runtime PM support on OMAP3 devices we need to be able to
> dynamically enable and disable the debug sub-system at runtime. By adding HWMOD
> data for the debug sub-system for OMAP3, we can build the PMU device using the
> debug sub-system HWMOD and control this power domain using runtime PM.
> 
> Reviewed-by: Benoit Cousson <b-cousson@ti.com>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index c9e3820..78a0c2d 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -114,6 +114,24 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
>  	.main_clk	= "iva2_ck",
>  };
>  
> +/*
> + * 'debugss' class
> + * debug and emulation sub system
> + */
> +
> +static struct omap_hwmod_class omap3xxx_debugss_hwmod_class = {
> +	.name	= "debugss",
> +};
> +
> +/* debugss */
> +static struct omap_hwmod omap3xxx_debugss_hwmod = {
> +	.name		= "debugss",
> +	.class		= &omap3xxx_debugss_hwmod_class,
> +	.clkdm_name	= "emu_clkdm",
> +	.main_clk	= "emu_src_ck",
> +	.flags		= HWMOD_NO_IDLEST,
> +};
> +
>  /* timer class */
>  static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = {
>  	.rev_offs	= 0x0000,
> @@ -2093,6 +2111,13 @@ static struct omap_hwmod_ocp_if omap3xxx_mpu__l3_main = {
>  	.user	= OCP_USER_MPU,
>  };
>  
> +/* l3 -> debugss */
> +static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_debugss = {
> +	.master		= &omap3xxx_l3_main_hwmod,
> +	.slave		= &omap3xxx_debugss_hwmod,
> +	.user		= OCP_USER_MPU,
> +};
> +
>  /* DSS -> l3 */
>  static struct omap_hwmod_ocp_if omap3430es1_dss__l3 = {
>  	.master		= &omap3430es1_dss_core_hwmod,
> @@ -3272,6 +3297,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[] __initdata = {
>  	&omap3xxx_l3_main__l4_core,
>  	&omap3xxx_l3_main__l4_per,
>  	&omap3xxx_mpu__l3_main,
> +	&omap3xxx_l3_main__l4_debugss,
>  	&omap3xxx_l4_core__l4_wkup,
>  	&omap3xxx_l4_core__mmc3,
>  	&omap3_l4_core__uart1,
> 

Re: [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data

[Paul Walmsley]

Hi Jon

On Mon, 10 Sep 2012, Jon Hunter wrote:

> To enable PMU with runtime PM support on OMAP3 devices we need to be able to
> dynamically enable and disable the debug sub-system at runtime. By adding HWMOD
> data for the debug sub-system for OMAP3, we can build the PMU device using the
> debug sub-system HWMOD and control this power domain using runtime PM.
> 
> Reviewed-by: Benoit Cousson <b-cousson@ti.com>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

Isn't this patch missing MPU address ranges?  Looking at the OMAP4 TRM 
Table 2-2 "L3_EMU Memory Space Mapping" it should cover 
0x54000000-0x541fffff?

> ---
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index c9e3820..78a0c2d 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -114,6 +114,24 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
>  	.main_clk	= "iva2_ck",
>  };
>  
> +/*
> + * 'debugss' class
> + * debug and emulation sub system
> + */
> +
> +static struct omap_hwmod_class omap3xxx_debugss_hwmod_class = {
> +	.name	= "debugss",
> +};
> +
> +/* debugss */
> +static struct omap_hwmod omap3xxx_debugss_hwmod = {
> +	.name		= "debugss",
> +	.class		= &omap3xxx_debugss_hwmod_class,
> +	.clkdm_name	= "emu_clkdm",
> +	.main_clk	= "emu_src_ck",
> +	.flags		= HWMOD_NO_IDLEST,
> +};
> +
>  /* timer class */
>  static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = {
>  	.rev_offs	= 0x0000,
> @@ -2093,6 +2111,13 @@ static struct omap_hwmod_ocp_if omap3xxx_mpu__l3_main = {
>  	.user	= OCP_USER_MPU,
>  };
>  
> +/* l3 -> debugss */
> +static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_debugss = {
> +	.master		= &omap3xxx_l3_main_hwmod,
> +	.slave		= &omap3xxx_debugss_hwmod,
> +	.user		= OCP_USER_MPU,
> +};
> +
>  /* DSS -> l3 */
>  static struct omap_hwmod_ocp_if omap3430es1_dss__l3 = {
>  	.master		= &omap3430es1_dss_core_hwmod,
> @@ -3272,6 +3297,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[] __initdata = {
>  	&omap3xxx_l3_main__l4_core,
>  	&omap3xxx_l3_main__l4_per,
>  	&omap3xxx_mpu__l3_main,
> +	&omap3xxx_l3_main__l4_debugss,
>  	&omap3xxx_l4_core__l4_wkup,
>  	&omap3xxx_l4_core__mmc3,
>  	&omap3_l4_core__uart1,
> -- 
> 1.7.9.5


- Paul

Re: [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data

[Paul Walmsley]

On Wed, 19 Sep 2012, Paul Walmsley wrote:

> On Mon, 10 Sep 2012, Jon Hunter wrote:
> 
> > To enable PMU with runtime PM support on OMAP3 devices we need to be able to
> > dynamically enable and disable the debug sub-system at runtime. By adding HWMOD
> > data for the debug sub-system for OMAP3, we can build the PMU device using the
> > debug sub-system HWMOD and control this power domain using runtime PM.
> > 
> > Reviewed-by: Benoit Cousson <b-cousson@ti.com>
> > Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> 
> Isn't this patch missing MPU address ranges?  Looking at the OMAP4 TRM 
> Table 2-2 "L3_EMU Memory Space Mapping" it should cover 
> 0x54000000-0x541fffff?

Looks like Jon is out of the office at the moment.  So this one has been 
updated locally to add the _OMAP3_ address space from the TRM (my earlier 
message referred incorrectly to the OMAP4 address space).  Updated patch 
below.


- Paul

From: Jon Hunter <jon-hunter@ti.com>
Date: Thu, 20 Sep 2012 01:59:37 -0600
Subject: [PATCH] ARM: OMAP3: hwmod data: Add debugss HWMOD data

To enable PMU with runtime PM support on OMAP3 devices we need to be able to
dynamically enable and disable the debug sub-system at runtime. By adding HWMOD
data for the debug sub-system for OMAP3, we can build the PMU device using the
debug sub-system HWMOD and control this power domain using runtime PM.

Reviewed-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply; added L4-EMU address space]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   36 ++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 4606351..fc64454 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -124,6 +124,24 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
 	},
 };
 
+/*
+ * 'debugss' class
+ * debug and emulation sub system
+ */
+
+static struct omap_hwmod_class omap3xxx_debugss_hwmod_class = {
+	.name	= "debugss",
+};
+
+/* debugss */
+static struct omap_hwmod omap3xxx_debugss_hwmod = {
+	.name		= "debugss",
+	.class		= &omap3xxx_debugss_hwmod_class,
+	.clkdm_name	= "emu_clkdm",
+	.main_clk	= "emu_src_ck",
+	.flags		= HWMOD_NO_IDLEST,
+};
+
 /* timer class */
 static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = {
 	.rev_offs	= 0x0000,
@@ -2186,6 +2204,23 @@ static struct omap_hwmod_ocp_if omap3xxx_mpu__l3_main = {
 	.user	= OCP_USER_MPU,
 };
 
+static struct omap_hwmod_addr_space omap3xxx_l4_emu_addrs[] = {
+	{
+		.pa_start	= 0x54000000,
+		.pa_end		= 0x547fffff,
+		.flags		= ADDR_TYPE_RT,
+	},
+	{ }
+};
+
+/* l3 -> debugss */
+static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_debugss = {
+	.master		= &omap3xxx_l3_main_hwmod,
+	.slave		= &omap3xxx_debugss_hwmod,
+	.addr		= &omap3xxx_l4_emu_hwmod,
+	.user		= OCP_USER_MPU,
+};
+
 /* DSS -> l3 */
 static struct omap_hwmod_ocp_if omap3430es1_dss__l3 = {
 	.master		= &omap3430es1_dss_core_hwmod,
@@ -3506,6 +3541,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[] __initdata = {
 	&omap3xxx_l3_main__l4_core,
 	&omap3xxx_l3_main__l4_per,
 	&omap3xxx_mpu__l3_main,
+	&omap3xxx_l3_main__l4_debugss,
 	&omap3xxx_l4_core__l4_wkup,
 	&omap3xxx_l4_core__mmc3,
 	&omap3_l4_core__uart1,
-- 
1.7.10.4

Re: [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data

[Jon Hunter]

Hi Paul,

On 09/20/2012 12:13 PM, Paul Walmsley wrote:
> On Wed, 19 Sep 2012, Paul Walmsley wrote:
> 
>> On Mon, 10 Sep 2012, Jon Hunter wrote:
>>
>>> To enable PMU with runtime PM support on OMAP3 devices we need to be able to
>>> dynamically enable and disable the debug sub-system at runtime. By adding HWMOD
>>> data for the debug sub-system for OMAP3, we can build the PMU device using the
>>> debug sub-system HWMOD and control this power domain using runtime PM.
>>>
>>> Reviewed-by: Benoit Cousson <b-cousson@ti.com>
>>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>>
>> Isn't this patch missing MPU address ranges?  Looking at the OMAP4 TRM 
>> Table 2-2 "L3_EMU Memory Space Mapping" it should cover 
>> 0x54000000-0x541fffff?
> 
> Looks like Jon is out of the office at the moment.  So this one has been 
> updated locally to add the _OMAP3_ address space from the TRM (my earlier 
> message referred incorrectly to the OMAP4 address space).  Updated patch 
> below.

Thanks for catching that. Was not needed for PMU use-case but I should
have added that for other use-cases.

Cheers
Jon

[PATCH V3 2/8] ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD

[Jon Hunter]

Convert OMAP2/3 devices to use HWMOD for creating a PMU device. To support PMU
on OMAP2 devices we only need to use MPU sub-system and so we can simply use
the MPU HWMOD to create the PMU device. To support PMU on OMAP3 devices, we need
to use the MPU and DEBUG sub-systems and so use these HWMODs to create the PMU
device for OMAP3.

The MPU HWMOD for OMAP2/3 devices is currently missing the PMU interrupt and so
add the PMU interrupt to the MPU HWMOD for these devices.

This change also moves the PMU code out of the mach-omap2/devices.c files into
its own pmu.c file as suggested by Kevin Hilman to de-clutter devices.c.

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/Makefile                       |    1 +
 arch/arm/mach-omap2/devices.c                      |   32 --------
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |    6 ++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    6 ++
 arch/arm/mach-omap2/pmu.c                          |   83 ++++++++++++++++++++
 arch/arm/plat-omap/include/plat/irqs.h             |    1 +
 6 files changed, 97 insertions(+), 32 deletions(-)
 create mode 100644 arch/arm/mach-omap2/pmu.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f6a24b3..9d533b7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -198,6 +198,7 @@ obj-$(CONFIG_ARCH_OMAP4)		+= omap_hwmod_44xx_data.o
 
 # EMU peripherals
 obj-$(CONFIG_OMAP3_EMU)			+= emu.o
+obj-$(CONFIG_HW_PERF_EVENTS)		+= pmu.o
 
 # L3 interconnect
 obj-$(CONFIG_ARCH_OMAP3)		+= omap_l3_smx.o
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 02b9478..2659c7b 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -433,37 +433,6 @@ static void omap_init_mcspi(void)
 static inline void omap_init_mcspi(void) {}
 #endif
 
-static struct resource omap2_pmu_resource = {
-	.start	= 3,
-	.end	= 3,
-	.flags	= IORESOURCE_IRQ,
-};
-
-static struct resource omap3_pmu_resource = {
-	.start	= INT_34XX_BENCH_MPU_EMUL,
-	.end	= INT_34XX_BENCH_MPU_EMUL,
-	.flags	= IORESOURCE_IRQ,
-};
-
-static struct platform_device omap_pmu_device = {
-	.name		= "arm-pmu",
-	.id		= -1,
-	.num_resources	= 1,
-};
-
-static void omap_init_pmu(void)
-{
-	if (cpu_is_omap24xx())
-		omap_pmu_device.resource = &omap2_pmu_resource;
-	else if (cpu_is_omap34xx())
-		omap_pmu_device.resource = &omap3_pmu_resource;
-	else
-		return;
-
-	platform_device_register(&omap_pmu_device);
-}
-
-
 #if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) || defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
 
 #ifdef CONFIG_ARCH_OMAP2
@@ -644,7 +613,6 @@ static int __init omap2_init_devices(void)
 		omap_init_mcpdm();
 		omap_init_mcspi();
 	}
-	omap_init_pmu();
 	omap_init_sti();
 	omap_init_sham();
 	omap_init_aes();
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index afad69c..411e2df 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -200,8 +200,14 @@ struct omap_hwmod omap2xxx_l4_wkup_hwmod = {
 };
 
 /* MPU */
+static struct omap_hwmod_irq_info omap2xxx_mpu_irqs[] = {
+	{ .name = "pmu", .irq = INT_24XX_BENCH_MPU_EMUL },
+	{ .irq = -1 }
+};
+
 struct omap_hwmod omap2xxx_mpu_hwmod = {
 	.name		= "mpu",
+	.mpu_irqs	= omap2xxx_mpu_irqs,
 	.class		= &mpu_hwmod_class,
 	.main_clk	= "mpu_ck",
 };
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 78a0c2d..4a5b8ab 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -92,8 +92,14 @@ static struct omap_hwmod omap3xxx_l4_sec_hwmod = {
 };
 
 /* MPU */
+static struct omap_hwmod_irq_info omap3xxx_mpu_irqs[] = {
+	{ .name = "pmu", .irq = INT_34XX_BENCH_MPU_EMUL },
+	{ .irq = -1 }
+};
+
 static struct omap_hwmod omap3xxx_mpu_hwmod = {
 	.name		= "mpu",
+	.mpu_irqs	= omap3xxx_mpu_irqs,
 	.class		= &mpu_hwmod_class,
 	.main_clk	= "arm_fck",
 };
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
new file mode 100644
index 0000000..1de52ed
--- /dev/null
+++ b/arch/arm/mach-omap2/pmu.c
@@ -0,0 +1,83 @@
+/*
+ * linux/arch/arm/mach-omap2/pmu.c
+ *
+ * OMAP2 ARM Performance Monitoring Unit (PMU) Support
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Contacts:
+ * Jon Hunter <jon-hunter@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <asm/pmu.h>
+
+#include <plat/omap_hwmod.h>
+#include <plat/omap_device.h>
+
+static char *omap2_pmu_oh_names[] = {"mpu"};
+static char *omap3_pmu_oh_names[] = {"mpu", "debugss"};
+static struct platform_device *omap_pmu_dev;
+
+/**
+ * omap2_init_pmu - creates and registers PMU platform device
+ * @oh_num:	Number of OMAP HWMODs required to create PMU device
+ * @oh_names:	Array of OMAP HWMODS names required to create PMU device
+ *
+ * Uses OMAP HWMOD framework to create and register an ARM PMU device
+ * from a list of HWMOD names passed. Currently supports OMAP2 and
+ * OMAP3 devices.
+ */
+static int __init omap2_init_pmu(unsigned oh_num, char *oh_names[])
+{
+	int i;
+	struct omap_hwmod *oh[2];
+	char *dev_name = "arm-pmu";
+
+	if ((!oh_num) || (oh_num > 2))
+		return -EINVAL;
+
+	for (i = 0; i < oh_num; i++) {
+		oh[i] = omap_hwmod_lookup(oh_names[i]);
+		if (!oh[i]) {
+			pr_err("Could not look up %s hwmod\n", oh_names[i]);
+			return -ENODEV;
+		}
+	}
+
+	omap_pmu_dev = omap_device_build_ss(dev_name, -1, oh, oh_num, NULL, 0,
+				NULL, 0, 0);
+	WARN(IS_ERR(omap_pmu_dev), "Can't build omap_device for %s.\n",
+				dev_name);
+
+	return IS_ERR(omap_pmu_dev) ? PTR_ERR(omap_pmu_dev) : 0;
+}
+
+static int __init omap_init_pmu(void)
+{
+	unsigned oh_num;
+	char **oh_names;
+
+	/*
+	 * To create an ARM-PMU device the following HWMODs
+	 * are required for the various OMAP2+ devices.
+	 *
+	 * OMAP24xx:	mpu
+	 * OMAP3xxx:	mpu, debugss
+	 */
+	if (cpu_is_omap24xx()) {
+		oh_num = ARRAY_SIZE(omap2_pmu_oh_names);
+		oh_names = omap2_pmu_oh_names;
+	} else if (cpu_is_omap34xx()) {
+		oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
+		oh_names = omap3_pmu_oh_names;
+	} else {
+		return 0;
+	}
+
+	return omap2_init_pmu(oh_num, oh_names);
+}
+subsys_initcall(omap_init_pmu);
diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h
index 37bbbbb..18883eb 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -243,6 +243,7 @@
 #define INT_7XX_DMA_CH15	(62 + IH2_BASE)
 #define INT_7XX_NAND		(63 + IH2_BASE)
 
+#define INT_24XX_BENCH_MPU_EMUL	3
 #define INT_24XX_SYS_NIRQ	7
 #define INT_24XX_SDMA_IRQ0	12
 #define INT_24XX_SDMA_IRQ1	13
-- 
1.7.9.5

[PATCH V3 3/8] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS

[Jon Hunter]

In order to use the CTI interrupts inconjunction with the DEBUGSS we need to
re-map the CTI IRQs to the DEBUGSS HWMOD. The purpose for doing this is so we
can create a PMU device based upon the DEBUGSS HWMOD and use the CTI interrupts
for routing ARM PMU events for OMAP4430 devices.

This is based upon Benoit Cousson's patch [1].

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/073319.html

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>

Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..7de8fbe 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -480,10 +480,17 @@ static struct omap_hwmod_class omap44xx_debugss_hwmod_class = {
 };
 
 /* 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 }
+};
+
 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 = {
@@ -2450,8 +2457,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 }
 };
 
-- 
1.7.9.5

Re: [PATCH V3 3/8] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS

[Paul Walmsley]

Hi

On Mon, 10 Sep 2012, Jon Hunter wrote:

> In order to use the CTI interrupts inconjunction with the DEBUGSS we need to
> re-map the CTI IRQs to the DEBUGSS HWMOD. The purpose for doing this is so we
> can create a PMU device based upon the DEBUGSS HWMOD and use the CTI interrupts
> for routing ARM PMU events for OMAP4430 devices.
> 
> This is based upon Benoit Cousson's patch [1].
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/073319.html
> 
> Cc: Ming Lei <ming.lei@canonical.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Kevin Hilman <khilman@ti.com>
> 
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

As with patch 6 of this series, setting this one aside until we can take a 
closer look at the way we set up the CTI.


- Paul

[PATCH V3 4/8] ARM: OMAP4430: Create PMU device via HWMOD

[Jon Hunter]

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

For OMAP4430 PMU events are routed to the CPU via the cross trigger interface
(CTI) because there are no dedicated interrupts. In order to route the PMU
events via the CTI IRQs, the following modules must be enabled:

        l3_instr, l3_main_3, debugss

Therefore, build the arm-pmu device via these three HWMODs.

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>

Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/pmu.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 1de52ed..7c137be 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -20,6 +20,7 @@
 
 static char *omap2_pmu_oh_names[] = {"mpu"};
 static char *omap3_pmu_oh_names[] = {"mpu", "debugss"};
+static char *omap4430_pmu_oh_names[] = {"l3_main_3", "l3_instr", "debugss"};
 static struct platform_device *omap_pmu_dev;
 
 /**
@@ -28,16 +29,16 @@ static struct platform_device *omap_pmu_dev;
  * @oh_names:	Array of OMAP HWMODS names required to create PMU device
  *
  * Uses OMAP HWMOD framework to create and register an ARM PMU device
- * from a list of HWMOD names passed. Currently supports OMAP2 and
- * OMAP3 devices.
+ * from a list of HWMOD names passed. Currently supports OMAP2, OMAP3
+ * and OMAP4430 devices.
  */
 static int __init omap2_init_pmu(unsigned oh_num, char *oh_names[])
 {
 	int i;
-	struct omap_hwmod *oh[2];
+	struct omap_hwmod *oh[3];
 	char *dev_name = "arm-pmu";
 
-	if ((!oh_num) || (oh_num > 2))
+	if ((!oh_num) || (oh_num > 3))
 		return -EINVAL;
 
 	for (i = 0; i < oh_num; i++) {
@@ -67,6 +68,7 @@ static int __init omap_init_pmu(void)
 	 *
 	 * OMAP24xx:	mpu
 	 * OMAP3xxx:	mpu, debugss
+	 * OMAP4430:	l3_main_3, l3_instr, debugss
 	 */
 	if (cpu_is_omap24xx()) {
 		oh_num = ARRAY_SIZE(omap2_pmu_oh_names);
@@ -74,6 +76,9 @@ static int __init omap_init_pmu(void)
 	} else if (cpu_is_omap34xx()) {
 		oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
 		oh_names = omap3_pmu_oh_names;
+	} else if (cpu_is_omap443x()) {
+		oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
+		oh_names = omap4430_pmu_oh_names;
 	} else {
 		return 0;
 	}
-- 
1.7.9.5

Re: [PATCH V3 4/8] ARM: OMAP4430: Create PMU device via HWMOD

[Paul Walmsley]

Hi

On Mon, 10 Sep 2012, Jon Hunter wrote:

> From: Ming Lei <ming.lei@canonical.com>
> 
> For OMAP4430 PMU events are routed to the CPU via the cross trigger interface
> (CTI) because there are no dedicated interrupts. In order to route the PMU
> events via the CTI IRQs, the following modules must be enabled:
> 
>         l3_instr, l3_main_3, debugss
> 
> Therefore, build the arm-pmu device via these three HWMODs.
> 
> Cc: Ming Lei <ming.lei@canonical.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Kevin Hilman <khilman@ti.com>
> 
> Signed-off-by: Ming Lei <ming.lei@canonical.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

Modified this one to skip the OMAP4430 PMU device creation for now and 
log a message; updated patch below.


- Paul

From: Ming Lei <ming.lei@canonical.com>
Date: Mon, 10 Sep 2012 10:23:42 -0500
Subject: [PATCH] ARM: OMAP4430: PMU: prepare to create PMU device via HWMOD

For OMAP4430 PMU events are routed to the CPU via the cross trigger interface
(CTI) because there are no dedicated interrupts. In order to route the PMU
events via the CTI IRQs, the following modules must be enabled:

        l3_instr, l3_main_3, debugss

Therefore, build the arm-pmu device via these three HWMODs.

However, the CTI support for this platform still needs some work.  Until
that's finished, temporarily disable the PMU on OMAP4430.

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: temporarily disabled OMAP4430 PMU support until a
 better CTI interface can be implemented; added patch description note]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/pmu.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index cf68bab..c49e058 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -19,6 +19,7 @@
 
 static char *omap2_pmu_oh_names[] = {"mpu"};
 static char *omap3_pmu_oh_names[] = {"mpu", "debugss"};
+static char *omap4430_pmu_oh_names[] = {"l3_main_3", "l3_instr", "debugss"};
 static struct platform_device *omap_pmu_dev;
 
 /**
@@ -27,16 +28,16 @@ static struct platform_device *omap_pmu_dev;
  * @oh_names:	Array of OMAP HWMODS names required to create PMU device
  *
  * Uses OMAP HWMOD framework to create and register an ARM PMU device
- * from a list of HWMOD names passed. Currently supports OMAP2 and
- * OMAP3 devices.
+ * from a list of HWMOD names passed. Currently supports OMAP2, OMAP3
+ * and OMAP4430 devices.
  */
 static int __init omap2_init_pmu(unsigned oh_num, char *oh_names[])
 {
 	int i;
-	struct omap_hwmod *oh[2];
+	struct omap_hwmod *oh[3];
 	char *dev_name = "arm-pmu";
 
-	if ((!oh_num) || (oh_num > 2))
+	if ((!oh_num) || (oh_num > 3))
 		return -EINVAL;
 
 	for (i = 0; i < oh_num; i++) {
@@ -66,6 +67,7 @@ static int __init omap_init_pmu(void)
 	 *
 	 * OMAP24xx:	mpu
 	 * OMAP3xxx:	mpu, debugss
+	 * OMAP4430:	l3_main_3, l3_instr, debugss
 	 */
 	if (cpu_is_omap24xx()) {
 		oh_num = ARRAY_SIZE(omap2_pmu_oh_names);
@@ -73,6 +75,12 @@ static int __init omap_init_pmu(void)
 	} else if (cpu_is_omap34xx()) {
 		oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
 		oh_names = omap3_pmu_oh_names;
+	} else if (cpu_is_omap443x()) {
+		oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
+		oh_names = omap4430_pmu_oh_names;
+		/* XXX Remove the next two lines when CTI driver available */
+		pr_info("ARM PMU: not yet supported on OMAP4430 due to missing CTI driver\n");
+		return 0;
 	} else {
 		return 0;
 	}
-- 
1.7.10.4

[PATCH V3 5/8] ARM: OMAP2+: PMU: Add runtime PM support

[Jon Hunter]

The original implementation of this patch was done by Ming Lei for PMU on OMAP4
[1]. Since then the PM runtime calls have been moved into the ARM PMU code and
this greatly simplifies the changes.

The another differnce since the original version, is that it is no longer
necessary to call pm_runtime_get/put during the PMU initialisation was we are no
longer accessing the hardware at this stage.

By adding runtime PM support, we can ensure that the appropriate power and clock
domains are kept on while PMU is being used.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074153.html

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/pmu.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 7c137be..03007b6 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -13,6 +13,8 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  */
+#include <linux/pm_runtime.h>
+
 #include <asm/pmu.h>
 
 #include <plat/omap_hwmod.h>
@@ -54,7 +56,12 @@ static int __init omap2_init_pmu(unsigned oh_num, char *oh_names[])
 	WARN(IS_ERR(omap_pmu_dev), "Can't build omap_device for %s.\n",
 				dev_name);
 
-	return IS_ERR(omap_pmu_dev) ? PTR_ERR(omap_pmu_dev) : 0;
+	if (IS_ERR(omap_pmu_dev))
+		return PTR_ERR(omap_pmu_dev);
+
+	pm_runtime_enable(&omap_pmu_dev->dev);
+
+	return 0;
 }
 
 static int __init omap_init_pmu(void)
-- 
1.7.9.5

[PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs

[Jon Hunter]

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

For OMAP4430 there are no dedicate PMU interrupts, however, PMU events can be
routed to via the CTI IRQs. This allows tools such as PERF and OPROFILE to work
on OMAP4430.

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

Ming's original patch was called "arm: omap4: support pmu" [1] and has been
renamed and modified by Jon Hunter. There main differences from the original
patch are ...

1. Instead of only configuring the CTI interrupt once during boot, the
   interrupts are configured everytime the the PMU is used. The reason for this
   is because during power transitions the CTI logic state will be lost and so
   we will need to configure the interrupts everytime they are used. This is
   accomplished by using the PM runtime callbacks which will be called whenever
   the PMU is used.
2. Assign the PMU events to different cross triggering channels. This prevents
   a single PMU event generating interrupts to both CPUs and hence can cause
   spurious interrupts to occur. Reported by Ming [2].

[1] http://marc.info/?l=linux-arm-kernel&m=132227620816504&w=2
[2] http://permalink.gmane.org/gmane.linux.linaro.devel/10532

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>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/pmu.c                  |   98 +++++++++++++++++++++++++++-
 arch/arm/plat-omap/include/plat/omap44xx.h |    3 +
 2 files changed, 99 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 03007b6..5918098 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -16,6 +16,7 @@
 #include <linux/pm_runtime.h>
 
 #include <asm/pmu.h>
+#include <asm/cti.h>
 
 #include <plat/omap_hwmod.h>
 #include <plat/omap_device.h>
@@ -24,6 +25,91 @@ static char *omap2_pmu_oh_names[] = {"mpu"};
 static char *omap3_pmu_oh_names[] = {"mpu", "debugss"};
 static char *omap4430_pmu_oh_names[] = {"l3_main_3", "l3_instr", "debugss"};
 static struct platform_device *omap_pmu_dev;
+static struct arm_pmu_platdata omap_pmu_data;
+static struct cti omap4_cti[2];
+
+/**
+ * omap4_pmu_runtime_resume - PMU runtime resume callback
+ * @dev		OMAP PMU device
+ *
+ * Platform specific PMU runtime resume callback for OMAP4430 devices to
+ * configure the cross trigger interface for routing PMU interrupts. This
+ * is called by the PM runtime framework.
+ */
+static int omap4_pmu_runtime_resume(struct device *dev)
+{
+	/* configure CTI0 for PMU IRQ routing */
+	cti_unlock(&omap4_cti[0]);
+	cti_map_trigger(&omap4_cti[0], 1, 6, 2);
+	cti_enable(&omap4_cti[0]);
+
+	/* configure CTI1 for PMU IRQ routing */
+	cti_unlock(&omap4_cti[1]);
+	cti_map_trigger(&omap4_cti[1], 1, 6, 3);
+	cti_enable(&omap4_cti[1]);
+
+	return 0;
+}
+
+/**
+ * omap4_pmu_runtime_suspend - PMU runtime suspend callback
+ * @dev		OMAP PMU device
+ *
+ * Platform specific PMU runtime suspend callback for OMAP4430 devices to
+ * disable the cross trigger interface interrupts. This is called by the
+ * PM runtime framework.
+ */
+static int omap4_pmu_runtime_suspend(struct device *dev)
+{
+	cti_disable(&omap4_cti[0]);
+	cti_disable(&omap4_cti[1]);
+
+	return 0;
+}
+
+/**
+ * omap4_pmu_handle_irq - PMU IRQ Handler
+ * @irq		OMAP CTI IRQ number
+ * @dev		OMAP PMU device
+ * @handler	ARM PMU interrupt handler
+ *
+ * Platform specific PMU IRQ handler for OMAP4430 devices that route PMU
+ * interrupts via cross trigger interface. This is called by the PMU driver.
+ */
+static irqreturn_t
+omap4_pmu_handle_irq(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);
+}
+
+/**
+ * omap4_init_cti - initialise cross trigger interface instances
+ *
+ * Initialises two cross trigger interface (CTI) instances in preparation
+ * for routing PMU interrupts to the OMAP interrupt controller. Note that
+ * this does not configure the actual CTI hardware but just the CTI
+ * software structures to be used.
+ */
+static int __init omap4_init_cti(void)
+{
+	omap4_cti[0].base = ioremap(OMAP44XX_CTI0_BASE, SZ_4K);
+	omap4_cti[1].base = ioremap(OMAP44XX_CTI1_BASE, SZ_4K);
+
+	if (!omap4_cti[0].base || !omap4_cti[1].base) {
+		pr_err("ioremap for OMAP4 CTI failed\n");
+		return -ENOMEM;
+	}
+
+	cti_init(&omap4_cti[0], omap4_cti[0].base, OMAP44XX_IRQ_CTI0, 6);
+	cti_init(&omap4_cti[1], omap4_cti[1].base, OMAP44XX_IRQ_CTI1, 6);
+
+	return 0;
+}
 
 /**
  * omap2_init_pmu - creates and registers PMU platform device
@@ -51,8 +137,8 @@ static int __init omap2_init_pmu(unsigned oh_num, char *oh_names[])
 		}
 	}
 
-	omap_pmu_dev = omap_device_build_ss(dev_name, -1, oh, oh_num, NULL, 0,
-				NULL, 0, 0);
+	omap_pmu_dev = omap_device_build_ss(dev_name, -1, oh, oh_num,
+			&omap_pmu_data, sizeof(omap_pmu_data), NULL, 0, 0);
 	WARN(IS_ERR(omap_pmu_dev), "Can't build omap_device for %s.\n",
 				dev_name);
 
@@ -66,6 +152,7 @@ static int __init omap2_init_pmu(unsigned oh_num, char *oh_names[])
 
 static int __init omap_init_pmu(void)
 {
+	int r;
 	unsigned oh_num;
 	char **oh_names;
 
@@ -84,6 +171,13 @@ static int __init omap_init_pmu(void)
 		oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
 		oh_names = omap3_pmu_oh_names;
 	} else if (cpu_is_omap443x()) {
+		r = omap4_init_cti();
+		if (r)
+			return r;
+
+		omap_pmu_data.handle_irq = omap4_pmu_handle_irq;
+		omap_pmu_data.runtime_resume = omap4_pmu_runtime_resume;
+		omap_pmu_data.runtime_suspend = omap4_pmu_runtime_suspend;
 		oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
 		oh_names = omap4430_pmu_oh_names;
 	} else {
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h
index c0d478e..1800a9b 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -58,5 +58,8 @@
 #define OMAP44XX_HSUSB_OHCI_BASE	(L4_44XX_BASE + 0x64800)
 #define OMAP44XX_HSUSB_EHCI_BASE	(L4_44XX_BASE + 0x64C00)
 
+#define OMAP44XX_CTI0_BASE		(L4_EMU_44XX_BASE + 0x148000)
+#define OMAP44XX_CTI1_BASE		(L4_EMU_44XX_BASE + 0x149000)
+
 #endif /* __ASM_ARCH_OMAP44XX_H */
 
-- 
1.7.9.5

Re: [PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs

[Paul Walmsley]

Hi

On Mon, 10 Sep 2012, Jon Hunter wrote:

> From: Ming Lei <ming.lei@canonical.com>
> 
> For OMAP4430 there are no dedicate PMU interrupts, however, PMU events can be
> routed to via the CTI IRQs. This allows tools such as PERF and OPROFILE to work
> on OMAP4430.
> 
> The idea is from Woodruff Richard in the disscussion about "Oprofile on
> Pandaboard / Omap4" on pandaboard@googlegroups.com.
> 
> Ming's original patch was called "arm: omap4: support pmu" [1] and has been
> renamed and modified by Jon Hunter. There main differences from the original
> patch are ...
> 
> 1. Instead of only configuring the CTI interrupt once during boot, the
>    interrupts are configured everytime the the PMU is used. The reason for this
>    is because during power transitions the CTI logic state will be lost and so
>    we will need to configure the interrupts everytime they are used. This is
>    accomplished by using the PM runtime callbacks which will be called whenever
>    the PMU is used.
> 2. Assign the PMU events to different cross triggering channels. This prevents
>    a single PMU event generating interrupts to both CPUs and hence can cause
>    spurious interrupts to occur. Reported by Ming [2].
> 
> [1] http://marc.info/?l=linux-arm-kernel&m=132227620816504&w=2
> [2] http://permalink.gmane.org/gmane.linux.linaro.devel/10532

Spent some time with this one here.  At this point I don't think I can 
queue it.  It's got hardcoded IRQ numbers and address information for the 
CTI, and mixes the CTI and PMU programming.  A few months ago we might 
have gotten away with this, but now it seems best to do this one cleanly.
Probably the CTI control should be moved off into mach-omap2/omap4-cti.c 
or somewhere into drivers/ if possible.  So let's revisit this for 3.8.


- Paul

Re: [PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs

[Jon Hunter]

On 09/20/2012 11:59 AM, Paul Walmsley wrote:
> Hi
> 
> On Mon, 10 Sep 2012, Jon Hunter wrote:
> 
>> From: Ming Lei <ming.lei@canonical.com>
>>
>> For OMAP4430 there are no dedicate PMU interrupts, however, PMU events can be
>> routed to via the CTI IRQs. This allows tools such as PERF and OPROFILE to work
>> on OMAP4430.
>>
>> The idea is from Woodruff Richard in the disscussion about "Oprofile on
>> Pandaboard / Omap4" on pandaboard@googlegroups.com.
>>
>> Ming's original patch was called "arm: omap4: support pmu" [1] and has been
>> renamed and modified by Jon Hunter. There main differences from the original
>> patch are ...
>>
>> 1. Instead of only configuring the CTI interrupt once during boot, the
>>    interrupts are configured everytime the the PMU is used. The reason for this
>>    is because during power transitions the CTI logic state will be lost and so
>>    we will need to configure the interrupts everytime they are used. This is
>>    accomplished by using the PM runtime callbacks which will be called whenever
>>    the PMU is used.
>> 2. Assign the PMU events to different cross triggering channels. This prevents
>>    a single PMU event generating interrupts to both CPUs and hence can cause
>>    spurious interrupts to occur. Reported by Ming [2].
>>
>> [1] http://marc.info/?l=linux-arm-kernel&m=132227620816504&w=2
>> [2] http://permalink.gmane.org/gmane.linux.linaro.devel/10532
> 
> Spent some time with this one here.  At this point I don't think I can 
> queue it.  It's got hardcoded IRQ numbers and address information for the 
> CTI, and mixes the CTI and PMU programming.  A few months ago we might 
> have gotten away with this, but now it seems best to do this one cleanly.
> Probably the CTI control should be moved off into mach-omap2/omap4-cti.c 
> or somewhere into drivers/ if possible.  So let's revisit this for 3.8.

Ok, no problem, I can't say I was thrilled with the implementation so
probably best to re-think some more. How about adding the cross-trigger
interface as a hwmod for omap4 to store the base address and interrupt
number?

Cheers
Jon

[PATCH V3 7/8] ARM: OMAP4: Enable PMU for OMAP4460/70

[Jon Hunter]

OMAP4460 and OMAP4470 devices have dedicated PMU interrupts and so add these
interrupts to the MPU HWMOD so we can use these for PMU events on these
devices. The PMU interrupts need to be the first interrupts in the array of
interrupts as the ARM PMU driver assumes this.

By using these dedicated interrupts we only need to enable the MPU and DEBUG
sub-systems for PMU to work. This is different to OMAP4430 that did not have
dedicated interrupts and required other power domains in addition to the DEBUG
sub-system to be enabled so we could route the PMU events to the CTI interrupts.
Hence, OMAP4460 and OMAP4470 devices can use the same list of HWMODs to create
the PMU device that is using by OMAP3.

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    2 ++
 arch/arm/mach-omap2/pmu.c                  |   17 ++++++++---------
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7de8fbe..cdf0e05 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2456,6 +2456,8 @@ static struct omap_hwmod_class omap44xx_mpu_hwmod_class = {
 
 /* mpu */
 static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = {
+	{ .name = "pmu0", .irq = 54 + OMAP44XX_IRQ_GIC_START },
+	{ .name = "pmu1", .irq = 55 + OMAP44XX_IRQ_GIC_START },
 	{ .name = "pl310", .irq = 0 + OMAP44XX_IRQ_GIC_START },
 	{ .irq = -1 }
 };
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 5918098..7fbaa3f 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -118,7 +118,7 @@ static int __init omap4_init_cti(void)
  *
  * Uses OMAP HWMOD framework to create and register an ARM PMU device
  * from a list of HWMOD names passed. Currently supports OMAP2, OMAP3
- * and OMAP4430 devices.
+ * and OMAP4 devices.
  */
 static int __init omap2_init_pmu(unsigned oh_num, char *oh_names[])
 {
@@ -163,14 +163,9 @@ static int __init omap_init_pmu(void)
 	 * OMAP24xx:	mpu
 	 * OMAP3xxx:	mpu, debugss
 	 * OMAP4430:	l3_main_3, l3_instr, debugss
+	 * OMAP4460/70:	mpu, debugss
 	 */
-	if (cpu_is_omap24xx()) {
-		oh_num = ARRAY_SIZE(omap2_pmu_oh_names);
-		oh_names = omap2_pmu_oh_names;
-	} else if (cpu_is_omap34xx()) {
-		oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
-		oh_names = omap3_pmu_oh_names;
-	} else if (cpu_is_omap443x()) {
+	if (cpu_is_omap443x()) {
 		r = omap4_init_cti();
 		if (r)
 			return r;
@@ -180,8 +175,12 @@ static int __init omap_init_pmu(void)
 		omap_pmu_data.runtime_suspend = omap4_pmu_runtime_suspend;
 		oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
 		oh_names = omap4430_pmu_oh_names;
+	} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
+		oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
+		oh_names = omap3_pmu_oh_names;
 	} else {
-		return 0;
+		oh_num = ARRAY_SIZE(omap2_pmu_oh_names);
+		oh_names = omap2_pmu_oh_names;
 	}
 
 	return omap2_init_pmu(oh_num, oh_names);
-- 
1.7.9.5

[PATCH V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint

[Jon Hunter]

When CPU-idle is enabled, the MPU sub-system will transition to low power
states during idle periods. If the PMU is active and the MPU sub-system
transitions to a low power state, such as retention, then the PMU context
will be lost and PMU events will stop. To prevent this from happening add a
QoS constraint whenever PMU is active to prevent the MPU sub-system from
transitioning to a low power state.

By default the PMU QoS constraint is set to -1 so it will not prevent any low
power states and when the PMU is enabled, it is set to 0, so that only C-state
C0 is allowed. I plan to re-visit this and relax the constraint to allow some
low power states, but for now I just wish to ensure PMU is working.

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/pmu.c |   49 +++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 7fbaa3f..ca158f0 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -13,6 +13,7 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  */
+#include <linux/pm_qos.h>
 #include <linux/pm_runtime.h>
 
 #include <asm/pmu.h>
@@ -24,11 +25,41 @@
 static char *omap2_pmu_oh_names[] = {"mpu"};
 static char *omap3_pmu_oh_names[] = {"mpu", "debugss"};
 static char *omap4430_pmu_oh_names[] = {"l3_main_3", "l3_instr", "debugss"};
+static struct pm_qos_request pmu_pm_qos_request;
 static struct platform_device *omap_pmu_dev;
-static struct arm_pmu_platdata omap_pmu_data;
 static struct cti omap4_cti[2];
 
 /**
+ * omap_pmu_runtime_resume - PMU runtime resume callback
+ * @dev		OMAP PMU device
+ *
+ * Platform specific PMU runtime resume callback for OMAP devices to
+ * configure the cross trigger interface for routing PMU interrupts.
+ * This is called by the PM runtime framework.
+ */
+static int omap_pmu_runtime_resume(struct device *dev)
+{
+	pm_qos_update_request(&pmu_pm_qos_request, 0);
+
+	return 0;
+}
+
+/**
+ * omap_pmu_runtime_suspend - PMU runtime suspend callback
+ * @dev		OMAP PMU device
+ *
+ * Platform specific PMU runtime suspend callback for OMAP devices to
+ * disable the cross trigger interface interrupts. This is called by
+ * the PM runtime framework.
+ */
+static int omap_pmu_runtime_suspend(struct device *dev)
+{
+	pm_qos_update_request(&pmu_pm_qos_request, PM_QOS_DEFAULT_VALUE);
+
+	return 0;
+}
+
+/**
  * omap4_pmu_runtime_resume - PMU runtime resume callback
  * @dev		OMAP PMU device
  *
@@ -38,6 +69,8 @@ static struct cti omap4_cti[2];
  */
 static int omap4_pmu_runtime_resume(struct device *dev)
 {
+	pm_qos_update_request(&pmu_pm_qos_request, 0);
+
 	/* configure CTI0 for PMU IRQ routing */
 	cti_unlock(&omap4_cti[0]);
 	cti_map_trigger(&omap4_cti[0], 1, 6, 2);
@@ -64,6 +97,8 @@ static int omap4_pmu_runtime_suspend(struct device *dev)
 	cti_disable(&omap4_cti[0]);
 	cti_disable(&omap4_cti[1]);
 
+	pm_qos_update_request(&pmu_pm_qos_request, PM_QOS_DEFAULT_VALUE);
+
 	return 0;
 }
 
@@ -111,6 +146,11 @@ static int __init omap4_init_cti(void)
 	return 0;
 }
 
+static struct arm_pmu_platdata omap_pmu_data = {
+	.runtime_resume = omap_pmu_runtime_resume,
+	.runtime_suspend = omap_pmu_runtime_suspend,
+};
+
 /**
  * omap2_init_pmu - creates and registers PMU platform device
  * @oh_num:	Number of OMAP HWMODs required to create PMU device
@@ -183,6 +223,11 @@ static int __init omap_init_pmu(void)
 		oh_names = omap2_pmu_oh_names;
 	}
 
-	return omap2_init_pmu(oh_num, oh_names);
+	r = omap2_init_pmu(oh_num, oh_names);
+	if (!r)
+		pm_qos_add_request(&pmu_pm_qos_request, PM_QOS_CPU_DMA_LATENCY,
+				PM_QOS_DEFAULT_VALUE);
+
+	return r;
 }
 subsys_initcall(omap_init_pmu);
-- 
1.7.9.5

Re: [PATCH V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint

[Paul Walmsley]

Hi

On Mon, 10 Sep 2012, Jon Hunter wrote:

> When CPU-idle is enabled, the MPU sub-system will transition to low power
> states during idle periods. If the PMU is active and the MPU sub-system
> transitions to a low power state, such as retention, then the PMU context
> will be lost and PMU events will stop. To prevent this from happening add a
> QoS constraint whenever PMU is active to prevent the MPU sub-system from
> transitioning to a low power state.
> 
> By default the PMU QoS constraint is set to -1 so it will not prevent any low
> power states and when the PMU is enabled, it is set to 0, so that only C-state
> C0 is allowed. I plan to re-visit this and relax the constraint to allow some
> low power states, but for now I just wish to ensure PMU is working.
> 
> Cc: Ming Lei <ming.lei@canonical.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Kevin Hilman <khilman@ti.com>
> 
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

This one looks like 3.7-rc material, due to the dependency on Will's PMU 
runtime PM adaptation series, which is unfortunately not yet in the 
stable merge base that I need to use to send these upstream.  Jon, care to 
update and re-send this one after Linus merges the other PMU patches?


- Paul

Re: [PATCH V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint

[Jon Hunter]

Hi Paul,

On 09/20/2012 12:14 PM, Paul Walmsley wrote:
> Hi
> 
> On Mon, 10 Sep 2012, Jon Hunter wrote:
> 
>> When CPU-idle is enabled, the MPU sub-system will transition to low power
>> states during idle periods. If the PMU is active and the MPU sub-system
>> transitions to a low power state, such as retention, then the PMU context
>> will be lost and PMU events will stop. To prevent this from happening add a
>> QoS constraint whenever PMU is active to prevent the MPU sub-system from
>> transitioning to a low power state.
>>
>> By default the PMU QoS constraint is set to -1 so it will not prevent any low
>> power states and when the PMU is enabled, it is set to 0, so that only C-state
>> C0 is allowed. I plan to re-visit this and relax the constraint to allow some
>> low power states, but for now I just wish to ensure PMU is working.
>>
>> Cc: Ming Lei <ming.lei@canonical.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Benoit Cousson <b-cousson@ti.com>
>> Cc: Paul Walmsley <paul@pwsan.com>
>> Cc: Kevin Hilman <khilman@ti.com>
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> 
> This one looks like 3.7-rc material, due to the dependency on Will's PMU 
> runtime PM adaptation series, which is unfortunately not yet in the 
> stable merge base that I need to use to send these upstream.  Jon, care to 
> update and re-send this one after Linus merges the other PMU patches?

Yes no problem. Will send out during the 3.7-rc.

Cheers
Jon

Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support

[Shilimkar, Santosh]

Jon,

On Mon, Sep 10, 2012 at 8:53 PM, Jon Hunter <jon-hunter@ti.com> wrote:
> This series adds PMU support for OMAP4 devices. This is based upon Will Deacons
> series [1] and re-based upon the latest arm-soc next/cleanup branch (3.6-rc3)
> that includes Will's series. It has been re-based upon this series because
> of the dependency on Sudeep KarkadaNagesha's change (ARM: pmu: remove
> arm_pmu_type enumeration) [2] that modifies the OMAP PMU code.
>
> This series is also dependent upon some clock fixes for OMAP3 [3] and OMAP4 [4]
> for PMU to operate correctly on OMAP3 and OMAP4.
>
> This series also converts OMAP2/3 devices to use HWMOD to create the PMU device
> and add a new file to mach-omap2 directory called pmu.c where the PMU devices
> are created.
>
> Testing:
> - Verified that PMU is working on OMAP2420 H4, OMAP3430 Beagle Board, OMAP4430
>   Panda and OMAP4460 Panda.
> - Tested on the above boards with CPU-idle enabled to ensure that PMU is working
>   with power management. For OMAP3430 verified that CORE retention state is
>   entered again after stopping PMU events.
>
> V3 changes:
> - Will Deacon has taken the PMU runtime PM adaption patch in his series and so
>   not included here [1].
> - Dropped my fix for managing the EMU power domain on OMAP4 in favour of Paul's
>   implementation [4]. Paul is planning to submit for v3.7.
> - Added HWMOD data for OMAP3 DEBUG sub-system. The DEBUG sub-system was always
>   being enabled on OMAP3 devices when using PMU and hence, hinding the fact
>   that PMU is dependent upon the DEBUG sub-system on OMAP3 for it to work.
>
> [1] git://git.kernel.org/pub/sicm/linux/kernel/git/will/linux.git perf/updates
> [2] http://www.spinics.net/lists/arm-kernel/msg188726.html
> [3] http://marc.info/?l=linux-omap&m=134333691309305&w=2
> [4] http://marc.info/?l=linux-arm-kernel&m=134383567112518&w=2
>
> Cc: Ming Lei <ming.lei@canonical.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Kevin Hilman <khilman@ti.com>
>
> Jon Hunter (6):
>   ARM: OMAP3: Add debugss HWMOD data
>   ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD
>   ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS
>   ARM: OMAP2+: PMU: Add runtime PM support
>   ARM: OMAP4: Enable PMU for OMAP4460/70
>   ARM: OMAP2+: PMU: Add QoS constraint
>
> Ming Lei (2):
>   ARM: OMAP4430: Create PMU device via HWMOD
>   ARM: OMAP4: Route PMU IRQs to CTI IRQs
>
Thanks for persisting with the PMU series and great work to get it working
across almost all OMAPs supporting PMU. I have acked few patches
already from the series. Just quickly rescanned full series and also tried it
on OMAP4 SDP. PMU counters seems to work fine with it.

Feel free to add my ack for the entire series.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support

[Paul Walmsley]

Hi Jon, Will, Ming, et al.,

Have queued most of these for 3.7 with the exception of the OMAP4430 
CTI-related patches (which look to me like 3.8 material) and the PM 
runtime suspend/resume patch (which looks to me like 3.7-rc material) -- 
assuming this series makes it in for 3.7 ... 

Apologies in advance if I broke something else in the process.


- Paul

Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support

[Shilimkar, Santosh]

Paul,

On Thu, Sep 20, 2012 at 10:47 PM, Paul Walmsley <paul@pwsan.com> wrote:
>
> Hi Jon, Will, Ming, et al.,
>
> Have queued most of these for 3.7 with the exception of the OMAP4430
> CTI-related patches (which look to me like 3.8 material) and the PM
> runtime suspend/resume patch (which looks to me like 3.7-rc material) --
> assuming this series makes it in for 3.7 ...
>
Any reason CTI patches can't be taken now. In fact the CTI patches are
on the list more time than the other ones.

> Apologies in advance if I broke something else in the process.
>
Perf will remain broken on OMAP4 without CTI patches.

Regards
Santosh

Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support

[Paul Walmsley]

Hi

On Thu, 20 Sep 2012, Shilimkar, Santosh wrote:

> On Thu, Sep 20, 2012 at 10:47 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > Have queued most of these for 3.7 with the exception of the OMAP4430
> > CTI-related patches (which look to me like 3.8 material) and the PM
> > runtime suspend/resume patch (which looks to me like 3.7-rc material) --
> > assuming this series makes it in for 3.7 ...
> >
> Any reason CTI patches can't be taken now. In fact the CTI patches are
> on the list more time than the other ones.

I listed the reasons briefly here:

   http://marc.info/?l=linux-omap&m=134816037709379&w=2

Let me know if you need more detail.

> > Apologies in advance if I broke something else in the process.
> >
> Perf will remain broken on OMAP4 without CTI patches.

Looks to me that it should work on OMAP4460/4470 since those chips don't 
have a CTI dependency for the PMU?


- Paul

Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support

[Shilimkar, Santosh]

On Thu, Sep 20, 2012 at 11:13 PM, Paul Walmsley <paul@pwsan.com> wrote:
> Hi
>
> On Thu, 20 Sep 2012, Shilimkar, Santosh wrote:
>
>> On Thu, Sep 20, 2012 at 10:47 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> >
>> > Have queued most of these for 3.7 with the exception of the OMAP4430
>> > CTI-related patches (which look to me like 3.8 material) and the PM
>> > runtime suspend/resume patch (which looks to me like 3.7-rc material) --
>> > assuming this series makes it in for 3.7 ...
>> >
>> Any reason CTI patches can't be taken now. In fact the CTI patches are
>> on the list more time than the other ones.
>
> I listed the reasons briefly here:
>
>    http://marc.info/?l=linux-omap&m=134816037709379&w=2
>
Sorry I should read it before asking the question.

> Let me know if you need more detail.
>
Thats pretty clear.

>> > Apologies in advance if I broke something else in the process.
>> >
>> Perf will remain broken on OMAP4 without CTI patches.
>
> Looks to me that it should work on OMAP4460/4470 since those chips don't
> have a CTI dependency for the PMU?
>
You are right. OMAP44_60/70 should work.

Thanks for clarification Paul.

Regards
Santosh

Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support

[Will Deacon]

On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote:
> 
> Hi Jon, Will, Ming, et al.,

Hi Paul,

> Have queued most of these for 3.7 with the exception of the OMAP4430 
> CTI-related patches (which look to me like 3.8 material) and the PM 
> runtime suspend/resume patch (which looks to me like 3.7-rc material) -- 
> assuming this series makes it in for 3.7 ... 

Ok, thanks for queueing what you did.

Jon -- could you pick the pieces up from what's left please and shout if
you need anything from me?

> Apologies in advance if I broke something else in the process.

There's not really anything to break yet :)

Cheers,

Will

Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support

[Jon Hunter]

Hi Will,

On 09/20/2012 04:09 PM, Will Deacon wrote:
> On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote:
>>
>> Hi Jon, Will, Ming, et al.,
> 
> Hi Paul,
> 
>> Have queued most of these for 3.7 with the exception of the OMAP4430 
>> CTI-related patches (which look to me like 3.8 material) and the PM 
>> runtime suspend/resume patch (which looks to me like 3.7-rc material) -- 
>> assuming this series makes it in for 3.7 ... 
> 
> Ok, thanks for queueing what you did.
> 
> Jon -- could you pick the pieces up from what's left please and shout if
> you need anything from me?

Yes will do.

Cheers
Jon

Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support

[Will Deacon]

On Mon, Sep 24, 2012 at 10:45:06PM +0100, Jon Hunter wrote:
> On 09/20/2012 04:09 PM, Will Deacon wrote:
> > On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote:
> >> Have queued most of these for 3.7 with the exception of the OMAP4430 
> >> CTI-related patches (which look to me like 3.8 material) and the PM 
> >> runtime suspend/resume patch (which looks to me like 3.7-rc material) -- 
> >> assuming this series makes it in for 3.7 ... 
> > 
> > Ok, thanks for queueing what you did.
> > 
> > Jon -- could you pick the pieces up from what's left please and shout if
> > you need anything from me?
> 
> Yes will do.

Great, thanks! Do you want me to do anything with my perf/omap4 branch? Now
that we have 3.6, I can try rebasing it but I don't know if it's worth the
effort if some of the patches are being reworked. Of course, I'm happy to
pick newer versions if they're available.

Cheers,

Will

Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support

[Jon Hunter]

On 10/01/2012 04:45 AM, Will Deacon wrote:
> On Mon, Sep 24, 2012 at 10:45:06PM +0100, Jon Hunter wrote:
>> On 09/20/2012 04:09 PM, Will Deacon wrote:
>>> On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote:
>>>> Have queued most of these for 3.7 with the exception of the OMAP4430 
>>>> CTI-related patches (which look to me like 3.8 material) and the PM 
>>>> runtime suspend/resume patch (which looks to me like 3.7-rc material) -- 
>>>> assuming this series makes it in for 3.7 ... 
>>>
>>> Ok, thanks for queueing what you did.
>>>
>>> Jon -- could you pick the pieces up from what's left please and shout if
>>> you need anything from me?
>>
>> Yes will do.
> 
> Great, thanks! Do you want me to do anything with my perf/omap4 branch? Now
> that we have 3.6, I can try rebasing it but I don't know if it's worth the
> effort if some of the patches are being reworked. Of course, I'm happy to
> pick newer versions if they're available.

I think that we are ok for the minute. I was going to wait until
everything gets merged for 3.7 and then rebase my branch [1] and start
re-working omap4430 support. So I would not worry right now.

Cheers
Jon

[1] https://github.com/jonhunter/linux/tree/dev-pmu

Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support

[Jon Hunter]

Hi Paul,

On 09/20/2012 12:17 PM, Paul Walmsley wrote:
> 
> Hi Jon, Will, Ming, et al.,
> 
> Have queued most of these for 3.7 with the exception of the OMAP4430 
> CTI-related patches (which look to me like 3.8 material) and the PM 
> runtime suspend/resume patch (which looks to me like 3.7-rc material) -- 
> assuming this series makes it in for 3.7 ... 
> 
> Apologies in advance if I broke something else in the process.

Looks good. Nothing you broke, but I just posted one fix for PMU
interrupts on OMAP2/3 [1]. With this PMU on Tony's master branch is
working fine on OMAP2420 and OMAP3430. I have also verified that PMU is
working on OMAP4460 too.

Cheers
Jon

[1] http://article.gmane.org/gmane.linux.ports.arm.omap/85294