summaryrefslogtreecommitdiff
path: root/arch/sparc64/kernel/pci_sun4v_asm.S
AgeCommit message (Collapse)Author
2008-12-04sparc,sparc64: unify kernel/Sam Ravnborg
o Move all files from sparc64/kernel/ to sparc/kernel - rename as appropriate o Update sparc/Makefile to the changes o Update sparc/kernel/Makefile to include the sparc64 files NOTE: This commit changes link order on sparc64! Link order had to change for either of sparc32 and sparc64. And assuming sparc64 see more testing than sparc32 change link order on sparc64 where issues will be caught faster. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-09-01sparc64: Use ENTRY/ENDPROC in PCI SUN4V asm.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-10[SPARC64]: Add PCI MSI support on Niagara.David S. Miller
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>
2006-03-20[SPARC64]: Remove PGLIST_NENTS PCI IOMMU mapping limitation on SUN4V.David S. Miller
Use a batching queue system for IOMMU mapping setup, with a page sized batch. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20[SPARC64]: Move devino_to_sysino out of pci_sun4v_asm.SDavid S. Miller
It is not PCI specific, it is for all system interrupts. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20[SPARC64]: First cut at SUN4V PCI IOMMU handling.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20[SPARC64]: Implement SUN4V PCI config space access.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20[SPARC64]: More SUN4V PCI controller work.David S. Miller
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>