On Apr 21, 2008, at 7:15 PM, Paul Mackerras wrote:
Kumar Gala writes:
Once again I want to go through it carefully and understand how it
all
works, and in particular understand things like the way it ensures
that the base address for the kmap region is aligned to a 4M
boundary
so all the kmap ptes are in a single page (assuming it does :).
I'm not clear on why this is needed. I can see value in having the
PGD entry in place but the pte PAs would be changing all the time
so I
don't see what benefit there is in keeping them in one page.
Have a look at map_new_virtual in mm/highmem.c. In particular:
set_pte_at(&init_mm, vaddr,
&(pkmap_page_table[last_pkmap_nr]), mk_pte(page,
kmap_prot));
assumes that the ptes that kmap uses are in a contiguous array whose
base is pkmap_page_table.
For normal kmap ptes we cover things in one PGD via:
#define PKMAP_BASE ((FIXADDR_BOOT_START -
PAGE_SIZE*(LAST_PKMAP +
1)) & PMD_MASK)
OK, that probably does the trick ... <checks> ... yes it does.
We seem to have a distinction without a difference between
FIXADDR_START and FIXADDR_BOOT_START, and similarly between
__FIXADDR_SIZE and __FIXADDR_BOOT_SIZE. Is there any actual
difference and if not why do we have two names for the same thing?
Also, we seem to have an unnecessary distinction (and unnecessary
casting) between __FIXADDR_TOP and FIXADDR_TOP.
its left over from the x86 port. I'll get rid of __FIXADDR_BOOT_SIZE,
FIXADDR_BOOT_START, and __FIXADDR_TOP.
If we want the early ioremap support in the future we can add back
__FIXADDR_BOOT_SIZE and FIXADDR_BOOT_START.
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
