1. 06 11月, 2008 1 次提交
    • B
      powerpc/pci: Split pcibios_fixup_bus() into bus setup and device setup · 8b8da358
      Benjamin Herrenschmidt 提交于
      Currently, our PCI code uses the pcibios_fixup_bus() callback, which
      is called by the generic code when probing PCI buses, for two
      different things.
      
      One is to set up things related to the bus itself, such as reading
      bridge resources for P2P bridges, fixing them up, or setting up the
      iommu's associated with bridges on some platforms.
      
      The other is some setup for each individual device under that bridge,
      mostly setting up DMA mappings and interrupts.
      
      The problem is that this approach doesn't work well with PCI hotplug
      when an existing bus is re-probed for new children.  We fix this
      problem by splitting pcibios_fixup_bus into two routines:
      
      	pcibios_setup_bus_self() is now called to setup the bus itself
      
      	pcibios_setup_bus_devices() is now called to setup devices
      
      pcibios_fixup_bus() is then modified to call these two after reading the
      bridge bases, and the OF based PCI probe is modified to avoid calling
      into the first one when rescanning an existing bridge.
      
      [paulus@samba.org - fixed eeh.h for 32-bit compile now that pci-common.c
      is including it unconditionally.]
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      8b8da358
  2. 04 8月, 2008 1 次提交
  3. 04 12月, 2006 2 次提交
    • B
      [POWERPC] Merge 32 and 64 bits asm-powerpc/io.h · 68a64357
      Benjamin Herrenschmidt 提交于
      powerpc: Merge 32 and 64 bits asm-powerpc/io.h
      
      The rework on io.h done for the new hookable accessors made it easier,
      so I just finished the work and merged 32 and 64 bits io.h for arch/powerpc.
      
      arch/ppc still uses the old version in asm-ppc, there is just too much gunk
      in there that I really can't be bothered trying to cleanup.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      68a64357
    • B
      [POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits · 4cb3cee0
      Benjamin Herrenschmidt 提交于
      This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
      and PIO) and provides a generic way for other platforms to do so (we
      have need to do that for various other platforms).
      
      While reworking the IO ops, I ended up doing some spring cleaning in
      io.h and eeh.h which I might want to split into 2 or 3 patches (among
      others, eeh.h had a lot of useless stuff in it).
      
      A side effect is that EEH for PIO should work now (it used to pass IO
      ports down to the eeh address check functions which is bogus).
      
      Also, new are MMIO "repeat" ops, which other archs like ARM already had,
      and that we have too now: readsb, readsw, readsl, writesb, writesw,
      writesl.
      
      In the long run, I might also make EEH use the hooks instead
      of wrapping at the toplevel, which would make things even cleaner and
      relegate EEH completely in platforms/iseries, but we have to measure the
      performance impact there (though it's really only on MMIO reads)
      
      Since I also need to hook on ioremap, I shuffled the functions a bit
      there. I introduced ioremap_flags() to use by drivers who want to pass
      explicit flags to ioremap (and it can be hooked). The old __ioremap() is
      still there as a low level and cannot be hooked, thus drivers who use it
      should migrate unless they know they want the low level version.
      
      The patch "arch provides generic iomap missing accessors" (should be
      number 4 in this series) is a pre-requisite to provide full iomap
      API support with this patch.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4cb3cee0
  4. 13 9月, 2006 1 次提交
    • P
      [POWERPC] Fix MMIO ops to provide expected barrier behaviour · f007cacf
      Paul Mackerras 提交于
      This changes the writeX family of functions to have a sync instruction
      before the MMIO store rather than after, because the generally expected
      behaviour is that the device receiving the MMIO store can be guaranteed
      to see the effects of any preceding writes to normal memory.
      
      To preserve ordering between writeX and readX, and to preserve ordering
      between preceding stores and the readX, the readX family of functions
      have had an sync added before the load.
      
      Although writeX followed by spin_unlock is not officially guaranteed
      to keep the writeX inside the spin-locked region unless an mmiowb()
      is used, there are currently drivers that depend on the previous
      behaviour on powerpc, which was that the mmiowb wasn't actually required.
      Therefore we have a per-cpu flag that is set by writeX, cleared by
      __raw_spin_lock and mmiowb, and tested by __raw_spin_unlock.  If it is
      set, __raw_spin_unlock does a sync and clears it.
      
      This changes both 32-bit and 64-bit readX/writeX.  32-bit already has a
      sync in __raw_spin_unlock (since lwsync doesn't exist on 32-bit), and thus
      doesn't need the per-cpu flag.
      
      Tested on G5 (PPC970) and POWER5.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f007cacf
  5. 26 4月, 2006 1 次提交
  6. 22 4月, 2006 1 次提交
  7. 01 4月, 2006 1 次提交
  8. 09 3月, 2006 1 次提交
    • M
      [PATCH] powerpc: restore eeh_add_device_late() prototype stub · 1c6cc5fd
      Mark Fasheh 提交于
      We fixed this:
      
      arch/powerpc/platforms/pseries/eeh.c: In function `eeh_add_device_tree_late':
      arch/powerpc/platforms/pseries/eeh.c:901: warning: implicit declaration of function `eeh_add_device_late'
      arch/powerpc/platforms/pseries/eeh.c: At top level:
      arch/powerpc/platforms/pseries/eeh.c:918: error: conflicting types for 'eeh_add_device_late'
      arch/powerpc/platforms/pseries/eeh.c:901: error: previous implicit declaration of 'eeh_add_device_late' was here
      make[2]: *** [arch/powerpc/platforms/pseries/eeh.o] Error 1
      
      But we forgot the !CONFIG_EEH stub.
      Signed-off-by: NMark Fasheh <mark.fasheh@oracle.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1c6cc5fd
  9. 02 3月, 2006 1 次提交
  10. 28 2月, 2006 1 次提交
  11. 10 1月, 2006 1 次提交
  12. 09 1月, 2006 3 次提交
  13. 17 11月, 2005 1 次提交
  14. 14 11月, 2005 1 次提交
  15. 10 11月, 2005 1 次提交
    • L
      [PATCH] ppc64: PCI error event dispatcher · 172ca926
      Linas Vepstas 提交于
      12-eeh-event-dispatcher.patch
      
      ppc64: EEH Recovery dispatcher thread
      
      This patch adds a mechanism to create recovery threads when an
      EEH event is received.  Since an EEH freeze state may be detected
      within an interrupt context, we need to get out of the interrupt
      context before starting recovery. This dispatcher does this in
      two steps: first, it uses a workqueue to get out, and then
      lanuches a kernel thread, so that the recovery routine can
      sleep for exteded periods without upseting the keventd.
      
      A kernel thread is created with each EEH event, rather than
      having one long-running daemon started at boot time.  This is
      because it is anticipated that EEH events will be very rare
      (very very rare, ideally) and so its pointless to cluter the
      process tables with a daemon that will almost never run.
      Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      172ca926
  16. 10 9月, 2005 1 次提交
  17. 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