[PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY

Santosh Shilimkar santosh.shilimkar at ti.com
Fri Oct 7 11:03:02 EDT 2011


On Friday 07 October 2011 08:13 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar at ti.com> [111006 23:06]:
>> On Thursday 06 October 2011 03:36 AM, Tony Lindgren wrote:
>>> * Nicolas Pitre <nico at fluxnic.net> [111004 17:26]:
>>>> On Tue, 4 Oct 2011, Tony Lindgren wrote:
>>> +void __iomem *
>>> +__arm_ioremap_exec(unsigned long phys_addr, size_t size, int cached)
>>> +{
>>> +	unsigned int mtype;
>>> +
>>> +	if (cached)
>>> +		mtype = MT_MEMORY;
>>> +	else
>>> +		mtype = MT_MEMORY_NONCACHED;
>>> +
>> Why don't we allow user to pass the mtype here ?
> 
> Well we want to keep the MT_MEMORY types out of asm/io.h.
> 
ok.

>> We do have a need also to map a page of DDR and SRAM as
>> strongly ordered for errata fix and this interface can be
>> used for that.
> 
> Yeah..
> 
>> Ofcourse, SO memory type is not executable memories, so the
>> API name might be miss-leading.
> 
> ..so I think we should just have a separate static mapping for
> the omap4 errata fix SO page, and just limit the memory available
> for SRAM code to ioremap.
> 
> How does that sounds to you?
> 
That's more or less what the patch is already doing.
Instead of static mapping, I was dynamically stealing one
page ( SZ_4K) and mapping it as MT_MEMORY_SO and rest
of the memory as MT_MEMORY for OMAP4.

It should be doable with your updates as well,
I guess with or without static mapping since the only
requisite is to keep one page of SRAM free on OMAP4 and
them map them using  iotable_init() with MT_MEMORY_SO.

Regards
Santosh






More information about the linux-arm-kernel mailing list