summaryrefslogtreecommitdiff
path: root/arch/xtensa/include/asm/page.h
AgeCommit message (Collapse)Author
2023-02-09mm, arch: add generic implementation of pfn_valid() for FLATMEMMike Rapoport (IBM)
Every architecture that supports FLATMEM memory model defines its own version of pfn_valid() that essentially compares a pfn to max_mapnr. Use mips/powerpc version implemented as static inline as a generic implementation of pfn_valid() and drop its per-architecture definitions. [rppt@kernel.org: fix the generic pfn_valid()] Link: https://lkml.kernel.org/r/Y9lg7R1Yd931C+y5@kernel.org Link: https://lkml.kernel.org/r/20230129124235.209895-5-rppt@kernel.org Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Guo Ren <guoren@kernel.org> [csky] Acked-by: Huacai Chen <chenhuacai@loongson.cn> [LoongArch] Acked-by: Stafford Horne <shorne@gmail.com> [OpenRISC] Acked-by: Michael Ellerman <mpe@ellerman.id.au> [powerpc] Reviewed-by: David Hildenbrand <david@redhat.com> Tested-by: Conor Dooley <conor.dooley@microchip.com> Cc: Brian Cain <bcain@quicinc.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Dinh Nguyen <dinguyen@kernel.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greg Ungerer <gerg@linux-m68k.org> Cc: Helge Deller <deller@gmx.de> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: Matt Turner <mattst88@gmail.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Richard Weinberger <richard@nod.at> Cc: Rich Felker <dalias@libc.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Vineet Gupta <vgupta@kernel.org> Cc: WANG Xuerui <kernel@xen0n.name> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2021-06-29arch, mm: remove stale mentions of DISCONIGMEMMike Rapoport
There are several places that mention DISCONIGMEM in comments or have stale code guarded by CONFIG_DISCONTIGMEM. Remove the dead code and update the comments. Link: https://lkml.kernel.org/r/20210608091316.3622-7-rppt@kernel.org Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matt Turner <mattst88@gmail.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-10mm/vma: define a default value for VM_DATA_DEFAULT_FLAGSAnshuman Khandual
There are many platforms with exact same value for VM_DATA_DEFAULT_FLAGS This creates a default value for VM_DATA_DEFAULT_FLAGS in line with the existing VM_STACK_DEFAULT_FLAGS. While here, also define some more macros with standard VMA access flag combinations that are used frequently across many platforms. Apart from simplification, this reduces code duplication as well. Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Richard Henderson <rth@twiddle.net> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Mark Salter <msalter@redhat.com> Cc: Guo Ren <guoren@kernel.org> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Brian Cain <bcain@codeaurora.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paulburton@kernel.org> Cc: Nick Hu <nickhu@andestech.com> Cc: Ley Foon Tan <ley.foon.tan@intel.com> Cc: Jonas Bonn <jonas@southpole.se> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Rich Felker <dalias@libc.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Guan Xuetao <gxt@pku.edu.cn> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jeff Dike <jdike@addtoit.com> Cc: Chris Zankel <chris@zankel.net> Link: http://lkml.kernel.org/r/1583391014-8170-2-git-send-email-anshuman.khandual@arm.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-11-26xtensa: add XIP kernel supportMax Filippov
XIP (eXecute In Place) kernel image is the image that can be run directly from ROM, using RAM only for writable data. XIP xtensa kernel differs from regular xtensa kernel in the following ways: - it has exception/IRQ vectors merged into text section. No vectors relocation takes place at kernel startup. - .data/.bss location must be specified in the kernel configuration, its content is copied there in the _startup function. - .init.text is merged with the rest of text and is executed from ROM. - when MMU is used the virtual address where the kernel will be mapped must be specified in the kernel configuration. It may be in the KSEG or in the KIO, __pa macro is adjusted to be able to handle both. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2018-08-20xtensa: rework {CONFIG,PLATFORM}_DEFAULT_MEM_STARTMax Filippov
Drop PLATFORM_DEFAULT_MEM_START from the platform/hardware.h headers. Provide definition of CONFIG_DEFAULT_MEM_START always, allow changing it only in noMMU configurations when PLATFORM_WANT_DEFAULT_MEM is selected. Change prompt and description so that it's clear that it controls PAGE_OFFSET and PHYS_OFFSET. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2017-12-16xtensa: move fixmap and kmap just above the KSEGMax Filippov
The virtual address space between the page table and the VMALLOC region is big enough to host KASAN shadow map and there's enough space between the VMALLOC area and KSEG for the fixmap and kmap. Move fixmap and kmap to the gap between VMALLOC area and KSEG, just above the KSEG. Reorder entries in the kernel memory layout printing code. Drop duplicate PGTABLE_START definition, use XCHAL_PAGE_TABLE_VADDR instead. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2017-03-30xtensa: make __pa work with uncached KSEG addressesMax Filippov
When __pa is applied to virtual address in uncached KSEG region the result is incorrect. Fix it by checking if the original address is in the uncached KSEG and adjusting the result. It looks better than masking off bits because pfn_valid would correctly work with new __pa results and it may be made working in noMMU case, once we get definition for uncached memory view. This is required for the dma_common_mmap and DMA debug code to work correctly: they both indirectly use __pa with coherent DMA addresses. In case of DMA debug the visible effect is false reports that an address mapped for DMA is accessed by CPU. Cc: stable@vger.kernel.org Tested-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2016-07-24xtensa: minimize use of PLATFORM_DEFAULT_MEM_{ADDR,SIZE}Max Filippov
Now that the kernel load address and KSEG physical base address have their own Kconfig symbols PLATFORM_DEFAULT_MEM seems redundant. It makes little sense to use it in MMU configurations instead of KSEG_PADDR. In noMMU configurations there's no explicit KSEG, so it's still useful for the early cache initialization and definition of ARCH_PFN_OFFSET, which affects mem_map size. - limit it to noMMU; MMU variants have XCHAL_KSEG_PADDR and XCHAL_KSEG_SIZE; - don't use it to define TASK_SIZE or MAX_LOW_PFN: first doesn't make any difference in noMMU, second is meaningless as there's no high memory; - don't add default physical memory region: memory layout should come from the DT, bootloader tags, or memmap= command line parameter. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2016-07-24xtensa: cleanup MMU setup and kernel layout macrosMax Filippov
Make kernel load address explicit, independent of the selected MMU configuration and configurable from Kconfig. Do not restrict it to the first 512MB of the physical address space. Cleanup kernel memory layout macros: - rename VECBASE_RESET_VADDR to VECBASE_VADDR, XC_VADDR to VECTOR_VADDR; - drop VIRTUAL_MEMORY_ADDRESS and LOAD_MEMORY_ADDRESS; - introduce PHYS_OFFSET and use it in __va and __pa definitions; - synchronize MMU/noMMU vectors, drop unused NMI vector; - replace hardcoded vectors offset of 0x3000 with Kconfig symbol. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2016-07-24xtensa: add alternative kernel memory layoutsMax Filippov
MMUv3 is able to support low memory bigger than 128MB. Implement 256MB and 512MB KSEG layouts: - add Kconfig selector for KSEG layout; - add KSEG base address, size and alignment definitions to arch/xtensa/include/asm/kmem_layout.h; - use new definitions in TLB initialization; - add build time memory map consistency checks. See Documentation/xtensa/mmu.txt for the details of new memory layouts. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2016-07-24xtensa: move kernel mapping addresses into kmem_layout.hMax Filippov
Create a header dedicated to memory layout definitions. Include it from places where these definitions are needed. Express vmalloc area address, VIRTUAL_MEMORY_ADDRESS and KERNELOFFSET through KSEG address. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2014-10-21xtensa: nommu: clean up memory map dumpMax Filippov
noMMU configuration doesn't use special area for vmalloc allocations, don't print it in the memory map. PAGE_OFFSET is fixed to 0 in noMMU, use min_low_pfn and max_low_pfn for lowmem range display. Make all XCHAL_KSEG_* constants unsigned long for consistency with other addresses. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2014-10-21xtensa: nommu: don't build most of the cache flushing codeMax Filippov
Most cache flushing code is only relevant for MMU. Don't build it for nommu configuration. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2014-08-14xtensa: support aliasing cache in k[un]map_atomicMax Filippov
Map high memory pages at virtual addresses with color that match color of their physical address. Existing cache alias management mechanisms may be used with such pages. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2014-08-14xtensa: implement clear_user_highpage and copy_user_highpageMax Filippov
Existing clear_user_page and copy_user_page cannot be used with highmem because they calculate physical page address from its virtual address and do it incorrectly in case of high memory page mapped with kmap_atomic. Also kmap is not needed, as most likely userspace mapping color would be different from the kmapped color. Provide clear_user_highpage and copy_user_highpage functions that determine if temporary mapping is needed for the pages. Move most of the logic of the former clear_user_page and copy_user_page to xtensa/mm/cache.c only leaving temporary mapping setup, invalidation and clearing/copying in the xtensa/mm/misc.S. Rename these functions to clear_page_alias and copy_page_alias. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2012-12-18xtensa: clean up files to make them code-style compliantChris Zankel
Remove heading and trailing spaces, trim trailing lines, and wrap lines that are longer than 80 characters. Signed-off-by: Chris Zankel <chris@zankel.net>
2011-05-25xtensa/mm: remove WANT_PAGE_VIRTUALSebastian Andrzej Siewior
This is not useful: it provides page->virtual and is used with highmem. xtensa has no support for highmem and those HIGHMEM bits which are found by grep are partly implemented. The interesting functions like kmap() are missing. If someone actually implements the complete HIGHMEM support he could use HASHED_PAGE_VIRTUAL like most others do. Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Cc: Chris Zankel <chris@zankel.net> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-11asm-generic: rename page.h and uaccess.hArnd Bergmann
The current asm-generic/page.h only contains the get_order function, and asm-generic/uaccess.h only implements unaligned accesses. This renames the file to getorder.h and uaccess-unaligned.h to make room for new page.h and uaccess.h file that will be usable by all simple (e.g. nommu) architectures. Signed-off-by: Remis Lima Baima <remis.developer@googlemail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2009-04-02xtensa: nommu supportJohannes Weiner
Add support for !CONFIG_MMU setups. Signed-off-by: Johannes Weiner <jw@emlix.com> Signed-off-by: Chris Zankel <chris@zankel.net>
2009-04-02xtensa: cope with ram beginning at higher addressesJohannes Weiner
The current assumption of the memory code is that the first RAM PFN in the system is 0. Adjust the relevant code to play well with setups where memory starts at higher addresses, indicated by PLATFORM_DEFAULT_MEM_START. The new memory model looks like this: +----------+--+----------------------+----------------+ | | | | | | | | RAM | | | | | | | +----------+--+----------------------+----------------+ | | | | | +- PFN 0 | +- min_low_pfn +- max_low_pfn +- max_pfn | +- ARCH_PFN_OFFSET +- PLATFORM_DEFAULT_MEM_START >> PAGE_SIZE The memory map contains pages starting from pfn ARCH_PFN_OFFSET up to max_low_pfn. The only zone used right now will span exactly the same region. Usually, ARCH_PFN_OFFSET and min_low_pfn are the same value. Handle them separately for robustness. Gapping pages will be in the memory map but marked as reserved and won't be touched. Signed-off-by: Johannes Weiner <jw@emlix.com> Signed-off-by: Chris Zankel <chris@zankel.net>
2008-11-06xtensa: move headers files to arch/xtensa/includeChris Zankel
Move all header files for xtensa to arch/xtensa/include and platform and variant header files to the appropriate arch/xtensa/platforms/ and arch/xtensa/variants/ directories. Moving the files gets also rid of all uses of symlinks in the Makefile. This has been completed already for the majority of the architectures and xtensa is one out of six missing. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Chris Zankel <chris@zankel.net>