[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

[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

[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@ti.com>
---
 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 at 48241000 {
 		compatible = "arm,cortex-a9-gic";
 		interrupt-controller;
-- 
2.3.0-rc1

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

[Felipe Balbi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150123/9bbb28bf/attachment.sig>

[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@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

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

[Felipe Balbi]

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.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/77448018/attachment.sig>

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

[Felipe Balbi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/6857ea67/attachment.sig>

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

[Felipe Balbi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150127/5ff81c46/attachment.sig>

[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

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

[Felipe Balbi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150127/ce89c6a7/attachment.sig>

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

[Felipe Balbi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150127/7d2c6293/attachment.sig>

[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

[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

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

[Felipe Balbi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150210/215ad510/attachment.sig>

[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