| Message ID | 1377775391-13103-3-git-send-email-rnayak@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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()? 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
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. Regards, Santosh -- 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
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 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. 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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. > > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. > > Regards, > Santosh > -- 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
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 ;-) -- 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
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. 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
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 -- 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 --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@40300000 { - compatible = "ti,am3352-ocmcram"; - reg = <0x40300000 0x10000>; - ti,hwmods = "ocmcram"; + compatible = "mmio-sram"; + reg = <0x40300000 0x10000>; /* 64k */ }; wkup_m3: wkup_m3@44d00000 { 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@40300000 { + compatible = "mmio-sram"; + reg = <0x40300000 0x40000>; /* 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@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..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 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()) 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
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 <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 | 26 +------------------------- arch/arm/mach-omap2/sram.h | 1 - 7 files changed, 19 insertions(+), 29 deletions(-)