1. 04 12月, 2006 1 次提交
    • B
      [POWERPC] Refactor 64 bits DMA operations · 12d04eef
      Benjamin Herrenschmidt 提交于
      This patch completely refactors DMA operations for 64 bits powerpc. 32 bits
      is untouched for now.
      
      We use the new dev_archdata structure to add the dma operations pointer
      and associated data to struct device. While at it, we also add the OF node
      pointer and numa node. In the future, we might want to look into merging
      that with pci_dn as well.
      
      The old vio, pci-iommu and pci-direct DMA ops are gone. They are now replaced
      by a set of generic iommu and direct DMA ops (non PCI specific) that can be
      used by bus types. The toplevel implementation is now inline.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      12d04eef
  2. 01 11月, 2006 1 次提交
    • L
      [POWERPC] Use 4kB iommu pages even on 64kB-page systems · 5d2efba6
      Linas Vepstas 提交于
      The 10Gigabit ethernet device drivers appear to be able to chew
      up all 256MB of TCE mappings on pSeries systems, as evidenced by
      numerous error messages:
      
       iommu_alloc failed, tbl c0000000010d5c48 vaddr c0000000d875eff0 npages 1
      
      Some experimentation indicates that this is essentially because
      one 1500 byte ethernet MTU gets mapped as a 64K DMA region when
      the large 64K pages are enabled. Thus, it doesn't take much to
      exhaust all of the available DMA mappings for a high-speed card.
      
      This patch changes the iommu allocator to work with its own
      unique, distinct page size. Although the patch is long, its
      actually quite simple: it just #defines a distinct IOMMU_PAGE_SIZE
      and then uses this in all the places that matter.
      
      As a side effect, it also dramatically improves network performance
      on platforms with H-calls on iommu translation inserts/removes (since
      we no longer call it 16 times for a 1500 bytes packet when the iommu HW
      is still 4k).
      
      In the future, we might want to make the IOMMU_PAGE_SIZE a variable
      in the iommu_table instance, thus allowing support for different HW
      page sizes in the iommu itself.
      Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Acked-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      5d2efba6
  3. 31 7月, 2006 1 次提交
  4. 03 7月, 2006 1 次提交
    • B
      [POWERPC] Add new interrupt mapping core and change platforms to use it · 0ebfff14
      Benjamin Herrenschmidt 提交于
      This adds the new irq remapper core and removes the old one.  Because
      there are some fundamental conflicts with the old code, like the value
      of NO_IRQ which I'm now setting to 0 (as per discussions with Linus),
      etc..., this commit also changes the relevant platform and driver code
      over to use the new remapper (so as not to cause difficulties later
      in bisecting).
      
      This patch removes the old pre-parsing of the open firmware interrupt
      tree along with all the bogus assumptions it made to try to renumber
      interrupts according to the platform. This is all to be handled by the
      new code now.
      
      For the pSeries XICS interrupt controller, a single remapper host is
      created for the whole machine regardless of how many interrupt
      presentation and source controllers are found, and it's set to match
      any device node that isn't a 8259.  That works fine on pSeries and
      avoids having to deal with some of the complexities of split source
      controllers vs. presentation controllers in the pSeries device trees.
      
      The powerpc i8259 PIC driver now always requests the legacy interrupt
      range. It also has the feature of being able to match any device node
      (including NULL) if passed no device node as an input. That will help
      porting over platforms with broken device-trees like Pegasos who don't
      have a proper interrupt tree.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0ebfff14
  5. 15 6月, 2006 1 次提交
  6. 09 6月, 2006 1 次提交
  7. 19 5月, 2006 2 次提交
  8. 29 4月, 2006 3 次提交
  9. 21 4月, 2006 1 次提交
  10. 14 1月, 2006 1 次提交
  11. 05 1月, 2006 1 次提交
  12. 09 11月, 2005 1 次提交
    • O
      [PATCH] ppc64: add MODALIAS= for vio bus · 143dcec2
      Olaf Hering 提交于
      A non-broken udev would autoload also the drivers for devices on the
      pseries vio bus, like ibmveth, ibmvscsic and hvsc.  This is similar to pci,
      usb and ieee1394:
      
       /lib/modules/`uname -r`/modules.alias
      alias vio:TvscsiSIBM,v-scsi* ibmvscsic
      alias vio:TnetworkSIBM,l-lan* ibmveth
      alias vio:Tserial-serverShvterm2* hvcs
      
      /events/debug.00004.pci.add.1394:MODALIAS='pci:v00001014d00000188sv00000000sd00000000bc06sc04i0f'
      /events/debug.00005.pci.add.1509:MODALIAS='pci:v00008086d00001229sv00001014sd000001FFbc02sc00i00'
      /events/debug.00026.vio.add.1519:MODALIAS='vio:TserialShvterm1'
      /events/debug.00027.vio.add.1446:MODALIAS='vio:TvscsiSIBM,v-scsi'
      /events/debug.00028.vio.add.1451:MODALIAS='vio:TnetworkSIBM,l-lan'
      
       modprobe -v vio:TnetworkSIBM,l-lan
      insmod /lib/modules/2.6.14-20051030_vio-ppc64/kernel/drivers/net/ibmveth.ko
      Signed-off-by: NOlaf Hering <olh@suse.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      143dcec2
  13. 24 10月, 2005 3 次提交
  14. 09 10月, 2005 1 次提交
  15. 30 8月, 2005 4 次提交
  16. 29 8月, 2005 3 次提交
  17. 22 6月, 2005 1 次提交
  18. 21 6月, 2005 1 次提交
  19. 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