2006-02-10 06:05:54 +00:00
|
|
|
/* pci_sun4v.h: SUN4V specific PCI controller support.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2006 David S. Miller (davem@davemloft.net)
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _PCI_SUN4V_H
|
|
|
|
|
#define _PCI_SUN4V_H
|
|
|
|
|
|
2014-05-16 21:25:51 +00:00
|
|
|
long pci_sun4v_iommu_map(unsigned long devhandle,
|
|
|
|
|
unsigned long tsbid,
|
|
|
|
|
unsigned long num_ttes,
|
|
|
|
|
unsigned long io_attributes,
|
|
|
|
|
unsigned long io_page_list_pa);
|
|
|
|
|
unsigned long pci_sun4v_iommu_demap(unsigned long devhandle,
|
|
|
|
|
unsigned long tsbid,
|
|
|
|
|
unsigned long num_ttes);
|
|
|
|
|
unsigned long pci_sun4v_iommu_getmap(unsigned long devhandle,
|
|
|
|
|
unsigned long tsbid,
|
|
|
|
|
unsigned long *io_attributes,
|
|
|
|
|
unsigned long *real_address);
|
|
|
|
|
unsigned long pci_sun4v_config_get(unsigned long devhandle,
|
|
|
|
|
unsigned long pci_device,
|
|
|
|
|
unsigned long config_offset,
|
|
|
|
|
unsigned long size);
|
|
|
|
|
int pci_sun4v_config_put(unsigned long devhandle,
|
|
|
|
|
unsigned long pci_device,
|
|
|
|
|
unsigned long config_offset,
|
|
|
|
|
unsigned long size,
|
|
|
|
|
unsigned long data);
|
2006-02-10 06:05:54 +00:00
|
|
|
|
2014-05-16 21:25:51 +00:00
|
|
|
unsigned long pci_sun4v_msiq_conf(unsigned long devhandle,
|
[SPARC64]: Add PCI MSI support on Niagara.
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>
2007-02-11 01:41:02 +00:00
|
|
|
unsigned long msiqid,
|
|
|
|
|
unsigned long msiq_paddr,
|
|
|
|
|
unsigned long num_entries);
|
2014-05-16 21:25:51 +00:00
|
|
|
unsigned long pci_sun4v_msiq_info(unsigned long devhandle,
|
|
|
|
|
unsigned long msiqid,
|
|
|
|
|
unsigned long *msiq_paddr,
|
|
|
|
|
unsigned long *num_entries);
|
|
|
|
|
unsigned long pci_sun4v_msiq_getvalid(unsigned long devhandle,
|
|
|
|
|
unsigned long msiqid,
|
|
|
|
|
unsigned long *valid);
|
|
|
|
|
unsigned long pci_sun4v_msiq_setvalid(unsigned long devhandle,
|
|
|
|
|
unsigned long msiqid,
|
|
|
|
|
unsigned long valid);
|
|
|
|
|
unsigned long pci_sun4v_msiq_getstate(unsigned long devhandle,
|
|
|
|
|
unsigned long msiqid,
|
|
|
|
|
unsigned long *state);
|
|
|
|
|
unsigned long pci_sun4v_msiq_setstate(unsigned long devhandle,
|
|
|
|
|
unsigned long msiqid,
|
|
|
|
|
unsigned long state);
|
|
|
|
|
unsigned long pci_sun4v_msiq_gethead(unsigned long devhandle,
|
|
|
|
|
unsigned long msiqid,
|
|
|
|
|
unsigned long *head);
|
|
|
|
|
unsigned long pci_sun4v_msiq_sethead(unsigned long devhandle,
|
|
|
|
|
unsigned long msiqid,
|
|
|
|
|
unsigned long head);
|
|
|
|
|
unsigned long pci_sun4v_msiq_gettail(unsigned long devhandle,
|
|
|
|
|
unsigned long msiqid,
|
|
|
|
|
unsigned long *head);
|
|
|
|
|
unsigned long pci_sun4v_msi_getvalid(unsigned long devhandle,
|
|
|
|
|
unsigned long msinum,
|
|
|
|
|
unsigned long *valid);
|
|
|
|
|
unsigned long pci_sun4v_msi_setvalid(unsigned long devhandle,
|
|
|
|
|
unsigned long msinum,
|
|
|
|
|
unsigned long valid);
|
|
|
|
|
unsigned long pci_sun4v_msi_getmsiq(unsigned long devhandle,
|
|
|
|
|
unsigned long msinum,
|
|
|
|
|
unsigned long *msiq);
|
|
|
|
|
unsigned long pci_sun4v_msi_setmsiq(unsigned long devhandle,
|
|
|
|
|
unsigned long msinum,
|
|
|
|
|
unsigned long msiq,
|
|
|
|
|
unsigned long msitype);
|
|
|
|
|
unsigned long pci_sun4v_msi_getstate(unsigned long devhandle,
|
|
|
|
|
unsigned long msinum,
|
|
|
|
|
unsigned long *state);
|
|
|
|
|
unsigned long pci_sun4v_msi_setstate(unsigned long devhandle,
|
|
|
|
|
unsigned long msinum,
|
|
|
|
|
unsigned long state);
|
|
|
|
|
unsigned long pci_sun4v_msg_getmsiq(unsigned long devhandle,
|
|
|
|
|
unsigned long msinum,
|
|
|
|
|
unsigned long *msiq);
|
|
|
|
|
unsigned long pci_sun4v_msg_setmsiq(unsigned long devhandle,
|
|
|
|
|
unsigned long msinum,
|
|
|
|
|
unsigned long msiq);
|
|
|
|
|
unsigned long pci_sun4v_msg_getvalid(unsigned long devhandle,
|
|
|
|
|
unsigned long msinum,
|
|
|
|
|
unsigned long *valid);
|
|
|
|
|
unsigned long pci_sun4v_msg_setvalid(unsigned long devhandle,
|
|
|
|
|
unsigned long msinum,
|
|
|
|
|
unsigned long valid);
|
[SPARC64]: Add PCI MSI support on Niagara.
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>
2007-02-11 01:41:02 +00:00
|
|
|
|
2006-02-10 06:05:54 +00:00
|
|
|
#endif /* !(_PCI_SUN4V_H) */
|
