> -----Original Message-----
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Tuesday, January 25, 2011 5:17 PM
> To: Santosh Shilimkar
> Cc: linux-arm-ker...@lists.infradead.org; catalin.mari...@arm.com;
> ccr...@android.com; linus.ml.wall...@gmail.com; linux-
> o...@vger.kernel.org
> Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header
> file
>
> On Mon, Jan 24, 2011 at 02:21:18PM +0530, Santosh Shilimkar wrote:
> > This patch moves SCU register defines from smp_scu.c to smp_scu.h
> > so that its available for platforms to use
> >
> > The SCU CPU power status registers is used for power management
> > on OMAP4.
>
> Could we instead have an API inside smp_scu.c rather than having
> each
> SoC implement its own SCU PM stuff?
>
I have similar patch implemented but what it does is just
prepares the value to be programmed and stores it to a scratchpad.
I see your point but below patch may now work well. The reason is the SCU
register needs to accessed at the lowest level. May be even when
stack is not available. Also this register needs to be cleared in cases
where the attempted power state is failed for some reason.

Also note that this register can be blocked using trust-zone which
again makes it platform dependent because direct write won't be
allowed in that case.

> Maybe this.  Note that scu_power_mode() needs to be called from a
> non-
> preemptible context, which is sane as we don't want to be
> rescheduled
> onto a different CPU between scu_power_mode() and the wfi/wfe
> required
> to enter the selected mode.
>
I would prefer the header export if there is no major
objection since there is already a possibility of custom
implementation with trust zone.

On OMAP4, on ES1.0 we need to use a secure API to achieve
this where as on ES2.0, it can be directly accessed.

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to