> -----Original Message-----
> From: Tony Lindgren [mailto:[email protected]]
> Sent: Friday, March 04, 2011 10:59 PM
> To: Hilman, Kevin
> Cc: DebBarma, Tarun Kanti; [email protected]; Basak, Partha
> Subject: Re: [PATCH v11 7/8] OMAP: dmtimer: pm_runtime support
>
> * Kevin Hilman <[email protected]> [110303 17:22]:
> > Tarun Kanti DebBarma <[email protected]> writes:
> >
> > > Add pm_runtime support to dmtimer. Since dmtimer is used during
> > > early boot before pm_runtime is initialized completely there are
> > > provisions to enable/disable clocks directly in the code during
> > > early boot.
> >
> > I'm still not crazy about the duplicate logic (both early & normal) in
> > all the enable/disable functions.
> >
> > As I've suggested in the past, why not just do a clk_get, clk_enable in
> > when the early timers are initialized, then do a clk_disable, clk_put()
> > as soon as the "normal" device is ready and PM runtime is enabled.
>
> Even better would be to have separate handling for the system timer
> with minimal dependencies to anything.
>
> > That will greatly simplify the code and eliminate the unnecessary checks
> > for ->is_early_device which will always be false except for in early
> > boot (when these functions are not likely to be called anyways.)
>
> And please note that only the system timer needs to be initialized early.
> We might as well treat the system timer separately to avoid these issues.
>
Yes, this is applicable normally for the system timer only.
But as I said earlier, we are giving flexibility whereby any one of the GPTs
Can be system timer.
--
Tarun
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
