On Mon, 23 May 2011, Dave Martin wrote:
> On Mon, May 23, 2011 at 05:11:49PM +0100, Russell King - ARM Linux wrote:
[ ... ]
>> I tend to suggest that the header file is the right place, because that's
>> where the interface is defined. Other people argue that its more likely
>> to be seen in the implementation (fiq.c). So I'm tempted to say both,
>> but lets go with fiq.h for the time being.
>
> OK -- the {get,set}_fiq_regs patch is currently in your patch system.
>
> If you have no objection, I'll submit a patch adding the above text to apply
> on top of the other patch (or, if possible, orthogonally).
>
> ---Dave
Thanks a lot !
>
>>
>>> That argument may apply to a ton of state in the Secure World, not just
>>> the FIQ registers
>>
>> It very much does, and I know OMAP has some kind of SMC call to handle
>> this.
>
Yes, _omap_sram_idle() does that bit, it gives a physical address to the
OMAP ROM code to save/restore the "secure state" in, triggered via smc.
Anyway, architecturally it seems to be much cleaner to _allow_ device
drivers (or machine-specific hooks) to save/restore _more_ state than
whatever the "core suspend code" would do, instead of _forcing_ the core
suspend code to do everything-and-the-kitchen-sink.
That's where things like FIQ or secure state would be.
FrankH.
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
