RE: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer

["Hiremath, Vaibhav" <hvaibhav@ti.com>]

On Fri, Mar 30, 2012 at 14:50:02, Shilimkar, Santosh wrote:
> On Fri, Mar 30, 2012 at 2:42 PM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote:
> > On Fri, Mar 30, 2012 at 14:08:20, Shilimkar, Santosh wrote:
> >> On Friday 30 March 2012 02:02 PM, Hiremath, Vaibhav wrote:
> >> > On Fri, Mar 30, 2012 at 13:11:35, Shilimkar, Santosh wrote:
> 
> [....]
> 
> >> >
> >> > With this patch, will you be able to choose gptimer as a clocksource
> >> > using bootparameter (or sysfs) for given kernel uImage?
> >> >
> >> Why do you want that ? Look at changelog. The gptimer based clocksource
> >> is useless for OMAP and for AM devices synctimer is not available.
> >>
> >>
> >> > The answer is simply NO...as the registration of gptimer is based on
> >> > failure from omap_init_clocksource_32k(). And this is nothing different
> >> > than my original patch, my patch exactly does same thing.
> >> >
> >> I ight have missed your original patch. If that patch is similar then
> >> no problems.
> >>
> >> > The requirement after 'ming Lie' response on my patch was, there will be
> >> > usecases where we might need to use gptimer for clocksource and with
> >> > the patch it is not possible, since you will only register
> >> > 32k_counter here.
> >> >
> >> I think Ming Lie might have expected that gptimer clocksource might
> >> be better which is not the case.
> >>
> >> > So in order to allow user to choose between 32K and gptimer, you must
> >> > register both and make 32k as a default thing.
> >> >
> >> As described in the commit log, its not needed at all. Let's not add
> >> a feature which is just useless because the gptimer based clock
> >> source has no advantage against the syntimer.
> >>
> >
> > I completely agree with you, and that is my understanding too.
> >
> Thanks !!
> 
> > After Ming Lie's comment, the point that I came to my mind was,
> > certainly there will be resolution difference between these two clocksources,
> > if  gptimer2 is sourced from sys_ck (26Mhz).
> >
> GPTIMER2 with sysclock is not an option. GPTIMER is not in wakeup domain
> and when sysclock is cut, it stops.
> 
> > I am quite not sure, whether will there be any practical usecase where you
> > change the kernel clocksource for high resolution dynamically through sysfs
> > or something. May be not....but still it is possible.
> >
> Even if there is a usecase, there no option with full PM.
> 

What if before suspending the system, you switch back to 32k_counter 
everytime, and in resume you again switch to gp_timer?

Please consider this as just a technical discussion, as I am myself quite 
not sure whether we have such use-case available.

> >
> > In that case my original patch still holds good here. I would still request
> > you to review the same and give your acked-by  or tested-by.
> >
> I just looked at that.
> It looks fine to me. Can you repost that patch addressing Kevin and
> Tony's comments.
> Also update the change log as describe in the patch i posted.
> 
> Once that done, will ack it.
> 

Thanks for the review and discussion, I will submit revised version shortly.


Thanks,
Vaibhav

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html