No subject

until the CPU enters WFI mode - which means that provided we can
guarantee no one issues a WFI instruction between setting the power mode,
and executing that instruction, being woken up (or failing) and resetting
the power mode back... that shouldn't require the power mode to be
programmed from assembly code.

In any case, we actually need the help of spinlocks to deal with
concurrent access to the SCU power control register - something you
can't do in assembly code.

On the way down to a WFI low power mode, we can call scu_power_mode(),
do the rest of the cleanup (which must not schedule) and issue WFI.  On
the way back up, do whatever needs to be done and call scu_power_mode()
to reset back to 'normal' mode.

> 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.

Yes, I did notice.  What's the OMAP SMC interface for that?

> 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.

As I say, I'd rather not have each SoC implementing access to this as
someone's bound to forget the spinlock if they're dealing with more than
one CPU, which'll make stuff unreliable (just like I did on my initial
version.)

We could have a callback to SoC code which does the appropriate SMC call,
but first I'll need to know what's required for the SMC call.