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@xxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
