RE: [PATCH 08/13] OMAP3: PM: Deny MPU idle while saving secure RAM

[Santosh Shilimkar <santosh.shilimkar@ti.com>]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Friday, November 19, 2010 10:39 PM
> To: Nishanth Menon
> Cc: linux-omap; Jean Pihet; Vishwanath Sripathy; Tony
> Subject: Re: [PATCH 08/13] OMAP3: PM: Deny MPU idle while saving secure
> RAM
>
> 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.
>
On the related topic I posted a patch some time back.
http://www.spinics.net/lists/linux-omap/msg37907.html
I guess Kevin is referring to the above patch.

Regards,
Santosh