diff mbox

[2/2] ARM: OMAP2+: Change core_initcall levels to postcore_initcall

Message ID 1448900789-4034-3-git-send-email-tony@atomide.com (mailing list archive)
State New, archived
Headers show

Commit Message

Tony Lindgren Nov. 30, 2015, 4:26 p.m. UTC
We want to be able to probe a few selected device drivers before hwmod
code populates the clocks in omap_hwmod_setup_all(). This allows us to
convert most of the clock drivers into regular device drivers.

We only need a few minimal clock drivers early for the system timers to
select between the 32KiHz clock and the high frequency oscillator.

With these changes, initializing the clock drivers can be just done at
core_initcall time with something like:

np = of_find_node_by_name(NULL, "plls");
if (np)
	of_platform_populate(np, NULL, NULL, NULL);

And then these clocks will be available for the interconnect code to use.

Having most of the clock drivers being regular device drivers allows
us to use the nice things like devm_* functions and dev_err and dev_dbg.
As an extra bonus, this also allows us to develop the clock drivers for
new SoCs as loadable modules initially for cases where we can boot up
the system based on the bootloader configured clocks.

To do this, let's change the core_initcalls to postcore_initcall under
mach-omap2.

Cc: Felipe Balbi <balbi@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/omap2-restart.c | 2 +-
 arch/arm/mach-omap2/omap_device.c   | 2 +-
 arch/arm/mach-omap2/omap_hwmod.c    | 2 +-
 arch/arm/mach-omap2/serial.c        | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

Comments

Tony Lindgren Dec. 3, 2015, 4 p.m. UTC | #1
* Tony Lindgren <tony@atomide.com> [151130 08:29]:
> We want to be able to probe a few selected device drivers before hwmod
> code populates the clocks in omap_hwmod_setup_all(). This allows us to
> convert most of the clock drivers into regular device drivers.
> 
> We only need a few minimal clock drivers early for the system timers to
> select between the 32KiHz clock and the high frequency oscillator.
> 
> With these changes, initializing the clock drivers can be just done at
> core_initcall time with something like:
> 
> np = of_find_node_by_name(NULL, "plls");
> if (np)
> 	of_platform_populate(np, NULL, NULL, NULL);
> 
> And then these clocks will be available for the interconnect code to use.
> 
> Having most of the clock drivers being regular device drivers allows
> us to use the nice things like devm_* functions and dev_err and dev_dbg.
> As an extra bonus, this also allows us to develop the clock drivers for
> new SoCs as loadable modules initially for cases where we can boot up
> the system based on the bootloader configured clocks.
> 
> To do this, let's change the core_initcalls to postcore_initcall under
> mach-omap2.

FYI I'm applying this one into omap-for-v4.5/soc today, the first patch
in this series needs more work as discussed.

Regards,

Tony
Grygorii Strashko Dec. 3, 2015, 4:34 p.m. UTC | #2
On 12/03/2015 06:00 PM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [151130 08:29]:
>> We want to be able to probe a few selected device drivers before hwmod
>> code populates the clocks in omap_hwmod_setup_all(). This allows us to
>> convert most of the clock drivers into regular device drivers.

if understand things right, ti clks now will be populated and initialized
from 
__omap_sync32k_timer_init
 - omap_clk_init()
   - .. 
   - of_clk_init()
   - ..
   - omap_clk_soc_init()

and __omap_sync32k_timer_init(), in turn, will be called from:
arch/arm/kernel/time.c
 - time_init()
	machine_desc->init_time();
(without your patch 1).

So, I don't see real dependency here between clk initialization and hwmods :(


>>
>> We only need a few minimal clock drivers early for the system timers to
>> select between the 32KiHz clock and the high frequency oscillator.
>>
>> With these changes, initializing the clock drivers can be just done at
>> core_initcall time with something like:
>>
>> np = of_find_node_by_name(NULL, "plls");
>> if (np)
>> 	of_platform_populate(np, NULL, NULL, NULL);
>>
>> And then these clocks will be available for the interconnect code to use.
>>
>> Having most of the clock drivers being regular device drivers allows
>> us to use the nice things like devm_* functions and dev_err and dev_dbg.
>> As an extra bonus, this also allows us to develop the clock drivers for
>> new SoCs as loadable modules initially for cases where we can boot up
>> the system based on the bootloader configured clocks.
>>
>> To do this, let's change the core_initcalls to postcore_initcall under
>> mach-omap2.
> 
> FYI I'm applying this one into omap-for-v4.5/soc today, the first patch
> in this series needs more work as discussed.
> 

To be honest I don't see how this will help to convert ti clks in regular
devices right now.
Wouldn't it be better to move forward with this patch together with future patches?
So it will be clear what benefits will this approach provide.

In other words, I think it should be a part of some bigger series.
Tony Lindgren Dec. 3, 2015, 4:41 p.m. UTC | #3
* Grygorii Strashko <grygorii.strashko@ti.com> [151203 08:35]:
> On 12/03/2015 06:00 PM, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [151130 08:29]:
> >> We want to be able to probe a few selected device drivers before hwmod
> >> code populates the clocks in omap_hwmod_setup_all(). This allows us to
> >> convert most of the clock drivers into regular device drivers.
> 
> if understand things right, ti clks now will be populated and initialized
> from 
> __omap_sync32k_timer_init
>  - omap_clk_init()
>    - .. 
>    - of_clk_init()
>    - ..
>    - omap_clk_soc_init()
> 
> and __omap_sync32k_timer_init(), in turn, will be called from:
> arch/arm/kernel/time.c
>  - time_init()
> 	machine_desc->init_time();
> (without your patch 1).

Yes that's the current approach, but we can do better. We only need the following
clocks for system timers at that point:

- mux clocks to select between the 32k and hf oscillator source

- clkctrl driver to gate the ocp clock

All the other clocks can be initialized at core_initcall time with this change.

> So, I don't see real dependency here between clk initialization and hwmods :(

You don't because it's only implemented so far for the dm814x ADPLL clock :)

That I posted as "[PATCH 0/2] Clock driver for dm814x ADPLL". Note how it's
just a regular device driver that also works as loadable module on boards that
have all the necessary clocks enabled already by the bootloader.

Regards,

Tony
Grygorii Strashko Dec. 3, 2015, 6:08 p.m. UTC | #4
On 12/03/2015 06:41 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko@ti.com> [151203 08:35]:
>> On 12/03/2015 06:00 PM, Tony Lindgren wrote:
>>> * Tony Lindgren <tony@atomide.com> [151130 08:29]:
>>>> We want to be able to probe a few selected device drivers before hwmod
>>>> code populates the clocks in omap_hwmod_setup_all(). This allows us to
>>>> convert most of the clock drivers into regular device drivers.
>>
>> if understand things right, ti clks now will be populated and initialized
>> from
>> __omap_sync32k_timer_init
>>   - omap_clk_init()
>>     - ..
>>     - of_clk_init()
>>     - ..
>>     - omap_clk_soc_init()
>>
>> and __omap_sync32k_timer_init(), in turn, will be called from:
>> arch/arm/kernel/time.c
>>   - time_init()
>> 	machine_desc->init_time();
>> (without your patch 1).
> 
> Yes that's the current approach, but we can do better. We only need the following
> clocks for system timers at that point:
> 
> - mux clocks to select between the 32k and hf oscillator source
> 
> - clkctrl driver to gate the ocp clock
> 
> All the other clocks can be initialized at core_initcall time with this change.
> 
>> So, I don't see real dependency here between clk initialization and hwmods :(
> 
> You don't because it's only implemented so far for the dm814x ADPLL clock :)
> 
> That I posted as "[PATCH 0/2] Clock driver for dm814x ADPLL". Note how it's
> just a regular device driver that also works as loadable module on boards that
> have all the necessary clocks enabled already by the bootloader.
> 

Ah. Thanks. I see it now.
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/omap2-restart.c b/arch/arm/mach-omap2/omap2-restart.c
index d937b2e..497269d 100644
--- a/arch/arm/mach-omap2/omap2-restart.c
+++ b/arch/arm/mach-omap2/omap2-restart.c
@@ -62,4 +62,4 @@  static int __init omap2xxx_common_look_up_clks_for_reset(void)
 
 	return 0;
 }
-omap_core_initcall(omap2xxx_common_look_up_clks_for_reset);
+omap_postcore_initcall(omap2xxx_common_look_up_clks_for_reset);
diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 72ebc4c..3750ed1 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -869,7 +869,7 @@  static int __init omap_device_init(void)
 	bus_register_notifier(&platform_bus_type, &platform_nb);
 	return 0;
 }
-omap_core_initcall(omap_device_init);
+omap_postcore_initcall(omap_device_init);
 
 /**
  * omap_device_late_idle - idle devices without drivers
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cc8a987..49d5376 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3307,7 +3307,7 @@  static int __init omap_hwmod_setup_all(void)
 
 	return 0;
 }
-omap_core_initcall(omap_hwmod_setup_all);
+omap_postcore_initcall(omap_hwmod_setup_all);
 
 /**
  * omap_hwmod_enable - enable an omap_hwmod
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5fb50fe..f164c6b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -213,7 +213,7 @@  static int __init omap_serial_early_init(void)
 
 	return 0;
 }
-omap_core_initcall(omap_serial_early_init);
+omap_postcore_initcall(omap_serial_early_init);
 
 /**
  * omap_serial_init_port() - initialize single serial port