[RFC 1/4] ARM: OMAP2+: Add CTRL_MODULE_CORE as a master clock provider for DRA7

[RFC 1/4] ARM: OMAP2+: Add CTRL_MODULE_CORE as a master clock provider for DRA7

[Archit Taneja]

The control module isn't actually a clock management module, but there are a few
register bits which perform gating and muxing of clocks.

Add CTRL_MODULE_CORE sub block as a clock provider for DRA7. The control module
has 2 sub modules: CTRL_MODULE_CORE, and CTRL_MODULE_WKUP. Out of these, only
the CORE sub module has clock related register fields. We ignore the WKUP sub
module.

Signed-off-by: Archit Taneja <archit@ti.com>
---
 arch/arm/mach-omap2/prm_common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index b4c4ab9..f86029a 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -489,6 +489,7 @@ static struct of_device_id omap_prcm_dt_match_table[] = {
 	{ .compatible = "ti,dra7-prm" },
 	{ .compatible = "ti,dra7-cm-core-aon" },
 	{ .compatible = "ti,dra7-cm-core" },
+	{ .compatible = "ti,dra7-ctrl-core" },
 	{ }
 };
 
-- 
1.8.3.2

[RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7

[Archit Taneja]

Add DT node for the ctrl-core sub module of the DRA7 control module. We map the
CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains register
fields which configure clocks. The remainder of the registers are related to
pad configurations or cross-bar configurations, and therefore aren't mapped.

Signed-off-by: Archit Taneja <archit@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1c0f8e1..58bbdf3 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -148,6 +148,19 @@
 			};
 		};
 
+		ctrl_core: ctrl_core at 4a002000 {
+			compatible = "ti,dra7-ctrl-core";
+			reg = <0x4a002000 0x6d0>;
+
+			ctrl_core_clocks: clocks {
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
+
+			ctrl_core_clockdomains: clockdomains {
+			};
+		};
+
 		counter32k: counter at 4ae04000 {
 			compatible = "ti,omap-counter32k";
 			reg = <0x4ae04000 0x40>;
-- 
1.8.3.2

[RFC 3/4] ARM: dts: Add dss_deshdcp clock node under dra7-ctrl-core

[Archit Taneja]

The DESHDCP clock is required only by the DES-HDCP block within HDMI in DSS.
However, if the clock isn't set before DSS clock domian is enabled, the clock
domain never comes out of idle state.

The DESHDCP clock is enabled/disabled at the DSS boundary by the bit
DSS_DESHDCP_CLKEN in CTRL_CORE_CONTROL_IO_2.

Add dss_deshdcp gate-clock node under dra7-ctrl-core. There are separate bit
fields for enabling and disabling the clock. We just map the enable bit since
this clock doesn't cause any impact if left enabled.

Signed-off-by: Archit Taneja <archit@ti.com>
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index e96da9a..78d309c 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -2007,6 +2007,16 @@
 	};
 };
 
+&ctrl_core_clocks {
+	dss_deshdcp_clk: dss_deshdcp_clk {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&l3_iclk_div>;
+		ti,bit-shift = <0>;
+		reg = <0x0558>;
+	};
+};
+
 &cm_core_clockdomains {
 	coreaon_clkdm: coreaon_clkdm {
 		compatible = "ti,clockdomain";
-- 
1.8.3.2

[RFC 4/4] CLK: TI: Enable dss_deshdcp clock in dra7xx_clk_init

[Archit Taneja]

The DESHDCP clock is required only by the DES-HDCP block within HDMI in DSS.
However, if the clock isn't set before DSS clock domian is enabled, the clock
domain never comes out of idle state.

This is because the DSS IP is designed in such a way that if DES-HDCP block
can't transition from idle state, the entire DSS clock domain also cannot
transition from idle to enabled. DES-HDCP block needs the DESHDCP clock
enabled to transition from idle successfully.

We enable the deshdcp clock in dra7xx_clk_init() which happens before omap
hwmods are setup. This clock is effectively a gate clock with the parent as
DSS_L3_GICLK. The parent is an automatically controlled clock by DSS clock
domain and hence doesn't have a clock node associated to it. Since
DSS_L3_GICLK is derived from the OCP clock, we set the dss_deshdcp_clk's
parent as l3_iclk_div.

Leaving this bit enabled doesn't prevent DSS or the system to suspend, and only
a very few flops get this clock all the time. So there is negligible impact.

Signed-off-by: Archit Taneja <archit@ti.com>
---
 drivers/clk/ti/clk-7xx.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index f7e4073..3f73a02 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -179,6 +179,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
 	DT_CLK(NULL, "dss_hdmi_clk", "dss_hdmi_clk"),
 	DT_CLK(NULL, "dss_video1_clk", "dss_video1_clk"),
 	DT_CLK(NULL, "dss_video2_clk", "dss_video2_clk"),
+	DT_CLK(NULL, "dss_deshdcp_clk", "dss_deshdcp_clk"),
 	DT_CLK(NULL, "gpio1_dbclk", "gpio1_dbclk"),
 	DT_CLK(NULL, "gpio2_dbclk", "gpio2_dbclk"),
 	DT_CLK(NULL, "gpio3_dbclk", "gpio3_dbclk"),
@@ -306,7 +307,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
 int __init dra7xx_dt_clk_init(void)
 {
 	int rc;
-	struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
+	struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *dss_deshdcp_ck;
 
 	ti_dt_clocks_register(dra7xx_clks);
 
@@ -327,5 +328,10 @@ int __init dra7xx_dt_clk_init(void)
 	if (rc)
 		pr_err("%s: failed to configure GMAC DPLL!\n", __func__);
 
+	dss_deshdcp_ck = clk_get_sys(NULL, "dss_deshdcp_clk");
+	rc = clk_prepare_enable(dss_deshdcp_ck);
+	if (rc)
+		pr_err("%s: failed to enable DESHDCP clock\n", __func__);
+
 	return rc;
 }
-- 
1.8.3.2

[RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7

[Tony Lindgren]

* Archit Taneja <archit@ti.com> [140416 06:20]:
> Add DT node for the ctrl-core sub module of the DRA7 control module. We map the
> CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains register
> fields which configure clocks. The remainder of the registers are related to
> pad configurations or cross-bar configurations, and therefore aren't mapped.

Can you please check if this can just use the existing
regmap syscon mapping:

syscon = <&dra7_ctrl_general>;

See how the drivers/regulator/pbias-regulator.c is using the
syscon to initialize a regulator and then omap_hsmmc.c just does
the standard regulator calls.

Depending what the range 0x4a002000 0x6d0 contains, you may
want to set it up as another syscon area.

Regards,

Tony

 
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
>  arch/arm/boot/dts/dra7.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 1c0f8e1..58bbdf3 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -148,6 +148,19 @@
>  			};
>  		};
>  
> +		ctrl_core: ctrl_core at 4a002000 {
> +			compatible = "ti,dra7-ctrl-core";
> +			reg = <0x4a002000 0x6d0>;
> +
> +			ctrl_core_clocks: clocks {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +			};
> +
> +			ctrl_core_clockdomains: clockdomains {
> +			};
> +		};
> +
>  		counter32k: counter at 4ae04000 {
>  			compatible = "ti,omap-counter32k";
>  			reg = <0x4ae04000 0x40>;
> -- 
> 1.8.3.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7

[Archit Taneja]

Hi,

On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote:
> * Archit Taneja <archit@ti.com> [140416 06:20]:
>> Add DT node for the ctrl-core sub module of the DRA7 control module. We map the
>> CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains register
>> fields which configure clocks. The remainder of the registers are related to
>> pad configurations or cross-bar configurations, and therefore aren't mapped.
>
> Can you please check if this can just use the existing
> regmap syscon mapping:
>
> syscon = <&dra7_ctrl_general>;
>
> See how the drivers/regulator/pbias-regulator.c is using the
> syscon to initialize a regulator and then omap_hsmmc.c just does
> the standard regulator calls.

The thing is that this bit needs to be set before the the DSS hwmods are 
reset, and that happens very early. If we don't do this, DSS won't reset 
properly, and not get back to an idle state.

I am not sure where I can configure the syscon register early enough 
that it happens before the hwmods are reset. With a syscon mapping, I 
guess we would access the register when the DSS driver is probed. But 
that's too late for us.

Ideally, it would be much better to have a syscon mapping. Do you have 
any suggestions how this can be achieved very early in boot?

Archit

>
> Depending what the range 0x4a002000 0x6d0 contains, you may
> want to set it up as another syscon area.
>
> Regards,
>
> Tony

[RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7

[Tony Lindgren]

* Archit Taneja <archit@ti.com> [140420 22:16]:
> Hi,
> 
> On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote:
> >* Archit Taneja <archit@ti.com> [140416 06:20]:
> >>Add DT node for the ctrl-core sub module of the DRA7 control module. We map the
> >>CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains register
> >>fields which configure clocks. The remainder of the registers are related to
> >>pad configurations or cross-bar configurations, and therefore aren't mapped.
> >
> >Can you please check if this can just use the existing
> >regmap syscon mapping:
> >
> >syscon = <&dra7_ctrl_general>;
> >
> >See how the drivers/regulator/pbias-regulator.c is using the
> >syscon to initialize a regulator and then omap_hsmmc.c just does
> >the standard regulator calls.
> 
> The thing is that this bit needs to be set before the the DSS hwmods are
> reset, and that happens very early. If we don't do this, DSS won't reset
> properly, and not get back to an idle state.
> 
> I am not sure where I can configure the syscon register early enough that it
> happens before the hwmods are reset. With a syscon mapping, I guess we would
> access the register when the DSS driver is probed. But that's too late for
> us.
> 
> Ideally, it would be much better to have a syscon mapping. Do you have any
> suggestions how this can be achieved very early in boot?

It's best to move the reset and initialization of DSS happen later. I believe
we already are resetting only some of the hwmods early on.

Regards,

Tony

[RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7

[Archit Taneja]

Hi,

On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote:
> * Archit Taneja <archit@ti.com> [140420 22:16]:
>> Hi,
>>
>> On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote:
>>> * Archit Taneja <archit@ti.com> [140416 06:20]:
>>>> Add DT node for the ctrl-core sub module of the DRA7 control module. We map the
>>>> CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains register
>>>> fields which configure clocks. The remainder of the registers are related to
>>>> pad configurations or cross-bar configurations, and therefore aren't mapped.
>>>
>>> Can you please check if this can just use the existing
>>> regmap syscon mapping:
>>>
>>> syscon = <&dra7_ctrl_general>;
>>>
>>> See how the drivers/regulator/pbias-regulator.c is using the
>>> syscon to initialize a regulator and then omap_hsmmc.c just does
>>> the standard regulator calls.
>>
>> The thing is that this bit needs to be set before the the DSS hwmods are
>> reset, and that happens very early. If we don't do this, DSS won't reset
>> properly, and not get back to an idle state.
>>
>> I am not sure where I can configure the syscon register early enough that it
>> happens before the hwmods are reset. With a syscon mapping, I guess we would
>> access the register when the DSS driver is probed. But that's too late for
>> us.
>>
>> Ideally, it would be much better to have a syscon mapping. Do you have any
>> suggestions how this can be achieved very early in boot?
>
> It's best to move the reset and initialization of DSS happen later. I believe
> we already are resetting only some of the hwmods early on.
>

I looked at this in some more detail. With the current hwmod 
flags(HWMOD_INIT_NO_RESET/NO_IDLE), we still try to enable the IP, it's 
just the reset part(ocp reset/custom reset and sysc register) or the 
disable part that is skipped. hwmod still tries to enable the IP.

This again results in the same issue.

One thing which wasn't clear was that why do we enable a hwmod in the 
first place, if we know that we are going to skip reset?

Archit

[RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7

[Tony Lindgren]

* Archit Taneja <archit@ti.com> [140505 22:24]:
> Hi,
> 
> On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote:
> >* Archit Taneja <archit@ti.com> [140420 22:16]:
> >>Hi,
> >>
> >>On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote:
> >>>* Archit Taneja <archit@ti.com> [140416 06:20]:
> >>>>Add DT node for the ctrl-core sub module of the DRA7 control module. We map the
> >>>>CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains register
> >>>>fields which configure clocks. The remainder of the registers are related to
> >>>>pad configurations or cross-bar configurations, and therefore aren't mapped.
> >>>
> >>>Can you please check if this can just use the existing
> >>>regmap syscon mapping:
> >>>
> >>>syscon = <&dra7_ctrl_general>;
> >>>
> >>>See how the drivers/regulator/pbias-regulator.c is using the
> >>>syscon to initialize a regulator and then omap_hsmmc.c just does
> >>>the standard regulator calls.
> >>
> >>The thing is that this bit needs to be set before the the DSS hwmods are
> >>reset, and that happens very early. If we don't do this, DSS won't reset
> >>properly, and not get back to an idle state.
> >>
> >>I am not sure where I can configure the syscon register early enough that it
> >>happens before the hwmods are reset. With a syscon mapping, I guess we would
> >>access the register when the DSS driver is probed. But that's too late for
> >>us.
> >>
> >>Ideally, it would be much better to have a syscon mapping. Do you have any
> >>suggestions how this can be achieved very early in boot?
> >
> >It's best to move the reset and initialization of DSS happen later. I believe
> >we already are resetting only some of the hwmods early on.
> >
> 
> I looked at this in some more detail. With the current hwmod
> flags(HWMOD_INIT_NO_RESET/NO_IDLE), we still try to enable the IP, it's just
> the reset part(ocp reset/custom reset and sysc register) or the disable part
> that is skipped. hwmod still tries to enable the IP.
> 
> This again results in the same issue.
> 
> One thing which wasn't clear was that why do we enable a hwmod in the first
> place, if we know that we are going to skip reset?

Probably to configure the idle bits. In general, we should configure the
modules lazily as the driver probes as requested, and then idle the
unused modules with a late_initcall.

Regards,

Tony

[RFC 1/4] ARM: OMAP2+: Add CTRL_MODULE_CORE as a master clock provider for DRA7

[Paul Walmsley]

Hi

On Wed, 16 Apr 2014, Archit Taneja wrote:

> The control module isn't actually a clock management module, but there are a few
> register bits which perform gating and muxing of clocks.
> 
> Add CTRL_MODULE_CORE sub block as a clock provider for DRA7. The control module
> has 2 sub modules: CTRL_MODULE_CORE, and CTRL_MODULE_WKUP. Out of these, only
> the CORE sub module has clock related register fields. We ignore the WKUP sub
> module.
> 
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
>  arch/arm/mach-omap2/prm_common.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
> index b4c4ab9..f86029a 100644
> --- a/arch/arm/mach-omap2/prm_common.c
> +++ b/arch/arm/mach-omap2/prm_common.c
> @@ -489,6 +489,7 @@ static struct of_device_id omap_prcm_dt_match_table[] = {
>  	{ .compatible = "ti,dra7-prm" },
>  	{ .compatible = "ti,dra7-cm-core-aon" },
>  	{ .compatible = "ti,dra7-cm-core" },
> +	{ .compatible = "ti,dra7-ctrl-core" },
>  	{ }
>  };

So, based on a quick glance, and without the benefit of any 
documentation, it makes general sense to add the DRA7 CTRL module as a 
clock provider, but it does not make any sense to associate it with the 
PRCM.  Please find a control module-specific piece of code to register as 
a clock provider, not prm_common.c.



- Paul

[RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7

[Archit Taneja]

On Tuesday 06 May 2014 07:56 PM, Tony Lindgren wrote:
> * Archit Taneja <archit@ti.com> [140505 22:24]:
>> Hi,
>>
>> On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote:
>>> * Archit Taneja <archit@ti.com> [140420 22:16]:
>>>> Hi,
>>>>
>>>> On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote:
>>>>> * Archit Taneja <archit@ti.com> [140416 06:20]:
>>>>>> Add DT node for the ctrl-core sub module of the DRA7 control module. We map the
>>>>>> CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains register
>>>>>> fields which configure clocks. The remainder of the registers are related to
>>>>>> pad configurations or cross-bar configurations, and therefore aren't mapped.
>>>>>
>>>>> Can you please check if this can just use the existing
>>>>> regmap syscon mapping:
>>>>>
>>>>> syscon = <&dra7_ctrl_general>;
>>>>>
>>>>> See how the drivers/regulator/pbias-regulator.c is using the
>>>>> syscon to initialize a regulator and then omap_hsmmc.c just does
>>>>> the standard regulator calls.
>>>>
>>>> The thing is that this bit needs to be set before the the DSS hwmods are
>>>> reset, and that happens very early. If we don't do this, DSS won't reset
>>>> properly, and not get back to an idle state.
>>>>
>>>> I am not sure where I can configure the syscon register early enough that it
>>>> happens before the hwmods are reset. With a syscon mapping, I guess we would
>>>> access the register when the DSS driver is probed. But that's too late for
>>>> us.
>>>>
>>>> Ideally, it would be much better to have a syscon mapping. Do you have any
>>>> suggestions how this can be achieved very early in boot?
>>>
>>> It's best to move the reset and initialization of DSS happen later. I believe
>>> we already are resetting only some of the hwmods early on.
>>>
>>
>> I looked at this in some more detail. With the current hwmod
>> flags(HWMOD_INIT_NO_RESET/NO_IDLE), we still try to enable the IP, it's just
>> the reset part(ocp reset/custom reset and sysc register) or the disable part
>> that is skipped. hwmod still tries to enable the IP.
>>
>> This again results in the same issue.
>>
>> One thing which wasn't clear was that why do we enable a hwmod in the first
>> place, if we know that we are going to skip reset?
>
> Probably to configure the idle bits. In general, we should configure the
> modules lazily as the driver probes as requested, and then idle the
> unused modules with a late_initcall.

Okay, we were thinking of changing the hwmod code to skip enable for 
hwmods(which have the HWMOD_INIT_NO_RESET flag) altogether. But that 
doesn't seem like a viable option.

I can't think of any other way of getting around this, besides making 
control module a clock provider.

Paul said that it's not that bad to make DRA7 CTRL module a clock 
provider, but outside of PRCM code. I guess that would involve having 
something along the lines of of_prcm_init() in mach-omap2/control.c

Archit


Archit

[RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7

[Tero Kristo]

On 05/08/2014 09:02 AM, Archit Taneja wrote:
> On Tuesday 06 May 2014 07:56 PM, Tony Lindgren wrote:
>> * Archit Taneja <archit@ti.com> [140505 22:24]:
>>> Hi,
>>>
>>> On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote:
>>>> * Archit Taneja <archit@ti.com> [140420 22:16]:
>>>>> Hi,
>>>>>
>>>>> On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote:
>>>>>> * Archit Taneja <archit@ti.com> [140416 06:20]:
>>>>>>> Add DT node for the ctrl-core sub module of the DRA7 control
>>>>>>> module. We map the
>>>>>>> CTRL_MODULE_CORE address region up to 0x4a002d60, this region
>>>>>>> contains register
>>>>>>> fields which configure clocks. The remainder of the registers are
>>>>>>> related to
>>>>>>> pad configurations or cross-bar configurations, and therefore
>>>>>>> aren't mapped.
>>>>>>
>>>>>> Can you please check if this can just use the existing
>>>>>> regmap syscon mapping:
>>>>>>
>>>>>> syscon = <&dra7_ctrl_general>;
>>>>>>
>>>>>> See how the drivers/regulator/pbias-regulator.c is using the
>>>>>> syscon to initialize a regulator and then omap_hsmmc.c just does
>>>>>> the standard regulator calls.
>>>>>
>>>>> The thing is that this bit needs to be set before the the DSS
>>>>> hwmods are
>>>>> reset, and that happens very early. If we don't do this, DSS won't
>>>>> reset
>>>>> properly, and not get back to an idle state.
>>>>>
>>>>> I am not sure where I can configure the syscon register early
>>>>> enough that it
>>>>> happens before the hwmods are reset. With a syscon mapping, I guess
>>>>> we would
>>>>> access the register when the DSS driver is probed. But that's too
>>>>> late for
>>>>> us.
>>>>>
>>>>> Ideally, it would be much better to have a syscon mapping. Do you
>>>>> have any
>>>>> suggestions how this can be achieved very early in boot?
>>>>
>>>> It's best to move the reset and initialization of DSS happen later.
>>>> I believe
>>>> we already are resetting only some of the hwmods early on.
>>>>
>>>
>>> I looked at this in some more detail. With the current hwmod
>>> flags(HWMOD_INIT_NO_RESET/NO_IDLE), we still try to enable the IP,
>>> it's just
>>> the reset part(ocp reset/custom reset and sysc register) or the
>>> disable part
>>> that is skipped. hwmod still tries to enable the IP.
>>>
>>> This again results in the same issue.
>>>
>>> One thing which wasn't clear was that why do we enable a hwmod in the
>>> first
>>> place, if we know that we are going to skip reset?
>>
>> Probably to configure the idle bits. In general, we should configure the
>> modules lazily as the driver probes as requested, and then idle the
>> unused modules with a late_initcall.
>
> Okay, we were thinking of changing the hwmod code to skip enable for
> hwmods(which have the HWMOD_INIT_NO_RESET flag) altogether. But that
> doesn't seem like a viable option.
>
> I can't think of any other way of getting around this, besides making
> control module a clock provider.
>
> Paul said that it's not that bad to make DRA7 CTRL module a clock
> provider, but outside of PRCM code. I guess that would involve having
> something along the lines of of_prcm_init() in mach-omap2/control.c

That sounds like pretty much one of the things I have done here:

https://github.com/t-kristo/linux-pm/tree/3.14-rc4-cm-prm-driver-wip

The patches in their current form haven't been posted yet though, as 
they are waiting for some of the pre-reqs, but feel free to re-use 
something from here.

-Tero

>
> Archit
>
>
> Archit
>

[RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7

[Archit Taneja]

On Thursday 08 May 2014 01:23 PM, Tero Kristo wrote:
> On 05/08/2014 09:02 AM, Archit Taneja wrote:
>> On Tuesday 06 May 2014 07:56 PM, Tony Lindgren wrote:
>>> * Archit Taneja <archit@ti.com> [140505 22:24]:
>>>> Hi,
>>>>
>>>> On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote:
>>>>> * Archit Taneja <archit@ti.com> [140420 22:16]:
>>>>>> Hi,
>>>>>>
>>>>>> On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote:
>>>>>>> * Archit Taneja <archit@ti.com> [140416 06:20]:
>>>>>>>> Add DT node for the ctrl-core sub module of the DRA7 control
>>>>>>>> module. We map the
>>>>>>>> CTRL_MODULE_CORE address region up to 0x4a002d60, this region
>>>>>>>> contains register
>>>>>>>> fields which configure clocks. The remainder of the registers are
>>>>>>>> related to
>>>>>>>> pad configurations or cross-bar configurations, and therefore
>>>>>>>> aren't mapped.
>>>>>>>
>>>>>>> Can you please check if this can just use the existing
>>>>>>> regmap syscon mapping:
>>>>>>>
>>>>>>> syscon = <&dra7_ctrl_general>;
>>>>>>>
>>>>>>> See how the drivers/regulator/pbias-regulator.c is using the
>>>>>>> syscon to initialize a regulator and then omap_hsmmc.c just does
>>>>>>> the standard regulator calls.
>>>>>>
>>>>>> The thing is that this bit needs to be set before the the DSS
>>>>>> hwmods are
>>>>>> reset, and that happens very early. If we don't do this, DSS won't
>>>>>> reset
>>>>>> properly, and not get back to an idle state.
>>>>>>
>>>>>> I am not sure where I can configure the syscon register early
>>>>>> enough that it
>>>>>> happens before the hwmods are reset. With a syscon mapping, I guess
>>>>>> we would
>>>>>> access the register when the DSS driver is probed. But that's too
>>>>>> late for
>>>>>> us.
>>>>>>
>>>>>> Ideally, it would be much better to have a syscon mapping. Do you
>>>>>> have any
>>>>>> suggestions how this can be achieved very early in boot?
>>>>>
>>>>> It's best to move the reset and initialization of DSS happen later.
>>>>> I believe
>>>>> we already are resetting only some of the hwmods early on.
>>>>>
>>>>
>>>> I looked at this in some more detail. With the current hwmod
>>>> flags(HWMOD_INIT_NO_RESET/NO_IDLE), we still try to enable the IP,
>>>> it's just
>>>> the reset part(ocp reset/custom reset and sysc register) or the
>>>> disable part
>>>> that is skipped. hwmod still tries to enable the IP.
>>>>
>>>> This again results in the same issue.
>>>>
>>>> One thing which wasn't clear was that why do we enable a hwmod in the
>>>> first
>>>> place, if we know that we are going to skip reset?
>>>
>>> Probably to configure the idle bits. In general, we should configure the
>>> modules lazily as the driver probes as requested, and then idle the
>>> unused modules with a late_initcall.
>>
>> Okay, we were thinking of changing the hwmod code to skip enable for
>> hwmods(which have the HWMOD_INIT_NO_RESET flag) altogether. But that
>> doesn't seem like a viable option.
>>
>> I can't think of any other way of getting around this, besides making
>> control module a clock provider.
>>
>> Paul said that it's not that bad to make DRA7 CTRL module a clock
>> provider, but outside of PRCM code. I guess that would involve having
>> something along the lines of of_prcm_init() in mach-omap2/control.c
>
> That sounds like pretty much one of the things I have done here:
>
> https://github.com/t-kristo/linux-pm/tree/3.14-rc4-cm-prm-driver-wip
>
> The patches in their current form haven't been posted yet though, as
> they are waiting for some of the pre-reqs, but feel free to re-use
> something from here.

Ah nice, thanks!

Archit