* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
@ 2012-09-10 15:23 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-arm, Jon Hunter, Ming Lei, Will Deacon,
Benoit Cousson, Paul Walmsley, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
@ 2012-09-10 15:23 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-10 15:23 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-arm, 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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data
@ 2012-09-10 15:23 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 2/8] ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-10 15:23 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-arm, Jon Hunter, Ming Lei, Will Deacon,
Benoit Cousson, Paul Walmsley, Kevin Hilman
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 2/8] ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD
@ 2012-09-10 15:23 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 3/8] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-10 15:23 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-arm, Jon Hunter, Ming Lei, Will Deacon,
Benoit Cousson, Paul Walmsley, Kevin Hilman
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 3/8] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS
@ 2012-09-10 15:23 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 4/8] ARM: OMAP4430: Create PMU device via HWMOD
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-10 15:23 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-arm, Ming Lei, Will Deacon, Benoit Cousson,
Paul Walmsley, Kevin Hilman, 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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 4/8] ARM: OMAP4430: Create PMU device via HWMOD
@ 2012-09-10 15:23 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 5/8] ARM: OMAP2+: PMU: Add runtime PM support
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-10 15:23 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-arm, Jon Hunter, Ming Lei, Will Deacon,
Benoit Cousson, Paul Walmsley, Kevin Hilman
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 5/8] ARM: OMAP2+: PMU: Add runtime PM support
@ 2012-09-10 15:23 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-10 15:23 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-arm, Ming Lei, Woodruff Richard, Will Deacon,
Benoit Cousson, Paul Walmsley, Kevin Hilman, 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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs
@ 2012-09-10 15:23 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 7/8] ARM: OMAP4: Enable PMU for OMAP4460/70
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-10 15:23 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-arm, Jon Hunter, Ming Lei, Will Deacon,
Benoit Cousson, Paul Walmsley, Kevin Hilman
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 7/8] ARM: OMAP4: Enable PMU for OMAP4460/70
@ 2012-09-10 15:23 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-10 15:23 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-arm, Jon Hunter, Ming Lei, Will Deacon,
Benoit Cousson, Paul Walmsley, Kevin Hilman
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint
@ 2012-09-10 15:23 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-11 6:48 ` Shilimkar, Santosh
-1 siblings, 0 replies; 58+ messages in thread
From: Shilimkar, Santosh @ 2012-09-11 6:48 UTC (permalink / raw)
To: Jon Hunter
Cc: Tony Lindgren, linux-omap, linux-arm, Ming Lei, Will Deacon,
Benoit Cousson, Paul Walmsley, Kevin Hilman
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>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
@ 2012-09-11 6:48 ` Shilimkar, Santosh
0 siblings, 0 replies; 58+ messages in thread
From: Shilimkar, Santosh @ 2012-09-11 6:48 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-13 3:32 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-13 3:32 UTC (permalink / raw)
To: Jon Hunter, Paul Walmsley; +Cc: Tony Lindgren, linux-omap, linux-arm
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,
>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data
@ 2012-09-13 3:32 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-13 3:32 UTC (permalink / raw)
To: linux-arm-kernel
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,
>
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-19 17:34 ` Paul Walmsley
-1 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-19 17:34 UTC (permalink / raw)
To: Jon Hunter; +Cc: Tony Lindgren, linux-omap, linux-arm
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data
@ 2012-09-19 17:34 ` Paul Walmsley
0 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-19 17:34 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-20 16:59 ` Paul Walmsley
-1 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 16:59 UTC (permalink / raw)
To: Jon Hunter
Cc: Tony Lindgren, linux-omap, linux-arm, Ming Lei, Woodruff Richard,
Will Deacon, Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs
@ 2012-09-20 16:59 ` Paul Walmsley
0 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 16:59 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 3/8] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-20 17:00 ` Paul Walmsley
-1 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 17:00 UTC (permalink / raw)
To: Jon Hunter
Cc: Tony Lindgren, linux-omap, linux-arm, Ming Lei, Will Deacon,
Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 3/8] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS
@ 2012-09-20 17:00 ` Paul Walmsley
0 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 17:00 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data
2012-09-19 17:34 ` Paul Walmsley
@ 2012-09-20 17:13 ` Paul Walmsley
-1 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 17:13 UTC (permalink / raw)
To: Jon Hunter; +Cc: Tony Lindgren, linux-omap, linux-arm
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data
@ 2012-09-20 17:13 ` Paul Walmsley
0 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 17:13 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH V3 4/8] ARM: OMAP4430: Create PMU device via HWMOD
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-20 17:14 ` Paul Walmsley
-1 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 17:14 UTC (permalink / raw)
To: Jon Hunter
Cc: Tony Lindgren, linux-omap, linux-arm, Ming Lei, Will Deacon,
Benoit Cousson, Kevin Hilman
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH V3 4/8] ARM: OMAP4430: Create PMU device via HWMOD
@ 2012-09-20 17:14 ` Paul Walmsley
0 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 17:14 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-20 17:14 ` Paul Walmsley
-1 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 17:14 UTC (permalink / raw)
To: Jon Hunter
Cc: Tony Lindgren, linux-omap, linux-arm, Ming Lei, Will Deacon,
Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint
@ 2012-09-20 17:14 ` Paul Walmsley
0 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 17:14 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
2012-09-10 15:23 ` Jon Hunter
@ 2012-09-20 17:17 ` Paul Walmsley
-1 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 17:17 UTC (permalink / raw)
To: Ming Lei, Will Deacon, Jon Hunter
Cc: Tony Lindgren, linux-omap, linux-arm, Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
@ 2012-09-20 17:17 ` Paul Walmsley
0 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 17:17 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
2012-09-20 17:17 ` Paul Walmsley
@ 2012-09-20 17:39 ` Shilimkar, Santosh
-1 siblings, 0 replies; 58+ messages in thread
From: Shilimkar, Santosh @ 2012-09-20 17:39 UTC (permalink / raw)
To: Paul Walmsley
Cc: Ming Lei, Will Deacon, Jon Hunter, Tony Lindgren, linux-omap,
linux-arm, Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
@ 2012-09-20 17:39 ` Shilimkar, Santosh
0 siblings, 0 replies; 58+ messages in thread
From: Shilimkar, Santosh @ 2012-09-20 17:39 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
2012-09-20 17:39 ` Shilimkar, Santosh
@ 2012-09-20 17:43 ` Paul Walmsley
-1 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 17:43 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: Ming Lei, Will Deacon, Jon Hunter, Tony Lindgren, linux-omap,
linux-arm, Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
@ 2012-09-20 17:43 ` Paul Walmsley
0 siblings, 0 replies; 58+ messages in thread
From: Paul Walmsley @ 2012-09-20 17:43 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
2012-09-20 17:43 ` Paul Walmsley
@ 2012-09-20 17:52 ` Shilimkar, Santosh
-1 siblings, 0 replies; 58+ messages in thread
From: Shilimkar, Santosh @ 2012-09-20 17:52 UTC (permalink / raw)
To: Paul Walmsley
Cc: Ming Lei, Will Deacon, Jon Hunter, Tony Lindgren, linux-omap,
linux-arm, Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
@ 2012-09-20 17:52 ` Shilimkar, Santosh
0 siblings, 0 replies; 58+ messages in thread
From: Shilimkar, Santosh @ 2012-09-20 17:52 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
2012-09-20 17:17 ` Paul Walmsley
@ 2012-09-20 21:09 ` Will Deacon
-1 siblings, 0 replies; 58+ messages in thread
From: Will Deacon @ 2012-09-20 21:09 UTC (permalink / raw)
To: Paul Walmsley
Cc: Ming Lei, Jon Hunter, Tony Lindgren, linux-omap, linux-arm,
Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
@ 2012-09-20 21:09 ` Will Deacon
0 siblings, 0 replies; 58+ messages in thread
From: Will Deacon @ 2012-09-20 21:09 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data
2012-09-20 17:13 ` Paul Walmsley
@ 2012-09-24 15:57 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-24 15:57 UTC (permalink / raw)
To: Paul Walmsley; +Cc: Tony Lindgren, linux-omap, linux-arm
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data
@ 2012-09-24 15:57 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-24 15:57 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint
2012-09-20 17:14 ` Paul Walmsley
@ 2012-09-24 16:08 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-24 16:08 UTC (permalink / raw)
To: Paul Walmsley
Cc: Tony Lindgren, linux-omap, linux-arm, Ming Lei, Will Deacon,
Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint
@ 2012-09-24 16:08 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-24 16:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs
2012-09-20 16:59 ` Paul Walmsley
@ 2012-09-24 19:46 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-24 19:46 UTC (permalink / raw)
To: Paul Walmsley
Cc: Tony Lindgren, linux-omap, linux-arm, Ming Lei, Woodruff Richard,
Will Deacon, Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs
@ 2012-09-24 19:46 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-24 19:46 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
2012-09-20 17:17 ` Paul Walmsley
@ 2012-09-24 21:43 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-24 21:43 UTC (permalink / raw)
To: Paul Walmsley
Cc: Ming Lei, Will Deacon, Tony Lindgren, linux-omap, linux-arm,
Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
@ 2012-09-24 21:43 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-24 21:43 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
2012-09-20 21:09 ` Will Deacon
@ 2012-09-24 21:45 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-24 21:45 UTC (permalink / raw)
To: Will Deacon
Cc: Paul Walmsley, Ming Lei, Tony Lindgren, linux-omap, linux-arm,
Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
@ 2012-09-24 21:45 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-09-24 21:45 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
2012-09-24 21:45 ` Jon Hunter
@ 2012-10-01 9:45 ` Will Deacon
-1 siblings, 0 replies; 58+ messages in thread
From: Will Deacon @ 2012-10-01 9:45 UTC (permalink / raw)
To: Jon Hunter
Cc: Paul Walmsley, Ming Lei, Tony Lindgren, linux-omap, linux-arm,
Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
@ 2012-10-01 9:45 ` Will Deacon
0 siblings, 0 replies; 58+ messages in thread
From: Will Deacon @ 2012-10-01 9:45 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
2012-10-01 9:45 ` Will Deacon
@ 2012-10-01 15:03 ` Jon Hunter
-1 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-10-01 15:03 UTC (permalink / raw)
To: Will Deacon
Cc: Paul Walmsley, Ming Lei, Tony Lindgren, linux-omap, linux-arm,
Benoit Cousson, Kevin Hilman
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
@ 2012-10-01 15:03 ` Jon Hunter
0 siblings, 0 replies; 58+ messages in thread
From: Jon Hunter @ 2012-10-01 15:03 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
end of thread, other threads:[~2012-10-01 15:03 UTC | newest]
Thread overview: 58+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-10 15:23 [PATCH V3 0/8] ARM: OMAP4: Add PMU Support Jon Hunter
2012-09-10 15:23 ` Jon Hunter
2012-09-10 15:23 ` [PATCH V3 1/8] ARM: OMAP3: Add debugss HWMOD data Jon Hunter
2012-09-10 15:23 ` Jon Hunter
2012-09-13 3:32 ` Jon Hunter
2012-09-13 3:32 ` Jon Hunter
2012-09-19 17:34 ` Paul Walmsley
2012-09-19 17:34 ` Paul Walmsley
2012-09-20 17:13 ` Paul Walmsley
2012-09-20 17:13 ` Paul Walmsley
2012-09-24 15:57 ` Jon Hunter
2012-09-24 15:57 ` Jon Hunter
2012-09-10 15:23 ` [PATCH V3 2/8] ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD Jon Hunter
2012-09-10 15:23 ` Jon Hunter
2012-09-10 15:23 ` [PATCH V3 3/8] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS Jon Hunter
2012-09-10 15:23 ` Jon Hunter
2012-09-20 17:00 ` Paul Walmsley
2012-09-20 17:00 ` Paul Walmsley
2012-09-10 15:23 ` [PATCH V3 4/8] ARM: OMAP4430: Create PMU device via HWMOD Jon Hunter
2012-09-10 15:23 ` Jon Hunter
2012-09-20 17:14 ` Paul Walmsley
2012-09-20 17:14 ` Paul Walmsley
2012-09-10 15:23 ` [PATCH V3 5/8] ARM: OMAP2+: PMU: Add runtime PM support Jon Hunter
2012-09-10 15:23 ` Jon Hunter
2012-09-10 15:23 ` [PATCH V3 6/8] ARM: OMAP4: Route PMU IRQs to CTI IRQs Jon Hunter
2012-09-10 15:23 ` Jon Hunter
2012-09-20 16:59 ` Paul Walmsley
2012-09-20 16:59 ` Paul Walmsley
2012-09-24 19:46 ` Jon Hunter
2012-09-24 19:46 ` Jon Hunter
2012-09-10 15:23 ` [PATCH V3 7/8] ARM: OMAP4: Enable PMU for OMAP4460/70 Jon Hunter
2012-09-10 15:23 ` Jon Hunter
2012-09-10 15:23 ` [PATCH V3 8/8] ARM: OMAP2+: PMU: Add QoS constraint Jon Hunter
2012-09-10 15:23 ` Jon Hunter
2012-09-20 17:14 ` Paul Walmsley
2012-09-20 17:14 ` Paul Walmsley
2012-09-24 16:08 ` Jon Hunter
2012-09-24 16:08 ` Jon Hunter
2012-09-11 6:48 ` [PATCH V3 0/8] ARM: OMAP4: Add PMU Support Shilimkar, Santosh
2012-09-11 6:48 ` Shilimkar, Santosh
2012-09-20 17:17 ` Paul Walmsley
2012-09-20 17:17 ` Paul Walmsley
2012-09-20 17:39 ` Shilimkar, Santosh
2012-09-20 17:39 ` Shilimkar, Santosh
2012-09-20 17:43 ` Paul Walmsley
2012-09-20 17:43 ` Paul Walmsley
2012-09-20 17:52 ` Shilimkar, Santosh
2012-09-20 17:52 ` Shilimkar, Santosh
2012-09-20 21:09 ` Will Deacon
2012-09-20 21:09 ` Will Deacon
2012-09-24 21:45 ` Jon Hunter
2012-09-24 21:45 ` Jon Hunter
2012-10-01 9:45 ` Will Deacon
2012-10-01 9:45 ` Will Deacon
2012-10-01 15:03 ` Jon Hunter
2012-10-01 15:03 ` Jon Hunter
2012-09-24 21:43 ` Jon Hunter
2012-09-24 21:43 ` Jon Hunter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.