aboutsummaryrefslogtreecommitdiffstats
path: root/include/asm-sparc64/pbm.h
Commit message (Collapse)AuthorAge
* [SPARC64]: of_device layer IRQ resolutionDavid S. Miller2006-06-29
| | | | | | | | | | | | | | | | | | Do IRQ determination generically by parsing the PROM properties, and using IRQ controller drivers for final resolution. One immediate positive effect is that all of the IRQ frobbing in the EBUS, ISA, and PCI controller layers has been eliminated. We just look up the of_device and use the properly computed value. The PCI controller irq_build() routines are gone and no longer used. Unfortunately sbus_build_irq() has to remain as there is a direct reference to this in the sunzilog driver. That can be killed off once the sparc32 side of this is written and the sunzilog driver is transformed into an "of" bus driver. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill starfire_cookie from SBUS/PCI.David S. Miller2006-06-29
| | | | | | | | | Totally unused. We need to traverse the list of global IRQ translaters, so storing it in the per-bus structures was useless. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Convert sparc64 PCI layer to in-kernel device tree.David S. Miller2006-06-24
| | | | | | | | One thing this change pointed out was that we really should pull the "get 'local-mac-address' property" logic into a helper function all the network drivers can call. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Use in-kernel OBP device tree for PCI controller probing.David S. Miller2006-06-24
| | | | | | It can be pushed even further down, but this is a first step. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: More SUN4V PCI controller work.David S. Miller2006-03-20
| | | | | | | | | | Add assembler file for PCI hypervisor calls. Setup basic skeleton of SUN4V PCI controller driver. Add 32-bit devhandle to PBM struct, as this is needed for hypervisor calls. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Eliminate PCI IOMMU dma mapping size limit.David S. Miller2005-10-14
| | | | | | | | | | | The hairy fast allocator in the sparc64 PCI IOMMU code has a hard limit of 256 pages. Certain devices can exceed this when performing very large I/Os. So replace with a more simple allocator, based largely upon the arch/ppc64/kernel/iommu.c code. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Consolidate common PCI IOMMU init code.David S. Miller2005-10-14
| | | | | | | All the PCI controller drivers were doing the same thing setting up the IOMMU software state, put it all in one spot. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Do proper DMA IRQ syncing on TomatilloDavid S. Miller2005-07-04
| | | | | | | | | | | | | | | This was the main impetus behind adding the PCI IRQ shim. In order to properly order DMA writes wrt. interrupts, you have to write to a PCI controller register, then poll for that bit clearing. There is one bit for each interrupt source, and setting this register bit tells Tomatillo to drain all pending DMA from that device. Furthermore, Tomatillo's with revision less than 4 require us to do a block store due to some memory transaction ordering issues it has on JBUS. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Fix streaming buffer flushing on PCI and SBUS.David S. Miller2005-05-31
| | | | | | | | | | | | | Firstly, if the direction is TODEVICE, then dirty data in the streaming cache is impossible so we can elide the flush-flag synchronization in that case. Next, the context allocator is broken. It is highly likely that contexts get used multiple times for different dma mappings, which confuses the strbuf flushing code and makes it run inefficiently. Signed-off-by: David S. Miller <davem@davemloft.net>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
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!