Russ Dill <Russ.Dill@xxxxxx> writes:
> On Thu, Aug 29, 2013 at 2:33 PM, Kevin Hilman <khilman@xxxxxxxxxx> wrote:
>> Vaibhav Bedia <vaibhav.bedia@xxxxxxxxx> 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.
Well, I was thinking of something much dumber.
I was thinking about just _carefully_ writing a single, self-contained C
function, with all of its data on the stack (and consts as #defines).
Think of it is a step up in readability from straight assembly (which
was the stated reason for moving the code to the M3 in the first place.)
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
