linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>,
	linux-omap@vger.kernel.org, Thara Gopinath <thara@ti.com>,
	Kevin Hilman <khilman@ti.com>
Subject: Re: [PATCH v12 4/9] OMAP2+: dmtimer: convert to platform devices
Date: Mon, 21 Mar 2011 10:07:58 -0700	[thread overview]
Message-ID: <20110321170758.GF2811@atomide.com> (raw)
In-Reply-To: <b65bf7960033964fba8f03e774b46905@mail.gmail.com>

* Santosh Shilimkar <santosh.shilimkar@ti.com> [110318 21:31]:
> > * 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.

Hmm, the next_timer_interrupt gets called before we enter idle, is
that what you mean maybe?

Assuming so, to set up the wake-up timer we can read the programmed
value from hardware to program the wake-up timer when entering
suspend-idle or off-idle. That part can be done just fine with
dmtimer framework.

But in general, we don't really want to start changing the physical
clock for WFI idle because of the time it takes to lock it. For
retention-idle and off-idle, we have much more time. But in these
case there's really no need to change the sources, all we care
about is the physical timer wake-up event and can then restore the
"local timer".
 
> Why do you want to waste one timer hardware for this purpose
> alone especially when generic framework has a support?

In this setup the additional wake-up timer is "only" needed in the
retention-idle and off-idle cases.

For keeping the wake-up timer separate, there are at least three
reasons that I can think of:

1. We don't need to touch the clockevent and clocksource code
   after init except to restore them when waking from retention-idle
   or off-idle.

2. We don't need to initialize anything early for omaps except
   clock framework to set up the clockevent and clocksource.

3. We can avoid switching the physical clock for the timer which
   cuts down latencies at least for the basic WFI case.

> > > 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.

Sure. We need to be able to change between the local timer and
the dmtimer also, and I don't see how the current dmtimer series
would make that any easier.
 
> > 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.

In this setup we don't really need to do anything via existing timer
framework, except to restore the clockevent and clocksource when
waking up from retention-idle or off-idle.
 
> 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.

Yes, we need to cut down the early_init dependencies to minimum.

The reason for that is that then we can initialize everything else
that's omap specific in normal way much later than we do currently.

For the timer, clock framework is essential to init early, but
hwmod is not.

Regards,

Tony

  reply	other threads:[~2011-03-21 17:08 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-08 23:45 [PATCH v12 0/9] dmtimer adaptation to platform_driver Tarun Kanti DebBarma
2011-03-08 23:45 ` [PATCH v12 1/9] OMAP2+: dmtimer: add device names to flck nodes Tarun Kanti DebBarma
2011-03-08 23:45 ` [PATCH v12 2/9] OMAP4: hwmod data: add dmtimer version information Tarun Kanti DebBarma
2011-03-08 23:45 ` [PATCH v12 3/9] OMAP1: dmtimer: conversion to platform devices Tarun Kanti DebBarma
2011-03-08 23:45 ` [PATCH v12 4/9] OMAP2+: dmtimer: convert " Tarun Kanti DebBarma
2011-03-09 21:42   ` Tony Lindgren
2011-03-10 15:29     ` DebBarma, Tarun Kanti
2011-03-10 22:52   ` Kevin Hilman
2011-03-11  4:36     ` DebBarma, Tarun Kanti
2011-03-10 23:14   ` Kevin Hilman
2011-03-11  4:20     ` DebBarma, Tarun Kanti
2011-03-11 19:13       ` Tony Lindgren
2011-03-12  0:03         ` Kevin Hilman
2011-03-14 17:12           ` Tony Lindgren
2011-03-17 22:00             ` Kevin Hilman
2011-03-19  0:27               ` Tony Lindgren
2011-03-19  4:34                 ` Santosh Shilimkar
2011-03-21 17:07                   ` Tony Lindgren [this message]
2011-03-21 18:33                     ` Kevin Hilman
2011-03-21 19:11                       ` Tony Lindgren
2011-03-25  6:55                         ` DebBarma, Tarun Kanti
2011-03-25 15:55                           ` Tony Lindgren
2011-03-29 17:13                             ` Tony Lindgren
2011-03-29 17:52                               ` Tony Lindgren
2011-03-10 23:21   ` Kevin Hilman
2011-03-11  4:13     ` DebBarma, Tarun Kanti
2011-03-08 23:45 ` [PATCH v12 5/9] OMAP: dmtimer: platform driver Tarun Kanti DebBarma
2011-03-08 23:45 ` [PATCH v12 6/9] dmtimer: switch-over to platform device driver Tarun Kanti DebBarma
2011-03-09 22:02   ` Tony Lindgren
2011-03-10 15:27     ` DebBarma, Tarun Kanti
2011-03-10 17:56       ` Tony Lindgren
2011-03-11  5:35         ` DebBarma, Tarun Kanti
2011-03-11 12:45           ` G, Manjunath Kondaiah
2011-03-11 19:15             ` Tony Lindgren
2011-03-12  4:20               ` G, Manjunath Kondaiah
2011-03-11 19:14           ` Tony Lindgren
2011-03-14  6:48             ` DebBarma, Tarun Kanti
2011-03-08 23:45 ` [PATCH v12 7/9] OMAP: dmtimer: pm_runtime support Tarun Kanti DebBarma
2011-03-08 23:45 ` [PATCH v12 8/9] OMAP: dmtimer: add timeout to low-level routines Tarun Kanti DebBarma
2011-03-08 23:45 ` [PATCH v12 9/9] OMAP: dmtimer: use mutex instead of spinlock Tarun Kanti DebBarma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110321170758.GF2811@atomide.com \
    --to=tony@atomide.com \
    --cc=khilman@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=santosh.shilimkar@ti.com \
    --cc=tarun.kanti@ti.com \
    --cc=thara@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).