From: t-kristo@ti.com (Tero Kristo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters
Date: Wed, 2 May 2012 12:20:21 +0300 [thread overview]
Message-ID: <1335950421.2149.189.camel@sokoban> (raw)
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EA6A33C@DBDE01.ent.ti.com>
On Wed, 2012-05-02 at 10:45 +0200, Bedia, Vaibhav wrote:
> Hi Tero,
>
> On Fri, Apr 20, 2012 at 14:49:49, Kristo, Tero wrote:
> > From: Axel Haslam <axelhaslam@gmail.com>
> >
> > On OMAP4, there is no support to read previous logic state
> > or previous memory state achieved when a power domain transitions
> > to RET. Instead there are module level context registers.
> >
> > In order to support the powerdomain level logic/mem_off_counters
> > on OMAP4, instead use the previous power state achieved (RET) and
> > the *programmed* logic/mem RET state to derive if a powerdomain lost
> > logic or did not.
> >
> > If the powerdomain is programmed to enter RET state and lose logic
> > in RET state, knowing that the powerdomain entered RET is good enough
> > to derive that the logic was lost as well, in such cases.
> >
>
> Unfortunately this won't scale for AM33xx devices :(
> It neither has module level context registers nor previous logic/memory state
> registers in PRCM.
>
> At a top level, there's a Cortex-M3 (CM3) to assist the low power state transitions
> and the indication of successful transition to a low power states is handled as part
> of the IPC mechanism between the MPU (A8) and CM3 which is s/w defined.
>
> Since the various APIs like omap_hwmod_get_context_loss_context() and friends are
> necessary to have correct context saves and restores in drivers we'll need
> to add another API for AM33xx which basically builds on the IPC mechanism
> and updates the counters.
>
> So, instead of the fallback mechanism that is currently in place, can the
> implementation for updating the logic/mem counters be converted to make use of
> function pointers. When AM33xx PM support comes in, we can just define
> a custom function and not pollute the code with cpu_is_* checks.
I think that should be fine. We can add arch_hwmod struct or such
(similar to arch_clkdm / arch_pwrdm) if need be. However, I think we
should just expand the support towards that way once we can implement
the am33xx support properly with a separate patch. I guess this doesn't
break anything on am33xx currently, right?
-Tero
next prev parent reply other threads:[~2012-05-02 9:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-20 9:19 [PATCHv4 0/8] ARM: OMAP4: core retention support Tero Kristo
2012-04-20 9:19 ` [PATCHv4 1/8] ARM: OMAP4: suspend: Program all domains to retention Tero Kristo
2012-04-20 9:19 ` [PATCHv4 2/8] TEMP: ARM: OMAP4: hwmod_data: Do not get DSP out of reset at boot time Tero Kristo
2012-04-20 9:19 ` [PATCHv4 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change Tero Kristo
2012-04-20 9:19 ` [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status Tero Kristo
2012-04-23 15:52 ` Jon Hunter
2012-04-24 14:46 ` Tero Kristo
2012-04-24 17:14 ` Cousson, Benoit
2012-05-15 22:22 ` Kevin Hilman
2012-05-16 5:24 ` Rajendra Nayak
2012-05-16 5:45 ` Rajendra Nayak
2012-05-22 14:20 ` Tero Kristo
2012-05-22 14:29 ` Cousson, Benoit
2012-04-20 9:19 ` [PATCHv4 5/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count Tero Kristo
2012-04-20 9:19 ` [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters Tero Kristo
2012-05-02 8:45 ` Bedia, Vaibhav
2012-05-02 9:20 ` Tero Kristo [this message]
2012-05-02 9:55 ` Bedia, Vaibhav
2012-05-08 0:19 ` Kevin Hilman
2012-05-08 8:03 ` Tero Kristo
2012-05-08 8:36 ` Tero Kristo
2012-05-08 8:57 ` Rajendra Nayak
2012-05-08 9:09 ` Tero Kristo
2012-05-08 9:15 ` Rajendra Nayak
2012-05-08 9:49 ` Tero Kristo
2012-04-20 9:19 ` [PATCHv4 7/8] ARM: OMAP4: PM: Add next_logic_state param to power_state Tero Kristo
2012-04-20 9:19 ` [PATCHv4 8/8] ARM: OMAP4: PM: Added option for enabling OSWR Tero Kristo
2012-05-03 11:03 ` Jean Pihet
2012-05-03 16:14 ` Tero Kristo
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=1335950421.2149.189.camel@sokoban \
--to=t-kristo@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).