summaryrefslogtreecommitdiffstats
path: root/include/asm-sparc64/pbm.h
Commit message (Collapse)AuthorAgeFilesLines
* [SPARC64]: Kill asm-sparc64/pbm.hDavid S. Miller2007-05-081-132/+0
| | | | | | Everything it contains can be hidden in pci_impl.h Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Move index info pci_pbm_info.David S. Miller2007-05-081-5/+1
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Move {setup,teardown}_msi_irq into pci_pbm_info.David S. Miller2007-05-081-7/+3
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Move pci_ops into pci_pbm_info.David S. Miller2007-05-081-3/+1
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64] PCI: Use root list of pbm's instead of pci_controller_info'sDavid S. Miller2007-05-081-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea is to move more and more things into the pbm, with the eventual goal of eliminating the pci_controller_info entirely as there really isn't any need for it. This stage of the transformations requires some reworking of the PCI error interrupt handling. It might be tricky to get rid of the pci_controller_info parenting for a few reasons: 1) When we get an uncorrectable or correctable error we want to interrogate the IOMMU and streaming cache of both PBMs for error status. These errors come from the UPA front-end which is shared between the two PBM PCI bus segments. Historically speaking this is why I choose the datastructure hierarchy of pci_controller_info-->pci_pbm_info 2) The probing does a portid/devhandle match to look for the 'other' pbm, but this is entirely an artifact and can be eliminated trivially. What we could do to solve #1 is to have a "buddy" pointer from one pbm to another. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64] PCI: Kill PROM_PCIRNG_MAX and PROM_PCIIMAP_MAX.David S. Miller2007-05-081-6/+0
| | | | | | They are totally unused. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64] PCI: Use common routine to fetch PBM properties.David S. Miller2007-05-081-2/+0
| | | | | | | | | | Namely bus-range and ino-bitmap. This allows us also to eliminate pci_controller_info's pci_{first,last}_busno fields as only the pbm ones are used now. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Convert PCI over to generic struct iommu/strbuf.David S. Miller2007-04-261-83/+7
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Consolidate {sbus,pci}_iommu_arena.David S. Miller2007-04-261-7/+1
| | | | | | Move to asm-sparc64/iommu.h and rename to plain "iommu_arena". Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Use DECLARE_BITMAP in struct pci_iommu.David S. Miller2007-04-261-1/+1
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill pbm->pci_first_slot.David S. Miller2007-04-261-3/+0
| | | | | | Set but never used. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill pci_controller->pbms_same_domainDavid S. Miller2007-04-261-3/+0
| | | | | | | | We don't do the "Simba APB is a PBM" bogosity for Sabre controllers any longer, so this pbms_same_domain thing is no longer necessary. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill pci_controller->base_address_update().David S. Miller2007-04-261-1/+0
| | | | | | Implemented but never actually used. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill pci_controller->resource_adjust()David S. Miller2007-04-261-1/+0
| | | | | | | All the implementations can be identical and generic, so no need for controller specific methods. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill PBM ranges software state.David S. Miller2007-04-261-2/+0
| | | | | | | It is only used in one spot and we can just fetch the OF property right there. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill PBM intmap software state.David S. Miller2007-04-261-3/+0
| | | | | | Set but never used. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Probe PCI bus using OF device tree.David S. Miller2007-04-261-23/+0
| | | | | | | | | Almost entirely taken from the 64-bit PowerPC PCI code. This allowed to eliminate a ton of cruft from the sparc64 PCI layer. Signed-off-by: David S. Miller <davem@davemloft.net>
* [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