Op 2 okt 2008, om 11:29 heeft Kevin Hilman het volgende geschreven:
Mans Rullgard <mans@xxxxxxxxx> writes:This increases VMALLOC_END to 0x18000000, making room for 256MB RAM with the default 128MB vmalloc region. Signed-off-by: Mans Rullgard <mans@xxxxxxxxx> --- arch/arm/plat-omap/include/mach/vmalloc.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h b/arch/arm/ plat-omap/include/mach/vmalloc.hindex d8515cb..b97dfaf 100644 --- a/arch/arm/plat-omap/include/mach/vmalloc.h +++ b/arch/arm/plat-omap/include/mach/vmalloc.h @@ -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)Acked-by: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> 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.
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
Attachment:
PGP.sig
Description: This is a digitally signed message part
