linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: santosh.shilimkar@ti.com (Shilimkar, Santosh)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 2/4] ARM: OMAP: PM: Get rid of Powerdomain book-keeping from cpuidle
Date: Fri, 20 Jul 2012 17:24:29 +0530	[thread overview]
Message-ID: <CAMQu2gww9O-Kv6c1xFYWjj42vsoR4Ewrdzr+H7Da5RC79s_-Zw@mail.gmail.com> (raw)
In-Reply-To: <1342774283.4672.181.camel@sokoban>

On Fri, Jul 20, 2012 at 2:21 PM, Tero Kristo <t-kristo@ti.com> wrote:
>
> On Fri, 2012-07-20 at 13:38 +0530, Rajendra Nayak wrote:
> > On Friday 20 July 2012 12:55 PM, Shilimkar, Santosh wrote:
> > > On Fri, Jul 20, 2012 at 11:34 AM, Rajendra Nayak<rnayak@ti.com>
> > > wrote:
> > >> pwrdm_pre_transition()/pwrdm_post_transition() have always been high
> > >> latency
> > >> operations done within cpuidle to do Powerdomain level book-keeping
> > >> to know
> > >> what state transitions for different Powerdomains have been
> > >> triggered.
> > >> This is also useful to do a restore-on-demand in some cases when we
> > >> know
> > >> the context for the given Powerdomain was lost etc.
> > >>
> > >> Now that we have definitive entry/exit points (thanks to the
> > >> Powerdomain
> > >> level usecounting) for Powerdomain transitions, these book-keeping
> > >> functions
> > >> can very well be moved from within CPUidle into
> > >> pwrdm_clkdm_enable()/pwrdm_
> > >> clkdm_disable() functions.
> > >>
> > >> Also rename _pwrdm_pre/post_transition_cb() to
> > >> pwrdm_pre/post_transition()
> > >> and get rid of the original ones which iterate over all powerdomains.
> > >>
> > >> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
> > >> ---
> > >>   arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++--
> > >>   arch/arm/mach-omap2/pm34xx.c              |    4 ++--
> > >>   arch/arm/mach-omap2/powerdomain.c         |   28
> > >> ++++++++--------------------
> > >>   arch/arm/mach-omap2/powerdomain.h         |    4 ++--
> > >>   4 files changed, 14 insertions(+), 26 deletions(-)
> > >>
> > >> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > >> b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > >> index 13670aa..ea19439 100644
> > >> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > >> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > >> @@ -255,7 +255,7 @@ int omap4_enter_lowpower(unsigned int cpu,
> > >> unsigned int power_state)
> > >>                  return -ENXIO;
> > >>          }
> > >>
> > >> -       pwrdm_pre_transition();
> > >> +       pwrdm_cpu_idle();
> > >>
> > > Glad to see this is getting optimized.
> > > I haven't seen how "pwrdm_cpu_[idle/wakeup]()" is
> > > implemented but will those work on SMP system ?
> > > I mean OMAP4, any CPU can make this call ?
> >
> > Thats a good question. I think Tero did this so he can kick in
> > voltage transitions at the right time in idle/suspend.
> > Given that these deal with incrementing/decrementing the MPU and CORE
> > pwrdm usecounts alone, maybe on OMAP4 (SMP systems) this needs to also
> > increment/decrement the specific CPU usecounts on the CPUs these calls
> > are made.
>
> Yeah, you should keep the usecounts valid by each cpu separately calling
> these functions. My current set only sets these usecounts based on cpu0
> activity, as cpu1 is statically controlled through cpu online / offline.
> Once per-cpu cpuidle is in, these should be changed so that each
> individual cpu increases the usecounts when they are brought up,
> decrease/increase during idle, and decrease when they are brought down.
> The usecount should always reflect the number of CPUs active on MPU
> domain.
>
Sounds good to me !!

Regards
santosh

  reply	other threads:[~2012-07-20 11:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-20  6:04 [RFC 0/4] OMAP Cpuidle/Suspend Cleanups Rajendra Nayak
2012-07-20  6:04 ` [RFC 1/4] ARM: OMAP3: cpuidle: Remove unused MPU OSWR support code Rajendra Nayak
2012-07-20  7:08   ` Shilimkar, Santosh
2012-07-20 18:25   ` Paul Walmsley
2012-07-23  7:10     ` Rajendra Nayak
2012-07-20  6:04 ` [RFC 2/4] ARM: OMAP: PM: Get rid of Powerdomain book-keeping from cpuidle Rajendra Nayak
2012-07-20  7:25   ` Shilimkar, Santosh
2012-07-20  8:08     ` Rajendra Nayak
2012-07-20  8:51       ` Tero Kristo
2012-07-20 11:54         ` Shilimkar, Santosh [this message]
2012-07-25 22:43         ` Kevin Hilman
2012-07-26 11:43           ` Rajendra Nayak
2012-07-26 12:42           ` Rajendra Nayak
2012-07-26 17:44             ` Kevin Hilman
2012-07-26 18:27               ` Tero Kristo
2012-07-26 20:50                 ` Paul Walmsley
2012-07-27  6:46                 ` Rajendra Nayak
2012-07-27  7:43                   ` Rajendra Nayak
2012-07-20  6:04 ` [RFC 3/4] ARM: OMAP: powerdomain: Add .power_on/.power_down hooks for powerdomains Rajendra Nayak
2012-07-20  7:26   ` Shilimkar, Santosh
2012-07-20  6:04 ` [RFC 4/4] ARM: OMAP3: PM: Use .power_on/.power_down to clean omap_sram_idle Rajendra Nayak
2012-07-20  7:30   ` Shilimkar, Santosh
2012-07-20  8:59 ` [RFC 0/4] OMAP Cpuidle/Suspend Cleanups Tero Kristo
2012-07-20  9:03   ` Rajendra Nayak

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=CAMQu2gww9O-Kv6c1xFYWjj42vsoR4Ewrdzr+H7Da5RC79s_-Zw@mail.gmail.com \
    --to=santosh.shilimkar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).