1. 15 1月, 2014 1 次提交
  2. 29 1月, 2013 1 次提交
  3. 07 9月, 2012 1 次提交
    • C
      powerpc/oprofile: Fix marked events support on Power7+ not set. · adbf115d
      Carl E. Love 提交于
      Starting with Power 7+ we need to check for marked events if the SIAR
      register is valid, i.e. it contains the correct address of the instruction
      at the time the performance counter overflowed.  The mmcra register on
      Power 7+, contains a new bit to indicate that the contents of the SIAR
      is valid. If the event is not marked, then the sample is recorded
      independently of the SIAR valid bit setting.  For older processors, there
      is no SIAR valid bit to check so the samples are always recorded.  This is
      done by forcing the cntr_marked_events bit mask to zero.  The code will
      always record the sample in this case since the bit mask says the event is
      not a marked event even if it really is a marked event.
      Signed-off-by: NCarl Love <cel@us.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      adbf115d
  4. 05 9月, 2012 1 次提交
  5. 29 3月, 2012 1 次提交
  6. 26 5月, 2011 1 次提交
  7. 24 5月, 2011 1 次提交
  8. 31 3月, 2011 1 次提交
  9. 15 5月, 2009 1 次提交
    • M
      powerpc: Fix oprofile sampling of marked events on POWER7 · e5fc948b
      Maynard Johnson 提交于
      Description
      -----------
      Change ppc64 oprofile kernel driver to use the SLOT bits (MMCRA[37:39]only on
      older processors where those bits are defined.
      
      Background
      ----------
      The performance monitor unit of the 64-bit POWER processor family has the
      ability to collect accurate instruction-level samples when profiling on marked
      events (i.e., "PM_MRK_<event-name>").  In processors prior to POWER6, the MMCRA
      register contained "slot information" that the oprofile kernel driver used to
      adjust the value latched in the SIAR at the time of a PMU interrupt.  But as of
      POWER6, these slot bits in MMCRA are no longer necessary for oprofile to use,
      since the SIAR itself holds the accurate sampled instruction address.  With
      POWER6, these MMCRA slot bits were zero'ed out by hardware so oprofile's use of
      these slot bits was, in effect, a NOP.  But with POWER7, these bits are no
      longer zero'ed out; however, they serve some other purpose rather than slot
      information.  Thus, using these bits on POWER7 to adjust the SIAR value results
      in samples being attributed to the wrong instructions.  The attached patch
      changes the oprofile kernel driver to ignore these slot bits on all newer
      processors starting with POWER6.
      Signed-off-by: NMaynard Johnson <maynardj@us.ibm.com>
      Signed-off-by: NMichael Wolf <mjw@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e5fc948b
  10. 20 8月, 2008 1 次提交
  11. 29 1月, 2008 1 次提交
  12. 21 7月, 2007 1 次提交
  13. 10 7月, 2007 1 次提交
  14. 07 2月, 2007 1 次提交
  15. 01 11月, 2006 1 次提交
    • A
      [POWERPC] Fix oprofile support for e500 in arch/powerpc · dd6c89f6
      Andy Fleming 提交于
      Fixed a compile error in building the 85xx support with oprofile, and in
      the process cleaned up some issues with the fsl_booke performance monitor
      code.
      
      * Reorganized FSL Book-E performance monitoring code so that the 7450
        wouldn't be built if the e500 was, and cleaned it up so it was more
        self-contained.
      
      * Added a cpu_setup function for FSL Book-E.  The original
        cpu_setup function prototype had no arguments, assuming that
        the reg_setup function would copy the required information into
        variables which represented the registers.  This was silly for
        e500, since it has 1 register per counter (rather than 3 for
        all counters), so the code has been restructured to have
        cpu_setup take the current counter config array as an argument,
        with op_powerpc_setup() invoking op_powerpc_cpu_setup() through
        on_each_cpu(), and op_powerpc_cpu_setup() invoking the
        model-specific cpu_setup function with an argument.  The
        argument is ignored on all other platforms at present.
      
      * Fixed a confusing line where a trinary operator only had two
        arguments
      Signed-off-by: NAndrew Fleming <afleming@freescale.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      dd6c89f6
  16. 23 10月, 2006 1 次提交
  17. 09 6月, 2006 1 次提交
  18. 29 3月, 2006 2 次提交
  19. 22 3月, 2006 1 次提交
  20. 09 1月, 2006 1 次提交
  21. 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
  22. 10 11月, 2005 1 次提交
  23. 08 11月, 2005 1 次提交
  24. 21 9月, 2005 2 次提交
  25. 06 9月, 2005 2 次提交
  26. 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