1. 16 10月, 2007 2 次提交
    • S
      kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP · 06c5040c
      Sam Ravnborg 提交于
      The variable CPPFLAGS is a wellknown variable and the usage by
      kbuild may result in unexpected behaviour.
      
      This patch replace use of CPPFLAGS with KBUILD_CPPFLAGS all over the
      tree and enabling one to use:
      make CPPFLAGS=...
      to specify additional CPP commandline options.
      
      Patch was tested on following architectures:
      alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      06c5040c
    • S
      kbuild: enable 'make AFLAGS=...' to add additional options to AS · 222d394d
      Sam Ravnborg 提交于
      The variable AFLAGS is a wellknown variable and the usage by
      kbuild may result in unexpected behaviour.
      On top of that several people over time has asked for a way to
      pass in additional flags to gcc.
      
      This patch replace use of AFLAGS with KBUILD_AFLAGS all over
      the tree.
      
      Patch was tested on following architectures:
      alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      222d394d
  2. 15 10月, 2007 1 次提交
    • S
      kbuild: enable 'make CFLAGS=...' to add additional options to CC · a0f97e06
      Sam Ravnborg 提交于
      The variable CFLAGS is a wellknown variable and the usage by
      kbuild may result in unexpected behaviour.
      On top of that several people over time has asked for a way to
      pass in additional flags to gcc.
      
      This patch replace use of CFLAGS with KBUILD_CFLAGS all over the
      tree and enabling one to use:
      make CFLAGS=...
      to specify additional gcc commandline options.
      
      One usecase is when trying to find gcc bugs but other
      use cases has been requested too.
      
      Patch was tested on following architectures:
      alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k
      
      Test was simple to do a defconfig build, apply the patch and check
      that nothing got rebuild.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      a0f97e06
  3. 17 9月, 2007 1 次提交
  4. 28 3月, 2006 2 次提交
    • K
      powerpc: move math-emu over to arch/powerpc · 5cd27208
      Kumar Gala 提交于
      Towards the goal of having arch/powerpc not build anything over in arch/ppc
      move math-emu over.  Also, killed some references to arch/ppc/ in the
      arch/powerpc Makefile which should belong in drivers/ when the particular
      sub-arch's move over to arch/powerpc.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      5cd27208
    • P
      ppc: Remove CHRP, POWER3 and POWER4 support from arch/ppc · 0a26b136
      Paul Mackerras 提交于
      32-bit CHRP machines are now supported only in arch/powerpc, as are
      all 64-bit PowerPC processors.  This means that we don't use
      Open Firmware on any platform in arch/ppc any more.
      
      This makes PReP support a single-platform option like every other
      platform support option in arch/ppc now, thus CONFIG_PPC_MULTIPLATFORM
      is gone from arch/ppc.  CONFIG_PPC_PREP is the option that selects
      PReP support and is generally what has replaced
      CONFIG_PPC_MULTIPLATFORM within arch/ppc.
      
      _machine is all but dead now, being #defined to 0.
      
      Updated Makefiles, comments and Kconfig options generally to reflect
      these changes.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0a26b136
  5. 27 3月, 2006 1 次提交
    • P
      powerpc: Unify the 32 and 64 bit idle loops · a0652fc9
      Paul Mackerras 提交于
      This unifies the 32-bit (ARCH=ppc and ARCH=powerpc) and 64-bit idle
      loops.  It brings over the concept of having a ppc_md.power_save
      function from 32-bit to ARCH=powerpc, which lets us get rid of
      native_idle().  With this we will also be able to simplify the idle
      handling for pSeries and cell.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a0652fc9
  6. 06 3月, 2006 1 次提交
  7. 09 1月, 2006 1 次提交
  8. 01 11月, 2005 1 次提交
    • D
      [PATCH] powerpc: Merge bitops.h · a0e60b20
      David Gibson 提交于
      Here's a revised version.  This re-introduces the set_bits() function
      from ppc64, which I removed because I thought it was unused (it exists
      on no other arch).  In fact it is used in the powermac interrupt code
      (but not on pSeries).
      
      - We use LARXL/STCXL macros to generate the right (32 or 64 bit)
        instructions, similar to LDL/STL from ppc_asm.h, used in fpu.S
      
      - ppc32 previously used a full "sync" barrier at the end of
        test_and_*_bit(), whereas ppc64 used an "isync".  The merged version
        uses "isync", since I believe that's sufficient.
      
      - The ppc64 versions of then minix_*() bitmap functions have changed
        semantics.  Previously on ppc64, these functions were big-endian
        (that is bit 0 was the LSB in the first 64-bit, big-endian word).
        On ppc32 (and x86, for that matter, they were little-endian.  As far
        as I can tell, the big-endian usage was simply wrong - I guess
        no-one ever tried to use minixfs on ppc64.
      
      - On ppc32 find_next_bit() and find_next_zero_bit() are no longer
        inline (they were already out-of-line on ppc64).
      
      - For ppc64, sched_find_first_bit() has moved from mmu_context.h to
        the merged bitops.  What it was doing in mmu_context.h in the first
        place, I have no idea.
      
      - The fls() function is now implemented using the cntlzw instruction
        on ppc64, instead of generic_fls(), as it already was on ppc32.
      
      - For ARCH=ppc, this patch requires adding arch/powerpc/lib to the
        arch/ppc/Makefile.  This in turn requires some changes to
        arch/powerpc/lib/Makefile which didn't correctly handle ARCH=ppc.
      
      Built and running on G5.
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a0e60b20
  9. 29 10月, 2005 1 次提交
    • L
      [PATCH] ppc: prevent GCC 4 from generating AltiVec instructions in kernel · 9e3699ea
      Lee Nicks 提交于
      Depending on how GCC is built, GCC 4 may generate altivec instructions without
      user explicitly requesting vector operations in the code.  Although this is a
      performance booster for user applications, it is a problem for kernel.
      
      This patch explicitly instruct GCC to NOT generate altivec instructions while
      building the kernel.
      
      Here are some test cases I ran.
      
      (1) build gcc 4.0.1 with '--with-cpu=7450 --enable-altivec
          --enable-cxx-flags=-mcpu=7450', and use this gcc to build kernel WITHOUT
          this kernel patch.  Kernel fail to boot up on a 7450 board because of
          altivec instructions in kernel.
      
      (2) build gcc 4.0.1 with "--with-cpu=7450 --enable-altivec
          --enable-cxx-flags=-mcpu=7450", and use this gcc to build kernel WITH this
          kernel patch.  Kernel boot up on a 7450 board without any problem.
      
      (3) build gcc 4.0.1 with "--with-cpu=750 --enable-cxx-flags=-mcpu=750",
          and use this gcc to build kernel with or without this kernel patch.
          Kernel boot up on a 7450 board without any problem.
      
      This patch should also work with GCC 3 or even earlier GCC 2.95.3.
      Signed-off-by: NLee Nicks <allinux@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      9e3699ea
  10. 26 10月, 2005 1 次提交
  11. 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
  12. 21 9月, 2005 1 次提交
  13. 12 9月, 2005 1 次提交
    • S
      kbuild: rename prepare to archprepare to fix dependency chain · 5bb78269
      Sam Ravnborg 提交于
      When introducing the generic asm-offsets.h support the dependency
      chain for the prepare targets was changed. All build scripts expecting
      include/asm/asm-offsets.h to be made when using the prepare target would broke.
      With the limited number of prepare targets left in arch Makefiles
      the trivial solution was to introduce a new arch specific target: archprepare
      
      The dependency chain looks like this now:
      
      prepare
        |
        +--> prepare0
               |
               +--> archprepare
                      |
      		+--> scripts_basic
                      +--> prepare1
                             |
                             +---> prepare2
                                     |
                                     +--> prepare3
      
      So prepare 3 is processed before prepare2 etc.
      This guaantees that the asm symlink, version.h, scripts_basic
      are all updated before archprepare is processed.
      
      prepare0 which build the asm-offsets.h file will need the
      actions performed by archprepare.
      
      The head target is now named prepare, because users scripts will most
      likely use that target, but prepare-all has been kept for compatibility.
      Updated Documentation/kbuild/makefiles.txt.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      5bb78269
  14. 11 9月, 2005 1 次提交
  15. 10 9月, 2005 1 次提交
  16. 30 8月, 2005 1 次提交
  17. 26 6月, 2005 1 次提交
  18. 01 5月, 2005 1 次提交
  19. 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