- 30 6月, 2006 1 次提交
-
-
由 Russell King 提交于
On some CPUs, bit 4 of section mappings means "update the cache when written to". On others, this bit is required to be one, and others it's required to be zero. Finally, on ARMv6 and above, setting it turns on "no execute" and prevents speculative prefetches. With all these combinations, no one value fits all CPUs, so we have to pick a value depending on the CPU type, and the area we're mapping. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 29 6月, 2006 1 次提交
-
-
由 Hyok S. Choi 提交于
In noMMU mode, various of functions which are defined in mm/proc-*.S is not valid or needed to be avoided. i.g. switch_mm is not needed, just returns and this makes the I & D caches are valid which shows great improvement of performance including task switching and IPC. Signed-off-by: NHyok S. Choi <hyok.choi@samsung.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 07 4月, 2006 1 次提交
-
-
由 Russell King 提交于
We had two implementations for flushing the cache, which meant StrongARM caches weren't being correctly flushed. Fix this by always using the v4wb_flush_kern_cache_all method, rather than duplicating it. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 22 3月, 2006 1 次提交
-
-
由 Russell King 提交于
Move the hardware PMD and PTE page table definitions from pgtable.h into pgtable-hwdef.h, and include pgtable-hwdef.h as necessary. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 20 9月, 2005 1 次提交
-
-
由 Ben Dooks 提交于
Patch from Ben Dooks The `make buildcheck` is erroneously reporting that the .proc.info list is referencing items in the .init section as it is not itself postfixed with .init Signed-off-by: NBen Dooks <ben-linux@fluff.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 10 9月, 2005 1 次提交
-
-
由 Sam Ravnborg 提交于
Delete obsoleted stuff from arch Makefile and rename constants.h to asm-offsets.h Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
- 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!
-