[PATCH 0/4] arm: am43xx: add PMU support

[PATCH 0/4] arm: am43xx: add PMU support

[Felipe Balbi]

Hi all,

with these patches we can use perf with AM43xx devices
and get actual statistics.

Full boot logs: http://hastebin.com/yoxaxurohu

Felipe Balbi (4):
  arm: omap: hwmod: 43xx: add DebugSS hwmod data
  arm: dts: am4372: add missing debugss clocks
  clk: ti: 43xx: add debugss clocks to DT_CLK() table
  arm: dts: am4372: add pmu DT data

 arch/arm/boot/dts/am4372.dtsi              |  8 +++++
 arch/arm/boot/dts/am43xx-clocks.dtsi       | 51 ++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 +++++++++++++++++++++++
 arch/arm/mach-omap2/prcm43xx.h             |  1 +
 drivers/clk/ti/clk-43xx.c                  |  6 ++++
 5 files changed, 106 insertions(+)

-- 
2.3.0-rc1

[PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

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,
+		},
+	},
+	.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
-- 
2.3.0-rc1

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Paul Walmsley]

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-l0cyMroinI0@public.gmane.org>
> ---
>  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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3088 bytes --]

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-l0cyMroinI0@public.gmane.org>
> > ---
> >  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.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2607 bytes --]

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

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]

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.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Paul Walmsley]

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

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

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...

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

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

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Paul Walmsley]

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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Paul Walmsley]

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

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]

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.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Paul Walmsley]

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

[PATCH 2/4] arm: dts: am4372: add missing debugss clocks

[Felipe Balbi]

These clocks are needed so that OMAP HWMOD can
control them when we're using performance
monitors.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/boot/dts/am43xx-clocks.dtsi | 51 ++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi b/arch/arm/boot/dts/am43xx-clocks.dtsi
index c7dc9dab93a4..9000a5c5b719 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -362,6 +362,57 @@
 		clock-div = <1>;
 	};
 
+	dbg_sysclk_ck: dbg_sysclk_ck {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&sys_clkin_ck>;
+		ti,bit-shift = <8>;
+		reg = <0x20>;
+	};
+
+	dbg_clka_ck: dbg_clka_ck {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&sys_clkin_ck>;
+		ti,bit-shift = <9>;
+		reg = <0x20>;
+	};
+
+	dbg_clkb_ck: dbg_clkb_ck {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&sys_clkin_ck>;
+		ti,bit-shift = <10>;
+		reg = <0x20>;
+	};
+
+	dbg_clkc_ck: dbg_clkc_ck {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&sys_clkin_ck>;
+		ti,bit-shift = <11>;
+		reg = <0x20>;
+	};
+
+	trace_pmd_clk_mux_ck: trace_pmd_clk_mux_ck {
+		#clock-cells = <0>;
+		compatible = "ti,mux-clock";
+		clocks = <&dbg_sysclk_ck>, <&dbg_clka_ck>,
+			<&dbg_clkb_ck>, <&dbg_clkc_ck>;
+		ti,bit-shift = <22>;
+		reg = <0x20>;
+	};
+
+	trace_clk_div_ck: trace_clk_div_ck {
+		#clock-cells = <0>;
+		compatible = "ti,divider-clock";
+		clocks = <&trace_pmd_clk_mux_ck>;
+		ti,bit-shift = <24>;
+		ti,max-div = <4>;
+		reg = <0x20>;
+		ti,index-power-of-two;
+	};
+
 	pruss_ocp_gclk: pruss_ocp_gclk {
 		#clock-cells = <0>;
 		compatible = "ti,mux-clock";
-- 
2.3.0-rc1

[PATCH 3/4] clk: ti: 43xx: add debugss clocks to DT_CLK() table

[Felipe Balbi]

without these entries, omap_hwmod will not be
able to find debugss clocks.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/clk/ti/clk-43xx.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 3795fce8a830..46a597c815c9 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -83,6 +83,12 @@ static struct ti_dt_clk am43xx_clks[] = {
 	DT_CLK(NULL, "gfx_fck_div_ck", "gfx_fck_div_ck"),
 	DT_CLK(NULL, "timer_32k_ck", "clkdiv32k_ick"),
 	DT_CLK(NULL, "timer_sys_ck", "sys_clkin_ck"),
+	DT_CLK(NULL, "trace_clk_div_ck", "trace_clk_div_ck"),
+	DT_CLK(NULL, "trace_pm_clk_mux_ck", "trace_pm_clk_mux_ck"),
+	DT_CLK(NULL, "dbg_sysclk_ck", "dbg_sysclk_ck"),
+	DT_CLK(NULL, "dbg_clka_ck", "dbg_clka_ck"),
+	DT_CLK(NULL, "dbg_clkb_ck", "dbg_clkb_ck"),
+	DT_CLK(NULL, "dbg_clkc_ck", "dbg_clkc_ck"),
 	DT_CLK(NULL, "sysclk_div", "sysclk_div"),
 	DT_CLK(NULL, "disp_clk", "disp_clk"),
 	DT_CLK(NULL, "clk_32k_mosc_ck", "clk_32k_mosc_ck"),
-- 
2.3.0-rc1

Re: [PATCH 3/4] clk: ti: 43xx: add debugss clocks to DT_CLK() table

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

On Fri, Jan 23, 2015 at 05:11:43PM -0600, Felipe Balbi wrote:
> without these entries, omap_hwmod will not be
> able to find debugss clocks.
> 
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>  drivers/clk/ti/clk-43xx.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
> index 3795fce8a830..46a597c815c9 100644
> --- a/drivers/clk/ti/clk-43xx.c
> +++ b/drivers/clk/ti/clk-43xx.c
> @@ -83,6 +83,12 @@ static struct ti_dt_clk am43xx_clks[] = {
>  	DT_CLK(NULL, "gfx_fck_div_ck", "gfx_fck_div_ck"),
>  	DT_CLK(NULL, "timer_32k_ck", "clkdiv32k_ick"),
>  	DT_CLK(NULL, "timer_sys_ck", "sys_clkin_ck"),
> +	DT_CLK(NULL, "trace_clk_div_ck", "trace_clk_div_ck"),
> +	DT_CLK(NULL, "trace_pm_clk_mux_ck", "trace_pm_clk_mux_ck"),

hmmm, this should be trace_pmd_clk_mux_ck. How did this even work ? I'll
fix and retest.

Won't resend until tomorrow though.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 4/4] arm: dts: am4372: add pmu DT data

[Felipe Balbi]

with this patch, performance monitors work
and show sensible data on AM43xx devices:

~# perf stat sleep 5

 Performance counter stats for 'sleep 5':

          6.079585      task-clock (msec)         #    0.001 CPUs utilized
                 3      context-switches          #    0.493 K/sec
                 0      cpu-migrations            #    0.000 K/sec
                35      page-faults               #    0.006 M/sec
           5888256      cycles                    #    0.969 GHz
           1458715      stalled-cycles-frontend   #   24.77% frontend cycles idle
           4632019      stalled-cycles-backend    #   78.67% backend  cycles idle
           1892556      instructions              #    0.32  insns per cycle
                                                  #    2.45  stalled cycles per insn
            141832      branches                  #   23.329 M/sec
             56093      branch-misses             #   39.55% of all branches

       5.018813000 seconds time elapsed

Signed-off-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/am4372.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 861f127dfead..ea103aa970f1 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -51,6 +51,14 @@
 		};
 	};
 
+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		reg = <0x4b000000 0x800000>;
+		interrutps = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+				<GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+		ti,hwmods = "debugss";
+	};
+
 	gic: interrupt-controller@48241000 {
 		compatible = "arm,cortex-a9-gic";
 		interrupt-controller;
-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html