aboutsummaryrefslogtreecommitdiffstats
path: root/include/asm-arm/mach/map.h (follow)
AgeCommit message (Collapse)AuthorFilesLines
2007-05-05[ARM] mm 10: allow memory type to be specified with ioremapRussell King1-4/+3
__ioremap() took a set of page table flags (specifically the cacheable and bufferable bits) to control the mapping type. However, with the advent of ARMv6, this is far too limited. Replace the page table flags with a memory type index, so that the desired attributes can be selected from the mem_type table. Finally, to prevent silent miscompilation due to the differing arguments, rename the __ioremap() and __ioremap_pfn() functions. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-05[ARM] mm 9: add additional device memory typesRussell King1-8/+12
Add cached device type for ioremap_cached(). Group all device memory types together, and ensure that they all have a "MT_DEVICE" prefix. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-06-28[ARM] nommu: remove fault-armv, mmap and mm-armv files from nommu buildRussell King1-0/+4
Remove fault-armv.o, mmap.o and mm-armv.o from uclinux builds - these are concerned with MMU-ful operations, and as such are redundant for uclinux. Since this also removes iotable_init() and iotable_init() is used extensively in the platform support files, just make it a no-op. Based upon a couple of patches by Hyok. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-06-28[ARM] Remove TABLE_SIZE, and several unused function prototypesRussell King1-5/+0
TABLE_SIZE is never used in arch/arm/mm/init.c. create_memmap_holes(), memtable_init, and setup_io_desc() no longer exist in the kernel. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-26[ARM] 3269/1: Add ARMv6 MT_NONSHARED_DEVICE mem_types[] indexGeorge G. Davis1-0/+1
Patch from George G. Davis This Freescale Semiconductor, Inc. contributed patch adds mem_types[] support for ARMv6 non-shared device memory region attributes. This implementation provides support for only first level section mapped non-shared devices. Second level non-shared device mappings are not yet supported. Signed-off-by: George G. Davis <gdavis@mvista.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-09[ARM] 3070/2: Add __ioremap_pfn() APIDeepak Saxena1-3/+0
Patch from Deepak Saxena In working on adding 36-bit addressed supersection support to ioremap(), I came to the conclusion that it would be far simpler to do so by just splitting __ioremap() into a main external interface and adding an __ioremap_pfn() function that takes a pfn + offset into the page that __ioremap() can call. This way existing callers of __ioremap() won't have to change their code and 36-bit systems will just call __ioremap_pfn() and we will not have to deal with unsigned long long variables. Note that __ioremap_pfn() should _NOT_ be called directly by drivers but is reserved for use by arch_ioremap() implementations that map 32-bit resource regions into the real 36-bit address and then call this new function. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-10-29[ARM] Fix buggy __phys_to_pfn / __pfn_to_physRussell King1-2/+2
Macro arguments should _always_ be surrounded by parentheses when used to prevent unexpected problems with operator precedence. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-10-28[ARM] 3016/1: Replace map_desc.physical with map_desc.pfnDeepak Saxena1-1/+4
Patch from Deepak Saxena Convert map_desc.physical to map_desc.pfn. This allows us to add support for 36-bit addressed physical devices in the static maps without having to resort to u64 variables. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+33
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!