diff mbox

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

Message ID 1377598305-15539-3-git-send-email-rnayak@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Rajendra Nayak Aug. 27, 2013, 10:11 a.m. UTC
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(-)

Comments

Sekhar Nori Aug. 27, 2013, 11:23 a.m. UTC | #1
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

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rajendra Nayak Aug. 28, 2013, 6:23 a.m. UTC | #2
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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sekhar Nori Aug. 28, 2013, 10:24 a.m. UTC | #3
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rajendra Nayak Aug. 29, 2013, 11:02 a.m. UTC | #4
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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Russ Dill Sept. 3, 2013, 1:56 p.m. UTC | #5
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lucas Stach Sept. 3, 2013, 2:35 p.m. UTC | #6
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
Russ Dill Sept. 3, 2013, 3:07 p.m. UTC | #7
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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@40300000 {
+			compatible = "mmio-sram";
+			reg = <0x40300000 0x10000>; /* 64k */
+		};
+
 		intc: interrupt-controller@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@40300000 {
+			compatible = "mmio-sram";
+			reg = <0x40300000 0x40000>; /* 256k */
+		};
+
 		uart0: serial@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@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..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@40300000 {
+			compatible = "mmio-sram";
+			reg = <0x40300000 0x20000>; /* 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..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