[PATCH] omap: Move omap_hwmod_late_init() to mdesc->timer->init() code

[PATCH] omap: Move omap_hwmod_late_init() to mdesc->timer->init() code

[Santosh Shilimkar]

To adhere to recent early_init changes, commit '44dc0' made
omap_hwmod_late_init() to core_initcall to avoid ioremap() failures.

Later 'e7c7d7' removed _mpu_rt_va population omap_hwmod_late_init()

So now if we move the  omap_hwmod_late_init() to mdesc->timer->init(),
timer1 should work with hwmod instead of any special hwmod settings.

This was proposed by Paul Walmsley <paul@pwsan.com>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
---
Same patch I posted as part of the "Linux-next as of
20110222 broken on OMAP4" thread.
 
 arch/arm/mach-omap2/omap_hwmod.c             |    3 +--
 arch/arm/mach-omap2/timer-gp.c               |    4 +++-
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    1 +
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 9e89a58..b39cb40 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1646,7 +1646,7 @@ static int __init _populate_mpu_rt_base(struct omap_hwmod *oh, void *data)
  * to struct clk pointers for each registered omap_hwmod.  Also calls
  * _setup() on each hwmod.  Returns 0.
  */
-static int __init omap_hwmod_late_init(void)
+int __init omap_hwmod_late_init(void)
 {
 	int r;
 
@@ -1664,7 +1664,6 @@ static int __init omap_hwmod_late_init(void)
 
 	return 0;
 }
-core_initcall(omap_hwmod_late_init);
 
 /**
  * omap_hwmod_enable - enable an omap_hwmod
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 7b7c268..319ca42 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -37,8 +37,9 @@
 #include <linux/clockchips.h>
 
 #include <asm/mach/time.h>
-#include <plat/dmtimer.h>
 #include <asm/localtimer.h>
+#include <plat/dmtimer.h>
+#include <plat/omap_hwmod.h>
 
 #include "timer-gp.h"
 
@@ -231,6 +232,7 @@ static void __init omap2_gp_clocksource_init(void)
 
 static void __init omap2_gp_timer_init(void)
 {
+	omap_hwmod_late_init();
 #ifdef CONFIG_LOCAL_TIMERS
 	if (cpu_is_omap44xx()) {
 		twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index fedd829..e2bdbb3 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -536,6 +536,7 @@ struct omap_hwmod {
 };
 
 int omap_hwmod_init(struct omap_hwmod **ohs);
+int omap_hwmod_late_init(void);
 struct omap_hwmod *omap_hwmod_lookup(const char *name);
 int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
 			void *data);
-- 
1.6.0.4

Re: [PATCH] omap: Move omap_hwmod_late_init() to mdesc->timer->init() code

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [110222 06:35]:
> To adhere to recent early_init changes, commit '44dc0' made
> omap_hwmod_late_init() to core_initcall to avoid ioremap() failures.
> 
> Later 'e7c7d7' removed _mpu_rt_va population omap_hwmod_late_init()
> 
> So now if we move the  omap_hwmod_late_init() to mdesc->timer->init(),
> timer1 should work with hwmod instead of any special hwmod settings.

There should be no need to have all hwmods initialized just to get
the system timer running. The system timer should be initialized
with minimal code needed.

Sure it can use hwmod functions as long as it makes sense, but
we certainly don't want the whole hwmod framework initialized
that early.

Tony

RE: [PATCH] omap: Move omap_hwmod_late_init() to mdesc->timer->init() code

[Santosh Shilimkar]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Tuesday, February 22, 2011 10:19 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Paul Walmsley; Kevin Hilman; Benoit
> Cousson
> Subject: Re: [PATCH] omap: Move omap_hwmod_late_init() to mdesc-
> >timer->init() code
>
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110222 06:35]:
> > To adhere to recent early_init changes, commit '44dc0' made
> > omap_hwmod_late_init() to core_initcall to avoid ioremap()
> failures.
> >
> > Later 'e7c7d7' removed _mpu_rt_va population
> omap_hwmod_late_init()
> >
> > So now if we move the  omap_hwmod_late_init() to mdesc->timer-
> >init(),
> > timer1 should work with hwmod instead of any special hwmod
> settings.
>
> There should be no need to have all hwmods initialized just to get
> the system timer running. The system timer should be initialized
> with minimal code needed.
>
Sure

> Sure it can use hwmod functions as long as it makes sense, but
> we certainly don't want the whole hwmod framework initialized
> that early.
>
Something like hwmod_early_init() would solve the issue of early
devices. At least this is better than hacking early hwmod
drivers.
Looks like that's what we decided to go head with
looking at other thread.

Regards,
Santosh

Re: [PATCH] omap: Move omap_hwmod_late_init() to mdesc->timer->init() code

[Paul Walmsley]

Hi Santosh,

On Tue, 22 Feb 2011, Santosh Shilimkar wrote:

> To adhere to recent early_init changes, commit '44dc0' made
> omap_hwmod_late_init() to core_initcall to avoid ioremap() failures.
> 
> Later 'e7c7d7' removed _mpu_rt_va population omap_hwmod_late_init()
> 
> So now if we move the  omap_hwmod_late_init() to mdesc->timer->init(),
> timer1 should work with hwmod instead of any special hwmod settings.
> 
> This was proposed by Paul Walmsley <paul@pwsan.com>

thanks -- something like this series was what I had in mind to go to 
mainline:

   http://marc.info/?l=linux-omap&m=129844518908008&w=2

This series is also available at the branch "hwmod_clockevent_2.6.39" of 
git://git.pwsan.com/linux-2.6.

Ultimately, of course, it's up to Tony to decide what approach he wants to 
use...


- Paul

Re: [PATCH] omap: Move omap_hwmod_late_init() to mdesc->timer->init() code

[Cousson, Benoit]

Salut Paul,

On 2/23/2011 8:18 AM, Paul Walmsley wrote:
> Hi Santosh,
>
> On Tue, 22 Feb 2011, Santosh Shilimkar wrote:
>
>> To adhere to recent early_init changes, commit '44dc0' made
>> omap_hwmod_late_init() to core_initcall to avoid ioremap() failures.
>>
>> Later 'e7c7d7' removed _mpu_rt_va population omap_hwmod_late_init()
>>
>> So now if we move the  omap_hwmod_late_init() to mdesc->timer->init(),
>> timer1 should work with hwmod instead of any special hwmod settings.
>>
>> This was proposed by Paul Walmsley<paul@pwsan.com>
>
> thanks -- something like this series was what I had in mind to go to
> mainline:
>
>     http://marc.info/?l=linux-omap&m=129844518908008&w=2
>
> This series is also available at the branch "hwmod_clockevent_2.6.39" of
> git://git.pwsan.com/linux-2.6.
>
> Ultimately, of course, it's up to Tony to decide what approach he wants to
> use...

This is indeed a little bit cleaner to init only the timer hwmod in the 
timer code, but I'm still wondering it it worth the extra complexity.

As soon as we have one hwmod to initialize, why cannot we initialize the 
whole list like before?
If tomorrow we want to handle PRCM and control module using hwmod, like 
I'd like to do, we will have to init these hwmods early as well.
Even earlier that init_early for the control module at least.

And then we will have a bunch of different init paths from different 
parts of the boot sequence that might become tricky to handle.

Regards,
Benoit

RE: [PATCH] omap: Move omap_hwmod_late_init() to mdesc->timer->init() code

[Santosh Shilimkar]

> -----Original Message-----
> From: Cousson, Benoit [mailto:b-cousson@ti.com]
> Sent: Wednesday, February 23, 2011 7:50 PM
> To: Paul Walmsley
> Cc: Shilimkar, Santosh; linux-omap@vger.kernel.org; Tony Lindgren;
> Hilman, Kevin
> Subject: Re: [PATCH] omap: Move omap_hwmod_late_init() to mdesc-
> >timer->init() code
>
> Salut Paul,
>
> On 2/23/2011 8:18 AM, Paul Walmsley wrote:
> > Hi Santosh,
> >
> > On Tue, 22 Feb 2011, Santosh Shilimkar wrote:
> >
> >> To adhere to recent early_init changes, commit '44dc0' made
> >> omap_hwmod_late_init() to core_initcall to avoid ioremap()
> failures.
> >>
> >> Later 'e7c7d7' removed _mpu_rt_va population
> omap_hwmod_late_init()
> >>
> >> So now if we move the  omap_hwmod_late_init() to mdesc->timer-
> >init(),
> >> timer1 should work with hwmod instead of any special hwmod
> settings.
> >>
> >> This was proposed by Paul Walmsley<paul@pwsan.com>
> >
> > thanks -- something like this series was what I had in mind to go
> to
> > mainline:
> >
> >     http://marc.info/?l=linux-omap&m=129844518908008&w=2
> >
> > This series is also available at the branch
> "hwmod_clockevent_2.6.39" of
> > git://git.pwsan.com/linux-2.6.
> >
> > Ultimately, of course, it's up to Tony to decide what approach he
> wants to
> > use...
>
> This is indeed a little bit cleaner to init only the timer hwmod in
> the timer code, but I'm still wondering it it worth the extra
> complexity.
>
I too like Paul's series except the hard coding as pointed on the
relevant patch.

> As soon as we have one hwmod to initialize, why cannot we initialize
> the whole list like before?
> If tomorrow we want to handle PRCM and control module using hwmod,
> like
> I'd like to do, we will have to init these hwmods early as well.
> Even earlier that init_early for the control module at least.
>
> And then we will have a bunch of different init paths from different
> parts of the boot sequence that might become tricky to handle.
>
I agree with Benoit. L3 interconnect error handling and EMIF are another
examples. Interconnect error handling to trap early failures
and EMIF to re-configure DDR as early as possible. At least before
the DVFS kicks in.

Regards,
Santosh

Re: [PATCH] omap: Move omap_hwmod_late_init() to mdesc->timer->init() code

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1326 bytes --]

Salut Benoît,

On Wed, 23 Feb 2011, Cousson, Benoit wrote:

> This is indeed a little bit cleaner to init only the timer hwmod in the timer
> code, but I'm still wondering it it worth the extra complexity.
> 
> As soon as we have one hwmod to initialize, why cannot we initialize the whole
> list like before?

Tony has mentioned that he wishes to move any code unnecessary for early 
initialization to late in the boot process.  This patch series was an 
attempt to do that with the current usage of the hwmod code.

> If tomorrow we want to handle PRCM and control module using hwmod, like I'd
> like to do, we will have to init these hwmods early as well.
> Even earlier that init_early for the control module at least.

Yes, that makes sense to me.  I'd suggest that the best time to deal with 
that is when the patches to handle PRCM and the SCM via hwmod are done.  
Then we would have a clear example of the need to move that code earlier.

> And then we will have a bunch of different init paths from different 
> parts of the boot sequence that might become tricky to handle.

If we're just initializing individual hwmods right before we use them in 
the early boot process, I hope this won't become too big of a problem.
But perhaps you are foreseeing a problem which I am not?


- Paul