1. 23 12月, 2008 1 次提交
  2. 31 10月, 2008 1 次提交
    • P
      powerpc: Fix compile errors with CONFIG_BUG=n · ebdba9af
      Paul Mackerras 提交于
      This makes sure we don't try to call find_bug or is_warning_bug when
      CONFIG_BUG=n and CONFIG_XMON=y.  Otherwise we get these errors:
      
      arch/powerpc/xmon/xmon.c: In function ‘print_bug_trap’:
      arch/powerpc/xmon/xmon.c:1364: error: implicit declaration of function ‘find_bug’
      arch/powerpc/xmon/xmon.c:1364: warning: assignment makes pointer from integer without a cast
      arch/powerpc/xmon/xmon.c:1367: error: implicit declaration of function ‘is_warning_bug’
      arch/powerpc/xmon/xmon.c:1374: error: dereferencing pointer to incomplete type
      make[2]: *** [arch/powerpc/xmon/xmon.o] Error 1
      make[1]: *** [arch/powerpc/xmon] Error 2
      make: *** [sub-make] Error 2
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      ebdba9af
  3. 16 6月, 2008 1 次提交
  4. 14 5月, 2008 2 次提交
    • M
      [POWERPC] Make cpus_in_xmon static and remove extern mess from hvc_console.c · 1c8950ff
      Michael Ellerman 提交于
      This is a little messier than I'd like because xmon.h only exists
      on powerpc and we can't have a static inline and an extern declaration
      visible at the same time.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      1c8950ff
    • M
      [POWERPC] Fix sparse warnings in xmon.c · 9f1067c2
      Michael Ellerman 提交于
      warning: Using plain integer as NULL pointer
      warning: Using plain integer as NULL pointer
      warning: symbol 'excprint' was not declared. Should it be static?
      warning: symbol 'prregs' was not declared. Should it be static?
      warning: symbol 'cacheflush' was not declared. Should it be static?
      warning: symbol 'read_spr' was not declared. Should it be static?
      warning: symbol 'write_spr' was not declared. Should it be static?
      warning: symbol 'super_regs' was not declared. Should it be static?
      warning: symbol 'mread' was not declared. Should it be static?
      warning: symbol 'mwrite' was not declared. Should it be static?
      warning: symbol 'byterev' was not declared. Should it be static?
      warning: symbol 'memex' was not declared. Should it be static?
      warning: symbol 'bsesc' was not declared. Should it be static?
      warning: symbol 'dump' was not declared. Should it be static?
      warning: symbol 'prdump' was not declared. Should it be static?
      warning: symbol 'generic_inst_dump' was not declared. Should it be static?
      warning: symbol 'ppc_inst_dump' was not declared. Should it be static?
      warning: symbol 'memops' was not declared. Should it be static?
      warning: symbol 'memdiffs' was not declared. Should it be static?
      warning: symbol 'memlocate' was not declared. Should it be static?
      warning: symbol 'memzcan' was not declared. Should it be static?
      warning: symbol 'proccall' was not declared. Should it be static?
      warning: symbol 'scannl' was not declared. Should it be static?
      warning: symbol 'hexdigit' was not declared. Should it be static?
      warning: symbol 'flush_input' was not declared. Should it be static?
      warning: symbol 'inchar' was not declared. Should it be static?
      warning: symbol 'take_input' was not declared. Should it be static?
      warning: symbol 'xmon_init' was not declared. Should it be static?
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      9f1067c2
  5. 05 5月, 2008 1 次提交
  6. 18 4月, 2008 1 次提交
  7. 15 4月, 2008 1 次提交
  8. 25 1月, 2008 1 次提交
  9. 11 12月, 2007 2 次提交
    • W
      [POWERPC] Update xmon slb code · b3b9595f
      will schmidt 提交于
      This adds a bit more detail to the xmon SLB output.  When the valid
      bit is set, this displays the ESID and VSID values, as well as
      decoding the segment size -- 1T or 256M -- and displaying the LLP
      bits.  This supresses the output for any slb entries that contain only
      zeros.
      
      sample output from power6 (1T segment support):
      00 c000000008000000 40004f7ca3000500  1T  ESID=   c00000  VSID=       4f7ca3 LLP:100
      01 d000000008000000 4000eb71b0000400  1T  ESID=   d00000  VSID=       eb71b0 LLP:  0
      08 0000000018000000 0000c8499f8ccc80 256M ESID=        1  VSID=    c8499f8cc LLP:  0
      09 00000000f8000000 0000d2c1a8e46c80 256M ESID=        f  VSID=    d2c1a8e46 LLP:  0
      10 0000000048000000 0000ca87eab1dc80 256M ESID=        4  VSID=    ca87eab1d LLP:  0
      43 cf00000008000000 400011b260000500  1T  ESID=   cf0000  VSID=       11b260 LLP:100
      
      sample output from power5 (notice the non-valid but non-zero entries)
      10 0000000008000000 00004fd0e077ac80 256M ESID=        0  VSID=    4fd0e077a LLP:  0
      11 00000000f8000000 00005b085830fc80 256M ESID=        f  VSID=    5b085830f LLP:  0
      12 0000000048000000 000052ce99fe6c80 256M ESID=        4  VSID=    52ce99fe6 LLP:  0
      13 0000000018000000 000050904ed95c80 256M ESID=        1  VSID=    50904ed95 LLP:  0
      14 cf00000008000000 0000d59aca40f500 256M ESID=cf0000000  VSID=    d59aca40f LLP:100
      15 c000000078000000 000045cb97751500 256M ESID=c00000007  VSID=    45cb97751 LLP:100
      
      Tested on power5 and power6.
      Signed-Off-By: NWill Schmidt <will_schmidt@vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      b3b9595f
    • M
      [POWERPC] Use SLB size from the device tree · 584f8b71
      Michael Neuling 提交于
      Currently we hardwire the number of SLBs to 64, but PAPR says we
      should use the ibm,slb-size property to obtain the number of SLB
      entries.  This uses this property instead of assuming 64.  If no
      property is found, we assume 64 entries as before.
      
      This soft patches the SLB handler, so it shouldn't change performance
      at all.
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      584f8b71
  10. 03 12月, 2007 1 次提交
  11. 22 7月, 2007 1 次提交
  12. 10 7月, 2007 1 次提交
  13. 09 5月, 2007 1 次提交
  14. 27 4月, 2007 1 次提交
    • A
      [POWERPC] Fix WARN_ON when entering xmon · f13659e0
      Anton Blanchard 提交于
      Whenever we enter xmon we get a WARN_ON out of the rtas code since it
      thinks interrupts are still on:
      
      Unable to handle kernel paging request for data at address 0x00000000
      Faulting instruction address: 0xd000000000080008
      cpu 0x3: Vector: 300 (Data Access) at [c0000000075dba00]
          pc: d000000000080008: .doit+0x8/0x40 [oopser]
          lr: c000000000077704: .sys_init_module+0x1664/0x1824
          sp: c0000000075dbc80
         msr: 9000000000009032
         dar: 0
       dsisr: 42000000
        current = 0xc000000003fa64b0
        paca    = 0xc000000000694280
          pid   = 2260, comm = insmod
      
      ------------[ cut here ]------------
      Badness at arch/powerpc/kernel/entry_64.S:651
      Call Trace:
      [C0000000075DAE70] [C00000000000EB64] .show_stack+0x68/0x1b0 (unreliable)
      [C0000000075DAF10] [C000000000216254] .report_bug+0x94/0xe8
      [C0000000075DAFA0] [C00000000047B140] __kprobes_text_start+0x178/0x584
      [C0000000075DB040] [C0000000000044F4] program_check_common+0xf4/0x100
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f13659e0
  15. 09 3月, 2007 1 次提交
  16. 08 3月, 2007 1 次提交
  17. 14 2月, 2007 1 次提交
  18. 11 12月, 2006 1 次提交
    • J
      [POWERPC] Generic BUG for powerpc · 73c9ceab
      Jeremy Fitzhardinge 提交于
      This makes powerpc use the generic BUG machinery.  The biggest reports the
      function name, since it is redundant with kallsyms, and not needed in general.
      
      There is an overall reduction of code, since module_32/64 duplicated several
      functions.
      
      Unfortunately there's no way to tell gcc that BUG won't return, so the BUG
      macro includes a goto loop.  This will generate a real jmp instruction, which
      is never used.
      
      [akpm@osdl.org: build fix]
      [paulus@samba.org: remove infinite loop in BUG_ON]
      Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Hugh Dickens <hugh@veritas.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      73c9ceab
  19. 04 12月, 2006 10 次提交
  20. 25 10月, 2006 2 次提交
    • M
      [POWERPC] add support for dumping spu info from xmon · a8984970
      Michael Ellerman 提交于
      This patch adds a command to xmon for dumping information about
      spu structs. The command is 'sf' for "spu fields" perhaps, and
      takes the spu number as an argument. This is the same value as the
      spu->number field, or the "phys-id" value of a context when it is
      bound to a physical spu.
      
      We try to catch memory errors as we dump each field, hopefully this
      will make the command reasonably robust, but YMMV. If people see a
      need we can easily add more fields to the dump in future.
      
      Output looks something like this:
      
      0:mon> sf 0
      Dumping spu fields at address c00000001ffd9e80:
        number                  = 0x0
        name                    = spe
        devnode->full_name      = /cpus/PowerPC,BE@0/spes/spe@0
        nid                     = 0x0
        local_store_phys        = 0x20000000000
        local_store             = 0xd0000800801e0000
        ls_size                 = 0x0
        isrc                    = 0x4
        node                    = 0x0
        flags                   = 0x0
        dar                     = 0x0
        dsisr                   = 0x0
        class_0_pending         = 0
        irqs[0]                 = 0x16
        irqs[1]                 = 0x17
        irqs[2]                 = 0x24
        slb_replace             = 0x0
        pid                     = 0
        prio                    = 0
        mm                      = 0x0000000000000000
        ctx                     = 0x0000000000000000
        rq                      = 0x0000000000000000
        timestamp               = 0x0000000000000000
        problem_phys            = 0x20000040000
        problem                 = 0xd000080080220000
        problem->spu_runcntl_RW = 0x0
        problem->spu_status_R   = 0x0
        problem->spu_npc_RW     = 0x0
        priv1                   = 0xd000080080240000
        priv1->mfc_sr1_RW       = 0x33
        priv2                   = 0xd000080080250000
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NArnd Bergmann <arnd.bergmann@de.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a8984970
    • M
      [POWERPC] add support for stopping spus from xmon · ff8a8f25
      Michael Ellerman 提交于
      This patch adds support for stopping, and restarting, spus
      from xmon. We use the spu master runcntl bit to stop execution,
      this is apparently the "right" way to control spu execution and
      spufs will be changed in the future to use this bit.
      
      Testing has shown that to restart execution we have to turn the
      master runcntl bit on and also rewrite the spu runcntl bit, even
      if it is already set to 1 (running).
      
      Stopping spus is triggered by the xmon command 'ss' - "spus stop"
      perhaps. Restarting them is triggered via 'sr'. Restart doesn't
      start execution on spus unless they were running prior to being
      stopped by xmon.
      
      Walking the spu->full_list in xmon after a panic, would mean
      corruption of any spu struct would make all the others
      inaccessible. To avoid this, and also to make the next patch
      easier, we cache pointers to all spus during boot.
      
      We attempt to catch and recover from errors while stopping and
      restarting the spus, but as with most xmon functionality there are
      no guarantees that performing these operations won't crash xmon
      itself.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NArnd Bergmann <arnd.bergmann@de.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      ff8a8f25
  21. 10 10月, 2006 1 次提交
  22. 05 10月, 2006 1 次提交
    • D
      IRQ: Maintain regs pointer globally rather than passing to IRQ handlers · 7d12e780
      David Howells 提交于
      Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
      of passing regs around manually through all ~1800 interrupt handlers in the
      Linux kernel.
      
      The regs pointer is used in few places, but it potentially costs both stack
      space and code to pass it around.  On the FRV arch, removing the regs parameter
      from all the genirq function results in a 20% speed up of the IRQ exit path
      (ie: from leaving timer_interrupt() to leaving do_IRQ()).
      
      Where appropriate, an arch may override the generic storage facility and do
      something different with the variable.  On FRV, for instance, the address is
      maintained in GR28 at all times inside the kernel as part of general exception
      handling.
      
      Having looked over the code, it appears that the parameter may be handed down
      through up to twenty or so layers of functions.  Consider a USB character
      device attached to a USB hub, attached to a USB controller that posts its
      interrupts through a cascaded auxiliary interrupt controller.  A character
      device driver may want to pass regs to the sysrq handler through the input
      layer which adds another few layers of parameter passing.
      
      I've build this code with allyesconfig for x86_64 and i386.  I've runtested the
      main part of the code on FRV and i386, though I can't test most of the drivers.
      I've also done partial conversion for powerpc and MIPS - these at least compile
      with minimal configurations.
      
      This will affect all archs.  Mostly the changes should be relatively easy.
      Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
      
      	struct pt_regs *old_regs = set_irq_regs(regs);
      
      And put the old one back at the end:
      
      	set_irq_regs(old_regs);
      
      Don't pass regs through to generic_handle_irq() or __do_IRQ().
      
      In timer_interrupt(), this sort of change will be necessary:
      
      	-	update_process_times(user_mode(regs));
      	-	profile_tick(CPU_PROFILING, regs);
      	+	update_process_times(user_mode(get_irq_regs()));
      	+	profile_tick(CPU_PROFILING);
      
      I'd like to move update_process_times()'s use of get_irq_regs() into itself,
      except that i386, alone of the archs, uses something other than user_mode().
      
      Some notes on the interrupt handling in the drivers:
      
       (*) input_dev() is now gone entirely.  The regs pointer is no longer stored in
           the input_dev struct.
      
       (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking.  It does
           something different depending on whether it's been supplied with a regs
           pointer or not.
      
       (*) Various IRQ handler function pointers have been moved to type
           irq_handler_t.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
      7d12e780
  23. 04 10月, 2006 2 次提交
  24. 13 9月, 2006 1 次提交
  25. 01 7月, 2006 1 次提交
  26. 26 6月, 2006 1 次提交
  27. 17 3月, 2006 1 次提交