[PATCH 2/2] ARM: OMAP4+: Move SRAM data to DT

Russ Dill Russ.Dill at ti.com
Tue Sep 3 11:07:56 EDT 2013


On Tue, Sep 3, 2013 at 7:35 AM, Lucas Stach <l.stach at pengutronix.de> wrote:
> Am Dienstag, den 03.09.2013, 06:56 -0700 schrieb Russ Dill:
>> On Tue, Aug 27, 2013 at 3:11 AM, Rajendra Nayak <rnayak at ti.com> wrote:
>> > Use drivers/misc/sram.c driver to manage SRAM on all DT only
>> > OMAP platforms (am33xx, am43xx, omap4 and omap5) instead of
>> > the existing private implementation.
>> >
>> > Address and size related data  is removed from mach-omap2/sram.c
>> > and now passed to drivers/misc/sram.c from DT.
>> >
>> > Users can hence use general purpose allocator apis instead of
>> > OMAP private ones to manage and use SRAM.
>> >
>> > Currently there are no users on SRAM on these platfoms.
>> >
>> > Signed-off-by: Rajendra Nayak <rnayak at ti.com>
>>
>> I was trying to experiment with this on am33xx, but I noticed that the
>> ioremap region is not marked exec, so it cannot be used to run code.
>
> Could you outline a use-case where you would need to execute code from
> SRAM while running in a linux system? I'm curious what you would use
> this for.

Code that needs to disable or reconfigure the memory controller is the
common use case. Some suspend/resume code even goes beyond that and
performs steps that must be done *after* the memory controller has
powered down, such as putting PLLs in bypass, etc.



More information about the linux-arm-kernel mailing list