[PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support

[Russ Dill]

On Thu, Aug 29, 2013 at 2:33 PM, Kevin Hilman <khilman at linaro.org> wrote:
> Vaibhav Bedia <vaibhav.bedia at gmail.com> writes:
[snip]
>> Morevoer, all the suggestions on how to keep the code in Linux working
>> around the complications due to the main memory not being accessible
>> will need to be replicated on the non-Linux s/w stacks and that's just
>> make it more difficult for them.
>
> The linux code has to be very self-contained (in assembler or C), so I'm
> not sure how it's difficult to replicated in any other OS (or non-OS.)

Let me pull on this thread a little bit. Would this involve defining a
bunch of different sections for each arch so that I could do:

void __sram_am33xx am33xx_some_pm_function(args....)
{
}

static struct am33xx_foo_dyn *blargity __sramdata_am33xx = { ...};

static const struct am33xx_foo_const *blarg __sramconst_am33xx = { ... };

The sram push code could then push these sections into sram. There
would then be a set of inlines or macros for converting addresses
within these sections to SRAM addresses, maybe also inlines or macros
for calling code that has been pushed into sram by wrapping the
original function pointer. The macros or inlines that call SRAM code
could perform the trampoline as well.

Would there be much general interest in a scheme like this? Is there
already I scheme like this I haven't noticed. Would such an explosion
of sections be a problem if all platforms started using this for SRAM
code?