> -----Original Message----- > From: Cousson, Benoit [mailto:b-cousson@xxxxxx] > Sent: Wednesday, February 23, 2011 7:50 PM > To: Paul Walmsley > Cc: Shilimkar, Santosh; linux-omap@xxxxxxxxxxxxxxx; 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@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. > 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 -- 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
