arm: pmu: support pmu/perf on OMAP4

From 6125bef1aeee84ef22efdf743077f27f5274b6da Mon Sep 17 00:00:00 2001

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

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

From: Ming Lei <[email protected]>

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

This patch supports device with other non-irq resources.

Signed-off-by Ming Lei <[email protected]>

---
 arch/arm/kernel/perf_event.c |    5 +++--
 arch/arm/kernel/pmu.c        |   12 ++++++++++--
 2 files changed, 13 insertions(+), 4 deletions(-)

arch/arm/kernel/perf_event.c +1 -0

index f367780..d91dba2 100644
@@ -19,6 +19,7 @@
 #include <linux/platform_device.h>
 #include <linux/spinlock.h>
 #include <linux/uaccess.h>
+#include <linux/cpumask.h>
 
 #include <asm/cputype.h>
 #include <asm/irq.h>

Hi Ming Lei,

Quoted 6 lines · ming.lei at canonical.com

From: Ming Lei <[email protected]>

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

This patch supports device with other non-irq resources.

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

Quoted 19 lines

Signed-off-by Ming Lei <[email protected]>

---
?arch/arm/kernel/perf_event.c | ? ?5 +++-- ?arch/arm/kernel/pmu.c ? ? ? ?| ? 12 ++++++++++-- ?2 files changed, 13 insertions(+), 4 deletions(-)

arch/arm/kernel/perf_event.c +0 -0

index f367780..d91dba2 100644
@@ -19,6 +19,7 @@

?#include <linux/platform_device.h>
?#include <linux/spinlock.h>
?#include <linux/uaccess.h>
+#include <linux/cpumask.h>

?#include <asm/cputype.h>
?#include <asm/irq.h>

arch/arm/kernel/perf_event.c armpmu_reserve_hardware(void) · line 421

Quoted 8 lines

arch/arm/kernel/perf_event.c +1 -1

@@ -414,7 +415,7 @@ armpmu_reserve_hardware(void)
 ? ? ? ? ? ? ? return -ENODEV;
 ? ? ? }
 
- ? ? for (i = 0; i < pmu_device->num_resources; ++i) {
+ ? ? for (i = 0; i < nr_cpu_ids; ++i) {
 ? ? ? ? ? ? ? irq = platform_get_irq(pmu_device, i);
 ? ? ? ? ? ? ? if (irq < 0)
 ? ? ? ? ? ? ? ? ? ? ? continue;

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

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

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

Quoted 9 lines

arch/arm/kernel/pmu.c +0 -0

index c53474f..0e9c908 100644
@@ -19,6 +19,7 @@

?#include <linux/module.h>
?#include <linux/of_device.h>
?#include <linux/platform_device.h>
+#include <linux/cpumask.h>

'fraid I've changed this file too!

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

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html

Quoted 8 lines

Quoted 5 lines

- ? ? for (i = 0; i < pmu_device->num_resources; ++i) {
+ ? ? for (i = 0; i < nr_cpu_ids; ++i) {
? ? ? ? ? ? ? irq = platform_get_irq(pmu_device, i); ? ? ? ? ? ? ? if (irq < 0)
? ? ? ? ? ? ? ? ? ? ? continue;

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

Quoted 4 lines

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

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

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

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

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

Quoted 2 lines · Will Deacon

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

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

Quoted 9 lines · Paul Walmsley

Quoted 2 lines · Will Deacon

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

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

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

Paul, expect your comments on OMAP4 parts.

+ Beno?t

Hi

Quoted 11 lines · Ming Lei

Quoted 9 lines · Paul Walmsley

Quoted 2 lines · Will Deacon

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

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

Quoted 5 lines

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

Paul, expect your comments on OMAP4 parts.

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

Quoted 2 lines · Paul Walmsley

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

Beno?t, gentle ping, :-)

From: Ming Lei <[email protected]>

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

Signed-off-by Ming Lei <[email protected]>

---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -0

index 393afac..c7289a8 100644
@@ -5276,6 +5276,30 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
 	.slaves_cnt	= ARRAY_SIZE(omap44xx_wd_timer3_slaves),
 };

Review

Quoted 5 lines

(quoted diff) +5 -0

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

Are you sure these are part of the emulation IP? ?We already have those

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

Review

Quoted 8 lines

(quoted diff) +8 -0

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

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

Quoted 10 lines

+ ? ? ? ? ? ? ? ? ? ? .modulemode ? = MODULEMODE_HWCTRL,
+ ? ? ? ? ? ? },
+ ? ? },
+ ? ? .mpu_irqs ? ? ? = omap44xx_emu_irqs,

(quoted diff) +2 -0

+};
+

?static __initdata struct omap_hwmod *omap44xx_hwmods[] = {

? ? ? /* dmm class */

Quoted 7 lines · Paul Walmsley

Review

Quoted 5 lines

(quoted diff) +5 -0

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

Are you sure these are part of the emulation IP? ?We already have those

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

Quoted 1 line

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

I just see it, but looks like the "mpu" hwmod isn't populated as omap_device, so the CTI irqs aren't requested now.

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

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

Quoted 10 lines

Review

Quoted 8 lines

(quoted diff) +8 -0

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

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

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

Quoted 2 lines · Ming Lei

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

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

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

[Adding Benoit to CC].

Quoted 8 lines · Paul Walmsley

Quoted 2 lines · Ming Lei

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

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

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

Quoted 6 lines · Will Deacon

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

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

Quoted 12 lines · Will Deacon

[Adding Benoit to CC].

Quoted 8 lines · Paul Walmsley

Quoted 2 lines · Ming Lei

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

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

Quoted 6 lines

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

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

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

Hi Benoit,

Quoted 1 line · Benoit

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

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

Hi Will,

Quoted 1 line

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

And I'll do :-)

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

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

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

The MPU will then only have the PL310 IRQ.

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

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

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

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

Hello Ming Lei,

just a few quick comments for now -

Quoted 10 lines · Ming Lei

Quoted 7 lines · Paul Walmsley

Review

Quoted 5 lines

(quoted diff) +5 -0

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

Are you sure these are part of the emulation IP? We already have those

Quoted 7 lines

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

Quoted 1 line

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

I just see it, but looks like the "mpu" hwmod isn't populated as omap_device, so the CTI irqs aren't requested now.

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

Quoted 2 lines

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

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

Quoted 14 lines

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

Quoted 10 lines

Review

Quoted 8 lines

(quoted diff) +8 -0

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

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

Quoted 3 lines

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

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

Hi Ming Lei,

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

Hi Benoit,

Quoted 3 lines · Benoit

Hi Ming Lei,

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

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

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

Then we'll have:

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

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

Cheers,

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html

Quoted 1 line · Will Deacon

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

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

Quoted 7 lines

Then we'll have:

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

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

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

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

Quoted 6 lines · Paul Walmsley

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

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

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

Quoted 8 lines · Will Deacon

Quoted 6 lines · Paul Walmsley

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

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

Quoted 2 lines

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

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

Quoted 12 lines · Ming Lei

Quoted 10 lines · Will Deacon

Quoted 6 lines · Paul Walmsley

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

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

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

Quoted 3 lines

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

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

Hi Ming Lei,

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

Quoted 55 lines

Hello Ming Lei,

just a few quick comments for now -

Quoted 10 lines · Ming Lei

Quoted 7 lines · On Tue, Nov 8, 2011 at 11:26 PM, Paul Walmsley<[email protected]> ?wrote:

Review

Quoted 5 lines

(quoted diff) +5 -0

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

Are you sure these are part of the emulation IP? ?We already have those

Quoted 7 lines

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

Quoted 1 line

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

I just see it, but looks like the "mpu" hwmod isn't populated as omap_device, so the CTI irqs aren't requested now.

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

Quoted 2 lines

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

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

Quoted 14 lines

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

Quoted 10 lines

Review

Quoted 8 lines

(quoted diff) +8 -0

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

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

Quoted 3 lines

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

Quoted 7 lines

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

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

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

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

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

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

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

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

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

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

Regards,
Benoit

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

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

Re-map the CTIs IRQs from MPU to DEBUGSS.

Signed-off-by Benoit Cousson <[email protected]>

Cc Ming Lei <[email protected]>

---
?arch/arm/mach-omap2/omap_hwmod_44xx_data.c | ?177 +++++++++++++++++++++++++++- ?1 files changed, 174 insertions(+), 3 deletions(-)

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -0

index 7695e5d..6cf21ee 100644
@@ -47,6 +47,7 @@
 

?/* Backward references (IPs with Bus Master capability) */ ?static struct omap_hwmod omap44xx_aess_hwmod; +static struct omap_hwmod omap44xx_debugss_hwmod; ?static struct omap_hwmod omap44xx_dma_system_hwmod; ?static struct omap_hwmod omap44xx_dmm_hwmod; ?static struct omap_hwmod omap44xx_dsp_hwmod;

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -0

@@ -337,6 +338,14 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
 ?};
 

?/* l3_main_2 */

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +8 -0

+/* debugss -> l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_debugss__l3_main_2 = {
+ ? ? ? .master ? ? ? ? = &omap44xx_debugss_hwmod,
+ ? ? ? .slave ? ? ? ? ?= &omap44xx_l3_main_2_hwmod,
+ ? ? ? .clk ? ? ? ? ? ?= "dbgclk_mux_ck",
+ ? ? ? .user ? ? ? ? ? = OCP_USER_MPU | OCP_USER_SDMA,
+};
+

?/* dma_system -> l3_main_2 */
?static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = { ? ? ? ?.master ? ? ? ? = &omap44xx_dma_system_hwmod,

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -0

@@ -686,7 +695,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {

?* ?ctrl_module_pad_core
?* ?ctrl_module_pad_wkup
?* ?ctrl_module_wkup
- * ?debugss
?* ?efuse_ctrl_cust
?* ?efuse_ctrl_std
?* ?elm

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -0

@@ -908,6 +916,168 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
 ?};
 

?/*
+ * 'debugss' class
+ * debug and emulation sub system
+ */

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +159 -0

+
+static struct omap_hwmod_class_sysconfig omap44xx_debugss_sysc = {
+ ? ? ? .rev_offs ? ? ? = 0x0000,
+ ? ? ? .sysc_offs ? ? ?= 0x0010,
+ ? ? ? .syss_offs ? ? ?= 0x0014,
+ ? ? ? .sysc_flags ? ? = (SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ ? ? ? .sysc_fields ? ?= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_debugss_hwmod_class = {
+ ? ? ? .name ? = "debugss",
+ ? ? ? .sysc ? = &omap44xx_debugss_sysc,
+};
+
+/* debugss */
+static struct omap_hwmod_irq_info omap44xx_debugss_irqs[] = {
+ ? ? ? { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
+ ? ? ? { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
+ ? ? ? { .irq = -1 }
+};
+
+/* debugss master ports */
+static struct omap_hwmod_ocp_if *omap44xx_debugss_masters[] = {
+ ? ? ? &omap44xx_debugss__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_debugss_addrs[] = {
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "mipi_stm_add_sp_0",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54000000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x540fffff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "mipi_stm_add_sp_1",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54100000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x5413ffff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "mpu_c0_debug",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54140000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54141fff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "mpu_c1_debug",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54142000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54143fff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "cti0_mpu",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54148000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54148fff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "cti1_mpu",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54149000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54149fff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "ptm0_mpu",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x5414c000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x5414cfff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "ptm1_mpu",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x5414d000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x5414dfff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "tf_mpu",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54158000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54158fff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "dap_pc_mpu",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54159000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54159fff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "apb_bridge_a_ctrl_time_out",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x5415f000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x5415ffff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "drm",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54160000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54160fff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "mipi_stm",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54161000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54161fff,
+ ? ? ? ? ? ? ? .flags ? ? ? ? ?= ADDR_TYPE_RT
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "csetb",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54162000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54162fff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "cstpiu",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54163000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54163fff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "cstf1",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54164000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54164fff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "cstf2",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54165000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54165fff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "l4_cfg_emu_conf_regs",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54167000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54167fff,
+ ? ? ? },
+ ? ? ? {
+ ? ? ? ? ? ? ? .name ? ? ? ? ? = "l3_instr_emu_conf_regs",
+ ? ? ? ? ? ? ? .pa_start ? ? ? = 0x54180000,
+ ? ? ? ? ? ? ? .pa_end ? ? ? ? = 0x54180fff,
+ ? ? ? },
+ ? ? ? { }
+};
+
+/* l3_instr -> debugss */
+static struct omap_hwmod_ocp_if omap44xx_l3_instr__debugss = {
+ ? ? ? .master ? ? ? ? = &omap44xx_l3_instr_hwmod,
+ ? ? ? .slave ? ? ? ? ?= &omap44xx_debugss_hwmod,
+ ? ? ? .clk ? ? ? ? ? ?= "l3_div_ck",
+ ? ? ? .addr ? ? ? ? ? = omap44xx_debugss_addrs,
+ ? ? ? .user ? ? ? ? ? = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* debugss slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_debugss_slaves[] = {
+ ? ? ? &omap44xx_l3_instr__debugss,
+};
+
+static struct omap_hwmod omap44xx_debugss_hwmod = {
+ ? ? ? .name ? ? ? ? ? = "debugss",
+ ? ? ? .class ? ? ? ? ?= &omap44xx_debugss_hwmod_class,
+ ? ? ? .clkdm_name ? ? = "emu_sys_clkdm",
+ ? ? ? .mpu_irqs ? ? ? = omap44xx_debugss_irqs,
+ ? ? ? .main_clk ? ? ? = "trace_clk_div_ck",
+ ? ? ? .prcm = {
+ ? ? ? ? ? ? ? .omap4 = {
+ ? ? ? ? ? ? ? ? ? ? ? .clkctrl_offs = OMAP4_CM_EMU_DEBUGSS_CLKCTRL_OFFSET,
+ ? ? ? ? ? ? ? ? ? ? ? .context_offs = OMAP4_RM_EMU_DEBUGSS_CONTEXT_OFFSET,
+ ? ? ? ? ? ? ? },
+ ? ? ? },
+ ? ? ? .slaves ? ? ? ? = omap44xx_debugss_slaves,
+ ? ? ? .slaves_cnt ? ? = ARRAY_SIZE(omap44xx_debugss_slaves),
+ ? ? ? .masters ? ? ? ?= omap44xx_debugss_masters,
+ ? ? ? .masters_cnt ? ?= ARRAY_SIZE(omap44xx_debugss_masters),
+};
+
+/*

?* 'dma' class
?* dma controller for data exchange between memory to memory (i.e. internal or ?* external memory) and gp peripherals to memory or memory to gp peripherals

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -0

@@ -3902,8 +4072,6 @@ static struct omap_hwmod_class omap44xx_mpu_hwmod_class = {

?/* mpu */
?static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = { ? ? ? ?{ .name = "pl310", .irq = 0 + OMAP44XX_IRQ_GIC_START },
- ? ? ? { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
- ? ? ? { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START }, ? ? ? ?{ .irq = -1 }
?};

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -0

@@ -5308,6 +5476,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {

? ? ? ?/* counter class */
?/* ? ? &omap44xx_counter_32k_hwmod, */

+ ? ? ? /* debugss class */
+ ? ? ? &omap44xx_debugss_hwmod,
+
? ? ? ?/* dma class */
? ? ? ?&omap44xx_dma_system_hwmod,

--
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html

From: Benoit Cousson <[email protected]>
Date: Fri, 18 Nov 2011 11:42:12 +0100
Subject: [PATCH] ARM: OMAP4: hwmod data: Add support for the debug modules

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

Re-map the CTIs IRQs from MPU to DEBUGSS.

Signed-off-by Benoit Cousson <[email protected]>

Cc Ming Lei <[email protected]>

---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  177 +++++++++++++++++++++++++++-
 1 files changed, 174 insertions(+), 3 deletions(-)

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +10 -1

index 7695e5d..6cf21ee 100644
@@ -47,6 +47,7 @@
 
 /* Backward references (IPs with Bus Master capability) */
 static struct omap_hwmod omap44xx_aess_hwmod;
+static struct omap_hwmod omap44xx_debugss_hwmod;
 static struct omap_hwmod omap44xx_dma_system_hwmod;
 static struct omap_hwmod omap44xx_dmm_hwmod;
 static struct omap_hwmod omap44xx_dsp_hwmod;

@@ -337,6 +338,14 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
 };
 
 /* l3_main_2 */
+/* debugss -> l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_debugss__l3_main_2 = {
+	.master		= &omap44xx_debugss_hwmod,
+	.slave		= &omap44xx_l3_main_2_hwmod,
+	.clk		= "dbgclk_mux_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* dma_system -> l3_main_2 */
 static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
 	.master		= &omap44xx_dma_system_hwmod,

@@ -686,7 +695,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
  *  ctrl_module_pad_core
  *  ctrl_module_pad_wkup
  *  ctrl_module_wkup
- *  debugss
  *  efuse_ctrl_cust
  *  efuse_ctrl_std
  *  elm

@@ -908,6 +916,168 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
 };
 
 /*
+ * 'debugss' class

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +106 -0

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

From the basic documentation that I have here, it's not clear to me where

Hi Beno?t,

a question about this patch.

arch/arm/mach-omap2/omap_hwmod_44xx_data.c static struct omap_hwmod omap44xx_counter_32k_hwmod = { · line 1013

Quoted 4 lines

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +4 -0

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

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

Quoted 3 lines · Paul Walmsley

Hi Beno?t,

a question about this patch.

...

Quoted 8 lines

arch/arm/mach-omap2/omap_hwmod_44xx_data.c static struct omap_hwmod omap44xx_counter_32k_hwmod = { · line 1013

Quoted 4 lines

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +4 -0

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

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

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

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

Quoted 2 lines · Paul Walmsley

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

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

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

Any thought?

Quoted 19 lines · Benoit

Quoted 2 lines · Paul Walmsley

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

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

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

Quoted 1 line

Any thought?

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

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

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

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

Hi

I just read

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

Looks to me that the L3_EMU interconnect and the emulation IP blocks need

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

?static struct platform_device* __init omap4_init_pmu(void) ?{
? ? ? ?int id = -1;

(quoted diff) +4 -0

@@ -420,6 +472,10 @@ static struct platform_device* __init omap4_init_pmu(void)
 ? ? ? ? ? ? ? ?return NULL;
 ? ? ? ?}
 
+ ? ? ? omap4_pmu_data.handle_irq = omap4_pmu_handler;
+ ? ? ? omap4_pmu_data.enable_irq = omap4_enable_cti;
+ ? ? ? omap4_pmu_data.disable_irq = omap4_disable_cti;
+
 ? ? ? ?pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sizeof(omap4_pmu_data),
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?omap_pmu_latency,

Quoted 17 lines · On Mon, Oct 24, 2011 at 20:15, ?<[email protected]> wrote:

?static struct platform_device* __init omap4_init_pmu(void) ?{
? ? ? ?int id = -1;

(quoted diff) +4 -0

@@ -420,6 +472,10 @@ static struct platform_device* __init omap4_init_pmu(void)
 ? ? ? ? ? ? ? ?return NULL;
 ? ? ? ?}
 
+ ? ? ? omap4_pmu_data.handle_irq = omap4_pmu_handler;
+ ? ? ? omap4_pmu_data.enable_irq = omap4_enable_cti;
+ ? ? ? omap4_pmu_data.disable_irq = omap4_disable_cti;
+
 ? ? ? ?pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sizeof(omap4_pmu_data),
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?omap_pmu_latency,

@@ -440,7 +496,9 @@ static void __init omap_init_pmu(void)
 ? ? ? ? ? ? ? ?pd = omap4_init_pmu();
 ? ? ? ? ? ? ? ?if (!pd)

Review static void __init omap_init_pmu(void) · line 501

Quoted 5 lines

(quoted diff) +3 -1

 ? ? ? ? ? ? ? ? ? ? ? ?return;
- ? ? ? ? ? ? ? omap_device_enable(pd);
+
+ ? ? ? ? ? ? ? omap_device_enable(&od->pdev);
+ ? ? ? ? ? ? ? omap4_configure_pmu_irq();

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