1. 31 12月, 2008 9 次提交
  2. 29 12月, 2008 1 次提交
  3. 25 12月, 2008 1 次提交
    • M
      [S390] arch_setup_additional_pages arguments · fc5243d9
      Martin Schwidefsky 提交于
      arch_setup_additional_pages currently gets two arguments, the binary
      format descripton and an indication if the process uses an executable
      stack or not. The second argument is not used by anybody, it could
      be removed without replacement.
      
      What actually does make sense is to pass an indication if the process
      uses the elf interpreter or not. The glibc code will not use anything
      from the vdso if the process does not use the dynamic linker, so for
      statically linked binaries the architecture backend can choose not
      to map the vdso.
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      fc5243d9
  4. 23 12月, 2008 4 次提交
  5. 21 12月, 2008 11 次提交
  6. 16 12月, 2008 10 次提交
  7. 03 12月, 2008 4 次提交
    • T
      powerpc: Better setup of boot page TLB entry · b3898895
      Trent Piepho 提交于
      The initial TLB mapping for the kernel boot didn't set the memory coherent
      attribute, MAS2[M], in SMP mode.
      
      If this code supported booting a secondary processor, which it doesn't yet,
      but if it did, then when a secondary processor boots, it would probably signal
      the primary processor by setting a variable called something like
      __secondary_hold_acknowledge.  However, due to the lack of the M bit, the
      primary processor would not snoop the transaction (even if a transaction were
      broadcast).  If primary CPU's L1 D-cache had a copy, it would not be flushed
      and the CPU would never see the ack.  Which would have resulted in the primary
      CPU spinning for a long time, perhaps a full second before it gives up, while
      it would have waited for the ack from the secondary CPU that it wouldn't have
      been able to see because of the stale cache.
      
      The value of MAS2 for the boot page TLB1 entry is a compile time constant,
      so there is no need to calculate it in powerpc assembly language.
      
      Also, from the MPC8572 manual section 6.12.5.3, "Bits that represent
      offsets within a page are ignored and should be cleared." Existing code
      didn't clear them, this code does.
      
      The same when the page of KERNELBASE is found; we don't need to use asm to
      mask the lower 12 bits off.
      
      In the code that computes the address to rfi from, don't hard code the
      offset to 24 bytes, but have the assembler figure that out for us.
      Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      b3898895
    • L
      powerpc: Add SPE/EFP math emulation for E500v1/v2 processors. · 6a800f36
      Liu Yu 提交于
      This patch add the handlers of SPE/EFP exceptions.
      The code is used to emulate float point arithmetic,
      when MSR(SPE) is enabled and receive EFP data interrupt or EFP round interrupt.
      
      This patch has no conflict with or dependence on FP math-emu.
      
      The code has been tested by TestFloat.
      
      Now the code doesn't support SPE/EFP instructions emulation
      (it won't be called when receive program interrupt),
      but it could be easily added.
      Signed-off-by: NLiu Yu <yu.liu@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      6a800f36
    • L
      powerpc/math-emu: Adopt new version of _FP_CHOOSENAN · 463a8c01
      Liu Yu 提交于
      Move to using the same macro definition for _FP_CHOOSENAN as s390,
      sh, sparc32/64.  The original author didn't understand this and
      matched what sparc64 was doing and they have updated to this definition.
      Signed-off-by: NLiu Yu <yu.liu@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      463a8c01
    • L
      powerpc/math-emu: Fix single float point division bug · cf030336
      Liu Yu 提交于
      PowerPC float point division emulation is derived from gcc.
      I reported this problem on gcc maillist and got this reply:
      http://gcc.gnu.org/ml/gcc/2008-03/msg00543.html
      
      Since UDIV_NEEDS_NORMALIZATION is not used by kernel, we should use
      _FP_DIV_MEAT_1_udiv_norm to make sure the single float point
      is normalized before udiv_qrnnd.
      Signed-off-by: NLiu Yu <yu.liu@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      cf030336