android_kernel_xiaomi_sm8350/include/asm-arm/arch-iop33x/vmalloc.h

/*
 * linux/include/asm-arm/arch-iop33x/vmalloc.h
 */

/*
 * Just any arbitrary offset to the start of the vmalloc VM area: the
 * current 8MB value just means that there will be a 8MB "hole" after the
 * physical memory until the kernel virtual memory starts.  That means that
 * any out-of-bounds memory accesses will hopefully be caught.
 * The vmalloc() routines leaves a hole of 4kB between each vmalloced
 * area for the same reason. ;)
 */
//#define VMALLOC_END       (0xe8000000)
/* increase usable physical RAM to ~992M per RMK */
#define VMALLOC_END       (0xfe000000)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 2005-04-16 18:20:36 -04:00			`/*`
[ARM] 3817/1: iop3xx: split the iop3xx mach into iop32x and iop33x Split the iop3xx mach type into iop32x and iop33x -- split the config symbols, and move the code in the mach-iop3xx directory to the mach-iop32x and mach-iop33x directories. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 2006-09-18 18:10:26 -04:00			`* linux/include/asm-arm/arch-iop33x/vmalloc.h`
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip! 2005-04-16 18:20:36 -04:00			`*/`

			`/*`
			`* Just any arbitrary offset to the start of the vmalloc VM area: the`
			`* current 8MB value just means that there will be a 8MB "hole" after the`
			`* physical memory until the kernel virtual memory starts. That means that`
			`* any out-of-bounds memory accesses will hopefully be caught.`
			`* The vmalloc() routines leaves a hole of 4kB between each vmalloced`
			`* area for the same reason. ;)`
			`*/`
			`//#define VMALLOC_END (0xe8000000)`
			`/* increase usable physical RAM to ~992M per RMK */`
			`#define VMALLOC_END (0xfe000000)`