1. 14 11月, 2005 1 次提交
  2. 11 11月, 2005 1 次提交
    • B
      [PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel · a7f290da
      Benjamin Herrenschmidt 提交于
      This patch moves the vdso's to arch/powerpc, adds support for the 32
      bits vdso to the 32 bits kernel, rename systemcfg (finally !), and adds
      some new (still untested) routines to both vdso's: clock_gettime() with
      support for CLOCK_REALTIME and CLOCK_MONOTONIC, clock_getres() (same
      clocks) and get_tbfreq() for glibc to retreive the timebase frequency.
      
      Tom,Steve: The implementation of get_tbfreq() I've done for 32 bits
      returns a long long (r3, r4) not a long. This is such that if we ever
      add support for >4Ghz timebases on ppc32, the userland interface won't
      have to change.
      
      I have tested gettimeofday() using some glibc patches in both ppc32 and
      ppc64 kernels using 32 bits userland (I haven't had a chance to test a
      64 bits userland yet, but the implementation didn't change and was
      tested earlier). I haven't tested yet the new functions.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a7f290da
  3. 10 11月, 2005 1 次提交
  4. 07 11月, 2005 1 次提交
    • B
      [PATCH] ppc64: support 64k pages · 3c726f8d
      Benjamin Herrenschmidt 提交于
      Adds a new CONFIG_PPC_64K_PAGES which, when enabled, changes the kernel
      base page size to 64K.  The resulting kernel still boots on any
      hardware.  On current machines with 4K pages support only, the kernel
      will maintain 16 "subpages" for each 64K page transparently.
      
      Note that while real 64K capable HW has been tested, the current patch
      will not enable it yet as such hardware is not released yet, and I'm
      still verifying with the firmware architects the proper to get the
      information from the newer hypervisors.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3c726f8d
  5. 02 11月, 2005 1 次提交
  6. 28 10月, 2005 1 次提交
  7. 26 10月, 2005 1 次提交
    • P
      powerpc: Merge rtas.c into arch/powerpc/kernel · 033ef338
      Paul Mackerras 提交于
      This splits arch/ppc64/kernel/rtas.c into arch/powerpc/kernel/rtas.c,
      which contains generic RTAS functions useful on any CHRP platform,
      and arch/powerpc/platforms/pseries/rtas-fw.[ch], which contain
      some pSeries-specific firmware flashing bits.  The parts of rtas.c
      that are to do with pSeries-specific error logging are protected
      by a new CONFIG_RTAS_ERROR_LOGGING symbol.  The inclusion of rtas.o
      is controlled by the CONFIG_PPC_RTAS symbol, and the relevant
      platforms select that.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      033ef338
  8. 21 10月, 2005 1 次提交
    • D
      [PATCH] powerpc: Merge thread_info.h · 6cb7bfeb
      David Gibson 提交于
      Merge ppc32 and ppc64 versions of thread_info.h.  They were pretty
      similar already, the chief changes are:
      
      	- Instead of inline asm to implement current_thread_info(),
      which needs to be different for ppc32 and ppc64, we use C with an
      asm("r1") register variable.  gcc turns it into the same asm as we
      used to have for both platforms.
      	- We replace ppc32's 'local_flags' with the ppc64
      'syscall_noerror' field.  The noerror flag was in fact the only thing
      in the local_flags field anyway, so the ppc64 approach is simpler, and
      means we only need a load-immediate/store instead of load/mask/store
      when clearing the flag.
      	- In readiness for 64k pages, when THREAD_SIZE will be less
      than a page, ppc64 used kmalloc() rather than get_free_pages() to
      allocate the kernel stack.  With this patch we do the same for ppc32,
      since there's no strong reason not to.
      	- For ppc64, we no longer export THREAD_SHIFT and THREAD_SIZE
      via asm-offsets, thread_info.h can now be safely included in asm, as
      on ppc32.
      
      Built and booted on G4 Powerbook (ARCH=ppc and ARCH=powerpc) and
      Power5 (ARCH=ppc64 and ARCH=powerpc).
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      6cb7bfeb
  9. 11 10月, 2005 1 次提交
    • P
      ppc: Various minor compile fixes · fd582ec8
      Paul Mackerras 提交于
      This fixes up a variety of minor problems in compiling with ARCH=ppc
      arising from using the merged versions of various header files.
      A lot of the changes are just adding #include <asm/machdep.h> to
      files that use ppc_md or smp_ops_t.
      
      This also arranges for us to use semaphore.c, vecemu.c, vector.S and
      fpu.S from arch/powerpc/kernel when compiling with ARCH=ppc.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      fd582ec8
  10. 10 10月, 2005 1 次提交
  11. 30 9月, 2005 1 次提交
  12. 26 9月, 2005 1 次提交
    • P
      powerpc: Merge enough to start building in arch/powerpc. · 14cf11af
      Paul Mackerras 提交于
      This creates the directory structure under arch/powerpc and a bunch
      of Kconfig files.  It does a first-cut merge of arch/powerpc/mm,
      arch/powerpc/lib and arch/powerpc/platforms/powermac.  This is enough
      to build a 32-bit powermac kernel with ARCH=powerpc.
      
      For now we are getting some unmerged files from arch/ppc/kernel and
      arch/ppc/syslib, or arch/ppc64/kernel.  This makes some minor changes
      to files in those directories and files outside arch/powerpc.
      
      The boot directory is still not merged.  That's going to be interesting.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      14cf11af
  13. 29 8月, 2005 1 次提交
    • D
      [PATCH] Dynamic hugepage addresses for ppc64 · c594adad
      David Gibson 提交于
      Paulus, I think this is now a reasonable candidate for the post-2.6.13
      queue.
      
      Relax address restrictions for hugepages on ppc64
      
      Presently, 64-bit applications on ppc64 may only use hugepages in the
      address region from 1-1.5T.  Furthermore, if hugepages are enabled in
      the kernel config, they may only use hugepages and never normal pages
      in this area.  This patch relaxes this restriction, allowing any
      address to be used with hugepages, but with a 1TB granularity.  That
      is if you map a hugepage anywhere in the region 1TB-2TB, that entire
      area will be reserved exclusively for hugepages for the remainder of
      the process's lifetime.  This works analagously to hugepages in 32-bit
      applications, where hugepages can be mapped anywhere, but with 256MB
      (mmu segment) granularity.
      
      This patch applies on top of the four level pagetable patch
      (http://patchwork.ozlabs.org/linuxppc64/patch?id=1936).
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      c594adad
  14. 27 8月, 2005 1 次提交
    • D
      Fix missing audit_syscall_exit() on ppc64 sigsuspend exit path · 17888225
      David Woodhouse 提交于
      When we leave sigsuspend() directly into a signal handler, we don't want
      to go via the normal syscall exit path -- it'll corrupt r4 and r5 which
      are supposed to be giving information to the signal handler, and it'll
      give us one more single-step SIGTRAP than we need if single-stepping is
      in operation.
      
      However, we _should_ be calling audit_syscall_exit(), which would
      normally get invoked in that patch. It's not wonderfully pretty, but I
      suspect the best answer is just to call it directly...
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      17888225
  15. 22 6月, 2005 1 次提交
  16. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus 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!
      1da177e4