* [PATCH 3/6] arm: omap4: support pmu
@ 2012-05-09 21:35 Jon Hunter
2012-05-16 10:12 ` Ming Lei
0 siblings, 1 reply; 4+ messages in thread
From: Jon Hunter @ 2012-05-09 21:35 UTC (permalink / raw)
To: linux-omap
Cc: Ming Lei, Woodruff Richard, Will Deacon, Benoit Cousson,
Paul Walmsley, Kevin Hilman, Jon Hunter
From: Ming Lei <ming.lei@canonical.com>
This patch supports pmu irq routed from CTI, so make pmu/perf working on
OMAP4.
The idea is from Woodruff Richard in the disscussion
about "Oprofile on Pandaboard / Omap4" on pandaboard@googlegroups.com.
Acked-by: Jean Pihet <j-pihet@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Woodruff Richard <r-woodruff2@ti.com>
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/devices.c | 60 +++++++++++++++++++++++++++-
arch/arm/plat-omap/include/plat/omap44xx.h | 3 +
2 files changed, 62 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d75b7d3..636533d 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -24,6 +24,7 @@
#include <asm/mach-types.h>
#include <asm/mach/map.h>
#include <asm/pmu.h>
+#include <asm/cti.h>
#include "iomap.h"
#include <plat/board.h>
@@ -432,6 +433,57 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
},
};
+static struct cti omap4_cti[2];
+
+static void omap4_enable_cti(int irq)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_enable(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_enable(&omap4_cti[1]);
+}
+
+static void omap4_disable_cti(int irq)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_disable(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_disable(&omap4_cti[1]);
+}
+
+static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t handler)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_irq_ack(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_irq_ack(&omap4_cti[1]);
+
+ return handler(irq, dev);
+}
+
+static void __init omap4_configure_pmu_irq(void)
+{
+ void __iomem *base0;
+ void __iomem *base1;
+
+ base0 = ioremap(OMAP44XX_CTI0_BASE, SZ_4K);
+ base1 = ioremap(OMAP44XX_CTI1_BASE, SZ_4K);
+ if (!base0 && !base1) {
+ pr_err("ioremap for OMAP4 CTI failed\n");
+ return;
+ }
+
+ /*configure CTI0 for pmu irq routing*/
+ cti_init(&omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
+ cti_unlock(&omap4_cti[0]);
+ cti_map_trigger(&omap4_cti[0], 1, 6, 2);
+
+ /*configure CTI1 for pmu irq routing*/
+ cti_init(&omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6);
+ cti_unlock(&omap4_cti[1]);
+ cti_map_trigger(&omap4_cti[1], 1, 6, 2);
+}
+
static struct platform_device* __init omap4_init_pmu(void)
{
int id = -1;
@@ -459,6 +511,10 @@ static struct platform_device* __init omap4_init_pmu(void)
return NULL;
}
+ omap4_pmu_data.handle_irq = omap4_pmu_handler;
+ omap4_pmu_data.enable_irq = omap4_enable_cti;
+ omap4_pmu_data.disable_irq = omap4_disable_cti;
+
pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
sizeof(omap4_pmu_data),
omap_pmu_latency,
@@ -479,7 +535,9 @@ static void __init omap_init_pmu(void)
pd = omap4_init_pmu();
if (!pd)
return;
- omap_device_enable(pd);
+
+ omap_device_enable(&od->pdev);
+ omap4_configure_pmu_irq();
return;
} else {
return;
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h
index c0d478e..0b04969 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 0x54148000
+#define OMAP44XX_CTI1_BASE 0x54149000
+
#endif /* __ASM_ARCH_OMAP44XX_H */
--
1.7.5.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH 3/6] arm: omap4: support pmu
2012-05-09 21:35 [PATCH 3/6] arm: omap4: support pmu Jon Hunter
@ 2012-05-16 10:12 ` Ming Lei
2012-05-18 18:17 ` Jon Hunter
0 siblings, 1 reply; 4+ messages in thread
From: Ming Lei @ 2012-05-16 10:12 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-omap, Woodruff Richard, Will Deacon, Benoit Cousson,
Paul Walmsley, Kevin Hilman
On Thu, May 10, 2012 at 5:35 AM, Jon Hunter <jon-hunter@ti.com> wrote:
> +
> + /*configure CTI0 for pmu irq routing*/
> + cti_init(&omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
> + cti_unlock(&omap4_cti[0]);
> + cti_map_trigger(&omap4_cti[0], 1, 6, 2);
> +
> + /*configure CTI1 for pmu irq routing*/
> + cti_init(&omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6);
> + cti_unlock(&omap4_cti[1]);
> + cti_map_trigger(&omap4_cti[1], 1, 6, 2);
As pointed in another thread, the above line should be changed to below:
cti_map_trigger(&omap4_cti[1], 1, 6, 3);
which can avoid irq flood issue at high frequency sample mode.
For detailed description about the issue and fix, see below link:
http://permalink.gmane.org/gmane.linux.linaro.devel/10532
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 3/6] arm: omap4: support pmu
2012-05-16 10:12 ` Ming Lei
@ 2012-05-18 18:17 ` Jon Hunter
2012-05-21 2:56 ` Ming Lei
0 siblings, 1 reply; 4+ messages in thread
From: Jon Hunter @ 2012-05-18 18:17 UTC (permalink / raw)
To: Ming Lei
Cc: linux-omap, Woodruff Richard, Will Deacon, Benoit Cousson,
Paul Walmsley, Kevin Hilman
Hi Ming,
On 05/16/2012 05:12 AM, Ming Lei wrote:
> On Thu, May 10, 2012 at 5:35 AM, Jon Hunter <jon-hunter@ti.com> wrote:
>
>> +
>> + /*configure CTI0 for pmu irq routing*/
>> + cti_init(&omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
>> + cti_unlock(&omap4_cti[0]);
>> + cti_map_trigger(&omap4_cti[0], 1, 6, 2);
>> +
>> + /*configure CTI1 for pmu irq routing*/
>> + cti_init(&omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6);
>> + cti_unlock(&omap4_cti[1]);
>> + cti_map_trigger(&omap4_cti[1], 1, 6, 2);
>
> As pointed in another thread, the above line should be changed to below:
>
> cti_map_trigger(&omap4_cti[1], 1, 6, 3);
>
> which can avoid irq flood issue at high frequency sample mode.
> For detailed description about the issue and fix, see below link:
>
> http://permalink.gmane.org/gmane.linux.linaro.devel/10532
I was performing the test you mentioned in the above thread to reproduce the problem. However, I was not able to reproduce the issue. Did you receive any confirmation from Dmitry this fixed his issue for oprofile?
By the way, I did not find too many details about the actual fix in the above thread. It appears to be mapping the interrupt to another channel. Can you clarify what this change is doing?
I did see the following kernel dump when running the perf record test. Applying your change did not help. Have you seen this? I am using the linux-omap master branch.
[ 199.186859] INFO: rcu_sched self-detected stall on CPU { 1} (t=7680 jiffies)
[ 199.194427] [<c001c5fc>] (unwind_backtrace+0x0/0xf4) from [<c00a8788>] (__rcu_pending+0x158/0x45c)
[ 199.203826] [<c00a8788>] (__rcu_pending+0x158/0x45c) from [<c00a8afc>] (rcu_check_callbacks+0x70/0x1ac)
[ 199.213653] [<c00a8afc>] (rcu_check_callbacks+0x70/0x1ac) from [<c0051a70>] (update_process_times+0x38/0x68)
[ 199.223968] [<c0051a70>] (update_process_times+0x38/0x68) from [<c008970c>] (tick_sched_timer+0x88/0xd8)
[ 199.233917] [<c008970c>] (tick_sched_timer+0x88/0xd8) from [<c0067550>] (__run_hrtimer+0x7c/0x1e0)
[ 199.243316] [<c0067550>] (__run_hrtimer+0x7c/0x1e0) from [<c0067920>] (hrtimer_interrupt+0x108/0x294)
[ 199.252990] [<c0067920>] (hrtimer_interrupt+0x108/0x294) from [<c001ad60>] (twd_handler+0x34/0x40)
[ 199.262359] [<c001ad60>] (twd_handler+0x34/0x40) from [<c00a325c>] (handle_percpu_devid_irq+0x8c/0x138)
[ 199.272216] [<c00a325c>] (handle_percpu_devid_irq+0x8c/0x138) from [<c00a02e8>] (generic_handle_irq+0x34/0x44)
[ 199.282714] [<c00a02e8>] (generic_handle_irq+0x34/0x44) from [<c00153c0>] (handle_IRQ+0x4c/0xac)
[ 199.291900] [<c00153c0>] (handle_IRQ+0x4c/0xac) from [<c0008480>] (gic_handle_irq+0x2c/0x60)
[ 199.300781] [<c0008480>] (gic_handle_irq+0x2c/0x60) from [<c0482964>] (__irq_svc+0x44/0x60)
[ 199.309509] Exception stack(0xef217c40 to 0xef217c88)
[ 199.314819] 7c40: 000000a2 00000000 00000000 ef0ef540 00000202 00000000 ef216000 c19c0080
[ 199.323394] 7c60: 00000000 c1a66d00 ef0ef7ac ef217d54 00000000 ef217c88 000000a3 c004a380
[ 199.331939] 7c80: 60000113 ffffffff
[ 199.335601] [<c0482964>] (__irq_svc+0x44/0x60) from [<c004a380>] (__do_softirq+0x64/0x214)
[ 199.344268] [<c004a380>] (__do_softirq+0x64/0x214) from [<c004a70c>] (irq_exit+0x90/0x98)
[ 199.352874] [<c004a70c>] (irq_exit+0x90/0x98) from [<c00153c4>] (handle_IRQ+0x50/0xac)
[ 199.361145] [<c00153c4>] (handle_IRQ+0x50/0xac) from [<c0008480>] (gic_handle_irq+0x2c/0x60)
[ 199.369995] [<c0008480>] (gic_handle_irq+0x2c/0x60) from [<c0482964>] (__irq_svc+0x44/0x60)
[ 199.378753] Exception stack(0xef217cf8 to 0xef217d40)
[ 199.384033] 7ce0: 0000009f 00000001
[ 199.392639] 7d00: 00000000 ef0ef540 00000000 ef1254c0 00000000 ef073480 c19de118 c19bd6c0
[ 199.401184] 7d20: ef0ef7ac ef217d54 00000001 ef217d40 000000a0 c0071df8 20000113 ffffffff
[ 199.409759] [<c0482964>] (__irq_svc+0x44/0x60) from [<c0071df8>] (finish_task_switch+0x4c/0xf0)
[ 199.418884] [<c0071df8>] (finish_task_switch+0x4c/0xf0) from [<c0481234>] (__schedule+0x410/0x808)
[ 199.428283] [<c0481234>] (__schedule+0x410/0x808) from [<c0112274>] (pipe_wait+0x58/0x78)
[ 199.436859] [<c0112274>] (pipe_wait+0x58/0x78) from [<c0112c3c>] (pipe_read+0x454/0x584)
[ 199.445343] [<c0112c3c>] (pipe_read+0x454/0x584) from [<c0109220>] (do_sync_read+0xac/0xf4)
[ 199.454101] [<c0109220>] (do_sync_read+0xac/0xf4) from [<c0109de4>] (vfs_read+0xac/0x130)
[ 199.462646] [<c0109de4>] (vfs_read+0xac/0x130) from [<c0109f38>] (sys_read+0x40/0x70)
[ 199.470855] [<c0109f38>] (sys_read+0x40/0x70) from [<c0014300>] (ret_fast_syscall+0x0/0x3c)
At the end of the test I also saw ...
"Processed 18048959 events and lost 26 chunks!
Check IO/CPU overload!"
Let me know if you have any thoughts.
Cheers
Jon
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 3/6] arm: omap4: support pmu
2012-05-18 18:17 ` Jon Hunter
@ 2012-05-21 2:56 ` Ming Lei
0 siblings, 0 replies; 4+ messages in thread
From: Ming Lei @ 2012-05-21 2:56 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-omap, Woodruff Richard, Will Deacon, Benoit Cousson,
Paul Walmsley, Kevin Hilman
Hi Jon,
On Sat, May 19, 2012 at 2:17 AM, Jon Hunter <jon-hunter@ti.com> wrote:
>
> I was performing the test you mentioned in the above thread to reproduce the problem. However, I was not able to reproduce the issue. Did you receive any confirmation from Dmitry this fixed his issue for oprofile?
No, looks Dmitry didn't reply on that thread, but I can
reproduce/verify the problem
easily, see below.
> By the way, I did not find too many details about the actual fix in the above thread. It appears to be mapping the interrupt to another channel. Can you clarify what this change is doing?
>
If two same channels are used as trigger out channel, any events may route to
both CPU, which can be easily observed that there are many unhandled IRQ in
one CPU but pmu is just enabled on another CPU.
Using different triger out channels can fix the problem and avoid IRQ
flood problem
which can be triggered by running the below(high frequency sample mode):
perf record -e cycles -F 40000 noploop 3
> I did see the following kernel dump when running the perf record test. Applying your change did not help. Have you seen this? I am using the linux-omap master branch.
>
No, I don't see the warning after applying the 6 patches against -next tree with
the mmc request_irq fix patch. From the below log, looks your PMU doesn't work
and perf is driven by hrtimer.
> [ 199.186859] INFO: rcu_sched self-detected stall on CPU { 1} (t=7680 jiffies)
> [ 199.194427] [<c001c5fc>] (unwind_backtrace+0x0/0xf4) from [<c00a8788>] (__rcu_pending+0x158/0x45c)
> [ 199.203826] [<c00a8788>] (__rcu_pending+0x158/0x45c) from [<c00a8afc>] (rcu_check_callbacks+0x70/0x1ac)
> [ 199.213653] [<c00a8afc>] (rcu_check_callbacks+0x70/0x1ac) from [<c0051a70>] (update_process_times+0x38/0x68)
> [ 199.223968] [<c0051a70>] (update_process_times+0x38/0x68) from [<c008970c>] (tick_sched_timer+0x88/0xd8)
> [ 199.233917] [<c008970c>] (tick_sched_timer+0x88/0xd8) from [<c0067550>] (__run_hrtimer+0x7c/0x1e0)
> [ 199.243316] [<c0067550>] (__run_hrtimer+0x7c/0x1e0) from [<c0067920>] (hrtimer_interrupt+0x108/0x294)
> [ 199.252990] [<c0067920>] (hrtimer_interrupt+0x108/0x294) from [<c001ad60>] (twd_handler+0x34/0x40)
> [ 199.262359] [<c001ad60>] (twd_handler+0x34/0x40) from [<c00a325c>] (handle_percpu_devid_irq+0x8c/0x138)
> [ 199.272216] [<c00a325c>] (handle_percpu_devid_irq+0x8c/0x138) from [<c00a02e8>] (generic_handle_irq+0x34/0x44)
> [ 199.282714] [<c00a02e8>] (generic_handle_irq+0x34/0x44) from [<c00153c0>] (handle_IRQ+0x4c/0xac)
> [ 199.291900] [<c00153c0>] (handle_IRQ+0x4c/0xac) from [<c0008480>] (gic_handle_irq+0x2c/0x60)
> [ 199.300781] [<c0008480>] (gic_handle_irq+0x2c/0x60) from [<c0482964>] (__irq_svc+0x44/0x60)
> [ 199.309509] Exception stack(0xef217c40 to 0xef217c88)
> [ 199.314819] 7c40: 000000a2 00000000 00000000 ef0ef540 00000202 00000000 ef216000 c19c0080
> [ 199.323394] 7c60: 00000000 c1a66d00 ef0ef7ac ef217d54 00000000 ef217c88 000000a3 c004a380
> [ 199.331939] 7c80: 60000113 ffffffff
> [ 199.335601] [<c0482964>] (__irq_svc+0x44/0x60) from [<c004a380>] (__do_softirq+0x64/0x214)
> [ 199.344268] [<c004a380>] (__do_softirq+0x64/0x214) from [<c004a70c>] (irq_exit+0x90/0x98)
> [ 199.352874] [<c004a70c>] (irq_exit+0x90/0x98) from [<c00153c4>] (handle_IRQ+0x50/0xac)
> [ 199.361145] [<c00153c4>] (handle_IRQ+0x50/0xac) from [<c0008480>] (gic_handle_irq+0x2c/0x60)
> [ 199.369995] [<c0008480>] (gic_handle_irq+0x2c/0x60) from [<c0482964>] (__irq_svc+0x44/0x60)
> [ 199.378753] Exception stack(0xef217cf8 to 0xef217d40)
> [ 199.384033] 7ce0: 0000009f 00000001
> [ 199.392639] 7d00: 00000000 ef0ef540 00000000 ef1254c0 00000000 ef073480 c19de118 c19bd6c0
> [ 199.401184] 7d20: ef0ef7ac ef217d54 00000001 ef217d40 000000a0 c0071df8 20000113 ffffffff
> [ 199.409759] [<c0482964>] (__irq_svc+0x44/0x60) from [<c0071df8>] (finish_task_switch+0x4c/0xf0)
> [ 199.418884] [<c0071df8>] (finish_task_switch+0x4c/0xf0) from [<c0481234>] (__schedule+0x410/0x808)
> [ 199.428283] [<c0481234>] (__schedule+0x410/0x808) from [<c0112274>] (pipe_wait+0x58/0x78)
> [ 199.436859] [<c0112274>] (pipe_wait+0x58/0x78) from [<c0112c3c>] (pipe_read+0x454/0x584)
> [ 199.445343] [<c0112c3c>] (pipe_read+0x454/0x584) from [<c0109220>] (do_sync_read+0xac/0xf4)
> [ 199.454101] [<c0109220>] (do_sync_read+0xac/0xf4) from [<c0109de4>] (vfs_read+0xac/0x130)
> [ 199.462646] [<c0109de4>] (vfs_read+0xac/0x130) from [<c0109f38>] (sys_read+0x40/0x70)
> [ 199.470855] [<c0109f38>] (sys_read+0x40/0x70) from [<c0014300>] (ret_fast_syscall+0x0/0x3c)
>
> At the end of the test I also saw ...
>
> "Processed 18048959 events and lost 26 chunks!
>
> Check IO/CPU overload!"
Generally, that is not a problem, you can save the trace into ram fs to
avoid it.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-05-21 2:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-05-09 21:35 [PATCH 3/6] arm: omap4: support pmu Jon Hunter
2012-05-16 10:12 ` Ming Lei
2012-05-18 18:17 ` Jon Hunter
2012-05-21 2:56 ` Ming Lei
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox