All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH-V2 0/4] ARM: OMAP2+: Cleanup series in order to remove ARCH_OMAPx dependency
@ 2012-05-08 19:52 ` Vaibhav Hiremath
  0 siblings, 0 replies; 38+ messages in thread
From: Vaibhav Hiremath @ 2012-05-08 19:52 UTC (permalink / raw)
  To: linux-omap; +Cc: tony, khilman, paul, linux-arm-kernel, Vaibhav Hiremath

In current implementation, some places we are still using
ARCH_OMAPx config option, making it difficult to add new devices;
for example, while adding am33xx device support I came across multiple
instances where I had to patch the existing code to make it work for
am33xx.

This patch tries to cleanup existing code for some of the
ARCH_OMAP2/3/4 dependency on the code.

NOTE: Patch series has been build tested for all possible
      combination of OMAP2, 3, 4 configurations.

History on Patch-series:
========================
Changes from V1:
   - Fixed comments from Tony
	- Config option name of SOC_HAS_SDRC changed to
	  SOC_HAS_OMAP2_SDRC
	- Config option name for SOC_HAS_DPLL_xxx flags to
	  SOC_HAS_OMAP3_DPLL_xxx.

Vaibhav Hiremath (4):
  ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add
    one entry
  ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c
  ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around
    __omap2_set_globals
  ARM: OMAP2+: CLEANUP: Add new config option for different DPLL
    features

 arch/arm/mach-omap2/Kconfig             |   42 +++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/clock.c             |   18 -------------
 arch/arm/mach-omap2/common.c            |    8 +-----
 arch/arm/mach-omap2/common.h            |    5 +++
 arch/arm/mach-omap2/dpll3xxx.c          |   14 ++++++++++
 arch/arm/plat-omap/Makefile             |    4 +--
 arch/arm/plat-omap/include/plat/clock.h |   14 ++++++++--
 7 files changed, 74 insertions(+), 31 deletions(-)


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 0/4] ARM: OMAP2+: Cleanup series in order to remove ARCH_OMAPx dependency
@ 2012-05-08 19:52 ` Vaibhav Hiremath
  0 siblings, 0 replies; 38+ messages in thread
From: Vaibhav Hiremath @ 2012-05-08 19:52 UTC (permalink / raw)
  To: linux-arm-kernel

In current implementation, some places we are still using
ARCH_OMAPx config option, making it difficult to add new devices;
for example, while adding am33xx device support I came across multiple
instances where I had to patch the existing code to make it work for
am33xx.

This patch tries to cleanup existing code for some of the
ARCH_OMAP2/3/4 dependency on the code.

NOTE: Patch series has been build tested for all possible
      combination of OMAP2, 3, 4 configurations.

History on Patch-series:
========================
Changes from V1:
   - Fixed comments from Tony
	- Config option name of SOC_HAS_SDRC changed to
	  SOC_HAS_OMAP2_SDRC
	- Config option name for SOC_HAS_DPLL_xxx flags to
	  SOC_HAS_OMAP3_DPLL_xxx.

Vaibhav Hiremath (4):
  ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add
    one entry
  ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c
  ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around
    __omap2_set_globals
  ARM: OMAP2+: CLEANUP: Add new config option for different DPLL
    features

 arch/arm/mach-omap2/Kconfig             |   42 +++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/clock.c             |   18 -------------
 arch/arm/mach-omap2/common.c            |    8 +-----
 arch/arm/mach-omap2/common.h            |    5 +++
 arch/arm/mach-omap2/dpll3xxx.c          |   14 ++++++++++
 arch/arm/plat-omap/Makefile             |    4 +--
 arch/arm/plat-omap/include/plat/clock.h |   14 ++++++++--
 7 files changed, 74 insertions(+), 31 deletions(-)

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 1/4] ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry
  2012-05-08 19:52 ` Vaibhav Hiremath
@ 2012-05-08 19:52   ` Vaibhav Hiremath
  -1 siblings, 0 replies; 38+ messages in thread
From: Vaibhav Hiremath @ 2012-05-08 19:52 UTC (permalink / raw)
  To: linux-omap; +Cc: tony, khilman, paul, linux-arm-kernel, Vaibhav Hiremath

All OMAP2PLUS based devices, builds omap-device.o target;
so just add one entry so that there is no need to patch this file
for any future OMAP2+ devices.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/plat-omap/Makefile |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index ed8605f..c5b5f05 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -10,9 +10,7 @@ obj-n :=
 obj-  :=

 # omap_device support (OMAP2+ only at the moment)
-obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
-obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
-obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
+obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_device.o

 obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
 obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o
--
1.7.0.4


^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH-V2 1/4] ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry
@ 2012-05-08 19:52   ` Vaibhav Hiremath
  0 siblings, 0 replies; 38+ messages in thread
From: Vaibhav Hiremath @ 2012-05-08 19:52 UTC (permalink / raw)
  To: linux-arm-kernel

All OMAP2PLUS based devices, builds omap-device.o target;
so just add one entry so that there is no need to patch this file
for any future OMAP2+ devices.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/plat-omap/Makefile |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index ed8605f..c5b5f05 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -10,9 +10,7 @@ obj-n :=
 obj-  :=

 # omap_device support (OMAP2+ only at the moment)
-obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
-obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
-obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
+obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_device.o

 obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
 obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o
--
1.7.0.4

^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH-V2 2/4] ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c
  2012-05-08 19:52 ` Vaibhav Hiremath
@ 2012-05-08 19:52   ` Vaibhav Hiremath
  -1 siblings, 0 replies; 38+ messages in thread
From: Vaibhav Hiremath @ 2012-05-08 19:52 UTC (permalink / raw)
  To: linux-omap; +Cc: tony, khilman, paul, linux-arm-kernel, Vaibhav Hiremath

In order to remove unnecessary idefs, move noncore and core
dpll ops to dpll3xxx.c file (where it should have been already).

The clkops (clkops_omap3_core_dpll_ops & clkops_omap3_noncore_dpll_ops)
is used in clock data files, and dependency is already handled by
Makefile rule.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/clock.c    |   18 ------------------
 arch/arm/mach-omap2/dpll3xxx.c |   14 ++++++++++++++
 2 files changed, 14 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index d9f4931..950a446 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -398,24 +398,6 @@ int omap2_clk_set_parent(struct clk *clk, struct clk *new_parent)
 	return omap2_clksel_set_parent(clk, new_parent);
 }
 
-/* OMAP3/4 non-CORE DPLL clkops */
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-
-const struct clkops clkops_omap3_noncore_dpll_ops = {
-	.enable		= omap3_noncore_dpll_enable,
-	.disable	= omap3_noncore_dpll_disable,
-	.allow_idle	= omap3_dpll_allow_idle,
-	.deny_idle	= omap3_dpll_deny_idle,
-};
-
-const struct clkops clkops_omap3_core_dpll_ops = {
-	.allow_idle	= omap3_dpll_allow_idle,
-	.deny_idle	= omap3_dpll_deny_idle,
-};
-
-#endif
-
 /*
  * OMAP2+ clock reset and init functions
  */
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index fc56745..d15f2a2 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -615,3 +615,17 @@ unsigned long omap3_clkoutx2_recalc(struct clk *clk)
 		rate = clk->parent->rate * 2;
 	return rate;
 }
+
+/* OMAP3/4 non-CORE DPLL clkops */
+
+const struct clkops clkops_omap3_noncore_dpll_ops = {
+	.enable		= omap3_noncore_dpll_enable,
+	.disable	= omap3_noncore_dpll_disable,
+	.allow_idle	= omap3_dpll_allow_idle,
+	.deny_idle	= omap3_dpll_deny_idle,
+};
+
+const struct clkops clkops_omap3_core_dpll_ops = {
+	.allow_idle	= omap3_dpll_allow_idle,
+	.deny_idle	= omap3_dpll_deny_idle,
+};
-- 
1.7.0.4


^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH-V2 2/4] ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c
@ 2012-05-08 19:52   ` Vaibhav Hiremath
  0 siblings, 0 replies; 38+ messages in thread
From: Vaibhav Hiremath @ 2012-05-08 19:52 UTC (permalink / raw)
  To: linux-arm-kernel

In order to remove unnecessary idefs, move noncore and core
dpll ops to dpll3xxx.c file (where it should have been already).

The clkops (clkops_omap3_core_dpll_ops & clkops_omap3_noncore_dpll_ops)
is used in clock data files, and dependency is already handled by
Makefile rule.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/clock.c    |   18 ------------------
 arch/arm/mach-omap2/dpll3xxx.c |   14 ++++++++++++++
 2 files changed, 14 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index d9f4931..950a446 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -398,24 +398,6 @@ int omap2_clk_set_parent(struct clk *clk, struct clk *new_parent)
 	return omap2_clksel_set_parent(clk, new_parent);
 }
 
-/* OMAP3/4 non-CORE DPLL clkops */
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-
-const struct clkops clkops_omap3_noncore_dpll_ops = {
-	.enable		= omap3_noncore_dpll_enable,
-	.disable	= omap3_noncore_dpll_disable,
-	.allow_idle	= omap3_dpll_allow_idle,
-	.deny_idle	= omap3_dpll_deny_idle,
-};
-
-const struct clkops clkops_omap3_core_dpll_ops = {
-	.allow_idle	= omap3_dpll_allow_idle,
-	.deny_idle	= omap3_dpll_deny_idle,
-};
-
-#endif
-
 /*
  * OMAP2+ clock reset and init functions
  */
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index fc56745..d15f2a2 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -615,3 +615,17 @@ unsigned long omap3_clkoutx2_recalc(struct clk *clk)
 		rate = clk->parent->rate * 2;
 	return rate;
 }
+
+/* OMAP3/4 non-CORE DPLL clkops */
+
+const struct clkops clkops_omap3_noncore_dpll_ops = {
+	.enable		= omap3_noncore_dpll_enable,
+	.disable	= omap3_noncore_dpll_disable,
+	.allow_idle	= omap3_dpll_allow_idle,
+	.deny_idle	= omap3_dpll_deny_idle,
+};
+
+const struct clkops clkops_omap3_core_dpll_ops = {
+	.allow_idle	= omap3_dpll_allow_idle,
+	.deny_idle	= omap3_dpll_deny_idle,
+};
-- 
1.7.0.4

^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
  2012-05-08 19:52 ` Vaibhav Hiremath
@ 2012-05-08 19:52   ` Vaibhav Hiremath
  -1 siblings, 0 replies; 38+ messages in thread
From: Vaibhav Hiremath @ 2012-05-08 19:52 UTC (permalink / raw)
  To: linux-omap; +Cc: tony, khilman, paul, linux-arm-kernel, Vaibhav Hiremath

The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions as in __omap2_set_globals() function
(except for sdrc).
This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
so that we can reuse same function across omap2/3/4...

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/Kconfig  |    8 ++++++++
 arch/arm/mach-omap2/common.c |    8 +-------
 arch/arm/mach-omap2/common.h |    5 +++++
 3 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0685dc8..a432f3e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -20,12 +20,16 @@ config ARCH_OMAP2PLUS_TYPICAL
 	help
 	  Compile a kernel suitable for booting most boards

+config SOC_HAS_OMAP2_SDRC
+	bool "OMAP2 SDRAM Controller support"
+
 config ARCH_OMAP2
 	bool "TI OMAP2"
 	depends on ARCH_OMAP2PLUS
 	default y
 	select CPU_V6
 	select MULTI_IRQ_HANDLER
+	select SOC_HAS_OMAP2_SDRC

 config ARCH_OMAP3
 	bool "TI OMAP3"
@@ -37,6 +41,7 @@ config ARCH_OMAP3
 	select PM_OPP if PM
 	select ARM_CPU_SUSPEND if PM
 	select MULTI_IRQ_HANDLER
+	select SOC_HAS_OMAP2_SDRC

 config ARCH_OMAP4
 	bool "TI OMAP4"
@@ -64,18 +69,21 @@ config SOC_OMAP2420
 	default y
 	select OMAP_DM_TIMER
 	select ARCH_OMAP_OTG
+	select SOC_HAS_OMAP2_SDRC

 config SOC_OMAP2430
 	bool "OMAP2430 support"
 	depends on ARCH_OMAP2
 	default y
 	select ARCH_OMAP_OTG
+	select SOC_HAS_OMAP2_SDRC

 config SOC_OMAP3430
 	bool "OMAP3430 support"
 	depends on ARCH_OMAP3
 	default y
 	select ARCH_OMAP_OTG
+	select SOC_HAS_OMAP2_SDRC

 config SOC_OMAPTI81XX
 	bool "TI81XX support"
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 1549c11..ad8626d 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -29,8 +29,6 @@

 /* Global address base setup code */

-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
-
 static void __init __omap2_set_globals(struct omap_globals *omap2_globals)
 {
 	omap2_set_globals_tap(omap2_globals);
@@ -39,8 +37,6 @@ static void __init __omap2_set_globals(struct omap_globals *omap2_globals)
 	omap2_set_globals_prcm(omap2_globals);
 }

-#endif
-
 #if defined(CONFIG_SOC_OMAP2420)

 static struct omap_globals omap242x_globals = {
@@ -170,9 +166,7 @@ static struct omap_globals omap4_globals = {

 void __init omap2_set_globals_443x(void)
 {
-	omap2_set_globals_tap(&omap4_globals);
-	omap2_set_globals_control(&omap4_globals);
-	omap2_set_globals_prcm(&omap4_globals);
+	__omap2_set_globals(&omap4_globals);
 }

 void __init omap4_map_io(void)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 0e95efc..87b132e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -122,7 +122,12 @@ void omap2_set_globals_am33xx(void);

 /* These get called from omap2_set_globals_xxxx(), do not call these */
 void omap2_set_globals_tap(struct omap_globals *);
+#if defined(CONFIG_SOC_HAS_OMAP2_SDRC)
 void omap2_set_globals_sdrc(struct omap_globals *);
+#else
+static inline void omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
+{ }
+#endif
 void omap2_set_globals_control(struct omap_globals *);
 void omap2_set_globals_prcm(struct omap_globals *);

--
1.7.0.4


^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
@ 2012-05-08 19:52   ` Vaibhav Hiremath
  0 siblings, 0 replies; 38+ messages in thread
From: Vaibhav Hiremath @ 2012-05-08 19:52 UTC (permalink / raw)
  To: linux-arm-kernel

The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions as in __omap2_set_globals() function
(except for sdrc).
This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
so that we can reuse same function across omap2/3/4...

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/Kconfig  |    8 ++++++++
 arch/arm/mach-omap2/common.c |    8 +-------
 arch/arm/mach-omap2/common.h |    5 +++++
 3 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0685dc8..a432f3e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -20,12 +20,16 @@ config ARCH_OMAP2PLUS_TYPICAL
 	help
 	  Compile a kernel suitable for booting most boards

+config SOC_HAS_OMAP2_SDRC
+	bool "OMAP2 SDRAM Controller support"
+
 config ARCH_OMAP2
 	bool "TI OMAP2"
 	depends on ARCH_OMAP2PLUS
 	default y
 	select CPU_V6
 	select MULTI_IRQ_HANDLER
+	select SOC_HAS_OMAP2_SDRC

 config ARCH_OMAP3
 	bool "TI OMAP3"
@@ -37,6 +41,7 @@ config ARCH_OMAP3
 	select PM_OPP if PM
 	select ARM_CPU_SUSPEND if PM
 	select MULTI_IRQ_HANDLER
+	select SOC_HAS_OMAP2_SDRC

 config ARCH_OMAP4
 	bool "TI OMAP4"
@@ -64,18 +69,21 @@ config SOC_OMAP2420
 	default y
 	select OMAP_DM_TIMER
 	select ARCH_OMAP_OTG
+	select SOC_HAS_OMAP2_SDRC

 config SOC_OMAP2430
 	bool "OMAP2430 support"
 	depends on ARCH_OMAP2
 	default y
 	select ARCH_OMAP_OTG
+	select SOC_HAS_OMAP2_SDRC

 config SOC_OMAP3430
 	bool "OMAP3430 support"
 	depends on ARCH_OMAP3
 	default y
 	select ARCH_OMAP_OTG
+	select SOC_HAS_OMAP2_SDRC

 config SOC_OMAPTI81XX
 	bool "TI81XX support"
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 1549c11..ad8626d 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -29,8 +29,6 @@

 /* Global address base setup code */

-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
-
 static void __init __omap2_set_globals(struct omap_globals *omap2_globals)
 {
 	omap2_set_globals_tap(omap2_globals);
@@ -39,8 +37,6 @@ static void __init __omap2_set_globals(struct omap_globals *omap2_globals)
 	omap2_set_globals_prcm(omap2_globals);
 }

-#endif
-
 #if defined(CONFIG_SOC_OMAP2420)

 static struct omap_globals omap242x_globals = {
@@ -170,9 +166,7 @@ static struct omap_globals omap4_globals = {

 void __init omap2_set_globals_443x(void)
 {
-	omap2_set_globals_tap(&omap4_globals);
-	omap2_set_globals_control(&omap4_globals);
-	omap2_set_globals_prcm(&omap4_globals);
+	__omap2_set_globals(&omap4_globals);
 }

 void __init omap4_map_io(void)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 0e95efc..87b132e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -122,7 +122,12 @@ void omap2_set_globals_am33xx(void);

 /* These get called from omap2_set_globals_xxxx(), do not call these */
 void omap2_set_globals_tap(struct omap_globals *);
+#if defined(CONFIG_SOC_HAS_OMAP2_SDRC)
 void omap2_set_globals_sdrc(struct omap_globals *);
+#else
+static inline void omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
+{ }
+#endif
 void omap2_set_globals_control(struct omap_globals *);
 void omap2_set_globals_prcm(struct omap_globals *);

--
1.7.0.4

^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
  2012-05-08 19:52 ` Vaibhav Hiremath
@ 2012-05-08 19:52   ` Vaibhav Hiremath
  -1 siblings, 0 replies; 38+ messages in thread
From: Vaibhav Hiremath @ 2012-05-08 19:52 UTC (permalink / raw)
  To: linux-omap; +Cc: tony, khilman, paul, linux-arm-kernel, Vaibhav Hiremath

This patch cleans up dpll_data structure, making structure
fields definition based on feature availability for given SoC,
managed using Kconfig rules.

SOC_HAS_OMAP3_DPLL_IDLE: idle state
SOC_HAS_OMAP3_DPLL_RECAL: recalibration capability
SOC_HAS_OMAP3_DPLL_DCO_SEL: dco selection
SOC_HAS_OMAP3_DPLL_SDDIV: sigma-delta div factor
SOC_HAS_OMAP3_DPLL_FREQSEL: frequency selection

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/Kconfig             |   34 +++++++++++++++++++++++++++++++
 arch/arm/plat-omap/include/plat/clock.h |   14 ++++++++++--
 2 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a432f3e..23999eb 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -20,6 +20,21 @@ config ARCH_OMAP2PLUS_TYPICAL
 	help
 	  Compile a kernel suitable for booting most boards

+config SOC_HAS_OMAP3_DPLL_IDLE
+	bool "OMAP3 DPLL idle state support"
+
+config SOC_HAS_OMAP3_DPLL_RECAL
+	bool "OMAP3 DPLL Recalibration support"
+
+config SOC_HAS_OMAP3_DPLL_DCO_SEL
+	bool "OMAP3 DPLL DCO (Digitally Controlled Oscilators) support"
+
+config SOC_HAS_OMAP3_DPLL_SDDIV
+	bool "OMAP3 DPLL Sigma-Delta Divider support"
+
+config SOC_HAS_OMAP3_DPLL_FREQSEL
+	bool "OMAP3 DPLL Freq Select support"
+
 config SOC_HAS_OMAP2_SDRC
 	bool "OMAP2 SDRAM Controller support"

@@ -42,6 +57,11 @@ config ARCH_OMAP3
 	select ARM_CPU_SUSPEND if PM
 	select MULTI_IRQ_HANDLER
 	select SOC_HAS_OMAP2_SDRC
+	select SOC_HAS_OMAP3_DPLL_IDLE
+	select SOC_HAS_OMAP3_DPLL_RECAL
+	select SOC_HAS_OMAP3_DPLL_DCO_SEL
+	select SOC_HAS_OMAP3_DPLL_SDDIV
+	select SOC_HAS_OMAP3_DPLL_FREQSEL

 config ARCH_OMAP4
 	bool "TI OMAP4"
@@ -59,6 +79,9 @@ config ARCH_OMAP4
 	select PM_OPP if PM
 	select USB_ARCH_HAS_EHCI if USB_SUPPORT
 	select ARM_CPU_SUSPEND if PM
+	select SOC_HAS_OMAP3_DPLL_IDLE
+	select SOC_HAS_OMAP3_DPLL_RECAL
+	select SOC_HAS_OMAP3_DPLL_SDDIV

 comment "OMAP Core Type"
 	depends on ARCH_OMAP2
@@ -84,16 +107,27 @@ config SOC_OMAP3430
 	default y
 	select ARCH_OMAP_OTG
 	select SOC_HAS_OMAP2_SDRC
+	select SOC_HAS_OMAP3_DPLL_IDLE
+	select SOC_HAS_OMAP3_DPLL_RECAL
+	select SOC_HAS_OMAP3_DPLL_DCO_SEL
+	select SOC_HAS_OMAP3_DPLL_SDDIV
+	select SOC_HAS_OMAP3_DPLL_FREQSEL

 config SOC_OMAPTI81XX
 	bool "TI81XX support"
 	depends on ARCH_OMAP3
 	default y
+	select SOC_HAS_OMAP3_DPLL_IDLE
+	select SOC_HAS_OMAP3_DPLL_RECAL
+	select SOC_HAS_OMAP3_DPLL_SDDIV

 config SOC_OMAPAM33XX
 	bool "AM33XX support"
 	depends on ARCH_OMAP3
 	default y
+	select SOC_HAS_OMAP3_DPLL_IDLE
+	select SOC_HAS_OMAP3_DPLL_RECAL
+	select SOC_HAS_OMAP3_DPLL_SDDIV

 config OMAP_PACKAGE_ZAF
        bool
diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..8d40de8 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,18 +156,26 @@ struct dpll_data {
 	u8			min_divider;
 	u16			max_divider;
 	u8			modes;
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_SOC_HAS_OMAP3_DPLL_IDLE)
 	void __iomem		*autoidle_reg;
 	void __iomem		*idlest_reg;
 	u32			autoidle_mask;
-	u32			freqsel_mask;
 	u32			idlest_mask;
+#endif
+#if defined(CONFIG_SOC_HAS_OMAP3_DPLL_FREQSEL)
+	u32			freqsel_mask;
+#endif
+#if defined(CONFIG_SOC_HAS_OMAP3_DPLL_DCO_SEL)
 	u32			dco_mask;
+#endif
+#if defined(CONFIG_SOC_HAS_OMAP3_DPLL_SDDIV)
 	u32			sddiv_mask;
+#endif
+#if defined(CONFIG_SOC_HAS_OMAP3_DPLL_RECAL)
 	u8			auto_recal_bit;
 	u8			recal_en_bit;
 	u8			recal_st_bit;
-#  endif
+#endif
 	u8			flags;
 };

--
1.7.0.4


^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
@ 2012-05-08 19:52   ` Vaibhav Hiremath
  0 siblings, 0 replies; 38+ messages in thread
From: Vaibhav Hiremath @ 2012-05-08 19:52 UTC (permalink / raw)
  To: linux-arm-kernel

This patch cleans up dpll_data structure, making structure
fields definition based on feature availability for given SoC,
managed using Kconfig rules.

SOC_HAS_OMAP3_DPLL_IDLE: idle state
SOC_HAS_OMAP3_DPLL_RECAL: recalibration capability
SOC_HAS_OMAP3_DPLL_DCO_SEL: dco selection
SOC_HAS_OMAP3_DPLL_SDDIV: sigma-delta div factor
SOC_HAS_OMAP3_DPLL_FREQSEL: frequency selection

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/Kconfig             |   34 +++++++++++++++++++++++++++++++
 arch/arm/plat-omap/include/plat/clock.h |   14 ++++++++++--
 2 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a432f3e..23999eb 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -20,6 +20,21 @@ config ARCH_OMAP2PLUS_TYPICAL
 	help
 	  Compile a kernel suitable for booting most boards

+config SOC_HAS_OMAP3_DPLL_IDLE
+	bool "OMAP3 DPLL idle state support"
+
+config SOC_HAS_OMAP3_DPLL_RECAL
+	bool "OMAP3 DPLL Recalibration support"
+
+config SOC_HAS_OMAP3_DPLL_DCO_SEL
+	bool "OMAP3 DPLL DCO (Digitally Controlled Oscilators) support"
+
+config SOC_HAS_OMAP3_DPLL_SDDIV
+	bool "OMAP3 DPLL Sigma-Delta Divider support"
+
+config SOC_HAS_OMAP3_DPLL_FREQSEL
+	bool "OMAP3 DPLL Freq Select support"
+
 config SOC_HAS_OMAP2_SDRC
 	bool "OMAP2 SDRAM Controller support"

@@ -42,6 +57,11 @@ config ARCH_OMAP3
 	select ARM_CPU_SUSPEND if PM
 	select MULTI_IRQ_HANDLER
 	select SOC_HAS_OMAP2_SDRC
+	select SOC_HAS_OMAP3_DPLL_IDLE
+	select SOC_HAS_OMAP3_DPLL_RECAL
+	select SOC_HAS_OMAP3_DPLL_DCO_SEL
+	select SOC_HAS_OMAP3_DPLL_SDDIV
+	select SOC_HAS_OMAP3_DPLL_FREQSEL

 config ARCH_OMAP4
 	bool "TI OMAP4"
@@ -59,6 +79,9 @@ config ARCH_OMAP4
 	select PM_OPP if PM
 	select USB_ARCH_HAS_EHCI if USB_SUPPORT
 	select ARM_CPU_SUSPEND if PM
+	select SOC_HAS_OMAP3_DPLL_IDLE
+	select SOC_HAS_OMAP3_DPLL_RECAL
+	select SOC_HAS_OMAP3_DPLL_SDDIV

 comment "OMAP Core Type"
 	depends on ARCH_OMAP2
@@ -84,16 +107,27 @@ config SOC_OMAP3430
 	default y
 	select ARCH_OMAP_OTG
 	select SOC_HAS_OMAP2_SDRC
+	select SOC_HAS_OMAP3_DPLL_IDLE
+	select SOC_HAS_OMAP3_DPLL_RECAL
+	select SOC_HAS_OMAP3_DPLL_DCO_SEL
+	select SOC_HAS_OMAP3_DPLL_SDDIV
+	select SOC_HAS_OMAP3_DPLL_FREQSEL

 config SOC_OMAPTI81XX
 	bool "TI81XX support"
 	depends on ARCH_OMAP3
 	default y
+	select SOC_HAS_OMAP3_DPLL_IDLE
+	select SOC_HAS_OMAP3_DPLL_RECAL
+	select SOC_HAS_OMAP3_DPLL_SDDIV

 config SOC_OMAPAM33XX
 	bool "AM33XX support"
 	depends on ARCH_OMAP3
 	default y
+	select SOC_HAS_OMAP3_DPLL_IDLE
+	select SOC_HAS_OMAP3_DPLL_RECAL
+	select SOC_HAS_OMAP3_DPLL_SDDIV

 config OMAP_PACKAGE_ZAF
        bool
diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..8d40de8 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,18 +156,26 @@ struct dpll_data {
 	u8			min_divider;
 	u16			max_divider;
 	u8			modes;
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_SOC_HAS_OMAP3_DPLL_IDLE)
 	void __iomem		*autoidle_reg;
 	void __iomem		*idlest_reg;
 	u32			autoidle_mask;
-	u32			freqsel_mask;
 	u32			idlest_mask;
+#endif
+#if defined(CONFIG_SOC_HAS_OMAP3_DPLL_FREQSEL)
+	u32			freqsel_mask;
+#endif
+#if defined(CONFIG_SOC_HAS_OMAP3_DPLL_DCO_SEL)
 	u32			dco_mask;
+#endif
+#if defined(CONFIG_SOC_HAS_OMAP3_DPLL_SDDIV)
 	u32			sddiv_mask;
+#endif
+#if defined(CONFIG_SOC_HAS_OMAP3_DPLL_RECAL)
 	u8			auto_recal_bit;
 	u8			recal_en_bit;
 	u8			recal_st_bit;
-#  endif
+#endif
 	u8			flags;
 };

--
1.7.0.4

^ permalink raw reply related	[flat|nested] 38+ messages in thread

* Re: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
  2012-05-08 19:52   ` Vaibhav Hiremath
@ 2012-05-08 22:38     ` Kevin Hilman
  -1 siblings, 0 replies; 38+ messages in thread
From: Kevin Hilman @ 2012-05-08 22:38 UTC (permalink / raw)
  To: Vaibhav Hiremath; +Cc: linux-omap, tony, paul, linux-arm-kernel

Vaibhav Hiremath <hvaibhav@ti.com> writes:

> The function __omap2_set_globals() can be common across all
> platforms/architectures, even in case of omap4, internally it
> calls same set of functions as in __omap2_set_globals() function
> (except for sdrc).

OK so far.

> This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
> so that we can reuse same function across omap2/3/4...

But what happens when a single kernel is built that has support for an
SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?

In that case this new SOC_HAS_OMAP2_SDRC will be set, and
set_globals_sdrc() will be called even for the SoCs without SDRC.

So, rather than add a new Kconfig option for this, I would rather see 
you using the existing runtime feature check for the SDRC: omap_has_sdrc()

Kevin

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
@ 2012-05-08 22:38     ` Kevin Hilman
  0 siblings, 0 replies; 38+ messages in thread
From: Kevin Hilman @ 2012-05-08 22:38 UTC (permalink / raw)
  To: linux-arm-kernel

Vaibhav Hiremath <hvaibhav@ti.com> writes:

> The function __omap2_set_globals() can be common across all
> platforms/architectures, even in case of omap4, internally it
> calls same set of functions as in __omap2_set_globals() function
> (except for sdrc).

OK so far.

> This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
> so that we can reuse same function across omap2/3/4...

But what happens when a single kernel is built that has support for an
SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?

In that case this new SOC_HAS_OMAP2_SDRC will be set, and
set_globals_sdrc() will be called even for the SoCs without SDRC.

So, rather than add a new Kconfig option for this, I would rather see 
you using the existing runtime feature check for the SDRC: omap_has_sdrc()

Kevin

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
  2012-05-08 19:52   ` Vaibhav Hiremath
@ 2012-05-08 22:50     ` Kevin Hilman
  -1 siblings, 0 replies; 38+ messages in thread
From: Kevin Hilman @ 2012-05-08 22:50 UTC (permalink / raw)
  To: Vaibhav Hiremath; +Cc: linux-omap, tony, paul, linux-arm-kernel

Vaibhav Hiremath <hvaibhav@ti.com> writes:

> This patch cleans up dpll_data structure, making structure
> fields definition based on feature availability for given SoC,
> managed using Kconfig rules.
>
> SOC_HAS_OMAP3_DPLL_IDLE: idle state
> SOC_HAS_OMAP3_DPLL_RECAL: recalibration capability
> SOC_HAS_OMAP3_DPLL_DCO_SEL: dco selection
> SOC_HAS_OMAP3_DPLL_SDDIV: sigma-delta div factor
> SOC_HAS_OMAP3_DPLL_FREQSEL: frequency selection
>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>

Paul is the one to make the call here, but personally I'd much prefer to
just see the existing ifdefs go away[1] instead of adding a bunch of new
ones.  

Yes, doing so would add a few fields to a struct that may be unused, but
IMO, the improvement in readabilitly and maintainability is improved.

Note that the users of these fields are not changed and are still based
on Kconfig/Makefile values as before (e.g. CONFIG_ARCH_OMAP3), so to me
this creates another layer of obfuscation.

Kevin


[1]
diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..656b986 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,7 +156,6 @@ struct dpll_data {
 	u8			min_divider;
 	u16			max_divider;
 	u8			modes;
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
 	void __iomem		*autoidle_reg;
 	void __iomem		*idlest_reg;
 	u32			autoidle_mask;
@@ -167,7 +166,6 @@ struct dpll_data {
 	u8			auto_recal_bit;
 	u8			recal_en_bit;
 	u8			recal_st_bit;
-#  endif
 	u8			flags;
 };
 

^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
@ 2012-05-08 22:50     ` Kevin Hilman
  0 siblings, 0 replies; 38+ messages in thread
From: Kevin Hilman @ 2012-05-08 22:50 UTC (permalink / raw)
  To: linux-arm-kernel

Vaibhav Hiremath <hvaibhav@ti.com> writes:

> This patch cleans up dpll_data structure, making structure
> fields definition based on feature availability for given SoC,
> managed using Kconfig rules.
>
> SOC_HAS_OMAP3_DPLL_IDLE: idle state
> SOC_HAS_OMAP3_DPLL_RECAL: recalibration capability
> SOC_HAS_OMAP3_DPLL_DCO_SEL: dco selection
> SOC_HAS_OMAP3_DPLL_SDDIV: sigma-delta div factor
> SOC_HAS_OMAP3_DPLL_FREQSEL: frequency selection
>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>

Paul is the one to make the call here, but personally I'd much prefer to
just see the existing ifdefs go away[1] instead of adding a bunch of new
ones.  

Yes, doing so would add a few fields to a struct that may be unused, but
IMO, the improvement in readabilitly and maintainability is improved.

Note that the users of these fields are not changed and are still based
on Kconfig/Makefile values as before (e.g. CONFIG_ARCH_OMAP3), so to me
this creates another layer of obfuscation.

Kevin


[1]
diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..656b986 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,7 +156,6 @@ struct dpll_data {
 	u8			min_divider;
 	u16			max_divider;
 	u8			modes;
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
 	void __iomem		*autoidle_reg;
 	void __iomem		*idlest_reg;
 	u32			autoidle_mask;
@@ -167,7 +166,6 @@ struct dpll_data {
 	u8			auto_recal_bit;
 	u8			recal_en_bit;
 	u8			recal_st_bit;
-#  endif
 	u8			flags;
 };
 

^ permalink raw reply related	[flat|nested] 38+ messages in thread

* RE: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
  2012-05-08 22:38     ` Kevin Hilman
@ 2012-05-09  8:59       ` Hiremath, Vaibhav
  -1 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-09  8:59 UTC (permalink / raw)
  To: Hilman, Kevin; +Cc: linux-omap, tony, paul, linux-arm-kernel

On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
> Vaibhav Hiremath <hvaibhav@ti.com> writes:
> 
> > The function __omap2_set_globals() can be common across all
> > platforms/architectures, even in case of omap4, internally it
> > calls same set of functions as in __omap2_set_globals() function
> > (except for sdrc).
> 
> OK so far.
> 
> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
> > so that we can reuse same function across omap2/3/4...
> 
> But what happens when a single kernel is built that has support for an
> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
> 

As such Nothing...I looking into this direction while implementing.

In that case, sdrc.c file will be compiled in and execution will jump to
omap2_set_globals_sdrc(). But inside this function, we are already checking 
whether the omap2_globals->sdrc and omap2_globals->sms for NULL and then use 
it.

And function omap2_sdrc_init() is also depends on machine, so in case of
Am33xx, it won't get into sdrc execution at all. And in case of omap4, it 
will.

> In that case this new SOC_HAS_OMAP2_SDRC will be set, and
> set_globals_sdrc() will be called even for the SoCs without SDRC.
> 
> So, rather than add a new Kconfig option for this, I would rather see 
> you using the existing runtime feature check for the SDRC: omap_has_sdrc()
> 

There is NO difference between runtime feature check Vs this patch, refer to the function implementation,

void __init omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
{
	if (omap2_globals->sdrc)
		omap2_sdrc_base = omap2_globals->sdrc;
	if (omap2_globals->sms)
		omap2_sms_base = omap2_globals->sms;
}

The initialization happens after checking for NULL, so even if you execute it or not, the variable are set to NULL in case of am33xx.

So I don't find any difference between runtime and this patch.

Thanks,
Vaibhav

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
@ 2012-05-09  8:59       ` Hiremath, Vaibhav
  0 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-09  8:59 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
> Vaibhav Hiremath <hvaibhav@ti.com> writes:
> 
> > The function __omap2_set_globals() can be common across all
> > platforms/architectures, even in case of omap4, internally it
> > calls same set of functions as in __omap2_set_globals() function
> > (except for sdrc).
> 
> OK so far.
> 
> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
> > so that we can reuse same function across omap2/3/4...
> 
> But what happens when a single kernel is built that has support for an
> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
> 

As such Nothing...I looking into this direction while implementing.

In that case, sdrc.c file will be compiled in and execution will jump to
omap2_set_globals_sdrc(). But inside this function, we are already checking 
whether the omap2_globals->sdrc and omap2_globals->sms for NULL and then use 
it.

And function omap2_sdrc_init() is also depends on machine, so in case of
Am33xx, it won't get into sdrc execution at all. And in case of omap4, it 
will.

> In that case this new SOC_HAS_OMAP2_SDRC will be set, and
> set_globals_sdrc() will be called even for the SoCs without SDRC.
> 
> So, rather than add a new Kconfig option for this, I would rather see 
> you using the existing runtime feature check for the SDRC: omap_has_sdrc()
> 

There is NO difference between runtime feature check Vs this patch, refer to the function implementation,

void __init omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
{
	if (omap2_globals->sdrc)
		omap2_sdrc_base = omap2_globals->sdrc;
	if (omap2_globals->sms)
		omap2_sms_base = omap2_globals->sms;
}

The initialization happens after checking for NULL, so even if you execute it or not, the variable are set to NULL in case of am33xx.

So I don't find any difference between runtime and this patch.

Thanks,
Vaibhav

^ permalink raw reply	[flat|nested] 38+ messages in thread

* RE: [PATCH-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
  2012-05-08 22:50     ` Kevin Hilman
@ 2012-05-09  9:06       ` Hiremath, Vaibhav
  -1 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-09  9:06 UTC (permalink / raw)
  To: Hilman, Kevin; +Cc: linux-omap, tony, paul, linux-arm-kernel

On Wed, May 09, 2012 at 04:20:06, Hilman, Kevin wrote:
> Vaibhav Hiremath <hvaibhav@ti.com> writes:
> 
> > This patch cleans up dpll_data structure, making structure
> > fields definition based on feature availability for given SoC,
> > managed using Kconfig rules.
> >
> > SOC_HAS_OMAP3_DPLL_IDLE: idle state
> > SOC_HAS_OMAP3_DPLL_RECAL: recalibration capability
> > SOC_HAS_OMAP3_DPLL_DCO_SEL: dco selection
> > SOC_HAS_OMAP3_DPLL_SDDIV: sigma-delta div factor
> > SOC_HAS_OMAP3_DPLL_FREQSEL: frequency selection
> >
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Kevin Hilman <khilman@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> 
> Paul is the one to make the call here, but personally I'd much prefer to
> just see the existing ifdefs go away[1] instead of adding a bunch of new
> ones.  
> 
> Yes, doing so would add a few fields to a struct that may be unused, but
> IMO, the improvement in readabilitly and maintainability is improved.
> 
> Note that the users of these fields are not changed and are still based
> on Kconfig/Makefile values as before (e.g. CONFIG_ARCH_OMAP3), so to me
> this creates another layer of obfuscation.
> 

This will bring in difference on omap2 alone build OR omap4, am33xx alone 
builds.
But again, how much it makes sense, and how much benefits we bring-in by 
adding config options for every bit-fields (like this) needs to be looked at.
And that's the reason, I submitted first version as a RFC.


> 
> [1]
> diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
> index d0ef57c..656b986 100644
> --- a/arch/arm/plat-omap/include/plat/clock.h
> +++ b/arch/arm/plat-omap/include/plat/clock.h
> @@ -156,7 +156,6 @@ struct dpll_data {
>  	u8			min_divider;
>  	u16			max_divider;
>  	u8			modes;
> -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
>  	void __iomem		*autoidle_reg;
>  	void __iomem		*idlest_reg;
>  	u32			autoidle_mask;
> @@ -167,7 +166,6 @@ struct dpll_data {
>  	u8			auto_recal_bit;
>  	u8			recal_en_bit;
>  	u8			recal_st_bit;
> -#  endif
>  	u8			flags;
>  };
>  

Honestly, I wanted to propose this first. 
I am OK, as long as we all agree on this.

Paul, can you conform on this?

Thanks,
Vaibhav

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
@ 2012-05-09  9:06       ` Hiremath, Vaibhav
  0 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-09  9:06 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 09, 2012 at 04:20:06, Hilman, Kevin wrote:
> Vaibhav Hiremath <hvaibhav@ti.com> writes:
> 
> > This patch cleans up dpll_data structure, making structure
> > fields definition based on feature availability for given SoC,
> > managed using Kconfig rules.
> >
> > SOC_HAS_OMAP3_DPLL_IDLE: idle state
> > SOC_HAS_OMAP3_DPLL_RECAL: recalibration capability
> > SOC_HAS_OMAP3_DPLL_DCO_SEL: dco selection
> > SOC_HAS_OMAP3_DPLL_SDDIV: sigma-delta div factor
> > SOC_HAS_OMAP3_DPLL_FREQSEL: frequency selection
> >
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Kevin Hilman <khilman@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> 
> Paul is the one to make the call here, but personally I'd much prefer to
> just see the existing ifdefs go away[1] instead of adding a bunch of new
> ones.  
> 
> Yes, doing so would add a few fields to a struct that may be unused, but
> IMO, the improvement in readabilitly and maintainability is improved.
> 
> Note that the users of these fields are not changed and are still based
> on Kconfig/Makefile values as before (e.g. CONFIG_ARCH_OMAP3), so to me
> this creates another layer of obfuscation.
> 

This will bring in difference on omap2 alone build OR omap4, am33xx alone 
builds.
But again, how much it makes sense, and how much benefits we bring-in by 
adding config options for every bit-fields (like this) needs to be looked at.
And that's the reason, I submitted first version as a RFC.


> 
> [1]
> diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
> index d0ef57c..656b986 100644
> --- a/arch/arm/plat-omap/include/plat/clock.h
> +++ b/arch/arm/plat-omap/include/plat/clock.h
> @@ -156,7 +156,6 @@ struct dpll_data {
>  	u8			min_divider;
>  	u16			max_divider;
>  	u8			modes;
> -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
>  	void __iomem		*autoidle_reg;
>  	void __iomem		*idlest_reg;
>  	u32			autoidle_mask;
> @@ -167,7 +166,6 @@ struct dpll_data {
>  	u8			auto_recal_bit;
>  	u8			recal_en_bit;
>  	u8			recal_st_bit;
> -#  endif
>  	u8			flags;
>  };
>  

Honestly, I wanted to propose this first. 
I am OK, as long as we all agree on this.

Paul, can you conform on this?

Thanks,
Vaibhav

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
  2012-05-09  8:59       ` Hiremath, Vaibhav
@ 2012-05-10 21:39         ` Kevin Hilman
  -1 siblings, 0 replies; 38+ messages in thread
From: Kevin Hilman @ 2012-05-10 21:39 UTC (permalink / raw)
  To: Hiremath, Vaibhav; +Cc: linux-omap, tony, paul, linux-arm-kernel

"Hiremath, Vaibhav" <hvaibhav@ti.com> writes:

> On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
>> Vaibhav Hiremath <hvaibhav@ti.com> writes:
>> 
>> > The function __omap2_set_globals() can be common across all
>> > platforms/architectures, even in case of omap4, internally it
>> > calls same set of functions as in __omap2_set_globals() function
>> > (except for sdrc).
>> 
>> OK so far.
>> 
>> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
>> > so that we can reuse same function across omap2/3/4...
>> 
>> But what happens when a single kernel is built that has support for an
>> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
>> 
>
> As such Nothing...I looking into this direction while implementing.
>
> In that case, sdrc.c file will be compiled in and execution will jump to
> omap2_set_globals_sdrc(). But inside this function, we are already checking 
> whether the omap2_globals->sdrc and omap2_globals->sms for NULL and then use 
> it.
>
> And function omap2_sdrc_init() is also depends on machine, so in case of
> Am33xx, it won't get into sdrc execution at all. And in case of omap4, it 
> will.

Then why bother with the #ifdef at all?

If it already safe to call on all SoCs, just get rid of the #ifdef all
together.

>> In that case this new SOC_HAS_OMAP2_SDRC will be set, and
>> set_globals_sdrc() will be called even for the SoCs without SDRC.
>> 
>> So, rather than add a new Kconfig option for this, I would rather see 
>> you using the existing runtime feature check for the SDRC: omap_has_sdrc()
>> 
>
> There is NO difference between runtime feature check Vs this patch, refer to the function implementation,
>
> void __init omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
> {
> 	if (omap2_globals->sdrc)
> 		omap2_sdrc_base = omap2_globals->sdrc;
> 	if (omap2_globals->sms)
> 		omap2_sms_base = omap2_globals->sms;
> }
>
> The initialization happens after checking for NULL, so even if you execute it or not, the variable are set to NULL in case of am33xx.
>
> So I don't find any difference between runtime and this patch.

Except readability.

Kevin

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
@ 2012-05-10 21:39         ` Kevin Hilman
  0 siblings, 0 replies; 38+ messages in thread
From: Kevin Hilman @ 2012-05-10 21:39 UTC (permalink / raw)
  To: linux-arm-kernel

"Hiremath, Vaibhav" <hvaibhav@ti.com> writes:

> On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
>> Vaibhav Hiremath <hvaibhav@ti.com> writes:
>> 
>> > The function __omap2_set_globals() can be common across all
>> > platforms/architectures, even in case of omap4, internally it
>> > calls same set of functions as in __omap2_set_globals() function
>> > (except for sdrc).
>> 
>> OK so far.
>> 
>> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
>> > so that we can reuse same function across omap2/3/4...
>> 
>> But what happens when a single kernel is built that has support for an
>> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
>> 
>
> As such Nothing...I looking into this direction while implementing.
>
> In that case, sdrc.c file will be compiled in and execution will jump to
> omap2_set_globals_sdrc(). But inside this function, we are already checking 
> whether the omap2_globals->sdrc and omap2_globals->sms for NULL and then use 
> it.
>
> And function omap2_sdrc_init() is also depends on machine, so in case of
> Am33xx, it won't get into sdrc execution at all. And in case of omap4, it 
> will.

Then why bother with the #ifdef at all?

If it already safe to call on all SoCs, just get rid of the #ifdef all
together.

>> In that case this new SOC_HAS_OMAP2_SDRC will be set, and
>> set_globals_sdrc() will be called even for the SoCs without SDRC.
>> 
>> So, rather than add a new Kconfig option for this, I would rather see 
>> you using the existing runtime feature check for the SDRC: omap_has_sdrc()
>> 
>
> There is NO difference between runtime feature check Vs this patch, refer to the function implementation,
>
> void __init omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
> {
> 	if (omap2_globals->sdrc)
> 		omap2_sdrc_base = omap2_globals->sdrc;
> 	if (omap2_globals->sms)
> 		omap2_sms_base = omap2_globals->sms;
> }
>
> The initialization happens after checking for NULL, so even if you execute it or not, the variable are set to NULL in case of am33xx.
>
> So I don't find any difference between runtime and this patch.

Except readability.

Kevin

^ permalink raw reply	[flat|nested] 38+ messages in thread

* RE: [PATCH-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
  2012-05-09  9:06       ` Hiremath, Vaibhav
@ 2012-05-10 22:35         ` Paul Walmsley
  -1 siblings, 0 replies; 38+ messages in thread
From: Paul Walmsley @ 2012-05-10 22:35 UTC (permalink / raw)
  To: Hiremath, Vaibhav; +Cc: Hilman, Kevin, linux-omap, tony, linux-arm-kernel

On Wed, 9 May 2012, Hiremath, Vaibhav wrote:

> On Wed, May 09, 2012 at 04:20:06, Hilman, Kevin wrote:
> 
> > 
> > [1]
> > diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
> > index d0ef57c..656b986 100644
> > --- a/arch/arm/plat-omap/include/plat/clock.h
> > +++ b/arch/arm/plat-omap/include/plat/clock.h
> > @@ -156,7 +156,6 @@ struct dpll_data {
> >  	u8			min_divider;
> >  	u16			max_divider;
> >  	u8			modes;
> > -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> >  	void __iomem		*autoidle_reg;
> >  	void __iomem		*idlest_reg;
> >  	u32			autoidle_mask;
> > @@ -167,7 +166,6 @@ struct dpll_data {
> >  	u8			auto_recal_bit;
> >  	u8			recal_en_bit;
> >  	u8			recal_st_bit;
> > -#  endif
> >  	u8			flags;
> >  };
> >  
> 
> Honestly, I wanted to propose this first. 
> I am OK, as long as we all agree on this.
> 
> Paul, can you conform on this?

Yes that's a better approach then defining CONFIG_* options for all the 
bitfields, so please go ahead and just send a patch to drop that #ifdef 
and I'll ack it.


- Paul

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
@ 2012-05-10 22:35         ` Paul Walmsley
  0 siblings, 0 replies; 38+ messages in thread
From: Paul Walmsley @ 2012-05-10 22:35 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, 9 May 2012, Hiremath, Vaibhav wrote:

> On Wed, May 09, 2012 at 04:20:06, Hilman, Kevin wrote:
> 
> > 
> > [1]
> > diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
> > index d0ef57c..656b986 100644
> > --- a/arch/arm/plat-omap/include/plat/clock.h
> > +++ b/arch/arm/plat-omap/include/plat/clock.h
> > @@ -156,7 +156,6 @@ struct dpll_data {
> >  	u8			min_divider;
> >  	u16			max_divider;
> >  	u8			modes;
> > -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> >  	void __iomem		*autoidle_reg;
> >  	void __iomem		*idlest_reg;
> >  	u32			autoidle_mask;
> > @@ -167,7 +166,6 @@ struct dpll_data {
> >  	u8			auto_recal_bit;
> >  	u8			recal_en_bit;
> >  	u8			recal_st_bit;
> > -#  endif
> >  	u8			flags;
> >  };
> >  
> 
> Honestly, I wanted to propose this first. 
> I am OK, as long as we all agree on this.
> 
> Paul, can you conform on this?

Yes that's a better approach then defining CONFIG_* options for all the 
bitfields, so please go ahead and just send a patch to drop that #ifdef 
and I'll ack it.


- Paul

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH-V2 2/4] ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c
  2012-05-08 19:52   ` Vaibhav Hiremath
@ 2012-05-10 23:02     ` Paul Walmsley
  -1 siblings, 0 replies; 38+ messages in thread
From: Paul Walmsley @ 2012-05-10 23:02 UTC (permalink / raw)
  To: Vaibhav Hiremath; +Cc: linux-omap, tony, khilman, linux-arm-kernel

On Wed, 9 May 2012, Vaibhav Hiremath wrote:

> In order to remove unnecessary idefs, move noncore and core
> dpll ops to dpll3xxx.c file (where it should have been already).
> 
> The clkops (clkops_omap3_core_dpll_ops & clkops_omap3_noncore_dpll_ops)
> is used in clock data files, and dependency is already handled by
> Makefile rule.
> 
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>

This is probably okay.

Acked-by: Paul Walmsley <paul@pwsan.com>


- Paul

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 2/4] ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c
@ 2012-05-10 23:02     ` Paul Walmsley
  0 siblings, 0 replies; 38+ messages in thread
From: Paul Walmsley @ 2012-05-10 23:02 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, 9 May 2012, Vaibhav Hiremath wrote:

> In order to remove unnecessary idefs, move noncore and core
> dpll ops to dpll3xxx.c file (where it should have been already).
> 
> The clkops (clkops_omap3_core_dpll_ops & clkops_omap3_noncore_dpll_ops)
> is used in clock data files, and dependency is already handled by
> Makefile rule.
> 
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>

This is probably okay.

Acked-by: Paul Walmsley <paul@pwsan.com>


- Paul

^ permalink raw reply	[flat|nested] 38+ messages in thread

* RE: [PATCH-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
  2012-05-10 22:35         ` Paul Walmsley
@ 2012-05-11  5:30           ` Hiremath, Vaibhav
  -1 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-11  5:30 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: Hilman, Kevin, linux-omap, tony, linux-arm-kernel

On Fri, May 11, 2012 at 04:05:56, Paul Walmsley wrote:
> On Wed, 9 May 2012, Hiremath, Vaibhav wrote:
> 
> > On Wed, May 09, 2012 at 04:20:06, Hilman, Kevin wrote:
> > 
> > > 
> > > [1]
> > > diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
> > > index d0ef57c..656b986 100644
> > > --- a/arch/arm/plat-omap/include/plat/clock.h
> > > +++ b/arch/arm/plat-omap/include/plat/clock.h
> > > @@ -156,7 +156,6 @@ struct dpll_data {
> > >  	u8			min_divider;
> > >  	u16			max_divider;
> > >  	u8			modes;
> > > -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> > >  	void __iomem		*autoidle_reg;
> > >  	void __iomem		*idlest_reg;
> > >  	u32			autoidle_mask;
> > > @@ -167,7 +166,6 @@ struct dpll_data {
> > >  	u8			auto_recal_bit;
> > >  	u8			recal_en_bit;
> > >  	u8			recal_st_bit;
> > > -#  endif
> > >  	u8			flags;
> > >  };
> > >  
> > 
> > Honestly, I wanted to propose this first. 
> > I am OK, as long as we all agree on this.
> > 
> > Paul, can you conform on this?
> 
> Yes that's a better approach then defining CONFIG_* options for all the 
> bitfields, so please go ahead and just send a patch to drop that #ifdef 
> and I'll ack it.
> 
> 

Thanks Paul,

I will submit it shortly.

Thanks,
Vaibhav

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
@ 2012-05-11  5:30           ` Hiremath, Vaibhav
  0 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-11  5:30 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, May 11, 2012 at 04:05:56, Paul Walmsley wrote:
> On Wed, 9 May 2012, Hiremath, Vaibhav wrote:
> 
> > On Wed, May 09, 2012 at 04:20:06, Hilman, Kevin wrote:
> > 
> > > 
> > > [1]
> > > diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
> > > index d0ef57c..656b986 100644
> > > --- a/arch/arm/plat-omap/include/plat/clock.h
> > > +++ b/arch/arm/plat-omap/include/plat/clock.h
> > > @@ -156,7 +156,6 @@ struct dpll_data {
> > >  	u8			min_divider;
> > >  	u16			max_divider;
> > >  	u8			modes;
> > > -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> > >  	void __iomem		*autoidle_reg;
> > >  	void __iomem		*idlest_reg;
> > >  	u32			autoidle_mask;
> > > @@ -167,7 +166,6 @@ struct dpll_data {
> > >  	u8			auto_recal_bit;
> > >  	u8			recal_en_bit;
> > >  	u8			recal_st_bit;
> > > -#  endif
> > >  	u8			flags;
> > >  };
> > >  
> > 
> > Honestly, I wanted to propose this first. 
> > I am OK, as long as we all agree on this.
> > 
> > Paul, can you conform on this?
> 
> Yes that's a better approach then defining CONFIG_* options for all the 
> bitfields, so please go ahead and just send a patch to drop that #ifdef 
> and I'll ack it.
> 
> 

Thanks Paul,

I will submit it shortly.

Thanks,
Vaibhav

^ permalink raw reply	[flat|nested] 38+ messages in thread

* RE: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
  2012-05-10 21:39         ` Kevin Hilman
@ 2012-05-11  6:09           ` Hiremath, Vaibhav
  -1 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-11  6:09 UTC (permalink / raw)
  To: Hilman, Kevin; +Cc: linux-omap, tony, paul, linux-arm-kernel

On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote:
> "Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
> 
> > On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
> >> Vaibhav Hiremath <hvaibhav@ti.com> writes:
> >> 
> >> > The function __omap2_set_globals() can be common across all
> >> > platforms/architectures, even in case of omap4, internally it
> >> > calls same set of functions as in __omap2_set_globals() function
> >> > (except for sdrc).
> >> 
> >> OK so far.
> >> 
> >> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
> >> > so that we can reuse same function across omap2/3/4...
> >> 
> >> But what happens when a single kernel is built that has support for an
> >> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
> >> 
> >
> > As such Nothing...I looking into this direction while implementing.
> >
> > In that case, sdrc.c file will be compiled in and execution will jump to
> > omap2_set_globals_sdrc(). But inside this function, we are already checking 
> > whether the omap2_globals->sdrc and omap2_globals->sms for NULL and then use 
> > it.
> >
> > And function omap2_sdrc_init() is also depends on machine, so in case of
> > Am33xx, it won't get into sdrc execution at all. And in case of omap4, it 
> > will.
> 
> Then why bother with the #ifdef at all?
> 
> If it already safe to call on all SoCs, just get rid of the #ifdef all
> together.
> 

Kevin,

sdrc.o target gets built only as "omap-2-3-common", this will not get built 
for omap4, am33xx, ti81xx, etc...
So in order to avoid build break, you have to have some mechanism, and that's where we need to create config option dependent on platform.

Another better way of handling this is adding __weak function.

What's your opinion on this?

Thanks,
Vaibhav


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
@ 2012-05-11  6:09           ` Hiremath, Vaibhav
  0 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-11  6:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote:
> "Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
> 
> > On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
> >> Vaibhav Hiremath <hvaibhav@ti.com> writes:
> >> 
> >> > The function __omap2_set_globals() can be common across all
> >> > platforms/architectures, even in case of omap4, internally it
> >> > calls same set of functions as in __omap2_set_globals() function
> >> > (except for sdrc).
> >> 
> >> OK so far.
> >> 
> >> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
> >> > so that we can reuse same function across omap2/3/4...
> >> 
> >> But what happens when a single kernel is built that has support for an
> >> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
> >> 
> >
> > As such Nothing...I looking into this direction while implementing.
> >
> > In that case, sdrc.c file will be compiled in and execution will jump to
> > omap2_set_globals_sdrc(). But inside this function, we are already checking 
> > whether the omap2_globals->sdrc and omap2_globals->sms for NULL and then use 
> > it.
> >
> > And function omap2_sdrc_init() is also depends on machine, so in case of
> > Am33xx, it won't get into sdrc execution at all. And in case of omap4, it 
> > will.
> 
> Then why bother with the #ifdef at all?
> 
> If it already safe to call on all SoCs, just get rid of the #ifdef all
> together.
> 

Kevin,

sdrc.o target gets built only as "omap-2-3-common", this will not get built 
for omap4, am33xx, ti81xx, etc...
So in order to avoid build break, you have to have some mechanism, and that's where we need to create config option dependent on platform.

Another better way of handling this is adding __weak function.

What's your opinion on this?

Thanks,
Vaibhav

^ permalink raw reply	[flat|nested] 38+ messages in thread

* RE: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
  2012-05-11  6:09           ` Hiremath, Vaibhav
@ 2012-05-11  6:37             ` Sricharan R
  -1 siblings, 0 replies; 38+ messages in thread
From: Sricharan R @ 2012-05-11  6:37 UTC (permalink / raw)
  To: Vaibhav Hiremath, Kevin Hilman; +Cc: linux-omap, tony, paul, linux-arm-kernel

Vaibhav,

> > >> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle
> sdrc,
> > >> > so that we can reuse same function across omap2/3/4...
> > >>
> > >> But what happens when a single kernel is built that has support
> for an
> > >> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
> > >>
> > >
> > > As such Nothing...I looking into this direction while implementing.
> > >
> > > In that case, sdrc.c file will be compiled in and execution will
> jump to
> > > omap2_set_globals_sdrc(). But inside this function, we are already
> checking
> > > whether the omap2_globals->sdrc and omap2_globals->sms for NULL and
> then use
> > > it.
> > >
> > > And function omap2_sdrc_init() is also depends on machine, so in
> case of
> > > Am33xx, it won't get into sdrc execution at all. And in case of
> omap4, it
> > > will.
> >
> > Then why bother with the #ifdef at all?
> >
> > If it already safe to call on all SoCs, just get rid of the #ifdef
> all
> > together.
> >
>
> Kevin,
>
> sdrc.o target gets built only as "omap-2-3-common", this will not get
> built
> for omap4, am33xx, ti81xx, etc...
> So in order to avoid build break, you have to have some mechanism, and
> that's where we need to create config option dependent on platform.
>
> Another better way of handling this is adding __weak function.
>
> What's your opinion on this?
>
  Then how about just allowing to compile for all omap2/3/4 ?

Thanks,
 Sricharan

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
@ 2012-05-11  6:37             ` Sricharan R
  0 siblings, 0 replies; 38+ messages in thread
From: Sricharan R @ 2012-05-11  6:37 UTC (permalink / raw)
  To: linux-arm-kernel

Vaibhav,

> > >> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle
> sdrc,
> > >> > so that we can reuse same function across omap2/3/4...
> > >>
> > >> But what happens when a single kernel is built that has support
> for an
> > >> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
> > >>
> > >
> > > As such Nothing...I looking into this direction while implementing.
> > >
> > > In that case, sdrc.c file will be compiled in and execution will
> jump to
> > > omap2_set_globals_sdrc(). But inside this function, we are already
> checking
> > > whether the omap2_globals->sdrc and omap2_globals->sms for NULL and
> then use
> > > it.
> > >
> > > And function omap2_sdrc_init() is also depends on machine, so in
> case of
> > > Am33xx, it won't get into sdrc execution at all. And in case of
> omap4, it
> > > will.
> >
> > Then why bother with the #ifdef at all?
> >
> > If it already safe to call on all SoCs, just get rid of the #ifdef
> all
> > together.
> >
>
> Kevin,
>
> sdrc.o target gets built only as "omap-2-3-common", this will not get
> built
> for omap4, am33xx, ti81xx, etc...
> So in order to avoid build break, you have to have some mechanism, and
> that's where we need to create config option dependent on platform.
>
> Another better way of handling this is adding __weak function.
>
> What's your opinion on this?
>
  Then how about just allowing to compile for all omap2/3/4 ?

Thanks,
 Sricharan

^ permalink raw reply	[flat|nested] 38+ messages in thread

* RE: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
  2012-05-11  6:37             ` Sricharan R
@ 2012-05-11  6:43               ` Hiremath, Vaibhav
  -1 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-11  6:43 UTC (permalink / raw)
  To: R, Sricharan, Hilman, Kevin; +Cc: linux-omap, tony, paul, linux-arm-kernel

On Fri, May 11, 2012 at 12:07:59, R, Sricharan wrote:
> Vaibhav,
> 
> > > >> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle
> > sdrc,
> > > >> > so that we can reuse same function across omap2/3/4...
> > > >>
> > > >> But what happens when a single kernel is built that has support
> > for an
> > > >> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
> > > >>
> > > >
> > > > As such Nothing...I looking into this direction while implementing.
> > > >
> > > > In that case, sdrc.c file will be compiled in and execution will
> > jump to
> > > > omap2_set_globals_sdrc(). But inside this function, we are already
> > checking
> > > > whether the omap2_globals->sdrc and omap2_globals->sms for NULL and
> > then use
> > > > it.
> > > >
> > > > And function omap2_sdrc_init() is also depends on machine, so in
> > case of
> > > > Am33xx, it won't get into sdrc execution at all. And in case of
> > omap4, it
> > > > will.
> > >
> > > Then why bother with the #ifdef at all?
> > >
> > > If it already safe to call on all SoCs, just get rid of the #ifdef
> > all
> > > together.
> > >
> >
> > Kevin,
> >
> > sdrc.o target gets built only as "omap-2-3-common", this will not get
> > built
> > for omap4, am33xx, ti81xx, etc...
> > So in order to avoid build break, you have to have some mechanism, and
> > that's where we need to create config option dependent on platform.
> >
> > Another better way of handling this is adding __weak function.
> >
> > What's your opinion on this?
> >
>   Then how about just allowing to compile for all omap2/3/4 ?
> 

I wouldn't recommend that. 
Also, now we have almost all the devices coming in with EMIF (no sdrc).

Thanks,
Vaibhav


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
@ 2012-05-11  6:43               ` Hiremath, Vaibhav
  0 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-11  6:43 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, May 11, 2012 at 12:07:59, R, Sricharan wrote:
> Vaibhav,
> 
> > > >> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle
> > sdrc,
> > > >> > so that we can reuse same function across omap2/3/4...
> > > >>
> > > >> But what happens when a single kernel is built that has support
> > for an
> > > >> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
> > > >>
> > > >
> > > > As such Nothing...I looking into this direction while implementing.
> > > >
> > > > In that case, sdrc.c file will be compiled in and execution will
> > jump to
> > > > omap2_set_globals_sdrc(). But inside this function, we are already
> > checking
> > > > whether the omap2_globals->sdrc and omap2_globals->sms for NULL and
> > then use
> > > > it.
> > > >
> > > > And function omap2_sdrc_init() is also depends on machine, so in
> > case of
> > > > Am33xx, it won't get into sdrc execution at all. And in case of
> > omap4, it
> > > > will.
> > >
> > > Then why bother with the #ifdef at all?
> > >
> > > If it already safe to call on all SoCs, just get rid of the #ifdef
> > all
> > > together.
> > >
> >
> > Kevin,
> >
> > sdrc.o target gets built only as "omap-2-3-common", this will not get
> > built
> > for omap4, am33xx, ti81xx, etc...
> > So in order to avoid build break, you have to have some mechanism, and
> > that's where we need to create config option dependent on platform.
> >
> > Another better way of handling this is adding __weak function.
> >
> > What's your opinion on this?
> >
>   Then how about just allowing to compile for all omap2/3/4 ?
> 

I wouldn't recommend that. 
Also, now we have almost all the devices coming in with EMIF (no sdrc).

Thanks,
Vaibhav

^ permalink raw reply	[flat|nested] 38+ messages in thread

* RE: [PATCH-V2 2/4] ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c
  2012-05-10 23:02     ` Paul Walmsley
@ 2012-05-11  7:01       ` Hiremath, Vaibhav
  -1 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-11  7:01 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: linux-omap, tony, Hilman, Kevin, linux-arm-kernel

On Fri, May 11, 2012 at 04:32:11, Paul Walmsley wrote:
> On Wed, 9 May 2012, Vaibhav Hiremath wrote:
> 
> > In order to remove unnecessary idefs, move noncore and core
> > dpll ops to dpll3xxx.c file (where it should have been already).
> > 
> > The clkops (clkops_omap3_core_dpll_ops & clkops_omap3_noncore_dpll_ops)
> > is used in clock data files, and dependency is already handled by
> > Makefile rule.
> > 
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Kevin Hilman <khilman@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> 
> This is probably okay.
> 
> Acked-by: Paul Walmsley <paul@pwsan.com>
> 
> 

Thanks Paul,

Thanks,
Vaibhav

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 2/4] ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c
@ 2012-05-11  7:01       ` Hiremath, Vaibhav
  0 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-11  7:01 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, May 11, 2012 at 04:32:11, Paul Walmsley wrote:
> On Wed, 9 May 2012, Vaibhav Hiremath wrote:
> 
> > In order to remove unnecessary idefs, move noncore and core
> > dpll ops to dpll3xxx.c file (where it should have been already).
> > 
> > The clkops (clkops_omap3_core_dpll_ops & clkops_omap3_noncore_dpll_ops)
> > is used in clock data files, and dependency is already handled by
> > Makefile rule.
> > 
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Kevin Hilman <khilman@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> 
> This is probably okay.
> 
> Acked-by: Paul Walmsley <paul@pwsan.com>
> 
> 

Thanks Paul,

Thanks,
Vaibhav

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
  2012-05-11  6:09           ` Hiremath, Vaibhav
@ 2012-05-11 21:54             ` Kevin Hilman
  -1 siblings, 0 replies; 38+ messages in thread
From: Kevin Hilman @ 2012-05-11 21:54 UTC (permalink / raw)
  To: Hiremath, Vaibhav; +Cc: linux-omap, tony, paul, linux-arm-kernel

"Hiremath, Vaibhav" <hvaibhav@ti.com> writes:

> On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote:
>> "Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
>> 
>> > On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
>> >> Vaibhav Hiremath <hvaibhav@ti.com> writes:
>> >> 
>> >> > The function __omap2_set_globals() can be common across all
>> >> > platforms/architectures, even in case of omap4, internally it
>> >> > calls same set of functions as in __omap2_set_globals() function
>> >> > (except for sdrc).
>> >> 
>> >> OK so far.
>> >> 
>> >> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
>> >> > so that we can reuse same function across omap2/3/4...
>> >> 
>> >> But what happens when a single kernel is built that has support for an
>> >> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
>> >> 
>> >
>> > As such Nothing...I looking into this direction while implementing.
>> >
>> > In that case, sdrc.c file will be compiled in and execution will jump to
>> > omap2_set_globals_sdrc(). But inside this function, we are already checking 
>> > whether the omap2_globals->sdrc and omap2_globals->sms for NULL and then use 
>> > it.
>> >
>> > And function omap2_sdrc_init() is also depends on machine, so in case of
>> > Am33xx, it won't get into sdrc execution at all. And in case of omap4, it 
>> > will.
>> 
>> Then why bother with the #ifdef at all?
>> 
>> If it already safe to call on all SoCs, just get rid of the #ifdef all
>> together.
>> 
>
> Kevin,
>
> sdrc.o target gets built only as "omap-2-3-common", this will not get built 
> for omap4, am33xx, ti81xx, etc...

OK, I see what you mean now.  I was confusing because this patch doesn't
touch sdrc.c, or the Makefile for sdrc.c.

> So in order to avoid build break, you have to have some mechanism, and
> that's where we need to create config option dependent on platform.

That being the case, for readability sake, I suggest you change the
Makefile to use the new config option for sdrc.c as well.

Kevin

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
@ 2012-05-11 21:54             ` Kevin Hilman
  0 siblings, 0 replies; 38+ messages in thread
From: Kevin Hilman @ 2012-05-11 21:54 UTC (permalink / raw)
  To: linux-arm-kernel

"Hiremath, Vaibhav" <hvaibhav@ti.com> writes:

> On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote:
>> "Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
>> 
>> > On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
>> >> Vaibhav Hiremath <hvaibhav@ti.com> writes:
>> >> 
>> >> > The function __omap2_set_globals() can be common across all
>> >> > platforms/architectures, even in case of omap4, internally it
>> >> > calls same set of functions as in __omap2_set_globals() function
>> >> > (except for sdrc).
>> >> 
>> >> OK so far.
>> >> 
>> >> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
>> >> > so that we can reuse same function across omap2/3/4...
>> >> 
>> >> But what happens when a single kernel is built that has support for an
>> >> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
>> >> 
>> >
>> > As such Nothing...I looking into this direction while implementing.
>> >
>> > In that case, sdrc.c file will be compiled in and execution will jump to
>> > omap2_set_globals_sdrc(). But inside this function, we are already checking 
>> > whether the omap2_globals->sdrc and omap2_globals->sms for NULL and then use 
>> > it.
>> >
>> > And function omap2_sdrc_init() is also depends on machine, so in case of
>> > Am33xx, it won't get into sdrc execution at all. And in case of omap4, it 
>> > will.
>> 
>> Then why bother with the #ifdef at all?
>> 
>> If it already safe to call on all SoCs, just get rid of the #ifdef all
>> together.
>> 
>
> Kevin,
>
> sdrc.o target gets built only as "omap-2-3-common", this will not get built 
> for omap4, am33xx, ti81xx, etc...

OK, I see what you mean now.  I was confusing because this patch doesn't
touch sdrc.c, or the Makefile for sdrc.c.

> So in order to avoid build break, you have to have some mechanism, and
> that's where we need to create config option dependent on platform.

That being the case, for readability sake, I suggest you change the
Makefile to use the new config option for sdrc.c as well.

Kevin

^ permalink raw reply	[flat|nested] 38+ messages in thread

* RE: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
  2012-05-11 21:54             ` Kevin Hilman
@ 2012-05-14  9:23               ` Hiremath, Vaibhav
  -1 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-14  9:23 UTC (permalink / raw)
  To: Hilman, Kevin; +Cc: linux-omap, tony, paul, linux-arm-kernel

On Sat, May 12, 2012 at 03:24:51, Hilman, Kevin wrote:
> "Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
> 
> > On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote:
> >> "Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
> >> 
> >> > On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
> >> >> Vaibhav Hiremath <hvaibhav@ti.com> writes:
> >> >> 
> >> >> > The function __omap2_set_globals() can be common across all
> >> >> > platforms/architectures, even in case of omap4, internally it
> >> >> > calls same set of functions as in __omap2_set_globals() function
> >> >> > (except for sdrc).
> >> >> 
> >> >> OK so far.
> >> >> 
> >> >> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
> >> >> > so that we can reuse same function across omap2/3/4...
> >> >> 
> >> >> But what happens when a single kernel is built that has support for an
> >> >> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
> >> >> 
> >> >
> >> > As such Nothing...I looking into this direction while implementing.
> >> >
> >> > In that case, sdrc.c file will be compiled in and execution will jump to
> >> > omap2_set_globals_sdrc(). But inside this function, we are already checking 
> >> > whether the omap2_globals->sdrc and omap2_globals->sms for NULL and then use 
> >> > it.
> >> >
> >> > And function omap2_sdrc_init() is also depends on machine, so in case of
> >> > Am33xx, it won't get into sdrc execution at all. And in case of omap4, it 
> >> > will.
> >> 
> >> Then why bother with the #ifdef at all?
> >> 
> >> If it already safe to call on all SoCs, just get rid of the #ifdef all
> >> together.
> >> 
> >
> > Kevin,
> >
> > sdrc.o target gets built only as "omap-2-3-common", this will not get built 
> > for omap4, am33xx, ti81xx, etc...
> 
> OK, I see what you mean now.  I was confusing because this patch doesn't
> touch sdrc.c, or the Makefile for sdrc.c.
> 

I think I understand the source of confusion here, but now we are on same 
page...

> > So in order to avoid build break, you have to have some mechanism, and
> > that's where we need to create config option dependent on platform.
> 
> That being the case, for readability sake, I suggest you change the
> Makefile to use the new config option for sdrc.c as well.
> 

Will submit the patch for this today.

Thanks,
Vaibhav

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
@ 2012-05-14  9:23               ` Hiremath, Vaibhav
  0 siblings, 0 replies; 38+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-14  9:23 UTC (permalink / raw)
  To: linux-arm-kernel

On Sat, May 12, 2012 at 03:24:51, Hilman, Kevin wrote:
> "Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
> 
> > On Fri, May 11, 2012 at 03:09:39, Hilman, Kevin wrote:
> >> "Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
> >> 
> >> > On Wed, May 09, 2012 at 04:08:09, Hilman, Kevin wrote:
> >> >> Vaibhav Hiremath <hvaibhav@ti.com> writes:
> >> >> 
> >> >> > The function __omap2_set_globals() can be common across all
> >> >> > platforms/architectures, even in case of omap4, internally it
> >> >> > calls same set of functions as in __omap2_set_globals() function
> >> >> > (except for sdrc).
> >> >> 
> >> >> OK so far.
> >> >> 
> >> >> > This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
> >> >> > so that we can reuse same function across omap2/3/4...
> >> >> 
> >> >> But what happens when a single kernel is built that has support for an
> >> >> SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)?
> >> >> 
> >> >
> >> > As such Nothing...I looking into this direction while implementing.
> >> >
> >> > In that case, sdrc.c file will be compiled in and execution will jump to
> >> > omap2_set_globals_sdrc(). But inside this function, we are already checking 
> >> > whether the omap2_globals->sdrc and omap2_globals->sms for NULL and then use 
> >> > it.
> >> >
> >> > And function omap2_sdrc_init() is also depends on machine, so in case of
> >> > Am33xx, it won't get into sdrc execution at all. And in case of omap4, it 
> >> > will.
> >> 
> >> Then why bother with the #ifdef at all?
> >> 
> >> If it already safe to call on all SoCs, just get rid of the #ifdef all
> >> together.
> >> 
> >
> > Kevin,
> >
> > sdrc.o target gets built only as "omap-2-3-common", this will not get built 
> > for omap4, am33xx, ti81xx, etc...
> 
> OK, I see what you mean now.  I was confusing because this patch doesn't
> touch sdrc.c, or the Makefile for sdrc.c.
> 

I think I understand the source of confusion here, but now we are on same 
page...

> > So in order to avoid build break, you have to have some mechanism, and
> > that's where we need to create config option dependent on platform.
> 
> That being the case, for readability sake, I suggest you change the
> Makefile to use the new config option for sdrc.c as well.
> 

Will submit the patch for this today.

Thanks,
Vaibhav

^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, other threads:[~2012-05-14  9:23 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-08 19:52 [PATCH-V2 0/4] ARM: OMAP2+: Cleanup series in order to remove ARCH_OMAPx dependency Vaibhav Hiremath
2012-05-08 19:52 ` Vaibhav Hiremath
2012-05-08 19:52 ` [PATCH-V2 1/4] ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry Vaibhav Hiremath
2012-05-08 19:52   ` Vaibhav Hiremath
2012-05-08 19:52 ` [PATCH-V2 2/4] ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c Vaibhav Hiremath
2012-05-08 19:52   ` Vaibhav Hiremath
2012-05-10 23:02   ` Paul Walmsley
2012-05-10 23:02     ` Paul Walmsley
2012-05-11  7:01     ` Hiremath, Vaibhav
2012-05-11  7:01       ` Hiremath, Vaibhav
2012-05-08 19:52 ` [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals Vaibhav Hiremath
2012-05-08 19:52   ` Vaibhav Hiremath
2012-05-08 22:38   ` Kevin Hilman
2012-05-08 22:38     ` Kevin Hilman
2012-05-09  8:59     ` Hiremath, Vaibhav
2012-05-09  8:59       ` Hiremath, Vaibhav
2012-05-10 21:39       ` Kevin Hilman
2012-05-10 21:39         ` Kevin Hilman
2012-05-11  6:09         ` Hiremath, Vaibhav
2012-05-11  6:09           ` Hiremath, Vaibhav
2012-05-11  6:37           ` Sricharan R
2012-05-11  6:37             ` Sricharan R
2012-05-11  6:43             ` Hiremath, Vaibhav
2012-05-11  6:43               ` Hiremath, Vaibhav
2012-05-11 21:54           ` Kevin Hilman
2012-05-11 21:54             ` Kevin Hilman
2012-05-14  9:23             ` Hiremath, Vaibhav
2012-05-14  9:23               ` Hiremath, Vaibhav
2012-05-08 19:52 ` [PATCH-V2 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features Vaibhav Hiremath
2012-05-08 19:52   ` Vaibhav Hiremath
2012-05-08 22:50   ` Kevin Hilman
2012-05-08 22:50     ` Kevin Hilman
2012-05-09  9:06     ` Hiremath, Vaibhav
2012-05-09  9:06       ` Hiremath, Vaibhav
2012-05-10 22:35       ` Paul Walmsley
2012-05-10 22:35         ` Paul Walmsley
2012-05-11  5:30         ` Hiremath, Vaibhav
2012-05-11  5:30           ` Hiremath, Vaibhav

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.