* DebBarma, Tarun Kanti <tarun.ka...@ti.com> [110304 10:55]: > > -----Original Message----- > > From: Tony Lindgren [mailto:t...@atomide.com] > > Sent: Friday, March 04, 2011 10:59 PM > > To: Hilman, Kevin > > Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org; Basak, Partha > > Subject: Re: [PATCH v11 7/8] OMAP: dmtimer: pm_runtime support > > > > * Kevin Hilman <khil...@ti.com> [110303 17:22]: > > > Tarun Kanti DebBarma <tarun.ka...@ti.com> 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.
Any one of them can be used, but no need to register the others this early. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
