- 22 11月, 2010 1 次提交
-
-
由 Anand Gadiyar 提交于
Commit 7c63984b (ARM: do not define VMALLOC_END relative to PAGE_OFFSET) changed VMALLOC_END to be an explicit value. Before this, it was relative to PAGE_OFFSET and therefore converted to unsigned long as PAGE_OFFSET is an unsigned long. This introduced the following build warning. Fix this by changing the explicit defines of VMALLOC_END to be unsigned long. CC arch/arm/mm/init.o arch/arm/mm/init.c: In function 'mem_init': arch/arm/mm/init.c:606: warning: format '%08lx' expects type 'long unsigned int', but argument 12 has type 'unsigned int' Signed-off-by: NAnand Gadiyar <gadiyar@ti.com> Acked-by: NUwe Kleine-K <u.kleine-koenig@pengutronix.dee> Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 02 10月, 2010 1 次提交
-
-
由 Nicolas Pitre 提交于
VMALLOC_END is supposed to be an absolute value, while PAGE_OFFSET may vary depending on the selected user:kernel memory split mode through CONFIG_VMSPLIT_*. In fact, the goal of moving PAGE_OFFSET down is to accommodate more directly addressed RAM by the kernel below the vmalloc area, and having VMALLOC_END move along PAGE_OFFSET is rather against the very reason why PAGE_OFFSET can be moved in the first place. Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
-
- 20 10月, 2009 2 次提交
-
-
由 Tony Lindgren 提交于
Earlier patch "omap: Remap L3, L4 to get more kernel io address space" changed the VMALLOC_END. However, this change causes problems on mach-omap1: BUG: mapping for 0xe0000000 at 0xe0000000 overlaps vmalloc space BUG: mapping for 0xe1000000 at 0xe1000000 overlaps vmalloc space Fix this by creating separate vmalloc.h files for mach-omap1 and mach-omap2. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Santosh Shilimkar 提交于
This patch remap L3 and L4 io space to get more kernel address space. With this patch, 512 MB of IO space is reclaimed. Some more combinations are possible but to make it uniform across OMAP24XX, OMAP34XX and OMAP4430, these io combinations are chosen Once this is reviewed and tested sufficiently, a documentation entry can be created to ease up reading and debugging. Like "Documentation/arm/omap/io_map.txt" Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 26 5月, 2009 1 次提交
-
-
由 Mans Rullgard 提交于
This increases VMALLOC_END to 0x18000000, making room for 256MB RAM with the default 128MB vmalloc region. Note that after this patch there's no longer a hole between vmalloc space and the beginning of IO space on omap2 as the first virtual mapping starts at 0xd8000000. Also fold in a related change from Paul Walmsley <paul@pwsan.com> to change the OMAP2_SRAM addresses accordingly. Signed-off-by: NMans Rullgard <mans@mansr.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> Acked-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 07 8月, 2008 1 次提交
-
-
由 Russell King 提交于
This just leaves include/asm-arm/plat-* to deal with. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 03 5月, 2005 1 次提交
-
-
由 Russell King 提交于
VMALLOC_START and VMALLOC_OFFSET are common between all ARM machine classes. Move them into include/asm-arm/pgtable.h, but allow a machine class to override them if required. Signed-off-by: NRussell King <rmk@arm.linux.org.uk>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
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!
-