1. 17 12月, 2009 1 次提交
    • M
      sh: Definitions for 3-level page table layout · 5d9b4b19
      Matt Fleming 提交于
      If using 64-bit PTEs and 4K pages then each page table has 512 entries
      (as opposed to 1024 entries with 32-bit PTEs). Unlike MIPS, SH follows
      the convention that all structures in the page table (pgd_t, pmd_t,
      pgprot_t, etc) must be the same size. Therefore, 64-bit PTEs require
      64-bit PGD entries, etc. Using 2-levels of page tables and 64-bit PTEs
      it is only possible to map 1GB of virtual address space.
      
      In order to map all 4GB of virtual address space we need to adopt a
      3-level page table layout. This actually works out better for
      CONFIG_SUPERH32 because we only waste 2 PGD entries on the P1 and P2
      areas (which are untranslated) instead of 256.
      Signed-off-by: NMatt Fleming <matt@console-pimps.org>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      5d9b4b19
  2. 11 11月, 2009 1 次提交
  3. 27 10月, 2009 1 次提交
    • P
      sh: Fix hugetlbfs dependencies for SH-3 && MMU configurations. · ffb4a73d
      Paul Mundt 提交于
      The hugetlb dependencies presently depend on SUPERH && MMU while the
      hugetlb page size definitions depend on CPU_SH4 or CPU_SH5. This
      unfortunately allows SH-3 + MMU configurations to enable hugetlbfs
      without a corresponding HPAGE_SHIFT definition, resulting in the build
      blowing up.
      
      As SH-3 doesn't support variable page sizes, we tighten up the
      dependenies a bit to prevent hugetlbfs from being enabled. These days
      we also have a shiny new SYS_SUPPORTS_HUGETLBFS, so switch to using
      that rather than adding to the list of corner cases in fs/Kconfig.
      Reported-by: NKristoffer Ericson <kristoffer.ericson@gmail.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      ffb4a73d
  4. 16 10月, 2009 1 次提交
  5. 10 10月, 2009 1 次提交
  6. 21 8月, 2009 1 次提交
  7. 14 5月, 2009 1 次提交
  8. 10 5月, 2009 1 次提交
  9. 02 4月, 2009 1 次提交
    • P
      sh: Kill off broken direct-mapped cache mode. · e8208828
      Paul Mundt 提交于
      Forcing direct-mapped worked on certain older 2-way set associative
      parts, but was always error prone on 4-way parts. As these are the
      norm these days, there is not much point in continuing to support this
      mode. Most of the folks that used direct-mapped mode generally just
      wanted writethrough caching in the first place..
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      e8208828
  10. 10 3月, 2009 1 次提交
  11. 17 9月, 2008 1 次提交
  12. 08 9月, 2008 1 次提交
  13. 11 8月, 2008 1 次提交
  14. 04 8月, 2008 1 次提交
  15. 28 7月, 2008 3 次提交
  16. 06 3月, 2008 1 次提交
  17. 28 1月, 2008 6 次提交
  18. 07 11月, 2007 1 次提交
    • P
      sh: Kill off the remaining ST40 cruft. · f9669187
      Paul Mundt 提交于
      The ST40 stuff in-tree hasn't built for some time, and hasn't been
      updated for over 3 years. ST maintains their own out-of-tree changes
      and rebases occasionally, and that's ultimately where all of the ST40
      users go anyways.
      
      In order for the ST40 code to be brought up to date most of the stuff
      removed in this changeset would have to be rewritten anyways, so there's
      very little benefit in keeping the remnants around either.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      f9669187
  19. 27 9月, 2007 3 次提交
  20. 21 9月, 2007 12 次提交