kernel.git/arch/arm/mm, branch linux-2.6.28.y

[ARM] Ensure linux/hardirqs.h is included where required

2008-12-15T10:34:48Z

... for the removal of it from asm-generic/local.h Signed-off-by: Russell King

[ARM] Fix alignment fault handling for ARMv6 and later CPUs

2008-12-07T09:44:55Z

On ARMv6 and later CPUs, it is possible for userspace processes to get stuck on a misaligned load or store due to the "ignore fault" setting; unlike previous CPUs, retrying the instruction without the 'A' bit set does not always cause the load to succeed. We have no real option but to default to fixing up alignment faults on these CPUs, and having the CPU fix up those misaligned accesses which it can. Reported-by: Wolfgang Grandegger Signed-off-by: Russell King

[ARM] iop: iop3xx needs registers mapped uncached+unbuffered

2008-11-09T11:18:36Z

Mikael Pettersson reported: The 2.6.28-rc kernels fail to detect PCI device 0000:00:01.0 (the first ethernet port) on my Thecus n2100 XScale box. There is however still a strange "ghost" device that gets partially detected in 2.6.28-rc2 vanilla. The IOP321 manual says: The user designates the memory region containing the OCCDR as non-cacheable and non-bufferable from the IntelR XScaleTM core. This guarantees that all load/stores to the OCCDR are only of DWORD quantities. Ensure that the OCCDR is so mapped. Signed-off-by: Russell King

[ARM] 5329/1: Feroceon: fix feroceon_l2_inv_range

2008-11-08T23:08:54Z

Same fix as commit c7cf72dcadb: when 'start' and 'end' are less than a cacheline apart and 'start' is unaligned we are done after cleaning and invalidating the first cacheline. Cc: Signed-off-by: Nicolas Pitre Signed-off-by: Russell King

Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/xscaleiop

2008-11-06T18:04:23Z

[ARM] xsc3: fix xsc3_l2_inv_range

2008-11-06T17:48:29Z

When 'start' and 'end' are less than a cacheline apart and 'start' is unaligned we are done after cleaning and invalidating the first cacheline. So check for (start < end) which will not walk off into invalid address ranges when (start > end). This issue was caught by drivers/dma/dmatest. 2.6.27 is susceptible. Cc: Cc: Haavard Skinnemoen Cc: Lothar WaÃ<9f>mann Cc: Lennert Buytenhek Cc: Eric Miao Signed-off-by: Dan Williams

[ARM] mm: fix page table initialization

2008-11-06T17:45:32Z

As a result of the ptebits changes, we ended up marking device mappings as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with serial ports and the like. While reviewing the section mapping table entries, other errors in the memory type settings for devices were detected and confirmed to prevent Xscale3 platforms booting. Tested on: OMAP34xx (ARMv7), OMAP24xx (ARMv6), OMAP16xx (ARM926T, ARMv5), PXA311 (Xscale3), PXA272 (Xscale), PXA255 (Xscale), IXP42x (Xscale), S3C2410 (ARM920T, ARMv4T), ARM720T (ARMv4T) StrongARM-110 (ARMv4) Acked-by: Tony Lindgren Tested-by: Robert Jarzmik Tested-by: Mike Rapoport Tested-by: Ben Dooks Tested-by: Anders Grafström Signed-off-by: Russell King

[ARM] fix naming of MODULE_START / MODULE_END

2008-11-06T17:13:47Z

As of 73bdf0a60e607f4b8ecc5aec597105976565a84f, the kernel needs to know where modules are located in the virtual address space. On ARM, we located this region between MODULE_START and MODULE_END. Unfortunately, everyone else calls it MODULES_VADDR and MODULES_END. Update ARM to use the same naming, so is_vmalloc_or_module_addr() can work properly. Also update the comment on mm/vmalloc.c to reflect that ARM also places modules in a separate region from the vmalloc space. Signed-off-by: Russell King

[ARM] xsc3: revert writethrough memory-type encoding change

2008-10-24T17:21:45Z

Commit 40df2d1d "[ARM] Update Xscale and Xscale3 PTE mappings" was fingered by git-bisect for a boot failure on iop13xx. The change made L_PTE_MT_WRITETHROUGH mappings L2-uncacheable. Russell points out that this mapping is used for the vector page. Given the regression, and the fact this page is used often, restore the old behaviour. Signed-off-by: Dan Williams

[ARM] 5318/1: Swap the PRRR and NMRR values in proc-v7.S

2008-10-22T18:40:21Z

A typo caused these values to be swapped leading to incorrect memory type attributes. Signed-off-by: Catalin Marinas Signed-off-by: Russell King