summaryrefslogtreecommitdiffstats
path: root/include/asm-sparc64/pbm.h
Commit message (Collapse)AuthorAgeFilesLines
* [SPARC64]: Add PCI MSI support on Niagara.David S. Miller2007-02-101-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is kind of hokey, we could use the hardware provided facilities much better. MSIs are assosciated with MSI Queues. MSI Queues generate interrupts when any MSI assosciated with it is signalled. This suggests a two-tiered IRQ dispatch scheme: MSI Queue interrupt --> queue interrupt handler MSI dispatch --> driver interrupt handler But we just get one-level under Linux currently. What I'd like to do is possibly stick the IRQ actions into a per-MSI-Queue data structure, and dispatch them form there, but the generic IRQ layer doesn't provide a way to do that right now. So, the current kludge is to "ACK" the interrupt by processing the MSI Queue data structures and ACK'ing them, then we run the actual handler like normal. We are wasting a lot of useful information, for example the MSI data and address are provided with ever MSI, as well as a system tick if available. If we could pass this into the IRQ handler it could help with certain things, in particular for PCI-Express error messages. The MSI entries on sparc64 also tell you exactly which bus/device/fn sent the MSI, which would be great for error handling when no registered IRQ handler can service the interrupt. We override the disable/enable IRQ chip methods in sun4v_msi, so we have to call {mask,unmask}_msi_irq() directly from there. This is another ugly wart. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: of_device layer IRQ resolutionDavid S. Miller2006-06-291-1/+2
| | | | | | | | | | | | | | | | | | 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-291-2/+0
| | | | | | | | | 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-231-2/+1
| | | | | | | | 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-231-6/+6
| | | | | | 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-201-0/+3
| | | | | | | | | | 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-131-20/+8
| | | | | | | | | | | 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-131-1/+1
| | | | | | | 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-041-0/+3
| | | | | | | | | | | | | | | 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-311-3/+5
| | | | | | | | | | | | | 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-161-0/+248
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!
OpenPOWER on IntegriCloud