[PATCH 0/2] OMAP4+: Get rid of internal SRAM handling

[PATCH 0/2] OMAP4+: Get rid of internal SRAM handling

[Rajendra Nayak]

Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5)
use drivers/misc/sram.c driver instead of the omap internal
implementation for SRAM handling.

Rajendra Nayak (2):
  ARM: AM335x: Get rid of unused sram init function
  ARM: OMAP4+: Move SRAM data to DT

 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           |   39 +---------------------------------
 arch/arm/mach-omap2/sram.h           |    1 -
 7 files changed, 22 insertions(+), 39 deletions(-)

-- 
1.7.9.5

[PATCH 1/2] ARM: AM335x: Get rid of unused sram init function

[Rajendra Nayak]

Remove the empty am33xx_sram_init() function.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/sram.c |    7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index 4bd0968..305fc2b 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -285,11 +285,6 @@ static inline int omap34xx_sram_init(void)
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
-static inline int am33xx_sram_init(void)
-{
-	return 0;
-}
-
 int __init omap_sram_init(void)
 {
 	omap_detect_sram();
@@ -299,8 +294,6 @@ int __init omap_sram_init(void)
 		omap242x_sram_init();
 	else if (cpu_is_omap2430())
 		omap243x_sram_init();
-	else if (soc_is_am33xx())
-		am33xx_sram_init();
 	else if (cpu_is_omap34xx())
 		omap34xx_sram_init();
 
-- 
1.7.9.5

[PATCH 1/2] ARM: AM335x: Get rid of unused sram init function

[Dave Gerlach]

On 08/27/2013 05:11 AM, Rajendra Nayak wrote:
> Remove the empty am33xx_sram_init() function.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
>   arch/arm/mach-omap2/sram.c |    7 -------
>   1 file changed, 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
> index 4bd0968..305fc2b 100644
> --- a/arch/arm/mach-omap2/sram.c
> +++ b/arch/arm/mach-omap2/sram.c
> @@ -285,11 +285,6 @@ static inline int omap34xx_sram_init(void)
>   }
>   #endif /* CONFIG_ARCH_OMAP3 */
>
> -static inline int am33xx_sram_init(void)
> -{
> -	return 0;
> -}
> -
>   int __init omap_sram_init(void)
>   {
>   	omap_detect_sram();
> @@ -299,8 +294,6 @@ int __init omap_sram_init(void)
>   		omap242x_sram_init();
>   	else if (cpu_is_omap2430())
>   		omap243x_sram_init();
> -	else if (soc_is_am33xx())
> -		am33xx_sram_init();
>   	else if (cpu_is_omap34xx())
>   		omap34xx_sram_init();
>
>

Suspend resume for AM33xx as of right now uses this function. This patch 
[1] uses this function to push the low-level suspend code to sram, it 
was added here to be consistent with other platforms that utilize the 
same type of functionality (omap34xx).

Regards,
Dave

[1] http://marc.info/?l=linux-omap&m=137581164813160&w=2

[PATCH 1/2] ARM: AM335x: Get rid of unused sram init function

[Rajendra Nayak]

On Tuesday 27 August 2013 09:36 PM, Dave Gerlach wrote:
> On 08/27/2013 05:11 AM, Rajendra Nayak wrote:
>> Remove the empty am33xx_sram_init() function.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> ---
>>   arch/arm/mach-omap2/sram.c |    7 -------
>>   1 file changed, 7 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
>> index 4bd0968..305fc2b 100644
>> --- a/arch/arm/mach-omap2/sram.c
>> +++ b/arch/arm/mach-omap2/sram.c
>> @@ -285,11 +285,6 @@ static inline int omap34xx_sram_init(void)
>>   }
>>   #endif /* CONFIG_ARCH_OMAP3 */
>>
>> -static inline int am33xx_sram_init(void)
>> -{
>> -    return 0;
>> -}
>> -
>>   int __init omap_sram_init(void)
>>   {
>>       omap_detect_sram();
>> @@ -299,8 +294,6 @@ int __init omap_sram_init(void)
>>           omap242x_sram_init();
>>       else if (cpu_is_omap2430())
>>           omap243x_sram_init();
>> -    else if (soc_is_am33xx())
>> -        am33xx_sram_init();
>>       else if (cpu_is_omap34xx())
>>           omap34xx_sram_init();
>>
>>
> 
> Suspend resume for AM33xx as of right now uses this function. This patch [1] uses this function to push the low-level suspend code to sram, it was added here to be consistent with other platforms that utilize the same type of functionality (omap34xx).

Right, but if you look at patch 2/2 in the series, that basically moves all OMAP DT only platforms from using legacy
OMAP private apis to push code/manage sram to using the generic gen_pool apis to manage sram.
Can you look at how you can use gen_pool for am33xx instead of the way omap3 does it, since we want to completely
get rid of the internal sram management apis (or atleast have them only for legacy non-DT OMAP platforms).


> 
> Regards,
> Dave
> 
> [1] http://marc.info/?l=linux-omap&m=137581164813160&w=2

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

[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 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@ti.com>
---
 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           |   32 +-------------------------------
 arch/arm/mach-omap2/sram.h           |    1 -
 7 files changed, 22 insertions(+), 32 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..6ed766e 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -88,6 +88,11 @@
 		ranges;
 		ti,hwmods = "l3_main";
 
+		sram: sram at 40300000 {
+			compatible = "mmio-sram";
+			reg = <0x40300000 0x10000>; /* 64k */
+		};
+
 		intc: interrupt-controller at 48200000 {
 			compatible = "ti,omap2-intc";
 			interrupt-controller;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..c78b74f 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -41,6 +41,11 @@
 		#size-cells = <1>;
 		ranges;
 
+		sram: sram at 40300000 {
+			compatible = "mmio-sram";
+			reg = <0x40300000 0x40000>; /* 256k */
+		};
+
 		uart0: serial at 44e09000 {
 			compatible = "ti,am4372-uart","ti,omap2-uart";
 			reg = <0x44e09000 0x2000>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..292e5b5 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -126,6 +126,11 @@
 			pinctrl-single,function-mask = <0x7fff>;
 		};
 
+		sram: sram at 40304000 {
+			compatible = "mmio-sram";
+			reg = <0x40304000 0xa000>; /* 40k */
+		};
+
 		sdma: dma-controller at 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..a9e3e6c 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -119,6 +119,11 @@
 			pinctrl-single,function-mask = <0x7fff>;
 		};
 
+		sram: sram at 40300000 {
+			compatible = "mmio-sram";
+			reg = <0x40300000 0x20000>; /* 128k */
+		};
+
 		sdma: dma-controller at 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..8591044 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		0x40300000
 
 #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 = 0x10000; /* 64K */
-		} else if (soc_is_am43xx()) {
-			omap_sram_start = AM33XX_SRAM_PA;
-			omap_sram_size = SZ_256K;
-		} else if (cpu_is_omap34xx()) {
+		if (cpu_is_omap34xx()) {
 			omap_sram_start = OMAP3_SRAM_PA;
 			omap_sram_size = 0x10000; /* 64K */
-		} else if (cpu_is_omap44xx()) {
-			omap_sram_start = OMAP4_SRAM_PA;
-			omap_sram_size = 0xe000; /* 56K */
-		} else if (soc_is_omap54xx()) {
-			omap_sram_start = OMAP5_SRAM_PA;
-			omap_sram_size = SZ_128K; /* 128KB */
 		} else {
 			omap_sram_start = OMAP2_SRAM_PA;
 			if (cpu_is_omap242x())
@@ -148,12 +124,6 @@ static void __init omap2_map_sram(void)
 {
 	int cached = 1;
 
-#ifdef CONFIG_OMAP4_ERRATA_I688
-	if (cpu_is_omap44xx()) {
-		omap_sram_start += PAGE_SIZE;
-		omap_sram_size -= SZ_16K;
-	}
-#endif
 	if (cpu_is_omap34xx()) {
 		/*
 		 * SRAM must be marked as non-cached on OMAP3 since the
diff --git a/arch/arm/mach-omap2/sram.h b/arch/arm/mach-omap2/sram.h
index ca7277c..3f83b80 100644
--- a/arch/arm/mach-omap2/sram.h
+++ b/arch/arm/mach-omap2/sram.h
@@ -80,4 +80,3 @@ static inline void omap_push_sram_idle(void) {}
 #else
 #define OMAP4_SRAM_PA		0x40300000
 #endif
-#define AM33XX_SRAM_PA		0x40300000
-- 
1.7.9.5

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

[Sekhar Nori]

On Tuesday 27 August 2013 03:41 PM, Rajendra Nayak 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@ti.com>

Nice getting rid of code.

> diff --git a/arch/arm/mach-omap2/sram.h b/arch/arm/mach-omap2/sram.h
> index ca7277c..3f83b80 100644
> --- a/arch/arm/mach-omap2/sram.h
> +++ b/arch/arm/mach-omap2/sram.h
> @@ -80,4 +80,3 @@ static inline void omap_push_sram_idle(void) {}
>  #else
>  #define OMAP4_SRAM_PA		0x40300000
>  #endif
> -#define AM33XX_SRAM_PA		0x40300000

I guess OMAP4_SRAM_PA is left in the code to take care of errata I688?
How about removing the iotable entry for SRAM on OMAP4 and converting
omap_barriers_init() to use the gen_pool API instead of passing an
incremented address to DT?

SRAM driver is a postcore initcall so I think you it will be ready
before first WFI hits (which is when the errata triggers).

Thanks,
Sekhar

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

[Rajendra Nayak]

On Tuesday 27 August 2013 04:53 PM, Sekhar Nori wrote:
> On Tuesday 27 August 2013 03:41 PM, Rajendra Nayak 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@ti.com>
> 
> Nice getting rid of code.
> 
>> diff --git a/arch/arm/mach-omap2/sram.h b/arch/arm/mach-omap2/sram.h
>> index ca7277c..3f83b80 100644
>> --- a/arch/arm/mach-omap2/sram.h
>> +++ b/arch/arm/mach-omap2/sram.h
>> @@ -80,4 +80,3 @@ static inline void omap_push_sram_idle(void) {}
>>  #else
>>  #define OMAP4_SRAM_PA		0x40300000
>>  #endif
>> -#define AM33XX_SRAM_PA		0x40300000
> 
> I guess OMAP4_SRAM_PA is left in the code to take care of errata I688?

right.

> How about removing the iotable entry for SRAM on OMAP4 and converting
> omap_barriers_init() to use the gen_pool API instead of passing an
> incremented address to DT?

Actually we dont really need to alloc and manage any sram pool for handling
the errata. It just needs to know an sram location which it can read and write
back into (which can be any sram location used/unused).
I should be able to get rid of the iotable entry and get the sram address from
DT instead.

> 
> SRAM driver is a postcore initcall so I think you it will be ready
> before firstts  WFI hi(which is when the errata triggers).

right, so that not an issue.

> 
> Thanks,
> Sekhar
> 

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

[Sekhar Nori]

On Wednesday 28 August 2013 11:53 AM, Rajendra Nayak wrote:
> On Tuesday 27 August 2013 04:53 PM, Sekhar Nori wrote:
>> On Tuesday 27 August 2013 03:41 PM, Rajendra Nayak 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@ti.com>
>>
>> Nice getting rid of code.
>>
>>> diff --git a/arch/arm/mach-omap2/sram.h b/arch/arm/mach-omap2/sram.h
>>> index ca7277c..3f83b80 100644
>>> --- a/arch/arm/mach-omap2/sram.h
>>> +++ b/arch/arm/mach-omap2/sram.h
>>> @@ -80,4 +80,3 @@ static inline void omap_push_sram_idle(void) {}
>>>  #else
>>>  #define OMAP4_SRAM_PA		0x40300000
>>>  #endif
>>> -#define AM33XX_SRAM_PA		0x40300000
>>
>> I guess OMAP4_SRAM_PA is left in the code to take care of errata I688?
> 
> right.
> 
>> How about removing the iotable entry for SRAM on OMAP4 and converting
>> omap_barriers_init() to use the gen_pool API instead of passing an
>> incremented address to DT?
> 
> Actually we dont really need to alloc and manage any sram pool for handling
> the errata. It just needs to know an sram location which it can read and write
> back into (which can be any sram location used/unused).

But there will be a race with other writes to SRAM since omap_bus_sync()
is not atomic context.

Thanks,
Sekhar

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

[Rajendra Nayak]

On Wednesday 28 August 2013 03:54 PM, Sekhar Nori wrote:
> On Wednesday 28 August 2013 11:53 AM, Rajendra Nayak wrote:
>> On Tuesday 27 August 2013 04:53 PM, Sekhar Nori wrote:
>>> On Tuesday 27 August 2013 03:41 PM, Rajendra Nayak 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@ti.com>
>>>
>>> Nice getting rid of code.
>>>
>>>> diff --git a/arch/arm/mach-omap2/sram.h b/arch/arm/mach-omap2/sram.h
>>>> index ca7277c..3f83b80 100644
>>>> --- a/arch/arm/mach-omap2/sram.h
>>>> +++ b/arch/arm/mach-omap2/sram.h
>>>> @@ -80,4 +80,3 @@ static inline void omap_push_sram_idle(void) {}
>>>>  #else
>>>>  #define OMAP4_SRAM_PA		0x40300000
>>>>  #endif
>>>> -#define AM33XX_SRAM_PA		0x40300000
>>>
>>> I guess OMAP4_SRAM_PA is left in the code to take care of errata I688?
>>
>> right.
>>
>>> How about removing the iotable entry for SRAM on OMAP4 and converting
>>> omap_barriers_init() to use the gen_pool API instead of passing an
>>> incremented address to DT?
>>
>> Actually we dont really need to alloc and manage any sram pool for handling
>> the errata. It just needs to know an sram location which it can read and write
>> back into (which can be any sram location used/unused).
> 
> But there will be a race with other writes to SRAM since omap_bus_sync()
> is not atomic context.

Right, I completely overlooked the fact that omap_bus_sync() is also done every
wmb(). I was thinking its needed only just before a wfi.

I will repost a v2 using gen_pool to allocate sram space to handle errata I688
and get rid of all the static mappings.

regards,
Rajendra
> 
> Thanks,
> Sekhar
> 

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

[Russ Dill]

On Tue, Aug 27, 2013 at 3:11 AM, Rajendra Nayak <rnayak@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@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.

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

[Lucas Stach]

Am Dienstag, den 03.09.2013, 06:56 -0700 schrieb Russ Dill:
> On Tue, Aug 27, 2013 at 3:11 AM, Rajendra Nayak <rnayak@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@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.

Regards,
Lucas
-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

[Russ Dill]

On Tue, Sep 3, 2013 at 7:35 AM, Lucas Stach <l.stach@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@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@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.

[PATCH 0/2] OMAP4+: Get rid of internal SRAM handling

[Santosh Shilimkar]

+ Paul,

On Tuesday 27 August 2013 06:11 AM, Rajendra Nayak wrote:
> Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5)
> use drivers/misc/sram.c driver instead of the omap internal
> implementation for SRAM handling.
> 
> Rajendra Nayak (2):
>   ARM: AM335x: Get rid of unused sram init function
>   ARM: OMAP4+: Move SRAM data to DT
> 
>  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           |   39 +---------------------------------
>  arch/arm/mach-omap2/sram.h           |    1 -
>  7 files changed, 22 insertions(+), 39 deletions(-)
> 
Really nice to see the SRAM code getting moved now. Thanks
a lot Rajendra.

- The sram_init() seems to be the post core init call.
Hope this is not a problem for SDRC init which needs to have
SRAM ready to update the DDR parameters.

Regards,
Santosh

[PATCH 0/2] OMAP4+: Get rid of internal SRAM handling

[Rajendra Nayak]

On Tuesday 27 August 2013 06:55 PM, Santosh Shilimkar wrote:
> + Paul,
> 
> On Tuesday 27 August 2013 06:11 AM, Rajendra Nayak wrote:
>> Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5)
>> use drivers/misc/sram.c driver instead of the omap internal
>> implementation for SRAM handling.
>>
>> Rajendra Nayak (2):
>>   ARM: AM335x: Get rid of unused sram init function
>>   ARM: OMAP4+: Move SRAM data to DT
>>
>>  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           |   39 +---------------------------------
>>  arch/arm/mach-omap2/sram.h           |    1 -
>>  7 files changed, 22 insertions(+), 39 deletions(-)
>>
> Really nice to see the SRAM code getting moved now. Thanks
> a lot Rajendra.
> 
> - The sram_init() seems to be the post core init call.
> Hope this is not a problem for SDRC init which needs to have
> SRAM ready to update the DDR parameters.

It should be fine given its needed only during core dvfs. Besides
drivers/misc/sram.c is useful only on DT platforms, so for now OMAP2/3
continue to use the omap specific sram handling.

> 
> Regards,
> Santosh
> 
> 

[PATCH 0/2] OMAP4+: Get rid of internal SRAM handling

[Santosh Shilimkar]

On Wednesday 28 August 2013 02:29 AM, Nayak, Rajendra wrote:
> On Tuesday 27 August 2013 06:55 PM, Santosh Shilimkar wrote:
>> + Paul,
>>
>> On Tuesday 27 August 2013 06:11 AM, Rajendra Nayak wrote:
>>> Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5)
>>> use drivers/misc/sram.c driver instead of the omap internal
>>> implementation for SRAM handling.
>>>
>>> Rajendra Nayak (2):
>>>   ARM: AM335x: Get rid of unused sram init function
>>>   ARM: OMAP4+: Move SRAM data to DT
>>>
>>>  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           |   39 +---------------------------------
>>>  arch/arm/mach-omap2/sram.h           |    1 -
>>>  7 files changed, 22 insertions(+), 39 deletions(-)
>>>
>> Really nice to see the SRAM code getting moved now. Thanks
>> a lot Rajendra.
>>
>> - The sram_init() seems to be the post core init call.
>> Hope this is not a problem for SDRC init which needs to have
>> SRAM ready to update the DDR parameters.
> 
> It should be fine given its needed only during core dvfs. Besides
> drivers/misc/sram.c is useful only on DT platforms, so for now OMAP2/3
> continue to use the omap specific sram handling.
> 
Its used in early boot to initialize the DDR parameters and then
later these can be used based on whether core DVFS supported or
not. Look for _omap2_init_reprogram_sdrc() which has init
dependency with omap_sram_init().

Regards,
Santosh

[PATCH 0/2] OMAP4+: Get rid of internal SRAM handling

[Rajendra Nayak]

On Wednesday 28 August 2013 07:08 PM, Santosh Shilimkar wrote:
> On Wednesday 28 August 2013 02:29 AM, Nayak, Rajendra wrote:
>> On Tuesday 27 August 2013 06:55 PM, Santosh Shilimkar wrote:
>>> + Paul,
>>>
>>> On Tuesday 27 August 2013 06:11 AM, Rajendra Nayak wrote:
>>>> Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5)
>>>> use drivers/misc/sram.c driver instead of the omap internal
>>>> implementation for SRAM handling.
>>>>
>>>> Rajendra Nayak (2):
>>>>   ARM: AM335x: Get rid of unused sram init function
>>>>   ARM: OMAP4+: Move SRAM data to DT
>>>>
>>>>  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           |   39 +---------------------------------
>>>>  arch/arm/mach-omap2/sram.h           |    1 -
>>>>  7 files changed, 22 insertions(+), 39 deletions(-)
>>>>
>>> Really nice to see the SRAM code getting moved now. Thanks
>>> a lot Rajendra.
>>>
>>> - The sram_init() seems to be the post core init call.
>>> Hope this is not a problem for SDRC init which needs to have
>>> SRAM ready to update the DDR parameters.
>>
>> It should be fine given its needed only during core dvfs. Besides
>> drivers/misc/sram.c is useful only on DT platforms, so for now OMAP2/3
>> continue to use the omap specific sram handling.
>>
> Its used in early boot to initialize the DDR parameters and then
> later these can be used based on whether core DVFS supported or
> not. Look for _omap2_init_reprogram_sdrc() which has init
> dependency with omap_sram_init().

Right, I see that now. With this series (which addresses only DT platforms)
we would still be fine with the omap2/3 sdrc usage.

> 
> Regards,
> Santosh
> 

[PATCH 0/2] OMAP4+: Get rid of internal SRAM handling

[Santosh Shilimkar]

On Wednesday 28 August 2013 09:42 AM, Rajendra Nayak wrote:
> On Wednesday 28 August 2013 07:08 PM, Santosh Shilimkar wrote:
>> On Wednesday 28 August 2013 02:29 AM, Nayak, Rajendra wrote:
>>> On Tuesday 27 August 2013 06:55 PM, Santosh Shilimkar wrote:
>>>> + Paul,
>>>>
>>>> On Tuesday 27 August 2013 06:11 AM, Rajendra Nayak wrote:
>>>>> Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5)
>>>>> use drivers/misc/sram.c driver instead of the omap internal
>>>>> implementation for SRAM handling.
>>>>>
>>>>> Rajendra Nayak (2):
>>>>>   ARM: AM335x: Get rid of unused sram init function
>>>>>   ARM: OMAP4+: Move SRAM data to DT
>>>>>
>>>>>  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           |   39 +---------------------------------
>>>>>  arch/arm/mach-omap2/sram.h           |    1 -
>>>>>  7 files changed, 22 insertions(+), 39 deletions(-)
>>>>>
>>>> Really nice to see the SRAM code getting moved now. Thanks
>>>> a lot Rajendra.
>>>>
>>>> - The sram_init() seems to be the post core init call.
>>>> Hope this is not a problem for SDRC init which needs to have
>>>> SRAM ready to update the DDR parameters.
>>>
>>> It should be fine given its needed only during core dvfs. Besides
>>> drivers/misc/sram.c is useful only on DT platforms, so for now OMAP2/3
>>> continue to use the omap specific sram handling.
>>>
>> Its used in early boot to initialize the DDR parameters and then
>> later these can be used based on whether core DVFS supported or
>> not. Look for _omap2_init_reprogram_sdrc() which has init
>> dependency with omap_sram_init().
> 
> Right, I see that now. With this series (which addresses only DT platforms)
> we would still be fine with the omap2/3 sdrc usage.
> 
Yep. When OMAP3 becomes DT only then this could become problem. Actually
the SDRC init can be moved bit further down to solve that one as well so
should be ok I guess.

Regards,
Santosh

[PATCH 0/2] OMAP4+: Get rid of internal SRAM handling

[Tony Lindgren]

* Rajendra Nayak <rnayak@ti.com> [130827 03:19]:
> Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5)
> use drivers/misc/sram.c driver instead of the omap internal
> implementation for SRAM handling.

Sounds like this series has some dependencies that we need
to clear, so marking this thread as read and assuming a new
series will be posted.

Regards,

Tony