RE: [PATCH 02/14] omap: Map only available sram memory
> -Original Message- > From: Grazvydas Ignotas [mailto:nota...@gmail.com] > Sent: Tuesday, October 05, 2010 5:14 AM > To: Shilimkar, Santosh > Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; Russell King - ARM Linux > Subject: Re: [PATCH 02/14] omap: Map only available sram memory > > > Looks like for you " is_sram_locked" function is failing. There was a > patch > > in my series from Vikram which was fixing this API. > > > > Do you have this patch applied when you are trying this out ? > > http://www.spinics.net/linux/lists/arm-kernel/msg98697.html > > Well it looks like this only happens on linux-next (was using > next-20101001 version) with this defconfig: > http://notaz.gp2x.de/misc/pnd/config_next_101001_2 > > this has yours and Vikram's patch you mentioned in. Using > omap2plus_defconfig on linux-next or this "bad" defconfig on > linux-omap boots fine, strange. Indeed strange. At least good to know that omap2plus_defconfig on linux-next is booting fine. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] omap: Map only available sram memory
* Tony Lindgren [101004 17:26]: > * Grazvydas Ignotas [101004 16:35]: > > > Looks like for you " is_sram_locked" function is failing. There was a > > > patch > > > in my series from Vikram which was fixing this API. > > > > > > Do you have this patch applied when you are trying this out ? > > > http://www.spinics.net/linux/lists/arm-kernel/msg98697.html > > > > Well it looks like this only happens on linux-next (was using > > next-20101001 version) with this defconfig: > > http://notaz.gp2x.de/misc/pnd/config_next_101001_2 > > > > this has yours and Vikram's patch you mentioned in. Using > > omap2plus_defconfig on linux-next or this "bad" defconfig on > > linux-omap boots fine, strange. > > Maybe you need to disable CONFIG_SMP still in for-next? > > At least one patch is still missing there, that's the TLB > broadcast patch we have in omap-testing and sitting in > Russell's patch system. Hmm, no CONFIG_SMP at least in the config above.. Must be something else then. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] omap: Map only available sram memory
* Grazvydas Ignotas [101004 16:35]: > > Looks like for you " is_sram_locked" function is failing. There was a patch > > in my series from Vikram which was fixing this API. > > > > Do you have this patch applied when you are trying this out ? > > http://www.spinics.net/linux/lists/arm-kernel/msg98697.html > > Well it looks like this only happens on linux-next (was using > next-20101001 version) with this defconfig: > http://notaz.gp2x.de/misc/pnd/config_next_101001_2 > > this has yours and Vikram's patch you mentioned in. Using > omap2plus_defconfig on linux-next or this "bad" defconfig on > linux-omap boots fine, strange. Maybe you need to disable CONFIG_SMP still in for-next? At least one patch is still missing there, that's the TLB broadcast patch we have in omap-testing and sitting in Russell's patch system. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] omap: Map only available sram memory
> Looks like for you " is_sram_locked" function is failing. There was a patch > in my series from Vikram which was fixing this API. > > Do you have this patch applied when you are trying this out ? > http://www.spinics.net/linux/lists/arm-kernel/msg98697.html Well it looks like this only happens on linux-next (was using next-20101001 version) with this defconfig: http://notaz.gp2x.de/misc/pnd/config_next_101001_2 this has yours and Vikram's patch you mentioned in. Using omap2plus_defconfig on linux-next or this "bad" defconfig on linux-omap boots fine, strange. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/14] omap: Map only available sram memory
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh > Sent: Monday, October 04, 2010 3:08 PM > To: Grazvydas Ignotas > Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; Russell King - ARM Linux > Subject: RE: [PATCH 02/14] omap: Map only available sram memory > > > -Original Message- > > From: Grazvydas Ignotas [mailto:nota...@gmail.com] > > Sent: Monday, October 04, 2010 2:34 PM > > To: Shilimkar, Santosh > > Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- > > ker...@lists.infradead.org; Russell King - ARM Linux > > Subject: Re: [PATCH 02/14] omap: Map only available sram memory > > > > >> > > > >> > This hangs OMAP3 pandora: > > >> > > > >> > [ 0.00] Linux version > > >> > 2.6.36-rc6-next-20101001-2-ge76bb53-dirty (no...@pixelinis) > (gcc > > >> > version 4.3.3 (Sourcery G++ Lite 2009q1-20 > > >> > [ 0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), > > >> cr=10c53c7f > > >> > [ 0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing > > >> > instruction cache > > >> > [ 0.00] Machine: Pandora Handheld Console > > >> > [ 0.00] Ignoring unrecognised tag 0x54410008 > > >> > [ 0.00] bootconsole [earlycon0] enabled > > >> > [ 0.00] Reserving 6422528 bytes SDRAM for VRAM > > >> > [ 0.00] Memory policy: ECC disabled, Data cache writeback > > >> > [ 0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) > > >> > [ 0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: > > 0x1 > > >> > (stuck here) > > >> > > > >> > reverting this fixes the problem. > > >> > > >> Hmm, boots fine here with overo. Any idea what in this patch breaks > > >> pandora? > > >> > > > The change in this patch is not board dependent really. Have tested > this > > > on 3430SDP. Pandora is OMAP3 based, right ? > > > > OMAP3530 ES2.1, also tried on friend's beagleboard b5 (also ES2.1) and > > it has the same problem. Maybe it's because of older Cortex A8 used > > there, or I'm missing some errata workaround in defconfig. > > > > BTW, hacking the size to 1M on top of your patch fixes the problem too: > > > > base = omap_sram_start; > > base = ROUND_DOWN(base, PAGE_SIZE); > > omap_sram_io_desc[0].pfn = __phys_to_pfn(base); > > - omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, > > PAGE_SIZE); > > + omap_sram_io_desc[0].length = 0x10; > This is the exact reason this patch is created :) > So that you map only available memory instead of 1 MB > > iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc)); Just booted latest mainline where this patch is already merged and my OMAP3630 boots fine ## Booting image at 8030 ... Image Name: Linux-2.6.36-rc6-00086-gd4e8aa3 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3242124 Bytes = 3.1 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.36-rc6-00086-gd4e8aa3 (a0393...@a0393909-desktop) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 Mon Oct 4 18:27:30 IST 2010 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP Zoom3 board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] SRAM: Mapped pa 0x40208000 to va 0xfe408000 size: 0x8000 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: root=/dev/ram0 rw mem=128M console=ttyS0,115200n8 noinitrd root=/dev/nfs rw nfsroot=172.24.190.46:/ubuntu/nfs-share/omap3_next/,nolock,tcp,rsize=4096,wsize=4096 ip=dhcp earlyprintk [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 128MB = 128MB total [0.00] Memory: 116148k/116148k available, 14924k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector :
RE: [PATCH 02/14] omap: Map only available sram memory
> -Original Message- > From: Grazvydas Ignotas [mailto:nota...@gmail.com] > Sent: Monday, October 04, 2010 2:34 PM > To: Shilimkar, Santosh > Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; Russell King - ARM Linux > Subject: Re: [PATCH 02/14] omap: Map only available sram memory > > >> > > >> > This hangs OMAP3 pandora: > >> > > >> > [ 0.00] Linux version > >> > 2.6.36-rc6-next-20101001-2-ge76bb53-dirty (no...@pixelinis) (gcc > >> > version 4.3.3 (Sourcery G++ Lite 2009q1-20 > >> > [ 0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), > >> cr=10c53c7f > >> > [ 0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing > >> > instruction cache > >> > [ 0.00] Machine: Pandora Handheld Console > >> > [ 0.00] Ignoring unrecognised tag 0x54410008 > >> > [ 0.00] bootconsole [earlycon0] enabled > >> > [ 0.00] Reserving 6422528 bytes SDRAM for VRAM > >> > [ 0.00] Memory policy: ECC disabled, Data cache writeback > >> > [ 0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) > >> > [ 0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: > 0x1 > >> > (stuck here) > >> > > >> > reverting this fixes the problem. > >> > >> Hmm, boots fine here with overo. Any idea what in this patch breaks > >> pandora? > >> > > The change in this patch is not board dependent really. Have tested this > > on 3430SDP. Pandora is OMAP3 based, right ? > > OMAP3530 ES2.1, also tried on friend's beagleboard b5 (also ES2.1) and > it has the same problem. Maybe it's because of older Cortex A8 used > there, or I'm missing some errata workaround in defconfig. > > BTW, hacking the size to 1M on top of your patch fixes the problem too: > > base = omap_sram_start; > base = ROUND_DOWN(base, PAGE_SIZE); > omap_sram_io_desc[0].pfn = __phys_to_pfn(base); > - omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, > PAGE_SIZE); > + omap_sram_io_desc[0].length = 0x10; This is the exact reason this patch is created :) So that you map only available memory instead of 1 MB > iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc)); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] omap: Map only available sram memory
>> > >> > This hangs OMAP3 pandora: >> > >> > [ 0.00] Linux version >> > 2.6.36-rc6-next-20101001-2-ge76bb53-dirty (no...@pixelinis) (gcc >> > version 4.3.3 (Sourcery G++ Lite 2009q1-20 >> > [ 0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), >> cr=10c53c7f >> > [ 0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing >> > instruction cache >> > [ 0.00] Machine: Pandora Handheld Console >> > [ 0.00] Ignoring unrecognised tag 0x54410008 >> > [ 0.00] bootconsole [earlycon0] enabled >> > [ 0.00] Reserving 6422528 bytes SDRAM for VRAM >> > [ 0.00] Memory policy: ECC disabled, Data cache writeback >> > [ 0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) >> > [ 0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 >> > (stuck here) >> > >> > reverting this fixes the problem. >> >> Hmm, boots fine here with overo. Any idea what in this patch breaks >> pandora? >> > The change in this patch is not board dependent really. Have tested this > on 3430SDP. Pandora is OMAP3 based, right ? OMAP3530 ES2.1, also tried on friend's beagleboard b5 (also ES2.1) and it has the same problem. Maybe it's because of older Cortex A8 used there, or I'm missing some errata workaround in defconfig. BTW, hacking the size to 1M on top of your patch fixes the problem too: base = omap_sram_start; base = ROUND_DOWN(base, PAGE_SIZE); omap_sram_io_desc[0].pfn = __phys_to_pfn(base); - omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE); + omap_sram_io_desc[0].length = 0x10; iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc)); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/14] omap: Map only available sram memory
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Saturday, October 02, 2010 4:23 AM > To: Grazvydas Ignotas > Cc: Shilimkar, Santosh; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; Russell King - ARM Linux > Subject: Re: [PATCH 02/14] omap: Map only available sram memory > > * Grazvydas Ignotas [101001 13:07]: > > On Fri, Sep 17, 2010 at 12:47 PM, Santosh Shilimkar > > wrote: > > > Currently we map 1 MB section while setting up SRAM on OMAPs. > > > The actual physcal OCM RAM available on OMAP SOCs is in order > > > of KBs. This patch maps only available sram and removes some > > > non necessary cpu_is_xxx checks. > > > > > > On the newer ARMs with speculation, this is dangerous and can > > > result in untraceable aborts. > > > > > > Signed-off-by: Santosh Shilimkar > > > > This hangs OMAP3 pandora: > > > > [0.00] Linux version > > 2.6.36-rc6-next-20101001-2-ge76bb53-dirty (no...@pixelinis) (gcc > > version 4.3.3 (Sourcery G++ Lite 2009q1-20 > > [0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), > cr=10c53c7f > > [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing > > instruction cache > > [0.00] Machine: Pandora Handheld Console > > [0.00] Ignoring unrecognised tag 0x54410008 > > [0.00] bootconsole [earlycon0] enabled > > [0.00] Reserving 6422528 bytes SDRAM for VRAM > > [0.00] Memory policy: ECC disabled, Data cache writeback > > [0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) > > [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 > > (stuck here) > > > > reverting this fixes the problem. > > Hmm, boots fine here with overo. Any idea what in this patch breaks > pandora? > The change in this patch is not board dependent really. Have tested this on 3430SDP. Pandora is OMAP3 based, right ? Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] omap: Map only available sram memory
* Grazvydas Ignotas [101001 13:07]: > On Fri, Sep 17, 2010 at 12:47 PM, Santosh Shilimkar > wrote: > > Currently we map 1 MB section while setting up SRAM on OMAPs. > > The actual physcal OCM RAM available on OMAP SOCs is in order > > of KBs. This patch maps only available sram and removes some > > non necessary cpu_is_xxx checks. > > > > On the newer ARMs with speculation, this is dangerous and can > > result in untraceable aborts. > > > > Signed-off-by: Santosh Shilimkar > > This hangs OMAP3 pandora: > > [0.00] Linux version > 2.6.36-rc6-next-20101001-2-ge76bb53-dirty (no...@pixelinis) (gcc > version 4.3.3 (Sourcery G++ Lite 2009q1-20 > [0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f > [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing > instruction cache > [0.00] Machine: Pandora Handheld Console > [0.00] Ignoring unrecognised tag 0x54410008 > [0.00] bootconsole [earlycon0] enabled > [0.00] Reserving 6422528 bytes SDRAM for VRAM > [0.00] Memory policy: ECC disabled, Data cache writeback > [0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) > [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 > (stuck here) > > reverting this fixes the problem. Hmm, boots fine here with overo. Any idea what in this patch breaks pandora? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] omap: Map only available sram memory
On Fri, Sep 17, 2010 at 12:47 PM, Santosh Shilimkar
wrote:
> Currently we map 1 MB section while setting up SRAM on OMAPs.
> The actual physcal OCM RAM available on OMAP SOCs is in order
> of KBs. This patch maps only available sram and removes some
> non necessary cpu_is_xxx checks.
>
> On the newer ARMs with speculation, this is dangerous and can
> result in untraceable aborts.
>
> Signed-off-by: Santosh Shilimkar
This hangs OMAP3 pandora:
[0.00] Linux version
2.6.36-rc6-next-20101001-2-ge76bb53-dirty (no...@pixelinis) (gcc
version 4.3.3 (Sourcery G++ Lite 2009q1-20
[0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f
[0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing
instruction cache
[0.00] Machine: Pandora Handheld Console
[0.00] Ignoring unrecognised tag 0x54410008
[0.00] bootconsole [earlycon0] enabled
[0.00] Reserving 6422528 bytes SDRAM for VRAM
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp )
[0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1
(stuck here)
reverting this fixes the problem.
> ---
> arch/arm/plat-omap/sram.c | 25 +
> 1 files changed, 5 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> index 226b2e8..10b3b4c 100644
> --- a/arch/arm/plat-omap/sram.c
> +++ b/arch/arm/plat-omap/sram.c
> @@ -220,20 +220,7 @@ void __init omap_map_sram(void)
> if (omap_sram_size == 0)
> return;
>
> - if (cpu_is_omap24xx()) {
> - omap_sram_io_desc[0].virtual = OMAP2_SRAM_VA;
> -
> - base = OMAP2_SRAM_PA;
> - base = ROUND_DOWN(base, PAGE_SIZE);
> - omap_sram_io_desc[0].pfn = __phys_to_pfn(base);
> - }
> -
> if (cpu_is_omap34xx()) {
> - omap_sram_io_desc[0].virtual = OMAP3_SRAM_VA;
> - base = OMAP3_SRAM_PA;
> - base = ROUND_DOWN(base, PAGE_SIZE);
> - omap_sram_io_desc[0].pfn = __phys_to_pfn(base);
> -
> /*
> * SRAM must be marked as non-cached on OMAP3 since the
> * CORE DPLL M2 divider change code (in SRAM) runs with the
> @@ -244,13 +231,11 @@ void __init omap_map_sram(void)
> omap_sram_io_desc[0].type = MT_MEMORY_NONCACHED;
> }
>
> - if (cpu_is_omap44xx()) {
> - omap_sram_io_desc[0].virtual = OMAP4_SRAM_VA;
> - base = OMAP4_SRAM_PA;
> - base = ROUND_DOWN(base, PAGE_SIZE);
> - omap_sram_io_desc[0].pfn = __phys_to_pfn(base);
> - }
> - omap_sram_io_desc[0].length = 1024 * 1024; /* Use section desc */
> + omap_sram_io_desc[0].virtual = omap_sram_base;
> + base = omap_sram_start;
> + base = ROUND_DOWN(base, PAGE_SIZE);
> + omap_sram_io_desc[0].pfn = __phys_to_pfn(base);
> + omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
> iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
>
> printk(KERN_INFO "SRAM: Mapped pa 0x%08lx to va 0x%08lx size: 0x%lx\n",
> --
> 1.6.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/14] omap: Map only available sram memory
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Friday, September 17, 2010 3:46 PM > To: Shilimkar, Santosh > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH 02/14] omap: Map only available sram memory > > On Fri, Sep 17, 2010 at 03:17:46PM +0530, Santosh Shilimkar wrote: > > Currently we map 1 MB section while setting up SRAM on OMAPs. > > The actual physcal OCM RAM available on OMAP SOCs is in order > > physical > > > of KBs. This patch maps only available sram and removes some > > non necessary cpu_is_xxx checks. > > > > On the newer ARMs with speculation, this is dangerous and can > > result in untraceable aborts. > > "this" should be expanded (otherwise it is unclear whether it refers to > the original code or the new code.) Will fix the change log as below. omap: Map only available sram memory Currently we map 1 MB section while setting up SRAM on OMAPs Regardless of the actual memory. The physical OCM RAM available on OMAP SOCs is in order of KBs. This patch maps only available sram and cleans up some un-necessary cpu_is_xxx checks. Mapping un-available or non-accessible(secure) memory on the newer ARM processor is dangerous. Because ARM CPUs can now speculatively prefetch, we should avoid mapping any no-existing or secure memory. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] omap: Map only available sram memory
On Fri, Sep 17, 2010 at 03:17:46PM +0530, Santosh Shilimkar wrote: > Currently we map 1 MB section while setting up SRAM on OMAPs. > The actual physcal OCM RAM available on OMAP SOCs is in order physical > of KBs. This patch maps only available sram and removes some > non necessary cpu_is_xxx checks. > > On the newer ARMs with speculation, this is dangerous and can > result in untraceable aborts. "this" should be expanded (otherwise it is unclear whether it refers to the original code or the new code.) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
