| Message ID | 1422054704-14915-2-git-send-email-balbi@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi the references below are from SPRUHL7 On Fri, 23 Jan 2015, Felipe Balbi wrote: > Without hwmod data for DebugSS, performance monitors > have no chance of running on AM43xx devices. > > Signed-off-by: Felipe Balbi <balbi@ti.com> > --- > arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 ++++++++++++++++++++++++++++++ > arch/arm/mach-omap2/prcm43xx.h | 1 + > 2 files changed, 41 insertions(+) > > diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c > index 5c6c8410160e..6709704dd5b5 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c > @@ -19,6 +19,7 @@ > #include "omap_hwmod.h" > #include "omap_hwmod_33xx_43xx_common_data.h" > #include "prcm43xx.h" > +#include "prm44xx.h" > #include "omap_hwmod_common_data.h" > > > @@ -60,6 +61,44 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = { > .rst_lines_cnt = ARRAY_SIZE(am33xx_wkup_m3_resets), > }; > > +/* > + * 'debugss' class > + * debug and emulation sub system > + */ > +static struct omap_hwmod_opt_clk am43xx_debugss_opt_clks[] = { > + { .role = "dbg_sysclk", .clk = "dbg_sysclk_ck" }, > + { .role = "dbg_clka", .clk = "dbg_clka_ck", }, > + { .role = "dbg_clkb", .clk = "dbg_clkb_ck", }, > + { .role = "dbg_clkc", .clk = "dbg_clkc_ck", }, > +}; > + > +static struct omap_hwmod_class am43xx_debugss_hwmod_class = { > + .name = "debugss", > +}; > + > +/* debugss */ > +static struct omap_hwmod am43xx_debugss_hwmod = { > + .name = "debugss", > + .class = &am43xx_debugss_hwmod_class, > + .clkdm_name = "l3_aon_clkdm", > + .main_clk = "trace_clk_div_ck", > + .prcm = { > + .omap4 = { > + .clkctrl_offs = AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET, According to Table 6-275 "PRCM_CM_WKUP_DBGSS_CLKCTRL Register Field Descriptions" this should have a .modulemode = MODULEMODE_SWCTRL, > + }, > + }, > + .opt_clks = am43xx_debugss_opt_clks, > + .opt_clks_cnt = ARRAY_SIZE(am43xx_debugss_opt_clks), > +}; > + > +/* debugss -> l3_main_2 */ > +static struct omap_hwmod_ocp_if am43xx_debugss__l3_main = { > + .master = &am43xx_debugss_hwmod, > + .slave = &am33xx_l3_main_hwmod, > + .clk = "sys_clkin_ck", > + .user = OCP_USER_MPU | OCP_USER_SDMA, > +}; > + According to Table 31-25 "Debug Modules Memory Mapping" there are a few initiator ports on the DEBUGSS that are connected to various slave ports on various chip-wide interconnects: L3_EMU, L4_PER, L4_WAKEUP, L4_CFG. I would suggest starting by adding at least one of them as a struct omap_hwmod_ocp_if record. The one attached to L3_EMU would seem like a good one to start with. > diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h > index ad7b3e9977f8..bb42cd80526d 100644 > --- a/arch/arm/mach-omap2/prcm43xx.h > +++ b/arch/arm/mach-omap2/prcm43xx.h > @@ -93,6 +93,7 @@ > #define AM43XX_CM_PER_TIMER5_CLKCTRL_OFFSET 0x0548 > #define AM43XX_CM_PER_TIMER6_CLKCTRL_OFFSET 0x0550 > #define AM43XX_CM_PER_TIMER7_CLKCTRL_OFFSET 0x0558 > +#define AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET 0x0020 > #define AM43XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET 0x0228 > #define AM43XX_CM_WKUP_CONTROL_CLKCTRL_OFFSET 0x0360 > #define AM43XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET 0x0350 > -- > 2.3.0-rc1 - Paul -- 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
Hi, On Mon, Jan 26, 2015 at 02:04:35AM +0000, Paul Walmsley wrote: > Hi > > the references below are from SPRUHL7 > > On Fri, 23 Jan 2015, Felipe Balbi wrote: > > > Without hwmod data for DebugSS, performance monitors > > have no chance of running on AM43xx devices. > > > > Signed-off-by: Felipe Balbi <balbi@ti.com> > > --- > > arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 ++++++++++++++++++++++++++++++ > > arch/arm/mach-omap2/prcm43xx.h | 1 + > > 2 files changed, 41 insertions(+) > > > > diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c > > index 5c6c8410160e..6709704dd5b5 100644 > > --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c > > +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c > > @@ -19,6 +19,7 @@ > > #include "omap_hwmod.h" > > #include "omap_hwmod_33xx_43xx_common_data.h" > > #include "prcm43xx.h" > > +#include "prm44xx.h" > > #include "omap_hwmod_common_data.h" > > > > > > @@ -60,6 +61,44 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = { > > .rst_lines_cnt = ARRAY_SIZE(am33xx_wkup_m3_resets), > > }; > > > > +/* > > + * 'debugss' class > > + * debug and emulation sub system > > + */ > > +static struct omap_hwmod_opt_clk am43xx_debugss_opt_clks[] = { > > + { .role = "dbg_sysclk", .clk = "dbg_sysclk_ck" }, > > + { .role = "dbg_clka", .clk = "dbg_clka_ck", }, > > + { .role = "dbg_clkb", .clk = "dbg_clkb_ck", }, > > + { .role = "dbg_clkc", .clk = "dbg_clkc_ck", }, > > +}; > > + > > +static struct omap_hwmod_class am43xx_debugss_hwmod_class = { > > + .name = "debugss", > > +}; > > + > > +/* debugss */ > > +static struct omap_hwmod am43xx_debugss_hwmod = { > > + .name = "debugss", > > + .class = &am43xx_debugss_hwmod_class, > > + .clkdm_name = "l3_aon_clkdm", > > + .main_clk = "trace_clk_div_ck", > > + .prcm = { > > + .omap4 = { > > + .clkctrl_offs = AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET, > > According to Table 6-275 "PRCM_CM_WKUP_DBGSS_CLKCTRL Register Field > Descriptions" this should have a > > .modulemode = MODULEMODE_SWCTRL, hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? > > + }, > > + }, > > + .opt_clks = am43xx_debugss_opt_clks, > > + .opt_clks_cnt = ARRAY_SIZE(am43xx_debugss_opt_clks), > > +}; > > + > > +/* debugss -> l3_main_2 */ > > +static struct omap_hwmod_ocp_if am43xx_debugss__l3_main = { > > + .master = &am43xx_debugss_hwmod, > > + .slave = &am33xx_l3_main_hwmod, > > + .clk = "sys_clkin_ck", > > + .user = OCP_USER_MPU | OCP_USER_SDMA, > > +}; > > + > > According to Table 31-25 "Debug Modules Memory Mapping" there are a few > initiator ports on the DEBUGSS that are connected to various slave ports > on various chip-wide interconnects: L3_EMU, L4_PER, L4_WAKEUP, L4_CFG. I > would suggest starting by adding at least one of them as a struct > omap_hwmod_ocp_if record. The one attached to L3_EMU would seem like a > good one to start with. I'll have a look.
Hi, On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: > > the references below are from SPRUHL7 > > > > On Fri, 23 Jan 2015, Felipe Balbi wrote: > > > > > Without hwmod data for DebugSS, performance monitors > > > have no chance of running on AM43xx devices. > > > > > > Signed-off-by: Felipe Balbi <balbi@ti.com> > > > --- > > > arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 ++++++++++++++++++++++++++++++ > > > arch/arm/mach-omap2/prcm43xx.h | 1 + > > > 2 files changed, 41 insertions(+) > > > > > > diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c > > > index 5c6c8410160e..6709704dd5b5 100644 > > > --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c > > > +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c > > > @@ -19,6 +19,7 @@ > > > #include "omap_hwmod.h" > > > #include "omap_hwmod_33xx_43xx_common_data.h" > > > #include "prcm43xx.h" > > > +#include "prm44xx.h" > > > #include "omap_hwmod_common_data.h" > > > > > > > > > @@ -60,6 +61,44 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = { > > > .rst_lines_cnt = ARRAY_SIZE(am33xx_wkup_m3_resets), > > > }; > > > > > > +/* > > > + * 'debugss' class > > > + * debug and emulation sub system > > > + */ > > > +static struct omap_hwmod_opt_clk am43xx_debugss_opt_clks[] = { > > > + { .role = "dbg_sysclk", .clk = "dbg_sysclk_ck" }, > > > + { .role = "dbg_clka", .clk = "dbg_clka_ck", }, > > > + { .role = "dbg_clkb", .clk = "dbg_clkb_ck", }, > > > + { .role = "dbg_clkc", .clk = "dbg_clkc_ck", }, > > > +}; > > > + > > > +static struct omap_hwmod_class am43xx_debugss_hwmod_class = { > > > + .name = "debugss", > > > +}; > > > + > > > +/* debugss */ > > > +static struct omap_hwmod am43xx_debugss_hwmod = { > > > + .name = "debugss", > > > + .class = &am43xx_debugss_hwmod_class, > > > + .clkdm_name = "l3_aon_clkdm", > > > + .main_clk = "trace_clk_div_ck", > > > + .prcm = { > > > + .omap4 = { > > > + .clkctrl_offs = AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET, > > > > According to Table 6-275 "PRCM_CM_WKUP_DBGSS_CLKCTRL Register Field > > Descriptions" this should have a > > > > .modulemode = MODULEMODE_SWCTRL, > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always read as 0x 12510f00 which would translate into: - module disabled - all opt clocks are on - module is transitioning - module in standby - clkA as TPIU and STM trace clock - all dividers set to 2
On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote: > Hi, > > On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: > > > the references below are from SPRUHL7 > > > > > > On Fri, 23 Jan 2015, Felipe Balbi wrote: > > > > > > > Without hwmod data for DebugSS, performance monitors > > > > have no chance of running on AM43xx devices. > > > > > > > > Signed-off-by: Felipe Balbi <balbi@ti.com> > > > > --- > > > > arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 ++++++++++++++++++++++++++++++ > > > > arch/arm/mach-omap2/prcm43xx.h | 1 + > > > > 2 files changed, 41 insertions(+) > > > > > > > > diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c > > > > index 5c6c8410160e..6709704dd5b5 100644 > > > > --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c > > > > +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c > > > > @@ -19,6 +19,7 @@ > > > > #include "omap_hwmod.h" > > > > #include "omap_hwmod_33xx_43xx_common_data.h" > > > > #include "prcm43xx.h" > > > > +#include "prm44xx.h" > > > > #include "omap_hwmod_common_data.h" > > > > > > > > > > > > @@ -60,6 +61,44 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = { > > > > .rst_lines_cnt = ARRAY_SIZE(am33xx_wkup_m3_resets), > > > > }; > > > > > > > > +/* > > > > + * 'debugss' class > > > > + * debug and emulation sub system > > > > + */ > > > > +static struct omap_hwmod_opt_clk am43xx_debugss_opt_clks[] = { > > > > + { .role = "dbg_sysclk", .clk = "dbg_sysclk_ck" }, > > > > + { .role = "dbg_clka", .clk = "dbg_clka_ck", }, > > > > + { .role = "dbg_clkb", .clk = "dbg_clkb_ck", }, > > > > + { .role = "dbg_clkc", .clk = "dbg_clkc_ck", }, > > > > +}; > > > > + > > > > +static struct omap_hwmod_class am43xx_debugss_hwmod_class = { > > > > + .name = "debugss", > > > > +}; > > > > + > > > > +/* debugss */ > > > > +static struct omap_hwmod am43xx_debugss_hwmod = { > > > > + .name = "debugss", > > > > + .class = &am43xx_debugss_hwmod_class, > > > > + .clkdm_name = "l3_aon_clkdm", > > > > + .main_clk = "trace_clk_div_ck", > > > > + .prcm = { > > > > + .omap4 = { > > > > + .clkctrl_offs = AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET, > > > > > > According to Table 6-275 "PRCM_CM_WKUP_DBGSS_CLKCTRL Register Field > > > Descriptions" this should have a > > > > > > .modulemode = MODULEMODE_SWCTRL, > > > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? > > gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always > read as 0x 12510f00 which would translate into: > > - module disabled > - all opt clocks are on > - module is transitioning > - module in standby > - clkA as TPIU and STM trace clock > - all dividers set to 2 just fyi, checking with HW folks, this might be a new bug, unless debugss needs something special.
Hi On Tue, 27 Jan 2015, Felipe Balbi wrote: > On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote: > > On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: > > > > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? > > > > gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always > > read as 0x 12510f00 which would translate into: > > > > - module disabled > > - all opt clocks are on > > - module is transitioning > > - module in standby > > - clkA as TPIU and STM trace clock > > - all dividers set to 2 > > just fyi, checking with HW folks, this might be a new bug, unless > debugss needs something special. If that happens on DEBUGSS disable, it's probably the same issue as on AM33xx: http://www.spinics.net/lists/arm-kernel/msg320801.html http://www.spinics.net/lists/arm-kernel/msg321930.html http://www.spinics.net/lists/arm-kernel/msg329151.html Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? - Paul -- 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
On Tue, Jan 27, 2015 at 05:12:05PM +0000, Paul Walmsley wrote: > Hi > > On Tue, 27 Jan 2015, Felipe Balbi wrote: > > > On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote: > > > On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: > > > > > > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? > > > > > > gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always > > > read as 0x 12510f00 which would translate into: > > > > > > - module disabled > > > - all opt clocks are on > > > - module is transitioning > > > - module in standby > > > - clkA as TPIU and STM trace clock > > > - all dividers set to 2 > > > > just fyi, checking with HW folks, this might be a new bug, unless > > debugss needs something special. > > If that happens on DEBUGSS disable, it's probably the same issue as on > AM33xx: > > http://www.spinics.net/lists/arm-kernel/msg320801.html > http://www.spinics.net/lists/arm-kernel/msg321930.html > http://www.spinics.net/lists/arm-kernel/msg329151.html > > Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? I'll try it out in a bit...
On Tue, Jan 27, 2015 at 11:15:32AM -0600, Felipe Balbi wrote: > On Tue, Jan 27, 2015 at 05:12:05PM +0000, Paul Walmsley wrote: > > Hi > > > > On Tue, 27 Jan 2015, Felipe Balbi wrote: > > > > > On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote: > > > > On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: > > > > > > > > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? > > > > > > > > gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always > > > > read as 0x 12510f00 which would translate into: > > > > > > > > - module disabled > > > > - all opt clocks are on > > > > - module is transitioning > > > > - module in standby > > > > - clkA as TPIU and STM trace clock > > > > - all dividers set to 2 > > > > > > just fyi, checking with HW folks, this might be a new bug, unless > > > debugss needs something special. > > > > If that happens on DEBUGSS disable, it's probably the same issue as on > > AM33xx: > > > > http://www.spinics.net/lists/arm-kernel/msg320801.html > > http://www.spinics.net/lists/arm-kernel/msg321930.html > > http://www.spinics.net/lists/arm-kernel/msg329151.html > > > > Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? > > I'll try it out in a bit... nope, same thing. [ 27.633235] omap_hwmod: debugss: _wait_target_disable failed
On Tue, 27 Jan 2015, Felipe Balbi wrote: > On Tue, Jan 27, 2015 at 11:15:32AM -0600, Felipe Balbi wrote: > > On Tue, Jan 27, 2015 at 05:12:05PM +0000, Paul Walmsley wrote: > > > On Tue, 27 Jan 2015, Felipe Balbi wrote: > > > > > > > On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote: > > > > > On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: > > > > > > > > > > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? > > > > > > > > > > gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always > > > > > read as 0x 12510f00 which would translate into: > > > > > > > > > > - module disabled > > > > > - all opt clocks are on > > > > > - module is transitioning > > > > > - module in standby > > > > > - clkA as TPIU and STM trace clock > > > > > - all dividers set to 2 > > > > > > > > just fyi, checking with HW folks, this might be a new bug, unless > > > > debugss needs something special. > > > > > > If that happens on DEBUGSS disable, it's probably the same issue as on > > > AM33xx: > > > > > > http://www.spinics.net/lists/arm-kernel/msg320801.html > > > http://www.spinics.net/lists/arm-kernel/msg321930.html > > > http://www.spinics.net/lists/arm-kernel/msg329151.html > > > > > > Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? > > > > I'll try it out in a bit... > > nope, same thing. > > [ 27.633235] omap_hwmod: debugss: _wait_target_disable failed OK, looking at the code, this makes sense. So here's what I'd suggest asking the hardware team: is the right approach to: 1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even when it's not in use or when entering chip low-power states, or 2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS is not in use or when entering chip low-power states, but ignore the DEBUGSS CLKCTRL IDLEST register We'll need a new hwmod flag either way; the question is whether it should be something like HWMOD_CANNOT_DISABLE (case 1), or HWMOD_DISABLE_IGNORE_IDLEST (case 2). - Paul -- 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
Hi Felipe On Tue, 27 Jan 2015, Paul Walmsley wrote: > On Tue, 27 Jan 2015, Felipe Balbi wrote: > > > On Tue, Jan 27, 2015 at 11:15:32AM -0600, Felipe Balbi wrote: > > > On Tue, Jan 27, 2015 at 05:12:05PM +0000, Paul Walmsley wrote: > > > > On Tue, 27 Jan 2015, Felipe Balbi wrote: > > > > > > > > > On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote: > > > > > > On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: > > > > > > > > > > > > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? > > > > > > > > > > > > gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always > > > > > > read as 0x 12510f00 which would translate into: > > > > > > > > > > > > - module disabled > > > > > > - all opt clocks are on > > > > > > - module is transitioning > > > > > > - module in standby > > > > > > - clkA as TPIU and STM trace clock > > > > > > - all dividers set to 2 > > > > > > > > > > just fyi, checking with HW folks, this might be a new bug, unless > > > > > debugss needs something special. > > > > > > > > If that happens on DEBUGSS disable, it's probably the same issue as on > > > > AM33xx: > > > > > > > > http://www.spinics.net/lists/arm-kernel/msg320801.html > > > > http://www.spinics.net/lists/arm-kernel/msg321930.html > > > > http://www.spinics.net/lists/arm-kernel/msg329151.html > > > > > > > > Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? > > > > > > I'll try it out in a bit... > > > > nope, same thing. > > > > [ 27.633235] omap_hwmod: debugss: _wait_target_disable failed > > OK, looking at the code, this makes sense. So here's what I'd suggest > asking the hardware team: is the right approach to: > > 1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even > when it's not in use or when entering chip low-power states, or > > 2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS > is not in use or when entering chip low-power states, but ignore the > DEBUGSS CLKCTRL IDLEST register > > We'll need a new hwmod flag either way; the question is whether it should > be something like HWMOD_CANNOT_DISABLE (case 1), or > HWMOD_DISABLE_IGNORE_IDLEST (case 2). Just checking on this. Heard anything from the hardware team? If not I'd say the HWMOD_CANNOT_DISABLE approach is probably the right one for now... - Paul -- 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
Hi, On Tue, Feb 10, 2015 at 11:12:40PM +0000, Paul Walmsley wrote: > > > > > > > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? > > > > > > > > > > > > > > gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always > > > > > > > read as 0x 12510f00 which would translate into: > > > > > > > > > > > > > > - module disabled > > > > > > > - all opt clocks are on > > > > > > > - module is transitioning > > > > > > > - module in standby > > > > > > > - clkA as TPIU and STM trace clock > > > > > > > - all dividers set to 2 > > > > > > > > > > > > just fyi, checking with HW folks, this might be a new bug, unless > > > > > > debugss needs something special. > > > > > > > > > > If that happens on DEBUGSS disable, it's probably the same issue as on > > > > > AM33xx: > > > > > > > > > > http://www.spinics.net/lists/arm-kernel/msg320801.html > > > > > http://www.spinics.net/lists/arm-kernel/msg321930.html > > > > > http://www.spinics.net/lists/arm-kernel/msg329151.html > > > > > > > > > > Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? > > > > > > > > I'll try it out in a bit... > > > > > > nope, same thing. > > > > > > [ 27.633235] omap_hwmod: debugss: _wait_target_disable failed > > > > OK, looking at the code, this makes sense. So here's what I'd suggest > > asking the hardware team: is the right approach to: > > > > 1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even > > when it's not in use or when entering chip low-power states, or > > > > 2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS > > is not in use or when entering chip low-power states, but ignore the > > DEBUGSS CLKCTRL IDLEST register > > > > We'll need a new hwmod flag either way; the question is whether it should > > be something like HWMOD_CANNOT_DISABLE (case 1), or > > HWMOD_DISABLE_IGNORE_IDLEST (case 2). > > Just checking on this. Heard anything from the hardware team? If not I'd > say the HWMOD_CANNOT_DISABLE approach is probably the right one for now... nothing from HW team yet. Last I heard is that they can reproduce the issue, and are now digging through documentation (and maybe RTL, but I'm speculating) to see if that should be supported or not. From my point of view, however, the thing idles, it just doesn't report it.
On Tue, 10 Feb 2015, Felipe Balbi wrote: > On Tue, Feb 10, 2015 at 11:12:40PM +0000, Paul Walmsley wrote: > > > > > > > > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? > > > > > > > > > > > > > > > > gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always > > > > > > > > read as 0x 12510f00 which would translate into: > > > > > > > > > > > > > > > > - module disabled > > > > > > > > - all opt clocks are on > > > > > > > > - module is transitioning > > > > > > > > - module in standby > > > > > > > > - clkA as TPIU and STM trace clock > > > > > > > > - all dividers set to 2 > > > > > > > > > > > > > > just fyi, checking with HW folks, this might be a new bug, unless > > > > > > > debugss needs something special. > > > > > > > > > > > > If that happens on DEBUGSS disable, it's probably the same issue as on > > > > > > AM33xx: > > > > > > > > > > > > http://www.spinics.net/lists/arm-kernel/msg320801.html > > > > > > http://www.spinics.net/lists/arm-kernel/msg321930.html > > > > > > http://www.spinics.net/lists/arm-kernel/msg329151.html > > > > > > > > > > > > Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? > > > > > > > > > > I'll try it out in a bit... > > > > > > > > nope, same thing. > > > > > > > > [ 27.633235] omap_hwmod: debugss: _wait_target_disable failed > > > > > > OK, looking at the code, this makes sense. So here's what I'd suggest > > > asking the hardware team: is the right approach to: > > > > > > 1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even > > > when it's not in use or when entering chip low-power states, or > > > > > > 2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS > > > is not in use or when entering chip low-power states, but ignore the > > > DEBUGSS CLKCTRL IDLEST register > > > > > > We'll need a new hwmod flag either way; the question is whether it should > > > be something like HWMOD_CANNOT_DISABLE (case 1), or > > > HWMOD_DISABLE_IGNORE_IDLEST (case 2). > > > > Just checking on this. Heard anything from the hardware team? If not I'd > > say the HWMOD_CANNOT_DISABLE approach is probably the right one for now... > > nothing from HW team yet. Last I heard is that they can reproduce the > issue, and are now digging through documentation (and maybe RTL, but I'm > speculating) to see if that should be supported or not. > > From my point of view, however, the thing idles, it just doesn't report > it. Ok sounds like the thing to do is to wait until you hear back from them, if they are still looking at it. - Paul -- 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
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c index 5c6c8410160e..6709704dd5b5 100644 --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c @@ -19,6 +19,7 @@ #include "omap_hwmod.h" #include "omap_hwmod_33xx_43xx_common_data.h" #include "prcm43xx.h" +#include "prm44xx.h" #include "omap_hwmod_common_data.h" @@ -60,6 +61,44 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = { .rst_lines_cnt = ARRAY_SIZE(am33xx_wkup_m3_resets), }; +/* + * 'debugss' class + * debug and emulation sub system + */ +static struct omap_hwmod_opt_clk am43xx_debugss_opt_clks[] = { + { .role = "dbg_sysclk", .clk = "dbg_sysclk_ck" }, + { .role = "dbg_clka", .clk = "dbg_clka_ck", }, + { .role = "dbg_clkb", .clk = "dbg_clkb_ck", }, + { .role = "dbg_clkc", .clk = "dbg_clkc_ck", }, +}; + +static struct omap_hwmod_class am43xx_debugss_hwmod_class = { + .name = "debugss", +}; + +/* debugss */ +static struct omap_hwmod am43xx_debugss_hwmod = { + .name = "debugss", + .class = &am43xx_debugss_hwmod_class, + .clkdm_name = "l3_aon_clkdm", + .main_clk = "trace_clk_div_ck", + .prcm = { + .omap4 = { + .clkctrl_offs = AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET, + }, + }, + .opt_clks = am43xx_debugss_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(am43xx_debugss_opt_clks), +}; + +/* debugss -> l3_main_2 */ +static struct omap_hwmod_ocp_if am43xx_debugss__l3_main = { + .master = &am43xx_debugss_hwmod, + .slave = &am33xx_l3_main_hwmod, + .clk = "sys_clkin_ck", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + static struct omap_hwmod am43xx_control_hwmod = { .name = "control", .class = &am33xx_control_hwmod_class, @@ -875,6 +914,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = { &am33xx_l3_main__tptc1, &am33xx_l3_main__tptc2, &am33xx_l3_main__ocmc, + &am43xx_debugss__l3_main, &am43xx_l4_hs__cpgmac0, &am33xx_cpgmac0__mdio, &am33xx_l3_main__sha0, diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h index ad7b3e9977f8..bb42cd80526d 100644 --- a/arch/arm/mach-omap2/prcm43xx.h +++ b/arch/arm/mach-omap2/prcm43xx.h @@ -93,6 +93,7 @@ #define AM43XX_CM_PER_TIMER5_CLKCTRL_OFFSET 0x0548 #define AM43XX_CM_PER_TIMER6_CLKCTRL_OFFSET 0x0550 #define AM43XX_CM_PER_TIMER7_CLKCTRL_OFFSET 0x0558 +#define AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET 0x0020 #define AM43XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET 0x0228 #define AM43XX_CM_WKUP_CONTROL_CLKCTRL_OFFSET 0x0360 #define AM43XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET 0x0350
Without hwmod data for DebugSS, performance monitors have no chance of running on AM43xx devices. Signed-off-by: Felipe Balbi <balbi@ti.com> --- arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 ++++++++++++++++++++++++++++++ arch/arm/mach-omap2/prcm43xx.h | 1 + 2 files changed, 41 insertions(+)