kernel/linux.git/arch/powerpc/include/asm/mmu.h, branch linux-4.4.y

powerpc: Remove MMU_FTR_SLB

2014-07-28T04:10:23+00:00

We now only support cpus that use an SLB, so we don't need an MMU feature to indicate that. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt

powerpc: Clean up MMU_FTRS_A2 and MMU_FTR_TYPE_3E

2014-07-11T02:55:05+00:00

In fb5a515704d7 "powerpc: Remove platforms/wsp and associated pieces", we removed the last user of MMU_FTRS_A2. So remove it. MMU_FTRS_A2 was the last user of MMU_FTR_TYPE_3E, so remove it also. This leaves some unreachable code in mmu_context_nohash.c, so remove that also. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt

powerpc/e6500: TLB miss handler with hardware tablewalk support

2014-01-09T23:52:19+00:00

There are a few things that make the existing hw tablewalk handlers unsuitable for e6500: - Indirect entries go in TLB1 (though the resulting direct entries go in TLB0). - It has threads, but no "tlbsrx." -- so we need a spinlock and a normal "tlbsx". Because we need this lock, hardware tablewalk is mandatory on e6500 unless we want to add spinlock+tlbsx to the normal bolted TLB miss handler. - TLB1 has no HES (nor next-victim hint) so we need software round robin (TODO: integrate this round robin data with hugetlb/KVM) - The existing tablewalk handlers map half of a page table at a time, because IBM hardware has a fixed 1MiB indirect page size. e6500 has variable size indirect entries, with a minimum of 2MiB. So we can't do the half-page indirect mapping, and even if we could it would be less efficient than mapping the full page. - Like on e5500, the linear mapping is bolted, so we don't need the overhead of supporting nested tlb misses. Note that hardware tablewalk does not work in rev1 of e6500. We do not expect to support e6500 rev1 in mainline Linux. Signed-off-by: Scott Wood Cc: Mihai Caraman

powerpc: POWER8 cputable entry

2012-11-15T02:00:45+00:00

Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt

powerpc/mm: Make some of the PGTABLE_RANGE dependency explicit

2012-09-17T06:31:53+00:00

slice array size and slice mask size depend on PGTABLE_RANGE. Reviewed-by: Paul Mackerras Signed-off-by: Aneesh Kumar K.V Signed-off-by: Benjamin Herrenschmidt

powerpc/mm: remove obsolete comment about page size name array

2012-07-03T04:14:50+00:00

The array of names in hugetlbpage.c no longer exists. Signed-off-by: Scott Wood Signed-off-by: Benjamin Herrenschmidt

powerpc: Hugetlb for BookE

2011-09-19T23:19:40+00:00

Enable hugepages on Freescale BookE processors. This allows the kernel to use huge TLB entries to map pages, which can greatly reduce the number of TLB misses and the amount of TLB thrashing experienced by applications with large memory footprints. Care should be taken when using this on FSL processors, as the number of large TLB entries supported by the core is low (16-64) on current processors. The supported set of hugepage sizes include 4m, 16m, 64m, 256m, and 1g. Page sizes larger than the max zone size are called "gigantic" pages and must be allocated on the command line (and cannot be deallocated). This is currently only fully implemented for Freescale 32-bit BookE processors, but there is some infrastructure in the code for 64-bit BooKE. Signed-off-by: Becky Bruce Signed-off-by: David Gibson Signed-off-by: Benjamin Herrenschmidt

Merge remote-tracking branch 'jwb/next' into next

2011-07-22T03:16:41+00:00

powerpc/44x: don't use tlbivax on AMP systems

2011-07-12T13:21:55+00:00

Since other OS's may be running on the other cores don't use tlbivax Signed-off-by: Dave Kleikamp Signed-off-by: Tony Breeds Cc: Benjamin Herrenschmidt Cc: Josh Boyer Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Josh Boyer

powerpc: Create next_tlbcam_idx percpu variable for FSL_BOOKE

2011-07-08T05:21:34+00:00

This is used to round-robin TLBCAM entries. Signed-off-by: Becky Bruce Signed-off-by: Kumar Gala