* [patch v4 0/3] arm: pmu: support pmu/perf on OMAP4
@ 2011-03-08 15:38 tom.leiming at gmail.com
2011-03-08 15:38 ` [patch v4 1/3] arm: introduce cross trigger interface helpers tom.leiming at gmail.com
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: tom.leiming at gmail.com @ 2011-03-08 15:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This patches support pmu irq routed from CTI, such as implemented
on OMAP4:
- introduce some CTI helpers and registers' definition
- introduce .enable_irq and .disable_irq into platform_data,
so perf irq handler can handle irq correctly if it is
routed from CTI on OMAP4
- configure CTI on OMAP4 so that perf can work on OMAP4
The patches have been tested Ok on Pandaboard, and 'perf' does work
after applying them.
v4:
- some minor fix(add __iomem, comments, checkpatch warning...)
v3:
- fix typo of patch 2/3 title, pointed by Will
- move cti addresses to plat/omap44xx.h, suggested by
Santosh Shilimkar
v2:
- move cti related code out of perf_event.c
- introduce .enable_irq and .disable_irq into platform_data
as suggested by Will.
v1:
- rebase the patch set against 2.6.38-rc6-next-20110301, fix
conflicts, which is pointed out by Will Deacon
arch/arm/include/asm/cti.h | 179 ++++++++++++++++++++++++++++
arch/arm/include/asm/pmu.h | 15 ++-
arch/arm/kernel/perf_event.c | 15 ++-
arch/arm/mach-omap2/devices.c | 82 ++++++++++++-
arch/arm/plat-omap/include/plat/omap44xx.h | 2 +
5 files changed, 284 insertions(+), 9 deletions(-)
thanks,
--
Lei Ming
^ permalink raw reply [flat|nested] 18+ messages in thread
* [patch v4 1/3] arm: introduce cross trigger interface helpers
2011-03-08 15:38 [patch v4 0/3] arm: pmu: support pmu/perf on OMAP4 tom.leiming at gmail.com
@ 2011-03-08 15:38 ` tom.leiming at gmail.com
2011-03-08 16:31 ` Ben Dooks
2011-03-09 5:38 ` Santosh Shilimkar
2011-03-08 15:38 ` [patch v4 2/3] arm: pmu: allow platform specific irq enable/disable handling tom.leiming at gmail.com
2011-03-08 15:38 ` tom.leiming at gmail.com
2 siblings, 2 replies; 18+ messages in thread
From: tom.leiming at gmail.com @ 2011-03-08 15:38 UTC (permalink / raw)
To: linux-arm-kernel
From: Ming Lei <tom.leiming@gmail.com>
OMAP4 uses cross trigger interface(CTI) to route
performance monitor irq to GIC, so introduce cti
helpers to make access for cti easily.
Acked-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
arch/arm/include/asm/cti.h | 179 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 179 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/cti.h
diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
new file mode 100644
index 0000000..a0ada3e
--- /dev/null
+++ b/arch/arm/include/asm/cti.h
@@ -0,0 +1,179 @@
+#ifndef __ASMARM_CTI_H
+#define __ASMARM_CTI_H
+
+#include <asm/io.h>
+
+/* The registers' definition is from section 3.2 of
+ * Embedded Cross Trigger Revision: r0p0
+ */
+#define CTICONTROL 0x000
+#define CTISTATUS 0x004
+#define CTILOCK 0x008
+#define CTIPROTECTION 0x00C
+#define CTIINTACK 0x010
+#define CTIAPPSET 0x014
+#define CTIAPPCLEAR 0x018
+#define CTIAPPPULSE 0x01c
+#define CTIINEN 0x020
+#define CTIOUTEN 0x0A0
+#define CTITRIGINSTATUS 0x130
+#define CTITRIGOUTSTATUS 0x134
+#define CTICHINSTATUS 0x138
+#define CTICHOUTSTATUS 0x13c
+#define CTIPERIPHID0 0xFE0
+#define CTIPERIPHID1 0xFE4
+#define CTIPERIPHID2 0xFE8
+#define CTIPERIPHID3 0xFEC
+#define CTIPCELLID0 0xFF0
+#define CTIPCELLID1 0xFF4
+#define CTIPCELLID2 0xFF8
+#define CTIPCELLID3 0xFFC
+
+/* The below are from section 3.6.4 of
+ * CoreSight v1.0 Architecture Specification
+ */
+#define LOCKACCESS 0xFB0
+#define LOCKSTATUS 0xFB4
+
+/* write this value to LOCKACCESS will unlock the module, and
+ * other value will lock the module
+ */
+#define LOCKCODE 0xC5ACCE55
+
+/**
+ * struct cti - cross trigger interface struct
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out_for_irq: triger out number which will cause
+ * the @irq happen
+ *
+ * cti struct used to operate cti registers.
+ */
+struct cti {
+ void __iomem *base;
+ int irq;
+ int trig_out_for_irq;
+};
+
+/**
+ * cti_init - initialize the cti instance
+ * @cti: cti instance
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out: triger out number which will cause
+ * the @irq happen
+ *
+ * called by machine code to pass the board dependent
+ * @base, @irq and @trig_out to cti.
+ */
+static inline void cti_init(struct cti *cti,
+ void __iomem *base, int irq, int trig_out)
+{
+ cti->base = base;
+ cti->irq = irq;
+ cti->trig_out_for_irq = trig_out;
+}
+
+/**
+ * cti_map_trigger - use the @chan to map @trig_in to @trig_out
+ * @cti: cti instance
+ * @trig_in: trigger in number
+ * @trig_out: trigger out number
+ * @channel: channel number
+ *
+ * This function maps one trigger in of @trig_in to one trigger
+ * out of @trig_out using the channel @chan.
+ */
+static inline void cti_map_trigger(struct cti *cti,
+ int trig_in, int trig_out, int chan)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + CTIINEN + trig_in * 4);
+ val |= BIT(chan);
+ __raw_writel(val, base + CTIINEN + trig_in * 4);
+
+ val = __raw_readl(base + CTIOUTEN + trig_out * 4);
+ val |= BIT(chan);
+ __raw_writel(val, base + CTIOUTEN + trig_out * 4);
+}
+
+/**
+ * cti_enable - enable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_enable(struct cti *cti)
+{
+ __raw_writel(0x1, cti->base + CTICONTROL);
+}
+
+/**
+ * cti_disable - disable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_disable(struct cti *cti)
+{
+ __raw_writel(0, cti->base + CTICONTROL);
+}
+
+/**
+ * cti_irq_ack - clear the cti irq
+ * @cti: cti instance
+ *
+ * clear the cti irq
+ */
+static inline void cti_irq_ack(struct cti *cti)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + CTIINTACK);
+ val |= BIT(cti->trig_out_for_irq);
+ __raw_writel(val, base + CTIINTACK);
+}
+
+/**
+ * cti_unlock - unlock cti module
+ * @cti: cti instance
+ *
+ * unlock the cti module, or else any writes to the cti
+ * module is not allowed.
+ */
+static inline void cti_unlock(struct cti *cti)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + LOCKSTATUS);
+
+ if (val & 1) {
+ val = LOCKCODE;
+ __raw_writel(val, base + LOCKACCESS);
+ }
+}
+
+/**
+ * cti_lock - lock cti module
+ * @cti: cti instance
+ *
+ * lock the cti module, so any writes to the cti
+ * module will be not allowed.
+ */
+static inline void cti_lock(struct cti *cti)
+{
+ void __iomem *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + LOCKSTATUS);
+
+ if (!(val & 1)) {
+ val = ~LOCKCODE;
+ __raw_writel(val, base + LOCKACCESS);
+ }
+}
+#endif
--
1.7.3
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [patch v4 2/3] arm: pmu: allow platform specific irq enable/disable handling
2011-03-08 15:38 [patch v4 0/3] arm: pmu: support pmu/perf on OMAP4 tom.leiming at gmail.com
2011-03-08 15:38 ` [patch v4 1/3] arm: introduce cross trigger interface helpers tom.leiming at gmail.com
@ 2011-03-08 15:38 ` tom.leiming at gmail.com
2011-03-08 15:38 ` tom.leiming at gmail.com
2 siblings, 0 replies; 18+ messages in thread
From: tom.leiming at gmail.com @ 2011-03-08 15:38 UTC (permalink / raw)
To: linux-arm-kernel
From: Ming Lei <tom.leiming@gmail.com>
This patch introduces .enable_irq and .disable_irq into
struct arm_pmu_platdata, so platform specific irq enablement
can be handled after request_irq, and platform specific irq
disablement can be handled before free_irq.
This patch is for support of pmu irq routed from CTI on omap4.
Acked-by: Jean Pihet <j-pihet@ti.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
arch/arm/include/asm/pmu.h | 15 ++++++++++++---
arch/arm/kernel/perf_event.c | 15 ++++++++++++---
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index 7544ce6..7ca3d15 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -22,13 +22,22 @@ enum arm_pmu_type {
/*
* struct arm_pmu_platdata - ARM PMU platform data
*
- * @handle_irq: an optional handler which will be called from the interrupt and
- * passed the address of the low level handler, and can be used to implement
- * any platform specific handling before or after calling it.
+ * @handle_irq: an optional handler which will be called from the
+ * interrupt and passed the address of the low level handler,
+ * and can be used to implement any platform specific handling
+ * before or after calling it.
+ * @enable_irq: an optional handler which will be called after
+ * request_irq and be used to handle some platform specific
+ * irq enablement
+ * @disable_irq: an optional handler which will be called before
+ * free_irq and be used to handle some platform specific
+ * irq disablement
*/
struct arm_pmu_platdata {
irqreturn_t (*handle_irq)(int irq, void *dev,
irq_handler_t pmu_handler);
+ void (*enable_irq)(int irq);
+ void (*disable_irq)(int irq);
};
#ifdef CONFIG_CPU_HAS_PMU
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 22e194eb..61ff471 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -422,14 +422,18 @@ armpmu_reserve_hardware(void)
pr_warning("unable to request IRQ%d for ARM perf "
"counters\n", irq);
break;
- }
+ } else if (plat->enable_irq)
+ plat->enable_irq(irq);
}
if (err) {
for (i = i - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
- if (irq >= 0)
+ if (irq >= 0) {
+ if (plat->disable_irq)
+ plat->disable_irq(irq);
free_irq(irq, NULL);
+ }
}
release_pmu(pmu_device);
pmu_device = NULL;
@@ -442,11 +446,16 @@ static void
armpmu_release_hardware(void)
{
int i, irq;
+ struct arm_pmu_platdata *plat =
+ dev_get_platdata(&pmu_device->dev);
for (i = pmu_device->num_resources - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
- if (irq >= 0)
+ if (irq >= 0) {
+ if (plat->disable_irq)
+ plat->disable_irq(irq);
free_irq(irq, NULL);
+ }
}
armpmu->stop();
--
1.7.3
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [patch v4 3/3] arm: omap4: support pmu
2011-03-08 15:38 [patch v4 0/3] arm: pmu: support pmu/perf on OMAP4 tom.leiming at gmail.com
@ 2011-03-08 15:38 ` tom.leiming at gmail.com
2011-03-08 15:38 ` [patch v4 2/3] arm: pmu: allow platform specific irq enable/disable handling tom.leiming at gmail.com
2011-03-08 15:38 ` tom.leiming at gmail.com
2 siblings, 0 replies; 18+ messages in thread
From: tom.leiming @ 2011-03-08 15:38 UTC (permalink / raw)
To: linux
Cc: linux-arm-kernel, will.deacon, Ming Lei, Woodruff Richard, linux-omap
From: Ming Lei <tom.leiming@gmail.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: linux-omap@vger.kernel.org
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
arch/arm/mach-omap2/devices.c | 82 +++++++++++++++++++++++++++-
arch/arm/plat-omap/include/plat/omap44xx.h | 2 +
2 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d216976..d97bb5a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -22,6 +22,7 @@
#include <asm/mach-types.h>
#include <asm/mach/map.h>
#include <asm/pmu.h>
+#include <asm/cti.h>
#include <plat/tc.h>
#include <plat/board.h>
@@ -322,20 +323,95 @@ static struct resource omap3_pmu_resource = {
.flags = IORESOURCE_IRQ,
};
+static struct resource omap4_pmu_resource[] = {
+ {
+ .start = OMAP44XX_IRQ_CTI0,
+ .end = OMAP44XX_IRQ_CTI0,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = OMAP44XX_IRQ_CTI1,
+ .end = OMAP44XX_IRQ_CTI1,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
static struct platform_device omap_pmu_device = {
.name = "arm-pmu",
.id = ARM_PMU_DEVICE_CPU,
.num_resources = 1,
};
+static struct arm_pmu_platdata omap4_pmu_data;
+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 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);
+
+ omap4_pmu_data.handle_irq = omap4_pmu_handler;
+ omap4_pmu_data.enable_irq = omap4_enable_cti;
+ omap4_pmu_data.disable_irq = omap4_disable_cti;
+}
+
static void omap_init_pmu(void)
{
- if (cpu_is_omap24xx())
+ if (cpu_is_omap24xx()) {
omap_pmu_device.resource = &omap2_pmu_resource;
- else if (cpu_is_omap34xx())
+ } else if (cpu_is_omap34xx()) {
omap_pmu_device.resource = &omap3_pmu_resource;
- else
+ } else if (cpu_is_omap44xx()) {
+ omap_pmu_device.resource = omap4_pmu_resource;
+ omap_pmu_device.num_resources = 2;
+ omap_pmu_device.dev.platform_data = &omap4_pmu_data;
+ omap4_configure_pmu_irq();
+ } else {
return;
+ }
platform_device_register(&omap_pmu_device);
}
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h
index ea2b8a6..b127a16 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -57,5 +57,7 @@
#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.3
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [patch v4 3/3] arm: omap4: support pmu
@ 2011-03-08 15:38 ` tom.leiming at gmail.com
0 siblings, 0 replies; 18+ messages in thread
From: tom.leiming at gmail.com @ 2011-03-08 15:38 UTC (permalink / raw)
To: linux-arm-kernel
From: Ming Lei <tom.leiming@gmail.com>
This patch supports pmu irq routed from CTI, so
make pmu/perf working on OMAP4.
The idea is from Woodruff Richard in the disscussion
about "Oprofile on Pandaboard / Omap4" on pandaboard at googlegroups.com.
Acked-by: Jean Pihet <j-pihet@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Woodruff Richard <r-woodruff2@ti.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
arch/arm/mach-omap2/devices.c | 82 +++++++++++++++++++++++++++-
arch/arm/plat-omap/include/plat/omap44xx.h | 2 +
2 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d216976..d97bb5a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -22,6 +22,7 @@
#include <asm/mach-types.h>
#include <asm/mach/map.h>
#include <asm/pmu.h>
+#include <asm/cti.h>
#include <plat/tc.h>
#include <plat/board.h>
@@ -322,20 +323,95 @@ static struct resource omap3_pmu_resource = {
.flags = IORESOURCE_IRQ,
};
+static struct resource omap4_pmu_resource[] = {
+ {
+ .start = OMAP44XX_IRQ_CTI0,
+ .end = OMAP44XX_IRQ_CTI0,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = OMAP44XX_IRQ_CTI1,
+ .end = OMAP44XX_IRQ_CTI1,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
static struct platform_device omap_pmu_device = {
.name = "arm-pmu",
.id = ARM_PMU_DEVICE_CPU,
.num_resources = 1,
};
+static struct arm_pmu_platdata omap4_pmu_data;
+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 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);
+
+ omap4_pmu_data.handle_irq = omap4_pmu_handler;
+ omap4_pmu_data.enable_irq = omap4_enable_cti;
+ omap4_pmu_data.disable_irq = omap4_disable_cti;
+}
+
static void omap_init_pmu(void)
{
- if (cpu_is_omap24xx())
+ if (cpu_is_omap24xx()) {
omap_pmu_device.resource = &omap2_pmu_resource;
- else if (cpu_is_omap34xx())
+ } else if (cpu_is_omap34xx()) {
omap_pmu_device.resource = &omap3_pmu_resource;
- else
+ } else if (cpu_is_omap44xx()) {
+ omap_pmu_device.resource = omap4_pmu_resource;
+ omap_pmu_device.num_resources = 2;
+ omap_pmu_device.dev.platform_data = &omap4_pmu_data;
+ omap4_configure_pmu_irq();
+ } else {
return;
+ }
platform_device_register(&omap_pmu_device);
}
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h
index ea2b8a6..b127a16 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -57,5 +57,7 @@
#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.3
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [patch v4 1/3] arm: introduce cross trigger interface helpers
2011-03-08 15:38 ` [patch v4 1/3] arm: introduce cross trigger interface helpers tom.leiming at gmail.com
@ 2011-03-08 16:31 ` Ben Dooks
2011-03-24 14:41 ` Ming Lei
2011-03-09 5:38 ` Santosh Shilimkar
1 sibling, 1 reply; 18+ messages in thread
From: Ben Dooks @ 2011-03-08 16:31 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 08, 2011 at 11:38:47PM +0800, tom.leiming at gmail.com wrote:
> From: Ming Lei <tom.leiming@gmail.com>
>
> OMAP4 uses cross trigger interface(CTI) to route
> performance monitor irq to GIC, so introduce cti
> helpers to make access for cti easily.
>
> Acked-by: Jean Pihet <j-pihet@ti.com>
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> ---
> arch/arm/include/asm/cti.h | 179 ++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 179 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/include/asm/cti.h
>
> diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
> new file mode 100644
> index 0000000..a0ada3e
> --- /dev/null
> +++ b/arch/arm/include/asm/cti.h
> @@ -0,0 +1,179 @@
> +#ifndef __ASMARM_CTI_H
> +#define __ASMARM_CTI_H
> +
> +#include <asm/io.h>
> +
> +/* The registers' definition is from section 3.2 of
> + * Embedded Cross Trigger Revision: r0p0
> + */
> +#define CTICONTROL 0x000
> +#define CTISTATUS 0x004
> +#define CTILOCK 0x008
> +#define CTIPROTECTION 0x00C
> +#define CTIINTACK 0x010
> +#define CTIAPPSET 0x014
> +#define CTIAPPCLEAR 0x018
> +#define CTIAPPPULSE 0x01c
> +#define CTIINEN 0x020
> +#define CTIOUTEN 0x0A0
> +#define CTITRIGINSTATUS 0x130
> +#define CTITRIGOUTSTATUS 0x134
> +#define CTICHINSTATUS 0x138
> +#define CTICHOUTSTATUS 0x13c
> +#define CTIPERIPHID0 0xFE0
> +#define CTIPERIPHID1 0xFE4
> +#define CTIPERIPHID2 0xFE8
> +#define CTIPERIPHID3 0xFEC
> +#define CTIPCELLID0 0xFF0
> +#define CTIPCELLID1 0xFF4
> +#define CTIPCELLID2 0xFF8
> +#define CTIPCELLID3 0xFFC
could you just use the primecell register information for these
> +/* The below are from section 3.6.4 of
> + * CoreSight v1.0 Architecture Specification
> + */
> +#define LOCKACCESS 0xFB0
> +#define LOCKSTATUS 0xFB4
> +
> +/* write this value to LOCKACCESS will unlock the module, and
> + * other value will lock the module
> + */
> +#define LOCKCODE 0xC5ACCE55
> +
> +/**
> + * struct cti - cross trigger interface struct
> + * @base: mapped virtual address for the cti base
> + * @irq: irq number for the cti
> + * @trig_out_for_irq: triger out number which will cause
> + * the @irq happen
> + *
> + * cti struct used to operate cti registers.
> + */
> +struct cti {
> + void __iomem *base;
> + int irq;
> + int trig_out_for_irq;
> +};
> +
> +/**
> + * cti_init - initialize the cti instance
> + * @cti: cti instance
> + * @base: mapped virtual address for the cti base
> + * @irq: irq number for the cti
> + * @trig_out: triger out number which will cause
> + * the @irq happen
> + *
> + * called by machine code to pass the board dependent
> + * @base, @irq and @trig_out to cti.
> + */
> +static inline void cti_init(struct cti *cti,
> + void __iomem *base, int irq, int trig_out)
> +{
> + cti->base = base;
> + cti->irq = irq;
> + cti->trig_out_for_irq = trig_out;
> +}
> +
> +/**
> + * cti_map_trigger - use the @chan to map @trig_in to @trig_out
> + * @cti: cti instance
> + * @trig_in: trigger in number
> + * @trig_out: trigger out number
> + * @channel: channel number
> + *
> + * This function maps one trigger in of @trig_in to one trigger
> + * out of @trig_out using the channel @chan.
> + */
> +static inline void cti_map_trigger(struct cti *cti,
> + int trig_in, int trig_out, int chan)
> +{
> + void __iomem *base = cti->base;
> + unsigned long val;
> +
> + val = __raw_readl(base + CTIINEN + trig_in * 4);
> + val |= BIT(chan);
> + __raw_writel(val, base + CTIINEN + trig_in * 4);
> +
> + val = __raw_readl(base + CTIOUTEN + trig_out * 4);
> + val |= BIT(chan);
> + __raw_writel(val, base + CTIOUTEN + trig_out * 4);
> +}
> +/**
> + * cti_enable - enable the cti module
> + * @cti: cti instance
> + *
> + * enable the cti module
> + */
> +static inline void cti_enable(struct cti *cti)
> +{
> + __raw_writel(0x1, cti->base + CTICONTROL);
> +}
> +static inline void cti_irq_ack(struct cti *cti)
> +{
> + void __iomem *base = cti->base;
> + unsigned long val;
> +
> + val = __raw_readl(base + CTIINTACK);
> + val |= BIT(cti->trig_out_for_irq);
would it be easier to get a pre-shifted bit here?
--
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [patch v4 1/3] arm: introduce cross trigger interface helpers
2011-03-08 15:38 ` [patch v4 1/3] arm: introduce cross trigger interface helpers tom.leiming at gmail.com
2011-03-08 16:31 ` Ben Dooks
@ 2011-03-09 5:38 ` Santosh Shilimkar
1 sibling, 0 replies; 18+ messages in thread
From: Santosh Shilimkar @ 2011-03-09 5:38 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
> arm-kernel-bounces at lists.infradead.org] On Behalf Of
> tom.leiming at gmail.com
> Sent: Tuesday, March 08, 2011 9:09 PM
> To: linux at arm.linux.org.uk
> Cc: Ming Lei; will.deacon at arm.com; linux-arm-
> kernel at lists.infradead.org
> Subject: [patch v4 1/3] arm: introduce cross trigger interface
> helpers
>
> From: Ming Lei <tom.leiming@gmail.com>
>
> OMAP4 uses cross trigger interface(CTI) to route
> performance monitor irq to GIC, so introduce cti
> helpers to make access for cti easily.
>
> Acked-by: Jean Pihet <j-pihet@ti.com>
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> ---
Looks good now.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> arch/arm/include/asm/cti.h | 179
> ++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 179 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/include/asm/cti.h
>
> diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
> new file mode 100644
> index 0000000..a0ada3e
> --- /dev/null
> +++ b/arch/arm/include/asm/cti.h
> @@ -0,0 +1,179 @@
> +#ifndef __ASMARM_CTI_H
> +#define __ASMARM_CTI_H
> +
> +#include <asm/io.h>
> +
> +/* The registers' definition is from section 3.2 of
> + * Embedded Cross Trigger Revision: r0p0
> + */
> +#define CTICONTROL 0x000
> +#define CTISTATUS 0x004
> +#define CTILOCK 0x008
> +#define CTIPROTECTION 0x00C
> +#define CTIINTACK 0x010
> +#define CTIAPPSET 0x014
> +#define CTIAPPCLEAR 0x018
> +#define CTIAPPPULSE 0x01c
> +#define CTIINEN 0x020
> +#define CTIOUTEN 0x0A0
> +#define CTITRIGINSTATUS 0x130
> +#define CTITRIGOUTSTATUS 0x134
> +#define CTICHINSTATUS 0x138
> +#define CTICHOUTSTATUS 0x13c
> +#define CTIPERIPHID0 0xFE0
> +#define CTIPERIPHID1 0xFE4
> +#define CTIPERIPHID2 0xFE8
> +#define CTIPERIPHID3 0xFEC
> +#define CTIPCELLID0 0xFF0
> +#define CTIPCELLID1 0xFF4
> +#define CTIPCELLID2 0xFF8
> +#define CTIPCELLID3 0xFFC
> +
> +/* The below are from section 3.6.4 of
> + * CoreSight v1.0 Architecture Specification
> + */
> +#define LOCKACCESS 0xFB0
> +#define LOCKSTATUS 0xFB4
> +
> +/* write this value to LOCKACCESS will unlock the module, and
> + * other value will lock the module
> + */
> +#define LOCKCODE 0xC5ACCE55
> +
> +/**
> + * struct cti - cross trigger interface struct
> + * @base: mapped virtual address for the cti base
> + * @irq: irq number for the cti
> + * @trig_out_for_irq: triger out number which will cause
> + * the @irq happen
> + *
> + * cti struct used to operate cti registers.
> + */
> +struct cti {
> + void __iomem *base;
> + int irq;
> + int trig_out_for_irq;
> +};
> +
> +/**
> + * cti_init - initialize the cti instance
> + * @cti: cti instance
> + * @base: mapped virtual address for the cti base
> + * @irq: irq number for the cti
> + * @trig_out: triger out number which will cause
> + * the @irq happen
> + *
> + * called by machine code to pass the board dependent
> + * @base, @irq and @trig_out to cti.
> + */
> +static inline void cti_init(struct cti *cti,
> + void __iomem *base, int irq, int trig_out)
> +{
> + cti->base = base;
> + cti->irq = irq;
> + cti->trig_out_for_irq = trig_out;
> +}
> +
> +/**
> + * cti_map_trigger - use the @chan to map @trig_in to @trig_out
> + * @cti: cti instance
> + * @trig_in: trigger in number
> + * @trig_out: trigger out number
> + * @channel: channel number
> + *
> + * This function maps one trigger in of @trig_in to one trigger
> + * out of @trig_out using the channel @chan.
> + */
> +static inline void cti_map_trigger(struct cti *cti,
> + int trig_in, int trig_out, int chan)
> +{
> + void __iomem *base = cti->base;
> + unsigned long val;
> +
> + val = __raw_readl(base + CTIINEN + trig_in * 4);
> + val |= BIT(chan);
> + __raw_writel(val, base + CTIINEN + trig_in * 4);
> +
> + val = __raw_readl(base + CTIOUTEN + trig_out * 4);
> + val |= BIT(chan);
> + __raw_writel(val, base + CTIOUTEN + trig_out * 4);
> +}
> +
> +/**
> + * cti_enable - enable the cti module
> + * @cti: cti instance
> + *
> + * enable the cti module
> + */
> +static inline void cti_enable(struct cti *cti)
> +{
> + __raw_writel(0x1, cti->base + CTICONTROL);
> +}
> +
> +/**
> + * cti_disable - disable the cti module
> + * @cti: cti instance
> + *
> + * enable the cti module
> + */
> +static inline void cti_disable(struct cti *cti)
> +{
> + __raw_writel(0, cti->base + CTICONTROL);
> +}
> +
> +/**
> + * cti_irq_ack - clear the cti irq
> + * @cti: cti instance
> + *
> + * clear the cti irq
> + */
> +static inline void cti_irq_ack(struct cti *cti)
> +{
> + void __iomem *base = cti->base;
> + unsigned long val;
> +
> + val = __raw_readl(base + CTIINTACK);
> + val |= BIT(cti->trig_out_for_irq);
> + __raw_writel(val, base + CTIINTACK);
> +}
> +
> +/**
> + * cti_unlock - unlock cti module
> + * @cti: cti instance
> + *
> + * unlock the cti module, or else any writes to the cti
> + * module is not allowed.
> + */
> +static inline void cti_unlock(struct cti *cti)
> +{
> + void __iomem *base = cti->base;
> + unsigned long val;
> +
> + val = __raw_readl(base + LOCKSTATUS);
> +
> + if (val & 1) {
> + val = LOCKCODE;
> + __raw_writel(val, base + LOCKACCESS);
> + }
> +}
> +
> +/**
> + * cti_lock - lock cti module
> + * @cti: cti instance
> + *
> + * lock the cti module, so any writes to the cti
> + * module will be not allowed.
> + */
> +static inline void cti_lock(struct cti *cti)
> +{
> + void __iomem *base = cti->base;
> + unsigned long val;
> +
> + val = __raw_readl(base + LOCKSTATUS);
> +
> + if (!(val & 1)) {
> + val = ~LOCKCODE;
> + __raw_writel(val, base + LOCKACCESS);
> + }
> +}
> +#endif
> --
> 1.7.3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 18+ messages in thread
* [patch v4 1/3] arm: introduce cross trigger interface helpers
2011-03-08 16:31 ` Ben Dooks
@ 2011-03-24 14:41 ` Ming Lei
0 siblings, 0 replies; 18+ messages in thread
From: Ming Lei @ 2011-03-24 14:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ben,
2011/3/9 Ben Dooks <ben-linux@fluff.org>:
> could you just use the primecell register information for these
Seems there is no the primecell register information for these.
Follows some comment from Will in private mail:
Other primecell drivers in the kernel (sp810, pl330, nomadik MTU, ...)
define these themselves so I don't see the problem. Furthermore,
the actual ID registers are often incorrect in the hardware, but
we don't appear to be using them anyway.
>> +static inline void cti_irq_ack(struct cti *cti)
>> +{
>> + ? ? void __iomem *base = cti->base;
>> + ? ? unsigned long val;
>> +
>> + ? ? val = __raw_readl(base + CTIINTACK);
>> + ? ? val |= BIT(cti->trig_out_for_irq);
>
> would it be easier to get a pre-shifted bit here?
I don't think the above is more difficult, do I?
thanks,
--
Lei Ming
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch v4 3/3] arm: omap4: support pmu
2011-03-08 15:38 ` tom.leiming at gmail.com
@ 2011-05-14 8:18 ` Rabin Vincent
-1 siblings, 0 replies; 18+ messages in thread
From: Rabin Vincent @ 2011-05-14 8:18 UTC (permalink / raw)
To: tom.leiming
Cc: linux, linux-omap, Woodruff Richard, will.deacon, linux-arm-kernel
On Tue, Mar 8, 2011 at 21:08, <tom.leiming@gmail.com> wrote:
> From: Ming Lei <tom.leiming@gmail.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: linux-omap@vger.kernel.org
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
What happened to this patch? It is neither in mainline nor in
linux-next.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [patch v4 3/3] arm: omap4: support pmu
@ 2011-05-14 8:18 ` Rabin Vincent
0 siblings, 0 replies; 18+ messages in thread
From: Rabin Vincent @ 2011-05-14 8:18 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Mar 8, 2011 at 21:08, <tom.leiming@gmail.com> wrote:
> From: Ming Lei <tom.leiming@gmail.com>
>
> This patch supports pmu irq routed from CTI, so
> make pmu/perf working on OMAP4.
>
> The idea is from Woodruff Richard in the disscussion
> about "Oprofile on Pandaboard / Omap4" on pandaboard at googlegroups.com.
>
> Acked-by: Jean Pihet <j-pihet@ti.com>
> Acked-by: Tony Lindgren <tony@atomide.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Woodruff Richard <r-woodruff2@ti.com>
> Cc: linux-omap at vger.kernel.org
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
What happened to this patch? It is neither in mainline nor in
linux-next.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch v4 3/3] arm: omap4: support pmu
2011-05-14 8:18 ` Rabin Vincent
@ 2011-05-14 8:48 ` Ming Lei
-1 siblings, 0 replies; 18+ messages in thread
From: Ming Lei @ 2011-05-14 8:48 UTC (permalink / raw)
To: Rabin Vincent
Cc: linux, linux-omap, Woodruff Richard, will.deacon, linux-arm-kernel
Hi Rabin,
2011/5/14 Rabin Vincent <rabin@rab.in>:
> What happened to this patch? It is neither in mainline nor in
> linux-next.
>
This patch depends on the two with titles:
introduce cross trigger interface helpers
pmu: allow platform specific irq enable/disable handling
and the above patches have been submitted to RMK's patch system
as 6839/1 and 6840/1, but not been pushed to -next or mainline by rmk,
so I can't ask omap guys to merge this one into their tree now.
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] 18+ messages in thread
* [patch v4 3/3] arm: omap4: support pmu
@ 2011-05-14 8:48 ` Ming Lei
0 siblings, 0 replies; 18+ messages in thread
From: Ming Lei @ 2011-05-14 8:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rabin,
2011/5/14 Rabin Vincent <rabin@rab.in>:
> What happened to this patch? ?It is neither in mainline nor in
> linux-next.
>
This patch depends on the two with titles:
introduce cross trigger interface helpers
pmu: allow platform specific irq enable/disable handling
and the above patches have been submitted to RMK's patch system
as 6839/1 and 6840/1, but not been pushed to -next or mainline by rmk,
so I can't ask omap guys to merge this one into their tree now.
thanks,
--
Ming Lei
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch v4 3/3] arm: omap4: support pmu
2011-05-14 8:48 ` Ming Lei
@ 2011-05-14 9:49 ` Russell King - ARM Linux
-1 siblings, 0 replies; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-05-14 9:49 UTC (permalink / raw)
To: Ming Lei
Cc: Rabin Vincent, linux-omap, Woodruff Richard, will.deacon,
linux-arm-kernel
On Sat, May 14, 2011 at 04:48:52PM +0800, Ming Lei wrote:
> Hi Rabin,
>
> 2011/5/14 Rabin Vincent <rabin@rab.in>:
> > What happened to this patch? It is neither in mainline nor in
> > linux-next.
> >
>
> This patch depends on the two with titles:
>
> introduce cross trigger interface helpers
> pmu: allow platform specific irq enable/disable handling
>
> and the above patches have been submitted to RMK's patch system
> as 6839/1 and 6840/1, but not been pushed to -next or mainline by rmk,
> so I can't ask omap guys to merge this one into their tree now.
Given the state of linux-next, which isn't showing much in the way of
consolidation by anyone other than what's in my tree, I'm _desperately_
avoiding adding any new code for this coming merge window. In fact, the
picture in linux-next is looking worse than the state of my tree.
For arch/arm, my tree looks like this:
256 files changed, 1022 insertions(+), 14022 deletions(-)
And for-next:
748 files changed, 15066 insertions(+), 26209 deletions(-)
So there's a net reduction of 13000 lines in my tree, compared to a net
reduction of 11143 lines in linux-next - so a net increase of 1857 lines
for arch/arm from trees which aren't my tree.
This is rather disappointing, and if linux-next really does reflect the
current state across all ARM trees, it means that we have to keep the
consolidation agenda running into the next merge cycle.
So, I really can not afford to be adding new stuff into my tree at the
present time.
--
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] 18+ messages in thread
* [patch v4 3/3] arm: omap4: support pmu
@ 2011-05-14 9:49 ` Russell King - ARM Linux
0 siblings, 0 replies; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-05-14 9:49 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, May 14, 2011 at 04:48:52PM +0800, Ming Lei wrote:
> Hi Rabin,
>
> 2011/5/14 Rabin Vincent <rabin@rab.in>:
> > What happened to this patch? ?It is neither in mainline nor in
> > linux-next.
> >
>
> This patch depends on the two with titles:
>
> introduce cross trigger interface helpers
> pmu: allow platform specific irq enable/disable handling
>
> and the above patches have been submitted to RMK's patch system
> as 6839/1 and 6840/1, but not been pushed to -next or mainline by rmk,
> so I can't ask omap guys to merge this one into their tree now.
Given the state of linux-next, which isn't showing much in the way of
consolidation by anyone other than what's in my tree, I'm _desperately_
avoiding adding any new code for this coming merge window. In fact, the
picture in linux-next is looking worse than the state of my tree.
For arch/arm, my tree looks like this:
256 files changed, 1022 insertions(+), 14022 deletions(-)
And for-next:
748 files changed, 15066 insertions(+), 26209 deletions(-)
So there's a net reduction of 13000 lines in my tree, compared to a net
reduction of 11143 lines in linux-next - so a net increase of 1857 lines
for arch/arm from trees which aren't my tree.
This is rather disappointing, and if linux-next really does reflect the
current state across all ARM trees, it means that we have to keep the
consolidation agenda running into the next merge cycle.
So, I really can not afford to be adding new stuff into my tree at the
present time.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch v4 3/3] arm: omap4: support pmu
2011-05-14 8:48 ` Ming Lei
@ 2011-05-15 14:16 ` Will Deacon
-1 siblings, 0 replies; 18+ messages in thread
From: Will Deacon @ 2011-05-15 14:16 UTC (permalink / raw)
To: Ming Lei
Cc: Woodruff Richard, linux, avik.sil, Rabin Vincent, linux-omap,
linux-arm-kernel
[Adding Avik],
On Sat, 2011-05-14 at 09:48 +0100, Ming Lei wrote:
> Hi Rabin,
>
> 2011/5/14 Rabin Vincent <rabin@rab.in>:
> > What happened to this patch? It is neither in mainline nor in
> > linux-next.
> >
>
> This patch depends on the two with titles:
>
> introduce cross trigger interface helpers
> pmu: allow platform specific irq enable/disable handling
>
> and the above patches have been submitted to RMK's patch system
> as 6839/1 and 6840/1, but not been pushed to -next or mainline by rmk,
> so I can't ask omap guys to merge this one into their tree now.
I don't think that Avik's problem with this patch has been fully
addressed yet:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/046899.html
So regardless of the state of -next, I think there's still some more
work to do on this code before it can go upstream.
Will
^ permalink raw reply [flat|nested] 18+ messages in thread
* [patch v4 3/3] arm: omap4: support pmu
@ 2011-05-15 14:16 ` Will Deacon
0 siblings, 0 replies; 18+ messages in thread
From: Will Deacon @ 2011-05-15 14:16 UTC (permalink / raw)
To: linux-arm-kernel
[Adding Avik],
On Sat, 2011-05-14 at 09:48 +0100, Ming Lei wrote:
> Hi Rabin,
>
> 2011/5/14 Rabin Vincent <rabin@rab.in>:
> > What happened to this patch? It is neither in mainline nor in
> > linux-next.
> >
>
> This patch depends on the two with titles:
>
> introduce cross trigger interface helpers
> pmu: allow platform specific irq enable/disable handling
>
> and the above patches have been submitted to RMK's patch system
> as 6839/1 and 6840/1, but not been pushed to -next or mainline by rmk,
> so I can't ask omap guys to merge this one into their tree now.
I don't think that Avik's problem with this patch has been fully
addressed yet:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/046899.html
So regardless of the state of -next, I think there's still some more
work to do on this code before it can go upstream.
Will
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch v4 3/3] arm: omap4: support pmu
2011-05-15 14:16 ` Will Deacon
@ 2011-05-16 1:28 ` Ming Lei
-1 siblings, 0 replies; 18+ messages in thread
From: Ming Lei @ 2011-05-16 1:28 UTC (permalink / raw)
To: Will Deacon
Cc: Rabin Vincent, linux, linux-omap, Woodruff Richard,
linux-arm-kernel, avik.sil
Hi,
2011/5/15 Will Deacon <will.deacon@arm.com>:
> [Adding Avik],
>
>
> On Sat, 2011-05-14 at 09:48 +0100, Ming Lei wrote:
>> Hi Rabin,
>>
>> 2011/5/14 Rabin Vincent <rabin@rab.in>:
>> > What happened to this patch? It is neither in mainline nor in
>> > linux-next.
>> >
>>
>> This patch depends on the two with titles:
>>
>> introduce cross trigger interface helpers
>> pmu: allow platform specific irq enable/disable handling
>>
>> and the above patches have been submitted to RMK's patch system
>> as 6839/1 and 6840/1, but not been pushed to -next or mainline by rmk,
>> so I can't ask omap guys to merge this one into their tree now.
>
> I don't think that Avik's problem with this patch has been fully
> addressed yet:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/046899.html
>
> So regardless of the state of -next, I think there's still some more
> work to do on this code before it can go upstream.
I remembered that Avik reported his issue on linaro kernel, instead of mainline.
If Avik can reproduce this issue on mainline plus pandaboard, we can help to
do it. In fact, this issue is not reproduced at all in mainline on my
pandaboard.
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] 18+ messages in thread
* [patch v4 3/3] arm: omap4: support pmu
@ 2011-05-16 1:28 ` Ming Lei
0 siblings, 0 replies; 18+ messages in thread
From: Ming Lei @ 2011-05-16 1:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
2011/5/15 Will Deacon <will.deacon@arm.com>:
> [Adding Avik],
>
>
> On Sat, 2011-05-14 at 09:48 +0100, Ming Lei wrote:
>> Hi Rabin,
>>
>> 2011/5/14 Rabin Vincent <rabin@rab.in>:
>> > What happened to this patch? ?It is neither in mainline nor in
>> > linux-next.
>> >
>>
>> This patch depends on the two with titles:
>>
>> ? ? ? introduce cross trigger interface helpers
>> ? ? ? pmu: allow platform specific irq enable/disable handling
>>
>> and the above patches have been submitted to RMK's patch system
>> as 6839/1 and 6840/1, but not been pushed to -next or mainline by rmk,
>> so I can't ask omap guys to merge this one into their tree now.
>
> I don't think that Avik's problem with this patch has been fully
> addressed yet:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/046899.html
>
> So regardless of the state of -next, I think there's still some more
> work to do on this code before it can go upstream.
I remembered that Avik reported his issue on linaro kernel, instead of mainline.
If Avik can reproduce this issue on mainline plus pandaboard, we can help to
do it. In fact, this issue is not reproduced at all in mainline on my
pandaboard.
thanks,
--
Ming Lei
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-05-16 1:28 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-08 15:38 [patch v4 0/3] arm: pmu: support pmu/perf on OMAP4 tom.leiming at gmail.com
2011-03-08 15:38 ` [patch v4 1/3] arm: introduce cross trigger interface helpers tom.leiming at gmail.com
2011-03-08 16:31 ` Ben Dooks
2011-03-24 14:41 ` Ming Lei
2011-03-09 5:38 ` Santosh Shilimkar
2011-03-08 15:38 ` [patch v4 2/3] arm: pmu: allow platform specific irq enable/disable handling tom.leiming at gmail.com
2011-03-08 15:38 ` [patch v4 3/3] arm: omap4: support pmu tom.leiming
2011-03-08 15:38 ` tom.leiming at gmail.com
2011-05-14 8:18 ` Rabin Vincent
2011-05-14 8:18 ` Rabin Vincent
2011-05-14 8:48 ` Ming Lei
2011-05-14 8:48 ` Ming Lei
2011-05-14 9:49 ` Russell King - ARM Linux
2011-05-14 9:49 ` Russell King - ARM Linux
2011-05-15 14:16 ` Will Deacon
2011-05-15 14:16 ` Will Deacon
2011-05-16 1:28 ` Ming Lei
2011-05-16 1:28 ` Ming Lei
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.