Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
On Tuesday 06 May 2014 07:56 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140505 22:24]: Hi, On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140420 22:16]: Hi, On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote: * Archit Taneja arc...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
On 05/08/2014 09:02 AM, Archit Taneja wrote: On Tuesday 06 May 2014 07:56 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140505 22:24]: Hi, On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140420 22:16]: Hi, On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote: * Archit Taneja arc...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
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 arc...@ti.com [140505 22:24]: Hi, On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140420 22:16]: Hi, On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote: * Archit Taneja arc...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
* Archit Taneja arc...@ti.com [140505 22:24]: Hi, On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140420 22:16]: Hi, On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote: * Archit Taneja arc...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
Hi, On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140420 22:16]: Hi, On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote: * Archit Taneja arc...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
* Archit Taneja arc...@ti.com [140420 22:16]: Hi, On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote: * Archit Taneja arc...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
Hi, On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote: * Archit Taneja arc...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
* Archit Taneja arc...@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 arc...@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@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@4ae04000 {
compatible = ti,omap-counter32k;
reg = 0x4ae04000 0x40;
--
1.8.3.2
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
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 arc...@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@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@4ae04000 {
compatible = ti,omap-counter32k;
reg = 0x4ae04000 0x40;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
