aboutsummaryrefslogtreecommitdiff
path: root/include/asm-ppc/pgtable.h
AgeCommit message (Collapse)Author
2005-08-06[PATCH] ppc32: ppc440 pagetable attributes (comments updates)Matt Porter
Here's an incremental patch with comment updates and some additional grammar cleanups. Signed-off-by: Matt Porter <mporter@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-05[PATCH] ppc32: fix ppc440 pagetable attributesMatt Porter
This patch fixes a bug in the PPC440 pagetable attributes that breaks swap support. It also adds some notes on the PPC440 attribute fields. Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> for CELF Signed-off-by: Matt Porter <mporter@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-21[PATCH] ppc32: Clean up NUM_TLBCAMS usage for Freescale Book-E PPC'sKumar Gala
Made the number of TLB CAM entries private and converted the board consumers to use num_tlbcam_entries which is setup at boot time from configuration registers. This way the only consumers of the #define NUM_TLBCAMS are the arrays used to manage the TLB. Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-19[PATCH] freepgt: arch FIRST_USER_ADDRESS 0Hugh Dickins
Replace misleading definition of FIRST_USER_PGD_NR 0 by definition of FIRST_USER_ADDRESS 0 in all the MMU architectures beyond arm and arm26. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] ppc32: Support 36-bit physical addressing on e500Kumar Gala
To add support for 36-bit physical addressing on e500 the following changes have been made. The changes are generalized to support any physical address size larger than 32-bits: * Allow FSL Book-E parts to use a 64-bit PTE, it is 44-bits of pfn, 20-bits of flags. * Introduced new CPU feature (CPU_FTR_BIG_PHYS) to allow runtime handling of updating hardware register (SPRN_MAS7) which holds the upper 32-bits of physical address that will be written into the TLB. This is useful since not all e500 cores support 36-bit physical addressing. * Currently have a pass through implementation of fixup_bigphys_addr * Moved _PAGE_DIRTY in the 64-bit PTE case to free room for three additional storage attributes that may exist in future FSL Book-E cores and updated fault handler to copy these bits into the hardware TLBs. Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] ppc32: Allow adjust of pfn offset in pteKumar Gala
Allow the pfn to be offset by more than just PAGE_SHIFT in the pte. Today, PAGE_SHIFT tends to allow us to have 12-bits of flags in the pte. In the future if we have a larger pte we can allocate more bits for flags by offsetting the pfn even further. Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] ppc32: Fix pte_update for 64-bit PTEsKumar Gala
While the existing pte_update code handled atomically modifying a 64-bit PTE, it did not return all 64-bits of the PTE before it was modified. This causes problems in some places that expect the full PTE to be returned, like ptep_get_and_clear(). Created a new pte_update function that is conditional on CONFIG_PTE_64BIT. It atomically reads the low PTE word which all PTE flags are required to be in and returns a premodified full 64-bit PTE. Since we now have an explicit 64-bit PTE version of pte_update we can also remove the hack that existed to get the low PTE word regardless of size. Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!