From: Kevin Hilman <khilman@deeprootsystems.com>
To: Nishanth Menon <nm@ti.com>
Cc: linux-omap <linux-omap@vger.kernel.org>,
Jean Pihet <jean.pihet@newoldbits.com>,
Vishwanath Sripathy <vishwanath.bs@ti.com>,
Tony <tony@atomide.com>
Subject: Re: [PATCH 08/13] OMAP3: PM: Deny MPU idle while saving secure RAM
Date: Fri, 19 Nov 2010 09:08:57 -0800 [thread overview]
Message-ID: <87eiahckba.fsf@deeprootsystems.com> (raw)
In-Reply-To: <1290131698-6194-9-git-send-email-nm@ti.com> (Nishanth Menon's message of "Thu, 18 Nov 2010 19:54:53 -0600")
Nishanth Menon <nm@ti.com> writes:
> From: Eduardo Valentin <eduardo.valentin@nokia.com>
>
> Deny MPU idle before save secure ram and allow it after save secure RAM.
> We want to deny MPU going to low power state because, there is a short
> time window where a wakeup event would happen around the time the MPU
> is going to idle. Since the first thing ROM code does after WFI is to
> read INTCPS register, we could reach a situation where the INTCPS is
> in idle, but the read is sent to it. That would produce a data abord
> during the save of secure ram, which will hang the system. we need
> to prevent clock transitions as well during this timeframe.
This changelog needs to be a bit clearer about exacly why MPU would be
going to a low power state during a secure-mode call. IIUC, it's
because the ROM code might do a WFI. Since it's completely
non-intuitive (and broken, at least to me) that the ROM code would do a
WFI, this should be stated explicitly in the changelog, and probably in
the code too.
Also, this approach only solves this problem for this particular
secure-mode call. Presumably there are other secure-mode calls that
might WFI as well, and will have the same problem. As I'm not familiar
with secure ROM or PPAs, so I don't know if this is true or not. If it
is, then somethen more general should be done.
Also, do we care about other powerdomains (besides MPU) going idle
during a secure mode call?
Because of those issues, some other proposals have been floated for this
problem. In particular, explicitly setting some of the powerdomain next
states (at least MPU & CORE) to ON when we're not in the normal idle
path so that would also prevent this problem.
I guess we need some more details on which secure mode calls can trigger
this problem. If this is an isolated case, I'm OK with this fix. If
it's more general, I'd like to see a more general fix.
Kevin
> [nm@ti.com: rebased to 2.6.37-rc2, used omap2_clkdm_deny_idle for
> clock prevention]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
> ---
> arch/arm/mach-omap2/pm34xx.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 7877f74..f520b38 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -194,15 +194,19 @@ int __init omap3_secure_copy_data_set(struct omap3_secure_copy_data *data)
> static void omap3_save_secure_ram_context(u32 target_mpu_state)
> {
> if (!secure_ram_saved && omap_type() != OMAP2_DEVICE_TYPE_GP) {
> + struct clockdomain *clkd = mpu_pwrdm->pwrdm_clkdms[0];
> +
> /*
> * MPU next state must be set to POWER_ON temporarily,
> * otherwise the WFI executed inside the ROM code
> * will hang the system.
> */
> pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
> + omap2_clkdm_deny_idle(clkd);
> secure_ram_save_status = _omap_save_secure_sram((u32 *)
> (omap3_secure_ram_storage));
> pwrdm_set_next_pwrst(mpu_pwrdm, target_mpu_state);
> + omap2_clkdm_allow_idle(clkd);
> if (!secure_copy_data.save_every_cycle)
> secure_ram_saved = 1;
> }
next prev parent reply other threads:[~2010-11-19 17:09 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-19 1:54 [PATCH 00/13] OMAP3: OFF mode fixes Nishanth Menon
2010-11-19 1:54 ` [PATCH 01/13] OMAP3: PM: Update clean_l2 to use v7_flush_dcache_all Nishanth Menon
2010-11-19 9:46 ` Jean Pihet
2010-11-19 9:57 ` Peter 'p2' De Schrijver
2010-11-19 10:15 ` Jean Pihet
2010-11-19 1:54 ` [PATCH 02/13] OMAP3: PM: Errata i581 suppport: dll kick strategy Nishanth Menon
2010-11-24 16:51 ` Sripathy, Vishwanath
2010-11-24 17:24 ` Nishanth Menon
2010-11-25 6:39 ` Sripathy, Vishwanath
2010-11-25 12:22 ` Peter 'p2' De Schrijver
2010-11-19 1:54 ` [PATCH 03/13] OMAP3: PM: make secure ram save size configurable Nishanth Menon
2010-11-19 1:54 ` [PATCH 04/13] OMAP3: PM: Save secure RAM context before entering WFI Nishanth Menon
2010-11-19 1:54 ` [PATCH 05/13] OMAP3: PM: optional save secure RAM context every core off cycle Nishanth Menon
2010-11-19 1:54 ` [PATCH 06/13] OMAP3: PM: Fix secure save size for OMAP3 Nishanth Menon
2010-11-19 1:54 ` [PATCH 07/13] OMAP3: PM: allocate secure RAM context memory from low-mem Nishanth Menon
2010-11-19 1:54 ` [PATCH 08/13] OMAP3: PM: Deny MPU idle while saving secure RAM Nishanth Menon
2010-11-19 17:08 ` Kevin Hilman [this message]
2010-11-19 17:16 ` Nishanth Menon
2010-11-19 17:18 ` Santosh Shilimkar
2010-11-19 17:24 ` Nishanth Menon
2010-11-19 17:28 ` Santosh Shilimkar
2010-11-19 18:51 ` Nishanth Menon
2010-11-19 20:39 ` Kevin Hilman
2010-11-19 20:54 ` Nishanth Menon
2010-11-19 21:06 ` Kevin Hilman
2010-11-19 21:15 ` Nishanth Menon
2010-11-20 10:04 ` Santosh Shilimkar
2010-11-19 19:41 ` Kevin Hilman
2010-11-19 20:18 ` Nishanth Menon
2010-11-19 20:55 ` Kevin Hilman
2010-11-19 21:02 ` Nishanth Menon
2010-11-19 21:09 ` Kevin Hilman
2010-11-20 10:02 ` Santosh Shilimkar
2010-11-19 1:54 ` [PATCH 09/13] OMAP3: PM: Apply errata i540 before save secure ram Nishanth Menon
2010-11-19 10:09 ` Jean Pihet
2010-11-19 12:12 ` Nishanth Menon
2010-11-19 12:54 ` Jean Pihet
2010-11-19 17:15 ` Kevin Hilman
2010-11-19 17:18 ` Nishanth Menon
2010-11-19 19:47 ` Kevin Hilman
2010-11-19 20:08 ` Nishanth Menon
2010-11-19 1:54 ` [PATCH 10/13] OMAP3: PM: Errata i582: per domain reset issue: uart Nishanth Menon
2010-11-22 18:59 ` Kevin Hilman
2010-11-19 1:54 ` [PATCH 11/13] OMAP3630: PM: Errata i608: disable RTA Nishanth Menon
2010-11-19 9:57 ` Jean Pihet
2010-11-19 12:09 ` Nishanth Menon
2010-11-19 1:54 ` [PATCH 12/13] OMAP3630: PM: Disable L2 cache while invalidating L2 cache Nishanth Menon
2010-11-19 1:54 ` [PATCH 13/13] OMAP3630: PM: Errata i583: disable coreoff if < ES1.2 Nishanth Menon
2010-11-19 10:07 ` Jean Pihet
2010-11-19 12:14 ` Nishanth Menon
2010-11-19 10:18 ` [PATCH 00/13] OMAP3: OFF mode fixes Jean Pihet
2010-11-19 12:03 ` Nishanth Menon
2010-11-19 21:20 ` Kevin Hilman
2010-11-19 21:37 ` Nishanth Menon
2010-11-20 9:56 ` Santosh Shilimkar
2010-11-22 16:08 ` Kevin Hilman
2010-11-22 19:16 ` Kevin Hilman
2010-11-23 9:02 ` Santosh Shilimkar
2010-11-23 20:35 ` Kevin Hilman
2010-11-24 5:34 ` Santosh Shilimkar
2010-11-24 9:22 ` Santosh Shilimkar
2010-11-24 17:11 ` Jean Pihet
2010-11-24 17:21 ` Nishanth Menon
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=87eiahckba.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=jean.pihet@newoldbits.com \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--cc=tony@atomide.com \
--cc=vishwanath.bs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.