Searched hist:"5 f0fbf9ecaf354fa4bbf266fffdea2ea3d14a0ed" (Results 1 – 2 of 2) sorted by relevance
| /openbmc/linux/arch/arm/include/asm/ |
| H A D | fixmap.h | 5f0fbf9ecaf354fa4bbf266fffdea2ea3d14a0ed Tue Sep 16 12:05:53 CDT 2008 Nicolas Pitre <nico@cam.org> [ARM] fixmap support
This is the minimum fixmap interface expected to be implemented by
architectures supporting highmem.
We have a second level page table already allocated and covering
0xfff00000-0xffffffff because the exception vector page is located
at 0xffff0000, and various cache tricks already use some entries above
0xffff0000. Therefore the PTEs covering 0xfff00000-0xfffeffff are free
to be used.
However the XScale cache flushing code already uses virtual addresses
between 0xfffe0000 and 0xfffeffff.
So this reserves the 0xfff00000-0xfffdffff range for fixmap stuff.
The Documentation/arm/memory.txt information is updated accordingly,
including the information about the actual top of DMA memory mapping
region which didn't match the code.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
|
| /openbmc/linux/arch/arm/mm/ |
| H A D | mm.h | diff 5f0fbf9ecaf354fa4bbf266fffdea2ea3d14a0ed Tue Sep 16 12:05:53 CDT 2008 Nicolas Pitre <nico@cam.org> [ARM] fixmap support
This is the minimum fixmap interface expected to be implemented by
architectures supporting highmem.
We have a second level page table already allocated and covering
0xfff00000-0xffffffff because the exception vector page is located
at 0xffff0000, and various cache tricks already use some entries above
0xffff0000. Therefore the PTEs covering 0xfff00000-0xfffeffff are free
to be used.
However the XScale cache flushing code already uses virtual addresses
between 0xfffe0000 and 0xfffeffff.
So this reserves the 0xfff00000-0xfffdffff range for fixmap stuff.
The Documentation/arm/memory.txt information is updated accordingly,
including the information about the actual top of DMA memory mapping
region which didn't match the code.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
|