summaryrefslogtreecommitdiffstats
path: root/arch/arm/mm/proc-syms.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* ARM: add size argument to __cpuc_flush_dcache_pageRussell King2009-12-141-1/+1
| | | | | | | ... and rename the function since it no longer operates on just pages. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: 5848/1: kill flush_ioremap_region()Nicolas Pitre2009-12-141-1/+0
| | | | | | | | | | | | There is not enough users to warrant its existence, and it is actually an obstacle to progress with the new DMA API which cannot cover this case properly. To keep backward compatibility, let's perform the necessary custom cache maintenance locally in the only driver affected. Signed-off-by: Nicolas Pitre <nico@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] export __cpu_flush_dcache_pageRussell King2009-07-051-0/+1
| | | | | | | | | | | | Now required for libsas: Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready Building modules, stage 2. MODPOST 1096 modules ERROR: "xscale_flush_kern_dcache_page" [drivers/scsi/libsas/libsas.ko] undefined! Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] 5364/1: allow flush_ioremap_region() to be used from modulesNicolas Pitre2009-01-121-0/+1
| | | | | | | | | Without this, the pxa2xx-flash driver cannot be used as a module. Reported-by: Chris Lawrence <chrisdl@netspace.net.au> Signed-off-by: Nicolas Pitre <nico@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] clearpage: provide our own clear_user_highpage()Russell King2008-11-281-1/+1
| | | | | | | For similar reasons as copy_user_page(), we want to avoid the additional kmap_atomic if it's unnecessary. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] copypage: provide our own copy_user_highpage()Russell King2008-11-281-1/+1
| | | | | | | | | | | | | | We used to override the copy_user_page() function. However, this is not only inefficient, it also causes additional complexity for highmem support, since we convert from a struct page to a kernel direct mapped address and back to a struct page again. Moreover, with highmem support, we end up pointlessly setting up kmap entries for pages which we're going to remap. So, push the kmapping down into the copypage implementation files where it's required. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] 4502/1: nommu: Do not export the copy/clear user page functionsCatalin Marinas2007-07-201-0/+2
| | | | | | | | The __cpu_{clear|copy}_user_page functions are not defined for the MMU-less case and therefore should not be exported. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Unuse another Linux PTE bitRussell King2006-12-131-1/+1
| | | | | | | | | | L_PTE_ASID is not really required to be stored in every PTE, since we can identify it via the address passed to set_pte_at(). So, create set_pte_ext() which takes the address of the PTE to set, the Linux PTE value, and the additional CPU PTE bits which aren't encoded in the Linux PTE value. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] 3737/1: Export ARM copy/clear_user_page symbolsGeorge G. Davis2006-07-291-0/+8
| | | | | | | | | | | | | | | | | Patch from George G. Davis As reported by various folks on the ARM Linux kernel mailing list, the video-buf.ko driver has undefined references on all ARM machines which use it as observed during `make modules`: Warning: "v4wb_clear_user_page" [drivers/media/video/video-buf.ko] undefined! Similar warnings exist for all ARM machines which use this driver. So this change adds the missing EXPORT_SYMBOLs to allow using this driver as a module. Signed-off-by: George G. Davis <gdavis@mvista.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-171-0/+40
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!