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

2013-09-03 Thread Sekhar Nori
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 0x4030 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  0x4030
>>>  
>>> from sram.h
>>> ---
>>>  #define OMAP2_SRAM_PA  0x4020
>>>  #define OMAP3_SRAM_PA   0x4020
>>> -#ifdef CONFIG_OMAP4_ERRATA_I688
>>> -#define OMAP4_SRAM_PA  0x40304000
>>> -#define OMAP4_SRAM_VA  0xfe404000
>>> -#else
>>> -#define OMAP4_SRAM_PA  0x4030
>>> -#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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2013-09-02 Thread Sekhar Nori
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 0x4030 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   0x4030
>>  
>> from sram.h
>> ---
>>  #define OMAP2_SRAM_PA   0x4020
>>  #define OMAP3_SRAM_PA   0x4020
>> -#ifdef CONFIG_OMAP4_ERRATA_I688
>> -#define OMAP4_SRAM_PA   0x40304000
>> -#define OMAP4_SRAM_VA   0xfe404000
>> -#else
>> -#define OMAP4_SRAM_PA   0x4030
>> -#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.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2013-08-29 Thread Santosh Shilimkar
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 0x4030 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_PAOMAP4_SRAM_PA
> -#else
> -#define OMAP4_SRAM_PUB_PA(OMAP4_SRAM_PA + 0x4000)
> -#endif
> -#define OMAP5_SRAM_PA0x4030
>  
> from sram.h
> ---
>  #define OMAP2_SRAM_PA0x4020
>  #define OMAP3_SRAM_PA   0x4020
> -#ifdef CONFIG_OMAP4_ERRATA_I688
> -#define OMAP4_SRAM_PA0x40304000
> -#define OMAP4_SRAM_VA0xfe404000
> -#else
> -#define OMAP4_SRAM_PA0x4030
> -#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 ;-)

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2013-08-29 Thread Rajendra Nayak
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 0x4030 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  0x4030
 
from sram.h
---
 #define OMAP2_SRAM_PA  0x4020
 #define OMAP3_SRAM_PA   0x4020
-#ifdef CONFIG_OMAP4_ERRATA_I688
-#define OMAP4_SRAM_PA  0x40304000
-#define OMAP4_SRAM_VA  0xfe404000
-#else
-#define OMAP4_SRAM_PA  0x4030
-#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.

> 
> Regards,
> Santosh
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2013-08-29 Thread Santosh Shilimkar
On Thursday 29 August 2013 09:44 AM, Sekhar Nori wrote:
> On 8/29/2013 7: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 0x4030 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.
> 
> Okay, the same problem is not applicable to OMAP5 and other devices? I
> am okay with this as such, may be just add a comment explaining why
> there is an offset.
> 
>From specs the errata is applicable only for O4 though OMAP5 downstream
kernel enabled it. Its ok to limit this one for O5 now.

Regards,
Santosh

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2013-08-29 Thread Sekhar Nori
On 8/29/2013 7: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 0x4030 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.

Okay, the same problem is not applicable to OMAP5 and other devices? I
am okay with this as such, may be just add a comment explaining why
there is an offset.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2013-08-29 Thread Santosh Shilimkar
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 0x4030 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.

Regards,
Santosh

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2013-08-29 Thread Sekhar Nori
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 0x4030 now that you have moved to
gen_pool_alloc()?

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2013-08-29 Thread Rajendra Nayak
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 plat-omap/sram.c

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.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/boot/dts/am33xx.dtsi|5 ++---
 arch/arm/boot/dts/am4372.dtsi|5 +
 arch/arm/boot/dts/omap4.dtsi |5 +
 arch/arm/boot/dts/omap5.dtsi |5 +
 arch/arm/configs/omap2plus_defconfig |1 +
 arch/arm/mach-omap2/sram.c   |   26 +-
 arch/arm/mach-omap2/sram.h   |1 -
 7 files changed, 19 insertions(+), 29 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..69cbce9 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -482,9 +482,8 @@
};
 
ocmcram: ocmcram@4030 {
-   compatible = "ti,am3352-ocmcram";
-   reg = <0x4030 0x1>;
-   ti,hwmods = "ocmcram";
+   compatible = "mmio-sram";
+   reg = <0x4030 0x1>; /* 64k */
};
 
wkup_m3: wkup_m3@44d0 {
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..5c8cee1 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,10 @@
compatible = 
"ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
};
+
+   ocmcram: ocmcram@4030 {
+   compatible = "mmio-sram";
+   reg = <0x4030 0x4>; /* 256k */
+   };
};
 };
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 {
+   compatible = "mmio-sram";
+   reg = <0x40304000 0xa000>; /* 40k */
+   };
+
sdma: dma-controller@4a056000 {
compatible = "ti,omap4430-sdma";
reg = <0x4a056000 0x1000>;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..461ffd8 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -119,6 +119,11 @@
pinctrl-single,function-mask = <0x7fff>;
};
 
+   ocmcram: ocmcram@4030 {
+   compatible = "mmio-sram";
+   reg = <0x4030 0x2>; /* 128k */
+   };
+
sdma: dma-controller@4a056000 {
compatible = "ti,omap4430-sdma";
reg = <0x4a056000 0x1000>;
diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 5339e6a..5d4c9b8 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -101,6 +101,7 @@ CONFIG_SENSORS_LIS3LV02D=m
 CONFIG_SENSORS_TSL2550=m
 CONFIG_SENSORS_LIS3_I2C=m
 CONFIG_BMP085_I2C=m
+CONFIG_SRAM=y
 CONFIG_SCSI=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_SCSI_MULTI_LUN=y
diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index 305fc2b..d5ecb75 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -32,12 +32,6 @@
 
 #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  0x4030
 
 #define SRAM_BOOTLOADER_SZ 0x00
 
@@ -105,32 +99,14 @@ static void __init omap_detect_sram(void)
} else {
omap_sram_size = 0x8000; /* 32K */
}
-   } else if (cpu_is_omap44xx()) {
-   omap_sram_start = OMAP4_SRAM_PUB_PA;
-   omap_sram_size = 0xa000; /* 40K */
-   } else if (soc_is_omap54xx()) {
-   omap_sram_start = OMAP5_SRAM_PA;
-   omap_sram_size = SZ_128K; /* 128KB */
} else {
omap_sram_start = OMAP2_SRAM_PUB_PA;
omap_sram_size = 0x800; /* 2K */
}
} else {
-   if (soc_is_am33xx()) {
-   omap_sram_start = AM33XX_SRAM_PA;
-   omap_sram_size = 0x1; /* 64K */
-