Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Paul, On 11/29/2011 7:11 PM, Paul Walmsley wrote: On Tue, 29 Nov 2011, Cousson, Benoit wrote: On 11/27/2011 3:07 AM, Paul Walmsley wrote: 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? 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. There is no OCP TA registers in this case, so finding the SYSCONFIG is the only important thing to do to set them properly at boot time. It appears to me that the DEBUGSS has no OCP header registers of its own. Yes, indeed. 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. Mmm, I'm not sure it makes sense to do that. There is only one PRCM control entry for all these IPs inside the debugss module. The diagram 28.9 seems to indicate that the STM is accessed through L3_INSTR using some internals L4_CFG_EMU and L3_INSTR_EMU buses. So for the hwmod / driver point of view having only one node for the debugss IPs connected to L3_INSTR is accurate enough. This is as well how the memory mapping is represented in the 28-42 table (28.11$). Moreover, having two different nodes controlled by a single PRCM entry will raise some dependency issue with STM and DEBUGSS. Splitting them will add some extra complexity that is not necessary in our case. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Paul, On 11/27/2011 3:07 AM, Paul Walmsley wrote: On Sat, 26 Nov 2011, Paul Walmsley wrote: Hi Benoît, a question about this patch. ... + .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? 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? Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On Tue, 29 Nov 2011, Cousson, Benoit wrote: On 11/27/2011 3:07 AM, Paul Walmsley wrote: 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? 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. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Benoît,
a question about this patch.
On Fri, 18 Nov 2011, Cousson, Benoit wrote:
From: Benoit Cousson b-cous...@ti.com
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 b-cous...@ti.com
Cc: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 177
+++-
1 files changed, 174 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7695e5d..6cf21ee 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -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
+ * debug and emulation sub system
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_debugss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
This defines the OCP register offsets for the DEBUGSS, but ...
+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 = 0x5400,
+ .pa_end = 0x540f,
+ },
+ {
+ .name = mipi_stm_add_sp_1,
+ .pa_start = 0x5410,
+ .pa_end = 0x5413,
+ },
+ {
+ .name = mpu_c0_debug,
+ .pa_start = 0x5414,
+ .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 = 0x5415,
+ },
+ {
+ .name = drm,
+ .pa_start = 0x5416,
+ .pa_end = 0x54160fff,
+ },
+ {
+ .name
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On Sat, 26 Nov 2011, Paul Walmsley wrote: Hi Benoît, a question about this patch. ... + .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? - Paul
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On Sun, Nov 20, 2011 at 03:27:19AM +, Paul Walmsley wrote: 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. Cheers, Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi, On Mon, Nov 21, 2011 at 9:58 PM, Will Deacon will.dea...@arm.com wrote: On Sun, Nov 20, 2011 at 03:27:19AM +, Paul Walmsley wrote: 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. 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. thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On Mon, Nov 21, 2011 at 02:53:54PM +, Ming Lei wrote: On Mon, Nov 21, 2011 at 9:58 PM, Will Deacon will.dea...@arm.com wrote: On Sun, Nov 20, 2011 at 03:27:19AM +, Paul Walmsley wrote: 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. 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. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On Mon, Nov 21, 2011 at 11:16 PM, Will Deacon will.dea...@arm.com wrote: On Mon, Nov 21, 2011 at 02:53:54PM +, Ming Lei wrote: On Mon, Nov 21, 2011 at 9:58 PM, Will Deacon will.dea...@arm.com wrote: On Sun, Nov 20, 2011 at 03:27:19AM +, Paul Walmsley wrote: 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. 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. Sorry too, :-) It should be that both 3/7 and 4/7 are not needed any more. Benoit's debugss patch will replace the 4/7 patch(introduce emu hwmod). thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Benoit,
On Fri, Nov 18, 2011 at 8:58 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Ming Lei,
Sorry, for the delay, it took me some time to gather the exhaustive data for
that block.
The work is really great.
On 11/10/2011 10:02 AM, Paul Walmsley wrote:
Hello Ming Lei,
just a few quick comments for now -
On Wed, 9 Nov 2011, Ming Lei wrote:
On Tue, Nov 8, 2011 at 11:26 PM, Paul Walmsleyp...@pwsan.com wrote:
+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], :-)
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.
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 any suggestion about CTI IRQs connecting to which hwmod, so that they can
be found by pmu driver?
+/*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?
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.
Currently these two modules are enabled in my patch 5/7 and 6/7, and the
pmu omap device is built from the three IPs: debugss, l3_main_3 and
the l3_instr,
so that these two modules can be enabled in omap_device_enable().
I don't know how to enable the two IPs in other ways, also I am not
sure if the way
is suitable, but it does work, could you help to review the two patches?
[ 0.416992] omap_hwmod: debugss: softreset failed (waited 1 usec)
[ 0.426727] omap_hwmod: debugss: _wait_target_disable failed
Just let me know if you have any issue with that patch.
In fact, now it is very easy to enable pmu on omap with your patch,
I have made omap4 pmu work already using debugss:
- replace the patch 3/7 with your debugss patch(replace 'emu'
with 'debugss')
- modify the patch 5/7 to create pmu omap device from 'debugss'
instead of 'emu'
thanks,
--
Ming Lei
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 b-cous...@ti.com
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 b-cous...@ti.com
Cc: Ming Lei ming@canonical.com
---
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Will, On Fri, Nov 18, 2011 at 10:56 PM, Will Deacon will.dea...@arm.com wrote: Hi Benoit, On Fri, Nov 18, 2011 at 12:58:20PM +, Cousson, Benoit wrote: 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? 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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi On Sat, 19 Nov 2011, Ming Lei wrote: On Fri, Nov 18, 2011 at 10:56 PM, Will Deacon will.dea...@arm.com wrote: 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. 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. - Paul
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Ming Lei,
Sorry, for the delay, it took me some time to gather the exhaustive data for
that block.
On 11/10/2011 10:02 AM, Paul Walmsley wrote:
Hello Ming Lei,
just a few quick comments for now -
On Wed, 9 Nov 2011, Ming Lei wrote:
On Tue, Nov 8, 2011 at 11:26 PM, Paul Walmsleyp...@pwsan.com wrote:
+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], :-)
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.
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 any suggestion about CTI IRQs connecting to which hwmod, so that they can
be found by pmu driver?
+/*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?
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 1 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 b-cous...@ti.com
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 b-cous...@ti.com
Cc: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 177 +++-
1 files changed, 174 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7695e5d..6cf21ee 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -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
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Benoit, On Fri, Nov 18, 2011 at 12:58:20PM +, Cousson, Benoit wrote: 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
[Adding Benoit to CC]. On Thu, Nov 10, 2011 at 09:02:14AM +, Paul Walmsley wrote: On Wed, 9 Nov 2011, Ming Lei wrote: 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. So although the ordering requirements are a bit of a pain, I do think it's reasonable for perf to expect that it's not being handed some random other interrupts along with those for the PMU. 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. Benoit? Please can you chime in here? Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On Fri, Nov 11, 2011 at 11:41:47AM +, Will Deacon wrote: [Adding Benoit to CC]. On Thu, Nov 10, 2011 at 09:02:14AM +, Paul Walmsley wrote: On Wed, 9 Nov 2011, Ming Lei wrote: 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. 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... Jamie -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On Fri, Nov 11, 2011 at 11:47:35AM +, Jamie Iles wrote: On Fri, Nov 11, 2011 at 11:41:47AM +, Will Deacon wrote: 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... That's good news - means I have an excuse other than laziness for not implementing this for perf :) Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On 11/11/2011 12:47 PM, Jamie Iles wrote: On Fri, Nov 11, 2011 at 11:41:47AM +, Will Deacon wrote: [Adding Benoit to CC]. On Thu, Nov 10, 2011 at 09:02:14AM +, Paul Walmsley wrote: On Wed, 9 Nov 2011, Ming Lei wrote: 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. 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. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Benoit, On Fri, Nov 11, 2011 at 02:56:05PM +, Cousson, Benoit wrote: 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 :) Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Will,
On 11/11/2011 3:58 PM, Will Deacon wrote:
Hi Benoit,
On Fri, Nov 11, 2011 at 02:56:05PM +, Cousson, Benoit wrote:
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 :)
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
0x5400-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.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
On Fri, Nov 11, 2011 at 03:12:49PM +, Cousson, Benoit wrote:
Hi Will,
Hello,
On 11/11/2011 3:58 PM, Will Deacon wrote:
Actually, I was hoping you could help Ming Lei with the hwmod stuff :)
And I'll do :-)
Cheers!
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 :-)
Ok, I'm not familiar with it so that's why I've been pestering.
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
0x5400-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 }
};
At some point I'd like to add support for the PL310 PMU, which will want to
use that IRQ. That would need to be passed to the PL310 driver though, which
will then register it's own PMU device with perf.
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.
That looks cracking and should work out of the box.
Thanks,
Will
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hello Ming Lei,
just a few quick comments for now -
On Wed, 9 Nov 2011, Ming Lei wrote:
On Tue, Nov 8, 2011 at 11:26 PM, Paul Walmsley p...@pwsan.com wrote:
+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], :-)
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.
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 any suggestion about CTI IRQs connecting to which hwmod, so that they can
be found by pmu driver?
+/*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?
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.
But also proper dependency support in hwmod enable/idle operations will be
needed to enable the instrumentation and emulation interconnects when the
DEBUGSS is enabled. This has been on my plate for a few months, it's good
to have another reason to prioritize it.
- Paul
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi,
Thanks for your comments.
On Tue, Nov 8, 2011 at 11:26 PM, Paul Walmsley p...@pwsan.com wrote:
+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], :-)
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?
+/*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?
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .mpu_irqs = omap44xx_emu_irqs,
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
c
[1], http://comments.gmane.org/gmane.comp.embedded.pandaboard/168
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi, On Tue, Nov 8, 2011 at 11:42 PM, Paul Walmsley p...@pwsan.com wrote: 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 You mean the emu hwmod in the patch should be kept and a new l3_emu hwmod need to be added? and make the clkdm_name of 'l3_emu' points to CD_L3_2? But in the link above, looks like the hwmod of l3_main_3 and l3_instr need to be enabled for routing IRQs of pmu on omap4. 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. thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi
some comments
On Mon, 24 Oct 2011, ming@canonical.com wrote:
From: Ming Lei ming@canonical.com
So that access to cross trigger interface can be allowed, which
will be introduce in later patches.
Signed-off-by: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 393afac..c7289a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5276,6 +5276,30 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer3_slaves),
};
+static struct omap_hwmod_class omap44xx_emu_hwmod_class = {
+ .name = emu,
+};
+
+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.
+/*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.
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .mpu_irqs = omap44xx_emu_irqs,
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
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. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
