| Message ID | 1377598305-15539-3-git-send-email-rnayak@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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
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
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
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
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 --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
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(-)