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

[Sekhar Nori <nsekhar@ti.com>]

On 9/2/2013 10:33 PM, Sekhar Nori wrote:
> On 8/29/2013 7:21 PM, Santosh Shilimkar wrote:
>> On Thursday 29 August 2013 09:50 AM, Rajendra Nayak wrote:
>>> On Thursday 29 August 2013 07:01 PM, Santosh Shilimkar wrote:
>>>> On Thursday 29 August 2013 09:26 AM, Sekhar Nori wrote:
>>>>> On 8/29/2013 4:53 PM, Rajendra Nayak wrote:
>>>>>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>>>>>> index 22d9f2b..1ba6a77 100644
>>>>>> --- a/arch/arm/boot/dts/omap4.dtsi
>>>>>> +++ b/arch/arm/boot/dts/omap4.dtsi
>>>>>> @@ -126,6 +126,11 @@
>>>>>>  			pinctrl-single,function-mask = <0x7fff>;
>>>>>>  		};
>>>>>>  
>>>>>> +		ocmcram: ocmcram@40304000 {
>>>>>
>>>>> This can now be changed to 0x40300000 now that you have moved to
>>>>> gen_pool_alloc()?
>>>>>
>>>> NO.
>>>> It won't work on secure devices since first 16 KB is occupied for
>>>> default configuration. Its not worth trouble also to handle
>>>> secure/non-secure considering the use of SRAM which is actually just
>>>> limited to errata. 40304000 will work for both devices.
>>>
>>> Right. Sekhar, you might have confused because of the existing buggy code
>>> in sram.c and sram.h which did this (and is removed in this series)
>>>
>>> from sram.c
>>> -----------
>>>  #define OMAP2_SRAM_PUB_PA	(OMAP2_SRAM_PA + 0xf800)
>>>  #define OMAP3_SRAM_PUB_PA       (OMAP3_SRAM_PA + 0x8000)
>>> -#ifdef CONFIG_OMAP4_ERRATA_I688
>>> -#define OMAP4_SRAM_PUB_PA	OMAP4_SRAM_PA
>>> -#else
>>> -#define OMAP4_SRAM_PUB_PA	(OMAP4_SRAM_PA + 0x4000)
>>> -#endif
>>> -#define OMAP5_SRAM_PA		0x40300000
>>>  
>>> from sram.h
>>> -----------
>>>  #define OMAP2_SRAM_PA		0x40200000
>>>  #define OMAP3_SRAM_PA           0x40200000
>>> -#ifdef CONFIG_OMAP4_ERRATA_I688
>>> -#define OMAP4_SRAM_PA		0x40304000
>>> -#define OMAP4_SRAM_VA		0xfe404000
>>> -#else
>>> -#define OMAP4_SRAM_PA		0x40300000
>>> -#endif
>>>
>>> I am not sure where the checks for CONFIG_OMAP4_ERRATA_I688
>>> came in from, but these are done, like Santosh said, to handle
>>> secure and non-secure sram across GP and HS devices and in
>>> no way related to handling errata I688.
>>>
>> The check was to ensure that with errata enabled, we don't care
>> about first 16 KB ;-)
> 
> Hi Rajendra, thanks for the explanation. Other devices like AM437x which
> have HS variants might need such adjustment too. It will be nice to
> check that.

So I checked with folks working on the HS variant and what you have for
AM437x is just fine. The secure runtime uses a different SRAM bank and
even if there is a need to use the GP SRAM, the space will first be
carved using gen_pool APIs on Linux. Only requirement from secure
runtime software is physically contiguous area - which I think
gen_pool_alloc() guarantees.

Thanks,
Sekhar