From: Rajendra Nayak <rnayak@ti.com>
To: t-kristo@ti.com
Cc: Kevin Hilman <khilman@ti.com>,
linux-omap@vger.kernel.org, paul@pwsan.com,
linux-arm-kernel@lists.infradead.org,
Axel Haslam <axelhaslam@gmail.com>
Subject: Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters
Date: Tue, 08 May 2012 14:27:32 +0530 [thread overview]
Message-ID: <4FA8DFFC.6050608@ti.com> (raw)
In-Reply-To: <1336466198.2149.269.camel@sokoban>
On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
> On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
>> Tero Kristo<t-kristo@ti.com> writes:
>>
>>> 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.
>>
>> OK, but this also changes the behavior for OMAP3 as well, right? I
>> don't see in the changelog how this affects OMAP3 and whether it is
>> still expected to work on OMAP3. When changing common code like this,
>> the changelog should describe the impacts on to all affected SoCs.
>>
>> As suggested by Vaibhav Bedia, now might be the right time to add this
>> function to the SoC specific function pointers (struct pwrdm_ops.)
>>
>> Doing that, the existing function could be used for OMAP3 (and OMAP4 if
>> the changelog describes that it can/should be used for both.)
>>
>> Then, when AM33xx support is added, it will be obvious where they will
>> need to plugin support for that SoC.
>
> How about the following patch? It will add a couple of redundant
> read_prev_pwrst calls, but works in the same way as the original patch,
> without touching the generic code. Also, as there have been talks about
> adding caching for some of the pwrdm registers (especially the
> prev_pwrst), this might not be that big of an issue.
>
> If this looks good to you, I'll re-post the set with this patch.
>
> -Tero
>
>
> diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
> b/arch/arm/mach-omap2/powerdomain44xx.c
> index 9bfb8a0..3d5e8d4 100644
> --- a/arch/arm/mach-omap2/powerdomain44xx.c
> +++ b/arch/arm/mach-omap2/powerdomain44xx.c
> @@ -155,6 +155,14 @@ static int omap4_pwrdm_read_logic_retst(struct
> powerdomain *pwrdm)
> return v;
> }
>
> +static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
> +{
> + if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
> + return PWRDM_POWER_ON;
> +
> + return omap4_pwrdm_read_logic_retst(pwrdm);
Looks good to me. Do these ever get called with target state programmed
to OFF?
regards,
Rajendra
> +}
> +
> static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8
> bank)
> {
> u32 m, v;
> @@ -183,6 +191,14 @@ static int omap4_pwrdm_read_mem_retst(struct
> powerdomain *pwrdm, u8 bank)
> return v;
> }
>
> +static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm,
> u8 bank)
> +{
> + if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
> + return PWRDM_POWER_ON;
> +
> + return omap4_pwrdm_read_mem_retst(pwrdm, bank);
> +}
> +
> static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
> {
> u32 c = 0;
> @@ -256,9 +272,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
> .pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
> .pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
> .pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
> + .pwrdm_read_prev_logic_pwrst = omap4_pwrdm_read_prev_logic_pwrst,
> .pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
> .pwrdm_read_mem_pwrst = omap4_pwrdm_read_mem_pwrst,
> .pwrdm_read_mem_retst = omap4_pwrdm_read_mem_retst,
> + .pwrdm_read_prev_mem_pwrst = omap4_pwrdm_read_prev_mem_pwrst,
> .pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
> .pwrdm_set_mem_retst = omap4_pwrdm_set_mem_retst,
> .pwrdm_wait_transition = omap4_pwrdm_wait_transition,
>
>
next prev parent reply other threads:[~2012-05-08 8:57 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
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 [this message]
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=4FA8DFFC.6050608@ti.com \
--to=rnayak@ti.com \
--cc=axelhaslam@gmail.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=t-kristo@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).