sh: CONFIG_SH_CLK_DISABLE_LEGACY

From: Magnus Damm <[email protected]>

Invert legacy kconfig logic in clkfwk branch. Instead of building clock-cpg.c if CONFIG_SH_CLK_CPG_LEGACY is set, let CONFIG_SH_CLK_DISABLE_LEGACY be no by default and let upgraded processors use select to disable the legacy code. While at it, put clock-cpg.c code in clock.c and wrap it in ifdefs to only build if CONFIG_SH_CLK_DISABLE_LEGACY is set to no.

---

 arch/sh/Kconfig                |    5 +--
 arch/sh/kernel/cpu/Makefile    |    1 
 arch/sh/kernel/cpu/clock-cpg.c |   60 ---------------------------------------
 arch/sh/kernel/cpu/clock.c     |   61 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 64 insertions(+), 63 deletions(-)

@@ -398,6 +398,7 @@ config CPU_SUBTYPE_SH7785
 	select CPU_SHX2
 	select ARCH_SPARSEMEM_ENABLE
 	select SYS_SUPPORTS_NUMA
+	select SH_CLK_DISABLE_LEGACY
 
 config CPU_SUBTYPE_SH7786
 	bool "Support SH7786 processor"

@@ -513,8 +514,8 @@ config SH_PCLK_FREQ
 	  This is necessary for determining the reference clock value on
 	  platforms lacking an RTC.
 
-config SH_CLK_CPG_LEGACY
-	def_bool y if !CPU_SUBTYPE_SH7785
+config SH_CLK_DISABLE_LEGACY
+	def_bool n
 
 config SH_CLK_MD
 	int "CPU Mode Pin Setting"

@@ -17,6 +17,5 @@ obj-$(CONFIG_ARCH_SHMOBILE)	+= shmobile/
 
 obj-$(CONFIG_UBC_WAKEUP)	+= ubc.o
 obj-$(CONFIG_SH_ADC)		+= adc.o
-obj-$(CONFIG_SH_CLK_CPG_LEGACY)	+= clock-cpg.o
 
 obj-y	+= irq/ init.o clock.o

From: Magnus Damm <[email protected]>

Invert legacy kconfig logic in clkfwk branch V2. Instead of building clock-cpg.c if CONFIG_SH_CLK_CPG_LEGACY is set, let CONFIG_SH_CLK_DISABLE_LEGACY be no by default and let upgraded processors use select to disable the legacy code. Always build clock-cpg.c but wrap legacy code in ifdefs to only build if CONFIG_SH_CLK_DISABLE_LEGACY is set to no.

---

 arch/sh/Kconfig                |    5 +++--
 arch/sh/kernel/cpu/Makefile    |    3 +--
 arch/sh/kernel/cpu/clock-cpg.c |    4 ++++
 3 files changed, 8 insertions(+), 4 deletions(-)

@@ -398,6 +398,7 @@ config CPU_SUBTYPE_SH7785
 	select CPU_SHX2
 	select ARCH_SPARSEMEM_ENABLE
 	select SYS_SUPPORTS_NUMA
+	select SH_CLK_DISABLE_LEGACY
 
 config CPU_SUBTYPE_SH7786
 	bool "Support SH7786 processor"

@@ -513,8 +514,8 @@ config SH_PCLK_FREQ
 	  This is necessary for determining the reference clock value on
 	  platforms lacking an RTC.
 
-config SH_CLK_CPG_LEGACY
-	def_bool y if !CPU_SUBTYPE_SH7785
+config SH_CLK_DISABLE_LEGACY
+	def_bool n
 
 config SH_CLK_MD
 	int "CPU Mode Pin Setting"

@@ -17,6 +17,5 @@ obj-$(CONFIG_ARCH_SHMOBILE)	+= shmobile/
 
 obj-$(CONFIG_UBC_WAKEUP)	+= ubc.o
 obj-$(CONFIG_SH_ADC)		+= adc.o
-obj-$(CONFIG_SH_CLK_CPG_LEGACY)	+= clock-cpg.o
 
-obj-y	+= irq/ init.o clock.o
+obj-y	+= irq/ init.o clock.o clock-cpg.o

@@ -2,6 +2,8 @@
 #include <linux/compiler.h>
 #include <asm/clock.h>
 
+#ifndef CONFIG_SH_CLK_DISABLE_LEGACY
+
 static struct clk master_clk = {
 	.name		= "master_clk",
 	.flags		= CLK_ENABLE_ON_INIT,

@@ -58,3 +60,5 @@ int __init __weak arch_clk_init(void)
 {
 	return cpg_clk_init();
 }
+
+#endif /* CONFIG_SH_CLK_DISABLE_LEGACY */

No, this is not the intention of the define. The intention was to keep it as a place holder until I had time to ween the rest of the users off of those clock definitions. As the vast majority of CPUs don't do much of anything with their clock frameworks, that should be pretty easy to do once SH7785 and the SH-Mobile bits have converged and settled.

Note that not building in the CPG clocks by default is behaviour we plan on maintaining. There are ST40 parts that do not include the CPG at all for example, and removing those legacy clocks are one of the only patches needed against the generic clock.c to fix things up for those use cases.

The goal for clock-cpg.c on the other hand is to get a bit more generic that most CPUs can tie their root clock information in to that to get most of the useful bits out of the way. This has not happened yet as I have been busy with PCI-Express.

In general, patches that invert logic are rarely useful. The logic was generally done that way for a reason, whether it is immediately evident or not. Bits in my topic branches may be a little less obvious than the stuff in HEAD mostly since it is still in a high state of flux and not yet ready for merging.