OMAP: Increase VMALLOC_END to allow 256MB RAM
Subsystems (2)
PATCH 1/1 OMAP: Increase VMALLOC_END to allow 256MB RAM
This increases VMALLOC_END to 0x18000000, making room for 256MB RAM with the default 128MB vmalloc region.
--- arch/arm/plat-omap/include/mach/vmalloc.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/plat-omap/include/mach/vmalloc.h +1 -1
@@ -17,5 +17,5 @@* along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#define VMALLOC_END (PAGE_OFFSET + 0x17000000) +#define VMALLOC_END (PAGE_OFFSET + 0x18000000)
Signature · 1 line
1.6.0.2
Quoted 13 lines · Mans Rullgard
This increases
VMALLOC_ENDto0x18000000, making room for 256MB RAM with the default 128MB vmalloc region.Signed-off-by Mans Rullgard <[email protected]>--- arch/arm/plat-omap/include/mach/vmalloc.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/plat-omap/include/mach/vmalloc.h +0
-0
arch/arm/plat-omap/include/mach/vmalloc.h line 20
Quoted 5 lines
arch/arm/plat-omap/include/mach/vmalloc.h +1
-1@@ -17,5 +17,5 @@* along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#define VMALLOC_END (PAGE_OFFSET + 0x17000000) +#define VMALLOC_END (PAGE_OFFSET + 0x18000000)
I have a similar patch locally, but the problem I currently have with it is that there is no longer any hole between vmalloc space and the beginning of IO space (the first virtual mappings start at 0xd8000000.)
It's a bit unsafe, but IMO it's is probably OK for the short term. Longer term I think the virtual address space of the OMAP kernels needs to be reworked. It currenly just maps directly onto the physical address space, which makes the IO_ADDRESS() conversion macros simple, but leaves lots of wasted space in the virtual address space.
Kevin
Op 2 okt 2008, om 11:29 heeft Kevin Hilman het volgende geschreven:
Quoted 29 lines
Quoted 17 lines · Mans Rullgard
This increases
VMALLOC_ENDto0x18000000, making room for 256MB RAM with the default 128MB vmalloc region.Signed-off-by Mans Rullgard <[email protected]>---
arch/arm/plat-omap/include/mach/vmalloc.h| 2 +-1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/plat-omap/include/mach/vmalloc.h +0
-0@@ -17,5 +17,5 @@* along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/arch/arm/plat-omap/include/mach/vmalloc.h line 20
Quoted 2 lines
arch/arm/plat-omap/include/mach/vmalloc.h +1
-1-#define VMALLOC_END (PAGE_OFFSET + 0x17000000) +#define VMALLOC_END (PAGE_OFFSET + 0x18000000)Acked-by Kevin Hilman <[email protected]>I have a similar patch locally, but the problem I currently have with it is that there is no longer any hole between vmalloc space and the beginning of IO space (the first virtual mappings start at
0xd8000000.)
Quoted 5 lines
It's a bit unsafe, but IMO it's is probably OK for the short term. Longer term I think the virtual address space of the OMAP kernels needs to be reworked. It currenly just maps directly onto the physical address space, which makes the
IO_ADDRESS()conversion macros simple, but leaves lots of wasted space in the virtual address space.
I was told that omap3 support 512MB of ram, so is it possible to account for that as well, or can we revisit that when the actual LP-DDR become available?
regards,
Koen
Quoted 38 lines · Koen Kooi
Op 2 okt 2008, om 11:29 heeft Kevin Hilman het volgende geschreven:
Quoted 35 lines
Quoted 18 lines · Mans Rullgard
This increases
VMALLOC_ENDto0x18000000, making room for 256MB RAM with the default 128MB vmalloc region.Signed-off-by Mans Rullgard <[email protected]>---
arch/arm/plat-omap/include/mach/vmalloc.h| 2 +-1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/ renamed from arch/arm/plat-omap/include/mach/vmalloc.h +0
-0
plat-omap/include/mach/vmalloc.h
index d8515cb..b97dfaf 100644arch/arm/plat-omap/include/mach/vmalloc.h +0
-0@@ -17,5 +17,5 @@* along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/arch/arm/plat-omap/include/mach/vmalloc.h line 20
Quoted 2 lines
arch/arm/plat-omap/include/mach/vmalloc.h +1
-1-#define VMALLOC_END (PAGE_OFFSET + 0x17000000) +#define VMALLOC_END (PAGE_OFFSET + 0x18000000)Acked-by Kevin Hilman <[email protected]>I have a similar patch locally, but the problem I currently have with it is that there is no longer any hole between vmalloc space and the beginning of IO space (the first virtual mappings start at
0xd8000000.)It's a bit unsafe, but IMO it's is probably OK for the short term. Longer term I think the virtual address space of the OMAP kernels needs to be reworked. It currenly just maps directly onto the physical address space, which makes the
IO_ADDRESS()conversion macros simple, but leaves lots of wasted space in the virtual address space.
Seems to be also safe for omap1, so I've pushed it.
Quoted 3 lines
I was told that omap3 support 512MB of ram, so is it possible to account for that as well, or can we revisit that when the actual LP-DDR become available?
Well, to make room for a long term solution let's do the following:
- Use OMAP1_IO_ADDRESS and OMAP2_IO_ADDRES and get rid of OMAP_IO_ADDRESS. This allows compiling in more code into a single binary
- Remove the remaining io_v2p() and any XXX_IO_ADDRESS() in the drivers. Drivers should be now using ioremap() as noted earlier
- Then we can further split OMAP2_IO_ADDRESS() into L3_IO_ADDRESS() and L4_IO_ADDRESS(), which allows us to move L4_XXXX_VIRT out of the way
Anybody got better ideas?
Regards,
Tony