Merge branch 'sparc64-Add-16GB-hugepage-support'

Nitin Gupta says:

====================
sparc64: Add 16GB hugepage support

SPARC architecture supports 16G hugepages but the kernel did not
support these. This patch series adds support for it and also cleanes
up some page walk/alloc functions.

Patch 1/3: Core changes needed to add 16G hugepage support: To map a
  single 16G hugepage, two PUD entries are used. Each PUD entry maps
  8G portion of a 16G page. This page table encoding scheme is same as
  that used for hugepages at PMD level (8M, 256M and 2G pages) where
  each PMD entry points successively to 8M regions within a page.  No
  page table entries below the PUD level are allocated for 16G
  hugepage since those are not required.

  TSB entries for a 16G page are created at every 4M boundary since
  the HUGE_TSB is used for these pages which is configured with page
  size of 4M.  When walking page tables (on a TSB miss), bits [32:22]
  are transferred from vaddr to PUD to resolve addresses at 4M
  boundary. The resolved address mapping is then stored in HUGE_TSB.

Patch 2/3: get_user_pages() etc. are used for direct IO. These
  functions were not aware of hugepages at the PUD level and would try
  to continue walking page tables beyond the PUD level. Since 16G
  hugepages have page tables allocated till PUD level only, these
  accesses would result in invalid access. This patch adds the case
  for PUD huge pages to these functions.

Patch 3/3: Patch 1 added the case of PUD entry being huge in page
  table walk and alloc functions. This new case further increased
  nesting in these functions and made them harder to follow. This
  patch flattens these functions for better readability.

Cc: sparclinux@vger.kernel.org
Changelog v5 vs v4:
 - Checking at PUD level for hugepage entry during page table walk is
   patched out if 16GB hugepages are not being used.
Changelog v4 vs v3:
 - Added cover letter (patch 0/4) for patch series.
Changelog v3 vs v2:
 - Fixed email headers so the subject shows up correctly.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>