RE: [PATCH v12 4/9] OMAP2+: dmtimer: convert to platform devices

[Santosh Shilimkar <santosh.shilimkar@ti.com>]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Saturday, March 19, 2011 5:57 AM
> To: Kevin Hilman
> Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org; Gopinath,
> Thara
> Subject: Re: [PATCH v12 4/9] OMAP2+: dmtimer: convert to platform
> devices
>
> * Kevin Hilman <khilman@ti.com> [110317 14:58]:
> > Tony Lindgren <tony@atomide.com> writes:
> > >
> > > In the long run, think "local timer" for runtime, and then
> > > "wakeup timer" that gets only programmed when we enter idle.
> > >  The "local timer" will continue operating normally after we
> > > wake-up and the "wakeuptimer" will be just one shot event.
> > > Of course in the omap[23] case the "local timer" is really a
> > > there's are real local timers.

This is already the case for OMAP4 with PM series. But it doesn't
work the way it is stated above. Wakeup timer is always programmed
and kept handy by the timer framework because switching of
clock event happened dynamically and it's too late to reprogram
the next timer expiry etc. What framework does, is just switch
the clock-event to wakeup capable clock-event.

> > >> If this can be done such that the system timer is eventually a
> > >> regular device driver, then that should be fine.
> > >
> > > In this setup there should not be need to mess with the system
> > > timer  after boot as we don't need to switch clock sources.
> >
> > I think we're confusing terminology.  By system timer, I think you
> > mean the clockevent, right?
>
> Yes.
>
> > The situation you described above requires switching clockevents
> > for sure.
>
> No it won't, because we can use a separate physical timer for
> runtime and wake-up events.
>
Why do you want to waste one timer hardware for this purpose
alone especially when generic framework has a support?

> > In addition, we already have a usecase for switching the
> > clocksource as well.  We currently setup a single clocksource
> > (not using the timer_32ka dmtimer.)  However, we already have
> > use-cases where we would like to switch to a higher resolution
> > clocksource (e.g. trace infrastructure for PM instrumentation.)
>
I agree with Kevin. Infact I tried prototyping this one. Clock-event
switching works seamlessly. Clock-source switching though isn't
supported yet by generic timer framework.

> Again that can be done with a separate physical timer, no need to
> switch and reprogram the clocksource.
>
If this can done via existing timer framework, I don't see point
wasting another physical timer for this.

I agree your basic point of making clock-source and clock-event
not depend on any frameworks. This is probably essential
considering any generic kernel changes can impact these. Recent
early_init() was a good example. May be I hold on my comments
since you plan to do some patches for system timer handling.

Regards,
Santosh