OMAP4+: Get rid of internal SRAM handling

Remove the empty am33xx_sram_init() function.

Signed-off-by Rajendra Nayak <[email protected]>

---
  arch/arm/mach-omap2/sram.c |    7 -------
  1 file changed, 7 deletions(-)

arch/arm/mach-omap2/sram.c +0 -5

index 4bd0968..305fc2b 100644
@@ -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();

Quoted 27 lines · Rajendra Nayak

Remove the empty am33xx_sram_init() function.

Signed-off-by Rajendra Nayak <[email protected]>

---
  arch/arm/mach-omap2/sram.c |    7 -------
  1 file changed, 7 deletions(-)

arch/arm/mach-omap2/sram.c +0 -5

index 4bd0968..305fc2b 100644
@@ -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();

arch/arm/mach-omap2/sram.c int __init omap_sram_init(void) · line 299

Quoted 6 lines

arch/arm/mach-omap2/sram.c +0 -2

-    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

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 <[email protected]>

Quoted 7 lines · 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.

Quoted 6 lines

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 <[email protected]>

Nice getting rid of code.

arch/arm/mach-omap2/sram.h static inline void omap_push_sram_idle(void) {} · line 83

Quoted 9 lines

arch/arm/mach-omap2/sram.h +0 -1

index ca7277c..3f83b80 100644
@@ -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 firstts WFI hi(which is when the errata triggers).

Thanks,
Sekhar

Quoted 17 lines · Sekhar Nori

Quoted 7 lines · 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.

Quoted 6 lines

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 <[email protected]>

Nice getting rid of code.

Quoted 11 lines

arch/arm/mach-omap2/sram.h static inline void omap_push_sram_idle(void) {} · line 83

Quoted 9 lines

arch/arm/mach-omap2/sram.h +0 -1

index ca7277c..3f83b80 100644
@@ -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.

Quoted 3 lines

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).

Quoted 36 lines · Rajendra Nayak

Quoted 17 lines · Sekhar Nori

Quoted 7 lines · 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.

Quoted 6 lines

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 <[email protected]>

Nice getting rid of code.

Quoted 11 lines

arch/arm/mach-omap2/sram.h static inline void omap_push_sram_idle(void) {} · line 83

Quoted 9 lines

arch/arm/mach-omap2/sram.h +0 -1

index ca7277c..3f83b80 100644
@@ -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.

Quoted 3 lines

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?

Quoted 3 lines

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

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 <[email protected]>

Quoted 10 lines

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.

Quoted 3 lines

Currently there are no users on SRAM on these platfoms.

Signed-off-by Rajendra Nayak <[email protected]>

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.

Am Dienstag, den 03.09.2013, 06:56 -0700 schrieb Russ Dill:

Quoted 13 lines · Rajendra Nayak

Quoted 12 lines

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.

Quoted 4 lines

Quoted 1 line

Signed-off-by Rajendra Nayak <[email protected]>

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.

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(-)

+ Paul,

Quoted 8 lines · 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

Quoted 9 lines

 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

Quoted 23 lines · Santosh Shilimkar

+ Paul,

Quoted 8 lines · 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

Quoted 9 lines

 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.

Quoted 3 lines

- 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.

Quoted 28 lines · Rajendra

Quoted 26 lines · Santosh Shilimkar

+ Paul,

Quoted 8 lines · 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

Quoted 9 lines

 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.

Quoted 4 lines

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

Quoted 33 lines · Santosh Shilimkar

Quoted 32 lines · Rajendra

Quoted 20 lines · Santosh Shilimkar

+ Paul,

Quoted 8 lines · 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

Quoted 9 lines

 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(-)

Quoted 6 lines

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.

Quoted 4 lines

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.

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.