1. 26 6月, 2009 6 次提交
  2. 22 6月, 2009 1 次提交
  3. 20 6月, 2009 1 次提交
  4. 19 6月, 2009 2 次提交
    • S
      function-graph: add stack frame test · 71e308a2
      Steven Rostedt 提交于
      In case gcc does something funny with the stack frames, or the return
      from function code, we would like to detect that.
      
      An arch may implement passing of a variable that is unique to the
      function and can be saved on entering a function and can be tested
      when exiting the function. Usually the frame pointer can be used for
      this purpose.
      
      This patch also implements this for x86. Where it passes in the stack
      frame of the parent function, and will test that frame on exit.
      
      There was a case in x86_32 with optimize for size (-Os) where, for a
      few functions, gcc would align the stack frame and place a copy of the
      return address into it. The function graph tracer modified the copy and
      not the actual return address. On return from the funtion, it did not go
      to the tracer hook, but returned to the parent. This broke the function
      graph tracer, because the return of the parent (where gcc did not do
      this funky manipulation) returned to the location that the child function
      was suppose to. This caused strange kernel crashes.
      
      This test detected the problem and pointed out where the issue was.
      
      This modifies the parameters of one of the functions that the arch
      specific code calls, so it includes changes to arch code to accommodate
      the new prototype.
      
      Note, I notice that the parsic arch implements its own push_return_trace.
      This is now a generic function and the ftrace_push_return_trace should be
      used instead. This patch does not touch that code.
      
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      71e308a2
    • H
      edac: cpc925 MC platform device setup · 8f101a05
      Harry Ciao 提交于
      Fix up the number of cells for the values of CPC925 Memory Controller,
      and setup related platform device during system booting up, against
      which CPC925 Memory Controller EDAC driver would be matched.
      Signed-off-by: NHarry Ciao <qingtao.cao@windriver.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Kumar Gala <galak@gate.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8f101a05
  5. 18 6月, 2009 8 次提交
    • P
      perf_counter: powerpc: Add processor back-end for MPC7450 family · 7325927e
      Paul Mackerras 提交于
      This adds support for the performance monitor hardware on the
      MPC7450 family of processors (7450, 7451, 7455, 7447/7457, 7447A,
      7448), used in the later Apple G4 powermacs/powerbooks and other
      machines.  These machines have 6 hardware counters with a unique
      set of events which can be counted on each counter, with some
      events being available on multiple counters.
      
      Raw event codes for these processors are (PMC << 8) + PMCSEL.
      If PMC is non-zero then the event is that selected by the given
      PMCSEL value for that PMC (hardware counter).  If PMC is zero
      then the event selected is one of the low-numbered ones that are
      common to several PMCs.  In this case PMCSEL must be <= 22 and
      the event is what that PMCSEL value would select on PMC1 (but
      it may be placed any other PMC that has the same event for that
      PMCSEL value).
      
      For events that count cycles or occurrences that exceed a threshold,
      the threshold requested can be specified in the 0x3f000 bits of the
      raw event codes.  If the event uses the threshold multiplier bit
      and that bit should be set, that is indicated with the 0x40000 bit
      of the raw event code.
      
      This fills in some of the generic cache events.  Unfortunately there
      are quite a few blank spaces in the table, partly because these
      processors tend to count cache hits rather than cache accesses.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: linuxppc-dev@ozlabs.org
      Cc: benh@kernel.crashing.org
      LKML-Reference: <19000.55631.802122.696927@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7325927e
    • P
      perf_counter: powerpc: Make powerpc perf_counter code safe for 32-bit kernels · 98fb1807
      Paul Mackerras 提交于
      This abstracts a few things in arch/powerpc/kernel/perf_counter.c
      that are specific to 64-bit kernels, and provides definitions for
      32-bit kernels.  In particular,
      
      * Only 64-bit has MMCRA and the bits in it that give information
        about a PMU interrupt (sampled PR, HV, slot number etc.)
      * Only 64-bit has the lppaca and the lppaca->pmcregs_in_use field
      * Use of SDAR is confined to 64-bit for now
      * Only 64-bit has soft/lazy interrupt disable and therefore
        pseudo-NMIs (interrupts that occur while interrupts are soft-disabled)
      * Only 64-bit has PMC7 and PMC8
      * Only 64-bit has the MSR_HV bit.
      
      This also fixes the types used in a couple of places, where we were
      using long types for things that need to be 64-bit.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: linuxppc-dev@ozlabs.org
      Cc: benh@kernel.crashing.org
      LKML-Reference: <19000.55590.634126.876084@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      98fb1807
    • P
      perf_counter: powerpc: Change how processor-specific back-ends get selected · 079b3c56
      Paul Mackerras 提交于
      At present, the powerpc generic (processor-independent) perf_counter
      code has list of processor back-end modules, and at initialization,
      it looks at the PVR (processor version register) and has a switch
      statement to select a suitable processor-specific back-end.
      
      This is going to become inconvenient as we add more processor-specific
      back-ends, so this inverts the order: now each back-end checks whether
      it applies to the current processor, and registers itself if so.
      Furthermore, instead of looking at the PVR, back-ends now check the
      cur_cpu_spec->oprofile_cpu_type string and match on that.
      
      Lastly, each back-end now specifies a name for itself so the core can
      print a nice message when a back-end registers itself.
      
      This doesn't provide any support for unregistering back-ends, but that
      wouldn't be hard to do and would allow back-ends to be modules.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: linuxppc-dev@ozlabs.org
      Cc: benh@kernel.crashing.org
      LKML-Reference: <19000.55529.762227.518531@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      079b3c56
    • P
      perf_counter: powerpc: Use unsigned long for register and constraint values · 448d64f8
      Paul Mackerras 提交于
      This changes the powerpc perf_counter back-end to use unsigned long
      types for hardware register values and for the value/mask pairs used
      in checking whether a given set of events fit within the hardware
      constraints.  This is in preparation for adding support for the PMU
      on some 32-bit powerpc processors.  On 32-bit processors the hardware
      registers are only 32 bits wide, and the PMU structure is generally
      simpler, so 32 bits should be ample for expressing the hardware
      constraints.  On 64-bit processors, unsigned long is 64 bits wide,
      so using unsigned long vs. u64 (unsigned long long) makes no actual
      difference.
      
      This makes some other very minor changes: adjusting whitespace to line
      things up in initialized structures, and simplifying some code in
      hw_perf_disable().
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: linuxppc-dev@ozlabs.org
      Cc: benh@kernel.crashing.org
      LKML-Reference: <19000.55473.26174.331511@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      448d64f8
    • P
      perf_counter: powerpc: Enable use of software counters on 32-bit powerpc · 105988c0
      Paul Mackerras 提交于
      This enables the perf_counter subsystem on 32-bit powerpc.  Since we
      don't have any support for hardware counters on 32-bit powerpc yet,
      only software counters can be used.
      
      Besides selecting HAVE_PERF_COUNTERS for 32-bit powerpc as well as
      64-bit, the main thing this does is add an implementation of
      set_perf_counter_pending().  This needs to arrange for
      perf_counter_do_pending() to be called when interrupts are enabled.
      Rather than add code to local_irq_restore as 64-bit does, the 32-bit
      set_perf_counter_pending() generates an interrupt by setting the
      decrementer to 1 so that a decrementer interrupt will become pending
      in 1 or 2 timebase ticks (if a decrementer interrupt isn't already
      pending).  When interrupts are enabled, timer_interrupt() will be
      called, and some new code in there calls perf_counter_do_pending().
      We use a per-cpu array of flags to indicate whether we need to call
      perf_counter_do_pending() or not.
      
      This introduces a couple of new Kconfig symbols: PPC_HAVE_PMU_SUPPORT,
      which is selected by processor families for which we have hardware PMU
      support (currently only PPC64), and PPC_PERF_CTRS, which enables the
      powerpc-specific perf_counter back-end.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: linuxppc-dev@ozlabs.org
      Cc: benh@kernel.crashing.org
      LKML-Reference: <19000.55404.103840.393470@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      105988c0
    • H
      net/ucc_geth: Add SGMII support for UCC GETH driver · fb1001f3
      Haiying Wang 提交于
      -- derived from reverted commit 047584ce
      -- reworked by Grant Likely to play nice with commit:
         "net: Rework ucc_geth driver to use of_mdio infrastructure"
         (0b9da337)
      Signed-off-by: NHaiying Wang <Haiying.Wang@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb1001f3
    • G
      Revert "net/ucc_geth: Add SGMII support for UEC GETH driver" · f3a32500
      Grant Likely 提交于
      This reverts commit 047584ce.
      
      This patch meshes badly with "net: Rework ucc_geth driver to use
      of_mdio infrastructure" (0b9da337).
      Since most of the patch needs to be reworked, it is clearer to revert
      the patch and then apply the corrected version
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3a32500
    • M
      Delete pcibios_select_root · a6c14096
      Matthew Wilcox 提交于
      This function was only used by pci_claim_resource(), and the last commit
      deleted that use.
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a6c14096
  6. 17 6月, 2009 8 次提交
  7. 16 6月, 2009 14 次提交