* [RFC 1/4] ARM: OMAP2+: Add CTRL_MODULE_CORE as a master clock provider for DRA7 @ 2014-04-16 13:14 ` Archit Taneja 0 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-04-16 13:14 UTC (permalink / raw) To: t-kristo; +Cc: linux-omap, linux-arm-kernel, 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [RFC 1/4] ARM: OMAP2+: Add CTRL_MODULE_CORE as a master clock provider for DRA7 @ 2014-04-16 13:14 ` Archit Taneja 0 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-04-16 13:14 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 2014-04-16 13:14 ` Archit Taneja @ 2014-04-16 13:14 ` Archit Taneja -1 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-04-16 13:14 UTC (permalink / raw) To: t-kristo; +Cc: linux-omap, linux-arm-kernel, 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@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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 @ 2014-04-16 13:14 ` Archit Taneja 0 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-04-16 13:14 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 2014-04-16 13:14 ` Archit Taneja @ 2014-04-18 17:18 ` Tony Lindgren -1 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2014-04-18 17:18 UTC (permalink / raw) To: Archit Taneja; +Cc: t-kristo, linux-omap, linux-arm-kernel * 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@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-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 @ 2014-04-18 17:18 ` Tony Lindgren 0 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2014-04-18 17:18 UTC (permalink / raw) To: linux-arm-kernel * 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 2014-04-18 17:18 ` Tony Lindgren @ 2014-04-21 5:15 ` Archit Taneja -1 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-04-21 5:15 UTC (permalink / raw) To: Tony Lindgren; +Cc: t-kristo, linux-omap, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 @ 2014-04-21 5:15 ` Archit Taneja 0 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-04-21 5:15 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 2014-04-21 5:15 ` Archit Taneja @ 2014-04-21 15:10 ` Tony Lindgren -1 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2014-04-21 15:10 UTC (permalink / raw) To: Archit Taneja; +Cc: t-kristo, linux-omap, linux-arm-kernel * 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 @ 2014-04-21 15:10 ` Tony Lindgren 0 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2014-04-21 15:10 UTC (permalink / raw) To: linux-arm-kernel * 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 2014-04-21 15:10 ` Tony Lindgren @ 2014-05-06 5:22 ` Archit Taneja -1 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-05-06 5:22 UTC (permalink / raw) To: Tony Lindgren; +Cc: t-kristo, linux-omap, linux-arm-kernel, Rajendra Nayak 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 @ 2014-05-06 5:22 ` Archit Taneja 0 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-05-06 5:22 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 2014-05-06 5:22 ` Archit Taneja @ 2014-05-06 14:26 ` Tony Lindgren -1 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2014-05-06 14:26 UTC (permalink / raw) To: Archit Taneja; +Cc: t-kristo, linux-omap, linux-arm-kernel, Rajendra Nayak * 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 @ 2014-05-06 14:26 ` Tony Lindgren 0 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2014-05-06 14:26 UTC (permalink / raw) To: linux-arm-kernel * 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 2014-05-06 14:26 ` Tony Lindgren @ 2014-05-08 6:02 ` Archit Taneja -1 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-05-08 6:02 UTC (permalink / raw) To: Tony Lindgren, paul Cc: t-kristo, linux-omap, linux-arm-kernel, Rajendra Nayak 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 @ 2014-05-08 6:02 ` Archit Taneja 0 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-05-08 6:02 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 2014-05-08 6:02 ` Archit Taneja @ 2014-05-08 7:53 ` Tero Kristo -1 siblings, 0 replies; 34+ messages in thread From: Tero Kristo @ 2014-05-08 7:53 UTC (permalink / raw) To: Archit Taneja, Tony Lindgren, paul Cc: linux-omap, linux-arm-kernel, Rajendra Nayak 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 > ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 @ 2014-05-08 7:53 ` Tero Kristo 0 siblings, 0 replies; 34+ messages in thread From: Tero Kristo @ 2014-05-08 7:53 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 2014-05-08 7:53 ` Tero Kristo @ 2014-05-08 8:16 ` Archit Taneja -1 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-05-08 8:16 UTC (permalink / raw) To: Tero Kristo, Tony Lindgren, paul Cc: linux-omap, linux-arm-kernel, Rajendra Nayak 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7 @ 2014-05-08 8:16 ` Archit Taneja 0 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-05-08 8:16 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC 3/4] ARM: dts: Add dss_deshdcp clock node under dra7-ctrl-core 2014-04-16 13:14 ` Archit Taneja @ 2014-04-16 13:14 ` Archit Taneja -1 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-04-16 13:14 UTC (permalink / raw) To: t-kristo; +Cc: linux-omap, linux-arm-kernel, 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [RFC 3/4] ARM: dts: Add dss_deshdcp clock node under dra7-ctrl-core @ 2014-04-16 13:14 ` Archit Taneja 0 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-04-16 13:14 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [RFC 4/4] CLK: TI: Enable dss_deshdcp clock in dra7xx_clk_init 2014-04-16 13:14 ` Archit Taneja @ 2014-04-16 13:14 ` Archit Taneja -1 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-04-16 13:14 UTC (permalink / raw) To: t-kristo; +Cc: linux-omap, linux-arm-kernel, 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [RFC 4/4] CLK: TI: Enable dss_deshdcp clock in dra7xx_clk_init @ 2014-04-16 13:14 ` Archit Taneja 0 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-04-16 13:14 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [RFC 1/4] ARM: OMAP2+: Add CTRL_MODULE_CORE as a master clock provider for DRA7 2014-04-16 13:14 ` Archit Taneja @ 2014-05-08 1:19 ` Paul Walmsley -1 siblings, 0 replies; 34+ messages in thread From: Paul Walmsley @ 2014-05-08 1:19 UTC (permalink / raw) To: Archit Taneja; +Cc: t-kristo, linux-omap, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC 1/4] ARM: OMAP2+: Add CTRL_MODULE_CORE as a master clock provider for DRA7 @ 2014-05-08 1:19 ` Paul Walmsley 0 siblings, 0 replies; 34+ messages in thread From: Paul Walmsley @ 2014-05-08 1:19 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC v2 0/6] ARM: dts: Add a new clk provider, and implement dss_deshdcp clock with it 2014-04-16 13:14 ` Archit Taneja ` (4 preceding siblings ...) (?) @ 2014-05-28 10:50 ` Archit Taneja 2014-05-28 10:50 ` [RFC v2 1/6] CLK: TI: clockdomain: add support for retrying init Archit Taneja ` (5 more replies) -1 siblings, 6 replies; 34+ messages in thread From: Archit Taneja @ 2014-05-28 10:50 UTC (permalink / raw) To: paul, t-kristo, rnayak; +Cc: linux-omap, Archit Taneja This series tries to create CONTROL_MODULE_CORE as a new clock provider, and create a clock using it required by DSS on DRA7. The previous revision of the series added the new clock provider within prcm driver code itself. Suggestions were made by Paul and Tero to move it to control module driver code. I picked up 2 patches from Tero's WIP branch below, and added DRA7's control module core block as a clock provider. The DSS_DESHDCP clock is easy to implement after that. https://github.com/t-kristo/linux-pm/tree/3.14-rc4-cm-prm-driver-wip Archit Taneja (5): ARM: PRCM: split PRCM module init to their own driver files ARM: OMAP2+: Add CONTROL_MODULE_CORE as a clock provider for DRA7x ARM: dts: Add ctrl-core DT node for DRA7 ARM: dts: Add dss_deshdcp clock node under dra7-ctrl-core CLK: TI: Enable dss_deshdcp clock in dra7xx_clk_init Tero Kristo (1): CLK: TI: clockdomain: add support for retrying init arch/arm/boot/dts/dra7.dtsi | 13 ++++++ arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 +++++ arch/arm/mach-omap2/cm_common.c | 18 +++++++++ arch/arm/mach-omap2/control.c | 35 ++++++++++++++++ arch/arm/mach-omap2/control.h | 1 + arch/arm/mach-omap2/io.c | 4 ++ arch/arm/mach-omap2/prcm-common.h | 5 +++ arch/arm/mach-omap2/prm_common.c | 55 +++++++++++++++----------- drivers/clk/ti/clk-7xx.c | 8 +++- drivers/clk/ti/clockdomain.c | 77 ++++++++++++++++++++++++++++++------ include/linux/clk/ti.h | 2 +- 11 files changed, 192 insertions(+), 36 deletions(-) -- 1.8.3.2 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC v2 1/6] CLK: TI: clockdomain: add support for retrying init 2014-05-28 10:50 ` [RFC v2 0/6] ARM: dts: Add a new clk provider, and implement dss_deshdcp clock with it Archit Taneja @ 2014-05-28 10:50 ` Archit Taneja 2014-05-28 10:50 ` [RFC v2 2/6] ARM: PRCM: split PRCM module init to their own driver files Archit Taneja ` (4 subsequent siblings) 5 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-05-28 10:50 UTC (permalink / raw) To: paul, t-kristo, rnayak; +Cc: linux-omap From: Tero Kristo <t-kristo@ti.com> Retry init is needed if clockdomains are registered before the corresponding clocks are ready. In this case, the clockdomain info is added to a list which will be processed once the clockdomains for next PRCM module are processed. Signed-off-by: Tero Kristo <t-kristo@ti.com> --- arch/arm/mach-omap2/prm_common.c | 3 +- drivers/clk/ti/clockdomain.c | 77 ++++++++++++++++++++++++++++++++++------ include/linux/clk/ti.h | 2 +- 3 files changed, 68 insertions(+), 14 deletions(-) diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c index b4c4ab9..56462af 100644 --- a/arch/arm/mach-omap2/prm_common.c +++ b/arch/arm/mach-omap2/prm_common.c @@ -523,10 +523,9 @@ int __init of_prcm_init(void) mem = of_iomap(np, 0); clk_memmaps[memmap_index] = mem; ti_dt_clk_init_provider(np, memmap_index); + ti_dt_clockdomains_setup(np); memmap_index++; } - ti_dt_clockdomains_setup(); - return 0; } diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c index f1e0038..29fa543 100644 --- a/drivers/clk/ti/clockdomain.c +++ b/drivers/clk/ti/clockdomain.c @@ -24,26 +24,60 @@ #undef pr_fmt #define pr_fmt(fmt) "%s: " fmt, __func__ -static void __init of_ti_clockdomain_setup(struct device_node *node) +struct clkdm_init_item { + struct device_node *node; + int index; + struct list_head link; +}; + +static LIST_HEAD(retry_list); + +static int of_ti_init_clk_clkdm(struct device_node *node, int index) { struct clk *clk; struct clk_hw *clk_hw; - const char *clkdm_name = node->name; + + clk = of_clk_get(node, index); + + if (IS_ERR_OR_NULL(clk)) { + pr_debug("%s[%d] = %08x\n", node->name, index, (u32)clk); + return -EBUSY; + } + + if (__clk_get_flags(clk) & CLK_IS_BASIC) { + pr_warn("can't setup clkdm for basic clk %s\n", + __clk_get_name(clk)); + return -EINVAL; + } + + clk_hw = __clk_get_hw(clk); + to_clk_hw_omap(clk_hw)->clkdm_name = node->name; + omap2_init_clk_clkdm(clk_hw); + + return 0; +} + +static void __init of_ti_clockdomain_setup(struct device_node *node) +{ int i; int num_clks; + struct clkdm_init_item *retry; + int ret; num_clks = of_count_phandle_with_args(node, "clocks", "#clock-cells"); for (i = 0; i < num_clks; i++) { - clk = of_clk_get(node, i); - if (__clk_get_flags(clk) & CLK_IS_BASIC) { - pr_warn("can't setup clkdm for basic clk %s\n", - __clk_get_name(clk)); + ret = of_ti_init_clk_clkdm(node, i); + + if (ret == -EBUSY) { + retry = kzalloc(sizeof(*retry), GFP_KERNEL); + if (!retry) + return; + retry->node = node; + retry->index = i; + list_add(&retry->link, &retry_list); continue; } - clk_hw = __clk_get_hw(clk); - to_clk_hw_omap(clk_hw)->clkdm_name = clkdm_name; - omap2_init_clk_clkdm(clk_hw); } } @@ -61,10 +95,31 @@ static struct of_device_id ti_clkdm_match_table[] __initdata = { * called after rest of the DT clock init has completed and all * clock nodes have been registered. */ -void __init ti_dt_clockdomains_setup(void) +void __init ti_dt_clockdomains_setup(struct device_node *node) { struct device_node *np; - for_each_matching_node(np, ti_clkdm_match_table) { + struct device_node *clkdms; + struct clkdm_init_item *retry, *tmp; + int ret; + + clkdms = of_get_child_by_name(node, "clockdomains"); + if (!clkdms) + return; + + list_for_each_entry_safe(retry, tmp, &retry_list, link) { + pr_debug("retry-init: %s [%d]\n", retry->node->name, + retry->index); + ret = of_ti_init_clk_clkdm(retry->node, retry->index); + if (!ret) { + list_del(&retry->link); + kfree(retry); + } + } + + for_each_child_of_node(clkdms, np) { + if (!of_match_node(ti_clkdm_match_table, np)) + continue; + of_ti_clockdomain_setup(np); } } diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h index 4a21a87..20dd7c0 100644 --- a/include/linux/clk/ti.h +++ b/include/linux/clk/ti.h @@ -263,7 +263,7 @@ void omap3_clk_lock_dpll5(void); void __iomem *ti_clk_get_reg_addr(struct device_node *node, int index); void ti_dt_clocks_register(struct ti_dt_clk *oclks); void ti_dt_clk_init_provider(struct device_node *np, int index); -void ti_dt_clockdomains_setup(void); +void ti_dt_clockdomains_setup(struct device_node *node); int ti_clk_retry_init(struct device_node *node, struct clk_hw *hw, ti_of_clk_init_cb_t func); int of_ti_clk_autoidle_setup(struct device_node *node); -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [RFC v2 2/6] ARM: PRCM: split PRCM module init to their own driver files 2014-05-28 10:50 ` [RFC v2 0/6] ARM: dts: Add a new clk provider, and implement dss_deshdcp clock with it Archit Taneja 2014-05-28 10:50 ` [RFC v2 1/6] CLK: TI: clockdomain: add support for retrying init Archit Taneja @ 2014-05-28 10:50 ` Archit Taneja 2014-06-16 11:48 ` Tony Lindgren 2014-05-28 10:50 ` [RFC v2 3/6] ARM: OMAP2+: Add CONTROL_MODULE_CORE as a clock provider for DRA7x Archit Taneja ` (3 subsequent siblings) 5 siblings, 1 reply; 34+ messages in thread From: Archit Taneja @ 2014-05-28 10:50 UTC (permalink / raw) To: paul, t-kristo, rnayak; +Cc: linux-omap, Archit Taneja Currently, clock providers coming from CM, PRM, and SCRM are all initialized in prm_common.c. Move the DT-match tables to their respective files, and create separate init functions for each module. Originally worked on by: Tero Kristo <t-kristo@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Archit Taneja <archit@ti.com> --- arch/arm/mach-omap2/cm_common.c | 18 ++++++++++++++ arch/arm/mach-omap2/control.c | 15 +++++++++++ arch/arm/mach-omap2/control.h | 1 + arch/arm/mach-omap2/io.c | 4 +++ arch/arm/mach-omap2/prcm-common.h | 5 ++++ arch/arm/mach-omap2/prm_common.c | 52 +++++++++++++++++++++++---------------- 6 files changed, 74 insertions(+), 21 deletions(-) diff --git a/arch/arm/mach-omap2/cm_common.c b/arch/arm/mach-omap2/cm_common.c index 40b3b5a..8506990 100644 --- a/arch/arm/mach-omap2/cm_common.c +++ b/arch/arm/mach-omap2/cm_common.c @@ -14,6 +14,7 @@ #include <linux/kernel.h> #include <linux/init.h> #include <linux/errno.h> +#include <linux/of.h> #include "cm2xxx.h" #include "cm3xxx.h" @@ -138,3 +139,20 @@ int cm_unregister(struct cm_ll_data *cld) return 0; } + +static struct of_device_id omap_cm_dt_match_table[] = { + { .compatible = "ti,omap3-cm" }, + { .compatible = "ti,omap4-cm1" }, + { .compatible = "ti,omap4-cm2" }, + { .compatible = "ti,omap5-cm-core-aon" }, + { .compatible = "ti,omap5-cm-core" }, + { .compatible = "ti,dra7-cm-core-aon" }, + { .compatible = "ti,dra7-cm-core" }, + { } +}; + + +int __init of_cm_init(void) +{ + return of_prcm_module_init(omap_cm_dt_match_table); +} diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 44bb4d5..12cd736 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -581,3 +581,18 @@ void omap3_ctrl_set_iva_bootmode_idle(void) OMAP343X_CONTROL_IVA2_BOOTMOD); } #endif /* CONFIG_ARCH_OMAP3 && CONFIG_PM */ + +static struct of_device_id omap_scrm_dt_match_table[] = { + { .compatible = "ti,am3-scrm" }, + { .compatible = "ti,am4-scrm" }, + { .compatible = "ti,omap2-scrm" }, + { .compatible = "ti,omap3-scrm" }, + { .compatible = "ti,omap4-scrm" }, + { .compatible = "ti,omap5-scrm" }, + { } +}; + +int __init of_scrm_init(void) +{ + return of_prcm_module_init(omap_scrm_dt_match_table); +} diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index da05480..5d695f1 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -428,6 +428,7 @@ extern void omap_ctrl_write_dsp_boot_mode(u8 bootmode); extern void omap3630_ctrl_disable_rta(void); extern int omap3_ctrl_save_padconf(void); extern void omap3_ctrl_set_iva_bootmode_idle(void); +int of_scrm_init(void); extern void omap2_set_globals_control(void __iomem *ctrl, void __iomem *ctrl_pad); #else diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index f14f9ac..c78e2b8 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -725,6 +725,10 @@ int __init omap_clk_init(void) if (!omap_clk_soc_init) return 0; + ret = of_scrm_init(); + if (ret) + return ret; + ret = of_prcm_init(); if (!ret) ret = omap_clk_soc_init(); diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index 0e841fd..a68d98e 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -493,6 +493,8 @@ struct omap_prcm_irq_setup { .priority = _priority \ } +struct of_device_id; + extern void omap_prcm_irq_cleanup(void); extern int omap_prcm_register_chain_handler( struct omap_prcm_irq_setup *irq_setup); @@ -500,6 +502,9 @@ extern int omap_prcm_event_to_irq(const char *event); extern void omap_prcm_irq_prepare(void); extern void omap_prcm_irq_complete(void); +int of_prcm_module_init(struct of_device_id *match_table); +int of_cm_init(void); + # endif #endif diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c index 56462af..85fc9f9 100644 --- a/arch/arm/mach-omap2/prm_common.c +++ b/arch/arm/mach-omap2/prm_common.c @@ -470,25 +470,18 @@ int prm_unregister(struct prm_ll_data *pld) return 0; } -static struct of_device_id omap_prcm_dt_match_table[] = { - { .compatible = "ti,am3-prcm" }, - { .compatible = "ti,am3-scrm" }, - { .compatible = "ti,am4-prcm" }, - { .compatible = "ti,am4-scrm" }, +static struct of_device_id omap_prm_dt_match_table[] = { { .compatible = "ti,omap3-prm" }, - { .compatible = "ti,omap3-cm" }, - { .compatible = "ti,omap3-scrm" }, - { .compatible = "ti,omap4-cm1" }, { .compatible = "ti,omap4-prm" }, - { .compatible = "ti,omap4-cm2" }, - { .compatible = "ti,omap4-scrm" }, { .compatible = "ti,omap5-prm" }, - { .compatible = "ti,omap5-cm-core-aon" }, - { .compatible = "ti,omap5-scrm" }, - { .compatible = "ti,omap5-cm-core" }, { .compatible = "ti,dra7-prm" }, - { .compatible = "ti,dra7-cm-core-aon" }, - { .compatible = "ti,dra7-cm-core" }, + { } +}; + +static struct of_device_id omap_prcm_dt_match_table[] = { + { .compatible = "ti,am3-prcm" }, + { .compatible = "ti,am4-prcm" }, + { .compatible = "ti,omap2-prcm" }, { } }; @@ -511,21 +504,38 @@ static struct ti_clk_ll_ops omap_clk_ll_ops = { .clk_writel = prm_clk_writel, }; -int __init of_prcm_init(void) +static int prcm_memmap_index; + +int __init of_prcm_module_init(struct of_device_id *match_table) { struct device_node *np; void __iomem *mem; - int memmap_index = 0; ti_clk_ll_ops = &omap_clk_ll_ops; - for_each_matching_node(np, omap_prcm_dt_match_table) { + for_each_matching_node(np, match_table) { mem = of_iomap(np, 0); - clk_memmaps[memmap_index] = mem; - ti_dt_clk_init_provider(np, memmap_index); + clk_memmaps[prcm_memmap_index] = mem; + ti_dt_clk_init_provider(np, prcm_memmap_index); ti_dt_clockdomains_setup(np); - memmap_index++; + prcm_memmap_index++; } return 0; } + +int __init of_prm_init(void) +{ + return of_prcm_module_init(omap_prm_dt_match_table); +} + +int __init of_prcm_init(void) +{ + int ret; + + ret = of_prm_init(); + ret |= of_cm_init(); + ret |= of_prcm_module_init(omap_prcm_dt_match_table); + + return ret; +} -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [RFC v2 2/6] ARM: PRCM: split PRCM module init to their own driver files 2014-05-28 10:50 ` [RFC v2 2/6] ARM: PRCM: split PRCM module init to their own driver files Archit Taneja @ 2014-06-16 11:48 ` Tony Lindgren 0 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2014-06-16 11:48 UTC (permalink / raw) To: Archit Taneja; +Cc: paul, t-kristo, rnayak, linux-omap * Archit Taneja <archit@ti.com> [140528 03:53]: > Currently, clock providers coming from CM, PRM, and SCRM are all initialized in > prm_common.c. > > Move the DT-match tables to their respective files, and create separate init > functions for each module. > > Originally worked on by: Tero Kristo <t-kristo@ti.com> > > Cc: Tero Kristo <t-kristo@ti.com> > Signed-off-by: Archit Taneja <archit@ti.com> > --- > arch/arm/mach-omap2/cm_common.c | 18 ++++++++++++++ > arch/arm/mach-omap2/control.c | 15 +++++++++++ > arch/arm/mach-omap2/control.h | 1 + > arch/arm/mach-omap2/io.c | 4 +++ > arch/arm/mach-omap2/prcm-common.h | 5 ++++ > arch/arm/mach-omap2/prm_common.c | 52 +++++++++++++++++++++++---------------- > 6 files changed, 74 insertions(+), 21 deletions(-) > > diff --git a/arch/arm/mach-omap2/cm_common.c b/arch/arm/mach-omap2/cm_common.c > index 40b3b5a..8506990 100644 > --- a/arch/arm/mach-omap2/cm_common.c > +++ b/arch/arm/mach-omap2/cm_common.c > @@ -14,6 +14,7 @@ > #include <linux/kernel.h> > #include <linux/init.h> > #include <linux/errno.h> > +#include <linux/of.h> > > #include "cm2xxx.h" > #include "cm3xxx.h" > @@ -138,3 +139,20 @@ int cm_unregister(struct cm_ll_data *cld) > > return 0; > } > + > +static struct of_device_id omap_cm_dt_match_table[] = { > + { .compatible = "ti,omap3-cm" }, > + { .compatible = "ti,omap4-cm1" }, > + { .compatible = "ti,omap4-cm2" }, > + { .compatible = "ti,omap5-cm-core-aon" }, > + { .compatible = "ti,omap5-cm-core" }, > + { .compatible = "ti,dra7-cm-core-aon" }, > + { .compatible = "ti,dra7-cm-core" }, > + { } > +}; > + > + > +int __init of_cm_init(void) > +{ > + return of_prcm_module_init(omap_cm_dt_match_table); > +} > diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c > index 44bb4d5..12cd736 100644 > --- a/arch/arm/mach-omap2/control.c > +++ b/arch/arm/mach-omap2/control.c > @@ -581,3 +581,18 @@ void omap3_ctrl_set_iva_bootmode_idle(void) > OMAP343X_CONTROL_IVA2_BOOTMOD); > } > #endif /* CONFIG_ARCH_OMAP3 && CONFIG_PM */ > + > +static struct of_device_id omap_scrm_dt_match_table[] = { > + { .compatible = "ti,am3-scrm" }, > + { .compatible = "ti,am4-scrm" }, > + { .compatible = "ti,omap2-scrm" }, > + { .compatible = "ti,omap3-scrm" }, > + { .compatible = "ti,omap4-scrm" }, > + { .compatible = "ti,omap5-scrm" }, > + { } > +}; > + > +int __init of_scrm_init(void) > +{ > + return of_prcm_module_init(omap_scrm_dt_match_table); > +} I think you may be able to leave out this driver like code from arch/arm/mach-omap2 by using the existing syscon mapping we have in the .dtsi files? See for example how the PBIAS is using the syscon in drivers/regulator/pbias-regulator.c. If the clock registers don't fall into the existing SCM syscon area, we can also set up more syscon areas. Regards, Tony ^ permalink raw reply [flat|nested] 34+ messages in thread
* [RFC v2 3/6] ARM: OMAP2+: Add CONTROL_MODULE_CORE as a clock provider for DRA7x 2014-05-28 10:50 ` [RFC v2 0/6] ARM: dts: Add a new clk provider, and implement dss_deshdcp clock with it Archit Taneja 2014-05-28 10:50 ` [RFC v2 1/6] CLK: TI: clockdomain: add support for retrying init Archit Taneja 2014-05-28 10:50 ` [RFC v2 2/6] ARM: PRCM: split PRCM module init to their own driver files Archit Taneja @ 2014-05-28 10:50 ` Archit Taneja 2014-05-28 10:50 ` [RFC v2 4/6] ARM: dts: Add ctrl-core DT node for DRA7 Archit Taneja ` (2 subsequent siblings) 5 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-05-28 10:50 UTC (permalink / raw) To: paul, t-kristo, rnayak; +Cc: linux-omap, Archit Taneja In DRA7x SoCs, the CONTROL_MODULE_CORE sub block in the control module has a few register fields which perform gating or muxing of clocks. These gate/muxes are generally SoC level clocks entering an IP, which didn't manage to make it in the clock management related registers for the IP. Other OMAP SOCs don't seem to have clock related register fields in the control module. We create a new table and function to init ctrl-core IPS as clock providers. This, along with scrm clock providers, are initialized in of_control_init(). We add a compatible string for dra7-ctrl-core in the DT match table. Signed-off-by: Archit Taneja <archit@ti.com> --- arch/arm/mach-omap2/control.c | 22 +++++++++++++++++++++- arch/arm/mach-omap2/control.h | 2 +- arch/arm/mach-omap2/io.c | 2 +- 3 files changed, 23 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 12cd736..d9567bc 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -592,7 +592,27 @@ static struct of_device_id omap_scrm_dt_match_table[] = { { } }; -int __init of_scrm_init(void) +static int __init of_scrm_init(void) { return of_prcm_module_init(omap_scrm_dt_match_table); } + +static struct of_device_id omap_ctrl_core_dt_match_table[] = { + { .compatible = "ti,dra7-ctrl-core" }, + { } +}; + +static int __init of_ctrl_core_init(void) +{ + return of_prcm_module_init(omap_ctrl_core_dt_match_table); +} + +int __init of_control_init(void) +{ + int ret; + + ret = of_scrm_init(); + ret |= of_ctrl_core_init(); + + return ret; +} diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index 5d695f1..405979e 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -428,7 +428,7 @@ extern void omap_ctrl_write_dsp_boot_mode(u8 bootmode); extern void omap3630_ctrl_disable_rta(void); extern int omap3_ctrl_save_padconf(void); extern void omap3_ctrl_set_iva_bootmode_idle(void); -int of_scrm_init(void); +int of_control_init(void); extern void omap2_set_globals_control(void __iomem *ctrl, void __iomem *ctrl_pad); #else diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index c78e2b8..49e344b 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -725,7 +725,7 @@ int __init omap_clk_init(void) if (!omap_clk_soc_init) return 0; - ret = of_scrm_init(); + ret = of_control_init(); if (ret) return ret; -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [RFC v2 4/6] ARM: dts: Add ctrl-core DT node for DRA7 2014-05-28 10:50 ` [RFC v2 0/6] ARM: dts: Add a new clk provider, and implement dss_deshdcp clock with it Archit Taneja ` (2 preceding siblings ...) 2014-05-28 10:50 ` [RFC v2 3/6] ARM: OMAP2+: Add CONTROL_MODULE_CORE as a clock provider for DRA7x Archit Taneja @ 2014-05-28 10:50 ` Archit Taneja 2014-05-28 10:50 ` [RFC v2 5/6] ARM: dts: Add dss_deshdcp clock node under dra7-ctrl-core Archit Taneja 2014-05-28 10:50 ` [RFC v2 6/6] CLK: TI: Enable dss_deshdcp clock in dra7xx_clk_init Archit Taneja 5 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-05-28 10:50 UTC (permalink / raw) To: paul, t-kristo, rnayak; +Cc: linux-omap, 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 149b550..14d1905 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [RFC v2 5/6] ARM: dts: Add dss_deshdcp clock node under dra7-ctrl-core 2014-05-28 10:50 ` [RFC v2 0/6] ARM: dts: Add a new clk provider, and implement dss_deshdcp clock with it Archit Taneja ` (3 preceding siblings ...) 2014-05-28 10:50 ` [RFC v2 4/6] ARM: dts: Add ctrl-core DT node for DRA7 Archit Taneja @ 2014-05-28 10:50 ` Archit Taneja 2014-05-28 10:50 ` [RFC v2 6/6] CLK: TI: Enable dss_deshdcp clock in dra7xx_clk_init Archit Taneja 5 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-05-28 10:50 UTC (permalink / raw) To: paul, t-kristo, rnayak; +Cc: linux-omap, 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 cfb8fc7..a1653ba 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [RFC v2 6/6] CLK: TI: Enable dss_deshdcp clock in dra7xx_clk_init 2014-05-28 10:50 ` [RFC v2 0/6] ARM: dts: Add a new clk provider, and implement dss_deshdcp clock with it Archit Taneja ` (4 preceding siblings ...) 2014-05-28 10:50 ` [RFC v2 5/6] ARM: dts: Add dss_deshdcp clock node under dra7-ctrl-core Archit Taneja @ 2014-05-28 10:50 ` Archit Taneja 5 siblings, 0 replies; 34+ messages in thread From: Archit Taneja @ 2014-05-28 10:50 UTC (permalink / raw) To: paul, t-kristo, rnayak; +Cc: linux-omap, 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
end of thread, other threads:[~2014-06-16 11:48 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-16 13:14 [RFC 1/4] ARM: OMAP2+: Add CTRL_MODULE_CORE as a master clock provider for DRA7 Archit Taneja 2014-04-16 13:14 ` Archit Taneja 2014-04-16 13:14 ` [RFC 2/4] ARM: dts: Add ctrl-core DT node " Archit Taneja 2014-04-16 13:14 ` Archit Taneja 2014-04-18 17:18 ` Tony Lindgren 2014-04-18 17:18 ` Tony Lindgren 2014-04-21 5:15 ` Archit Taneja 2014-04-21 5:15 ` Archit Taneja 2014-04-21 15:10 ` Tony Lindgren 2014-04-21 15:10 ` Tony Lindgren 2014-05-06 5:22 ` Archit Taneja 2014-05-06 5:22 ` Archit Taneja 2014-05-06 14:26 ` Tony Lindgren 2014-05-06 14:26 ` Tony Lindgren 2014-05-08 6:02 ` Archit Taneja 2014-05-08 6:02 ` Archit Taneja 2014-05-08 7:53 ` Tero Kristo 2014-05-08 7:53 ` Tero Kristo 2014-05-08 8:16 ` Archit Taneja 2014-05-08 8:16 ` Archit Taneja 2014-04-16 13:14 ` [RFC 3/4] ARM: dts: Add dss_deshdcp clock node under dra7-ctrl-core Archit Taneja 2014-04-16 13:14 ` Archit Taneja 2014-04-16 13:14 ` [RFC 4/4] CLK: TI: Enable dss_deshdcp clock in dra7xx_clk_init Archit Taneja 2014-04-16 13:14 ` Archit Taneja 2014-05-08 1:19 ` [RFC 1/4] ARM: OMAP2+: Add CTRL_MODULE_CORE as a master clock provider for DRA7 Paul Walmsley 2014-05-08 1:19 ` Paul Walmsley 2014-05-28 10:50 ` [RFC v2 0/6] ARM: dts: Add a new clk provider, and implement dss_deshdcp clock with it Archit Taneja 2014-05-28 10:50 ` [RFC v2 1/6] CLK: TI: clockdomain: add support for retrying init Archit Taneja 2014-05-28 10:50 ` [RFC v2 2/6] ARM: PRCM: split PRCM module init to their own driver files Archit Taneja 2014-06-16 11:48 ` Tony Lindgren 2014-05-28 10:50 ` [RFC v2 3/6] ARM: OMAP2+: Add CONTROL_MODULE_CORE as a clock provider for DRA7x Archit Taneja 2014-05-28 10:50 ` [RFC v2 4/6] ARM: dts: Add ctrl-core DT node for DRA7 Archit Taneja 2014-05-28 10:50 ` [RFC v2 5/6] ARM: dts: Add dss_deshdcp clock node under dra7-ctrl-core Archit Taneja 2014-05-28 10:50 ` [RFC v2 6/6] CLK: TI: Enable dss_deshdcp clock in dra7xx_clk_init Archit Taneja
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.