2006-02-10 05:32:07 +00:00
|
|
|
/* pci_sun4v.c: SUN4V specific PCI controller support.
|
|
|
|
*
|
2008-02-09 02:05:46 +00:00
|
|
|
* Copyright (C) 2006, 2007, 2008 David S. Miller (davem@davemloft.net)
|
2006-02-10 05:32:07 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/interrupt.h>
|
2006-02-10 08:08:26 +00:00
|
|
|
#include <linux/percpu.h>
|
[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
|
|
|
#include <linux/irq.h>
|
|
|
|
#include <linux/msi.h>
|
2007-05-24 01:00:46 +00:00
|
|
|
#include <linux/log2.h>
|
2006-02-10 05:32:07 +00:00
|
|
|
|
|
|
|
#include <asm/iommu.h>
|
|
|
|
#include <asm/irq.h>
|
|
|
|
#include <asm/upa.h>
|
|
|
|
#include <asm/pstate.h>
|
|
|
|
#include <asm/oplib.h>
|
|
|
|
#include <asm/hypervisor.h>
|
2006-06-22 01:18:47 +00:00
|
|
|
#include <asm/prom.h>
|
2006-02-10 05:32:07 +00:00
|
|
|
|
|
|
|
#include "pci_impl.h"
|
|
|
|
#include "iommu_common.h"
|
|
|
|
|
2006-02-10 06:05:54 +00:00
|
|
|
#include "pci_sun4v.h"
|
|
|
|
|
2007-05-25 08:04:15 +00:00
|
|
|
static unsigned long vpci_major = 1;
|
|
|
|
static unsigned long vpci_minor = 1;
|
|
|
|
|
2006-02-14 05:50:27 +00:00
|
|
|
#define PGLIST_NENTS (PAGE_SIZE / sizeof(u64))
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2007-04-27 04:08:21 +00:00
|
|
|
struct iommu_batch {
|
2007-07-28 05:39:14 +00:00
|
|
|
struct device *dev; /* Device mapping is for. */
|
2006-02-20 06:21:32 +00:00
|
|
|
unsigned long prot; /* IOMMU page protections */
|
|
|
|
unsigned long entry; /* Index into IOTSB. */
|
|
|
|
u64 *pglist; /* List of physical pages */
|
|
|
|
unsigned long npages; /* Number of pages in list. */
|
2006-02-10 08:08:26 +00:00
|
|
|
};
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
static DEFINE_PER_CPU(struct iommu_batch, iommu_batch);
|
2006-02-20 06:21:32 +00:00
|
|
|
|
|
|
|
/* Interrupts must be disabled. */
|
2007-07-28 05:39:14 +00:00
|
|
|
static inline void iommu_batch_start(struct device *dev, unsigned long prot, unsigned long entry)
|
2006-02-20 06:21:32 +00:00
|
|
|
{
|
2007-07-28 05:39:14 +00:00
|
|
|
struct iommu_batch *p = &__get_cpu_var(iommu_batch);
|
2006-02-20 06:21:32 +00:00
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
p->dev = dev;
|
2006-02-20 06:21:32 +00:00
|
|
|
p->prot = prot;
|
|
|
|
p->entry = entry;
|
|
|
|
p->npages = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Interrupts must be disabled. */
|
2007-07-28 05:39:14 +00:00
|
|
|
static long iommu_batch_flush(struct iommu_batch *p)
|
2006-02-20 06:21:32 +00:00
|
|
|
{
|
2007-07-28 05:39:14 +00:00
|
|
|
struct pci_pbm_info *pbm = p->dev->archdata.host_controller;
|
2007-03-01 07:35:04 +00:00
|
|
|
unsigned long devhandle = pbm->devhandle;
|
2006-02-20 06:21:32 +00:00
|
|
|
unsigned long prot = p->prot;
|
|
|
|
unsigned long entry = p->entry;
|
|
|
|
u64 *pglist = p->pglist;
|
|
|
|
unsigned long npages = p->npages;
|
|
|
|
|
2006-02-20 09:42:51 +00:00
|
|
|
while (npages != 0) {
|
2006-02-20 06:21:32 +00:00
|
|
|
long num;
|
|
|
|
|
|
|
|
num = pci_sun4v_iommu_map(devhandle, HV_PCI_TSBID(0, entry),
|
|
|
|
npages, prot, __pa(pglist));
|
|
|
|
if (unlikely(num < 0)) {
|
|
|
|
if (printk_ratelimit())
|
2007-07-28 05:39:14 +00:00
|
|
|
printk("iommu_batch_flush: IOMMU map of "
|
2006-02-20 06:21:32 +00:00
|
|
|
"[%08lx:%08lx:%lx:%lx:%lx] failed with "
|
|
|
|
"status %ld\n",
|
|
|
|
devhandle, HV_PCI_TSBID(0, entry),
|
|
|
|
npages, prot, __pa(pglist), num);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
entry += num;
|
|
|
|
npages -= num;
|
|
|
|
pglist += num;
|
2006-02-20 09:42:51 +00:00
|
|
|
}
|
2006-02-20 06:21:32 +00:00
|
|
|
|
|
|
|
p->entry = entry;
|
|
|
|
p->npages = 0;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Interrupts must be disabled. */
|
2007-07-28 05:39:14 +00:00
|
|
|
static inline long iommu_batch_add(u64 phys_page)
|
2006-02-20 06:21:32 +00:00
|
|
|
{
|
2007-07-28 05:39:14 +00:00
|
|
|
struct iommu_batch *p = &__get_cpu_var(iommu_batch);
|
2006-02-20 06:21:32 +00:00
|
|
|
|
|
|
|
BUG_ON(p->npages >= PGLIST_NENTS);
|
|
|
|
|
|
|
|
p->pglist[p->npages++] = phys_page;
|
|
|
|
if (p->npages == PGLIST_NENTS)
|
2007-07-28 05:39:14 +00:00
|
|
|
return iommu_batch_flush(p);
|
2006-02-20 06:21:32 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Interrupts must be disabled. */
|
2007-07-28 05:39:14 +00:00
|
|
|
static inline long iommu_batch_end(void)
|
2006-02-20 06:21:32 +00:00
|
|
|
{
|
2007-07-28 05:39:14 +00:00
|
|
|
struct iommu_batch *p = &__get_cpu_var(iommu_batch);
|
2006-02-20 06:21:32 +00:00
|
|
|
|
|
|
|
BUG_ON(p->npages >= PGLIST_NENTS);
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
return iommu_batch_flush(p);
|
2006-02-20 06:21:32 +00:00
|
|
|
}
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
static void *dma_4v_alloc_coherent(struct device *dev, size_t size,
|
|
|
|
dma_addr_t *dma_addrp, gfp_t gfp)
|
2006-02-10 05:32:07 +00:00
|
|
|
{
|
2007-04-27 04:08:21 +00:00
|
|
|
struct iommu *iommu;
|
2006-02-14 05:50:27 +00:00
|
|
|
unsigned long flags, order, first_page, npages, n;
|
2006-02-10 08:08:26 +00:00
|
|
|
void *ret;
|
|
|
|
long entry;
|
|
|
|
|
|
|
|
size = IO_PAGE_ALIGN(size);
|
|
|
|
order = get_order(size);
|
2006-02-20 06:21:32 +00:00
|
|
|
if (unlikely(order >= MAX_ORDER))
|
2006-02-10 08:08:26 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
npages = size >> IO_PAGE_SHIFT;
|
|
|
|
|
2006-05-23 09:07:22 +00:00
|
|
|
first_page = __get_free_pages(gfp, order);
|
2006-02-20 06:21:32 +00:00
|
|
|
if (unlikely(first_page == 0UL))
|
2006-02-10 08:08:26 +00:00
|
|
|
return NULL;
|
2006-02-16 06:25:27 +00:00
|
|
|
|
2006-02-10 08:08:26 +00:00
|
|
|
memset((char *)first_page, 0, PAGE_SIZE << order);
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
iommu = dev->archdata.iommu;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
spin_lock_irqsave(&iommu->lock, flags);
|
2008-02-09 02:05:46 +00:00
|
|
|
entry = iommu_range_alloc(dev, iommu, npages, NULL);
|
2006-02-10 08:08:26 +00:00
|
|
|
spin_unlock_irqrestore(&iommu->lock, flags);
|
|
|
|
|
2008-02-09 02:05:46 +00:00
|
|
|
if (unlikely(entry == DMA_ERROR_CODE))
|
|
|
|
goto range_alloc_fail;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
*dma_addrp = (iommu->page_table_map_base +
|
|
|
|
(entry << IO_PAGE_SHIFT));
|
|
|
|
ret = (void *) first_page;
|
|
|
|
first_page = __pa(first_page);
|
|
|
|
|
2006-02-20 06:21:32 +00:00
|
|
|
local_irq_save(flags);
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
iommu_batch_start(dev,
|
|
|
|
(HV_PCI_MAP_ATTR_READ |
|
|
|
|
HV_PCI_MAP_ATTR_WRITE),
|
|
|
|
entry);
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2006-02-20 06:21:32 +00:00
|
|
|
for (n = 0; n < npages; n++) {
|
2007-07-28 05:39:14 +00:00
|
|
|
long err = iommu_batch_add(first_page + (n * PAGE_SIZE));
|
2006-02-20 06:21:32 +00:00
|
|
|
if (unlikely(err < 0L))
|
|
|
|
goto iommu_map_fail;
|
|
|
|
}
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
if (unlikely(iommu_batch_end() < 0L))
|
2006-02-20 06:21:32 +00:00
|
|
|
goto iommu_map_fail;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2006-02-20 06:21:32 +00:00
|
|
|
local_irq_restore(flags);
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
return ret;
|
2006-02-20 06:21:32 +00:00
|
|
|
|
|
|
|
iommu_map_fail:
|
|
|
|
/* Interrupts are disabled. */
|
|
|
|
spin_lock(&iommu->lock);
|
2008-02-09 02:05:46 +00:00
|
|
|
iommu_range_free(iommu, *dma_addrp, npages);
|
2006-02-20 06:21:32 +00:00
|
|
|
spin_unlock_irqrestore(&iommu->lock, flags);
|
|
|
|
|
2008-02-09 02:05:46 +00:00
|
|
|
range_alloc_fail:
|
2006-02-20 06:21:32 +00:00
|
|
|
free_pages(first_page, order);
|
|
|
|
return NULL;
|
2006-02-10 05:32:07 +00:00
|
|
|
}
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
static void dma_4v_free_coherent(struct device *dev, size_t size, void *cpu,
|
|
|
|
dma_addr_t dvma)
|
2006-02-10 05:32:07 +00:00
|
|
|
{
|
2007-03-01 07:35:04 +00:00
|
|
|
struct pci_pbm_info *pbm;
|
2007-04-27 04:08:21 +00:00
|
|
|
struct iommu *iommu;
|
2006-02-14 05:50:27 +00:00
|
|
|
unsigned long flags, order, npages, entry;
|
|
|
|
u32 devhandle;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
npages = IO_PAGE_ALIGN(size) >> IO_PAGE_SHIFT;
|
2007-07-28 05:39:14 +00:00
|
|
|
iommu = dev->archdata.iommu;
|
|
|
|
pbm = dev->archdata.host_controller;
|
2007-03-01 07:35:04 +00:00
|
|
|
devhandle = pbm->devhandle;
|
2006-02-10 08:08:26 +00:00
|
|
|
entry = ((dvma - iommu->page_table_map_base) >> IO_PAGE_SHIFT);
|
|
|
|
|
|
|
|
spin_lock_irqsave(&iommu->lock, flags);
|
|
|
|
|
2008-02-09 02:05:46 +00:00
|
|
|
iommu_range_free(iommu, dvma, npages);
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
do {
|
|
|
|
unsigned long num;
|
|
|
|
|
|
|
|
num = pci_sun4v_iommu_demap(devhandle, HV_PCI_TSBID(0, entry),
|
|
|
|
npages);
|
|
|
|
entry += num;
|
|
|
|
npages -= num;
|
|
|
|
} while (npages != 0);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&iommu->lock, flags);
|
|
|
|
|
|
|
|
order = get_order(size);
|
|
|
|
if (order < 10)
|
|
|
|
free_pages((unsigned long)cpu, order);
|
2006-02-10 05:32:07 +00:00
|
|
|
}
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
static dma_addr_t dma_4v_map_single(struct device *dev, void *ptr, size_t sz,
|
|
|
|
enum dma_data_direction direction)
|
2006-02-10 05:32:07 +00:00
|
|
|
{
|
2007-04-27 04:08:21 +00:00
|
|
|
struct iommu *iommu;
|
2006-02-10 08:08:26 +00:00
|
|
|
unsigned long flags, npages, oaddr;
|
2006-02-14 05:50:27 +00:00
|
|
|
unsigned long i, base_paddr;
|
2006-02-20 06:21:32 +00:00
|
|
|
u32 bus_addr, ret;
|
2006-02-10 08:08:26 +00:00
|
|
|
unsigned long prot;
|
|
|
|
long entry;
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
iommu = dev->archdata.iommu;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
if (unlikely(direction == DMA_NONE))
|
2006-02-10 08:08:26 +00:00
|
|
|
goto bad;
|
|
|
|
|
|
|
|
oaddr = (unsigned long)ptr;
|
|
|
|
npages = IO_PAGE_ALIGN(oaddr + sz) - (oaddr & IO_PAGE_MASK);
|
|
|
|
npages >>= IO_PAGE_SHIFT;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&iommu->lock, flags);
|
2008-02-09 02:05:46 +00:00
|
|
|
entry = iommu_range_alloc(dev, iommu, npages, NULL);
|
2006-02-10 08:08:26 +00:00
|
|
|
spin_unlock_irqrestore(&iommu->lock, flags);
|
|
|
|
|
2008-02-09 02:05:46 +00:00
|
|
|
if (unlikely(entry == DMA_ERROR_CODE))
|
2006-02-10 08:08:26 +00:00
|
|
|
goto bad;
|
|
|
|
|
|
|
|
bus_addr = (iommu->page_table_map_base +
|
|
|
|
(entry << IO_PAGE_SHIFT));
|
|
|
|
ret = bus_addr | (oaddr & ~IO_PAGE_MASK);
|
|
|
|
base_paddr = __pa(oaddr & IO_PAGE_MASK);
|
|
|
|
prot = HV_PCI_MAP_ATTR_READ;
|
2007-07-28 05:39:14 +00:00
|
|
|
if (direction != DMA_TO_DEVICE)
|
2006-02-10 08:08:26 +00:00
|
|
|
prot |= HV_PCI_MAP_ATTR_WRITE;
|
|
|
|
|
2006-02-20 06:21:32 +00:00
|
|
|
local_irq_save(flags);
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
iommu_batch_start(dev, prot, entry);
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2006-02-20 06:21:32 +00:00
|
|
|
for (i = 0; i < npages; i++, base_paddr += IO_PAGE_SIZE) {
|
2007-07-28 05:39:14 +00:00
|
|
|
long err = iommu_batch_add(base_paddr);
|
2006-02-20 06:21:32 +00:00
|
|
|
if (unlikely(err < 0L))
|
|
|
|
goto iommu_map_fail;
|
|
|
|
}
|
2007-07-28 05:39:14 +00:00
|
|
|
if (unlikely(iommu_batch_end() < 0L))
|
2006-02-20 06:21:32 +00:00
|
|
|
goto iommu_map_fail;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2006-02-20 06:21:32 +00:00
|
|
|
local_irq_restore(flags);
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
bad:
|
|
|
|
if (printk_ratelimit())
|
|
|
|
WARN_ON(1);
|
2007-07-28 05:39:14 +00:00
|
|
|
return DMA_ERROR_CODE;
|
2006-02-20 06:21:32 +00:00
|
|
|
|
|
|
|
iommu_map_fail:
|
|
|
|
/* Interrupts are disabled. */
|
|
|
|
spin_lock(&iommu->lock);
|
2008-02-09 02:05:46 +00:00
|
|
|
iommu_range_free(iommu, bus_addr, npages);
|
2006-02-20 06:21:32 +00:00
|
|
|
spin_unlock_irqrestore(&iommu->lock, flags);
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
return DMA_ERROR_CODE;
|
2006-02-10 05:32:07 +00:00
|
|
|
}
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
static void dma_4v_unmap_single(struct device *dev, dma_addr_t bus_addr,
|
|
|
|
size_t sz, enum dma_data_direction direction)
|
2006-02-10 05:32:07 +00:00
|
|
|
{
|
2007-03-01 07:35:04 +00:00
|
|
|
struct pci_pbm_info *pbm;
|
2007-04-27 04:08:21 +00:00
|
|
|
struct iommu *iommu;
|
2006-02-14 05:50:27 +00:00
|
|
|
unsigned long flags, npages;
|
2006-02-10 08:08:26 +00:00
|
|
|
long entry;
|
2006-02-14 05:50:27 +00:00
|
|
|
u32 devhandle;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
if (unlikely(direction == DMA_NONE)) {
|
2006-02-10 08:08:26 +00:00
|
|
|
if (printk_ratelimit())
|
|
|
|
WARN_ON(1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
iommu = dev->archdata.iommu;
|
|
|
|
pbm = dev->archdata.host_controller;
|
2007-03-01 07:35:04 +00:00
|
|
|
devhandle = pbm->devhandle;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
npages = IO_PAGE_ALIGN(bus_addr + sz) - (bus_addr & IO_PAGE_MASK);
|
|
|
|
npages >>= IO_PAGE_SHIFT;
|
|
|
|
bus_addr &= IO_PAGE_MASK;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&iommu->lock, flags);
|
|
|
|
|
2008-02-09 02:05:46 +00:00
|
|
|
iommu_range_free(iommu, bus_addr, npages);
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2008-02-09 02:05:46 +00:00
|
|
|
entry = (bus_addr - iommu->page_table_map_base) >> IO_PAGE_SHIFT;
|
2006-02-10 08:08:26 +00:00
|
|
|
do {
|
|
|
|
unsigned long num;
|
|
|
|
|
|
|
|
num = pci_sun4v_iommu_demap(devhandle, HV_PCI_TSBID(0, entry),
|
|
|
|
npages);
|
|
|
|
entry += num;
|
|
|
|
npages -= num;
|
|
|
|
} while (npages != 0);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&iommu->lock, flags);
|
|
|
|
}
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
static int dma_4v_map_sg(struct device *dev, struct scatterlist *sglist,
|
|
|
|
int nelems, enum dma_data_direction direction)
|
2006-02-10 05:32:07 +00:00
|
|
|
{
|
2008-02-06 11:50:26 +00:00
|
|
|
unsigned long flags, npages, i, prot;
|
2008-02-09 02:05:46 +00:00
|
|
|
u32 dma_base, orig_dma_base;
|
2008-02-06 11:50:26 +00:00
|
|
|
struct scatterlist *sg;
|
2007-04-27 04:08:21 +00:00
|
|
|
struct iommu *iommu;
|
2006-02-20 06:21:32 +00:00
|
|
|
long entry, err;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
/* Fast path single entry scatterlists. */
|
|
|
|
if (nelems == 1) {
|
|
|
|
sglist->dma_address =
|
2007-10-22 18:02:46 +00:00
|
|
|
dma_4v_map_single(dev, sg_virt(sglist),
|
2006-02-10 08:08:26 +00:00
|
|
|
sglist->length, direction);
|
2007-07-28 05:39:14 +00:00
|
|
|
if (unlikely(sglist->dma_address == DMA_ERROR_CODE))
|
2006-02-10 08:08:26 +00:00
|
|
|
return 0;
|
|
|
|
sglist->dma_length = sglist->length;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
iommu = dev->archdata.iommu;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
if (unlikely(direction == DMA_NONE))
|
2006-02-10 08:08:26 +00:00
|
|
|
goto bad;
|
|
|
|
|
2008-02-06 11:50:26 +00:00
|
|
|
npages = calc_npages(sglist, nelems);
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
spin_lock_irqsave(&iommu->lock, flags);
|
2008-02-09 02:05:46 +00:00
|
|
|
entry = iommu_range_alloc(dev, iommu, npages, NULL);
|
2006-02-10 08:08:26 +00:00
|
|
|
spin_unlock_irqrestore(&iommu->lock, flags);
|
|
|
|
|
2008-02-09 02:05:46 +00:00
|
|
|
if (unlikely(entry == DMA_ERROR_CODE))
|
2006-02-10 08:08:26 +00:00
|
|
|
goto bad;
|
|
|
|
|
2008-02-09 02:05:46 +00:00
|
|
|
orig_dma_base = dma_base = iommu->page_table_map_base +
|
2006-02-10 08:08:26 +00:00
|
|
|
(entry << IO_PAGE_SHIFT);
|
|
|
|
|
|
|
|
prot = HV_PCI_MAP_ATTR_READ;
|
2007-07-28 05:39:14 +00:00
|
|
|
if (direction != DMA_TO_DEVICE)
|
2006-02-10 08:08:26 +00:00
|
|
|
prot |= HV_PCI_MAP_ATTR_WRITE;
|
|
|
|
|
2008-02-06 11:50:26 +00:00
|
|
|
local_irq_save(flags);
|
|
|
|
|
|
|
|
iommu_batch_start(dev, prot, entry);
|
|
|
|
|
|
|
|
for_each_sg(sglist, sg, nelems, i) {
|
|
|
|
unsigned long paddr = SG_ENT_PHYS_ADDRESS(sg);
|
|
|
|
unsigned long slen = sg->length;
|
|
|
|
unsigned long this_npages;
|
|
|
|
|
|
|
|
this_npages = iommu_num_pages(paddr, slen);
|
|
|
|
|
|
|
|
sg->dma_address = dma_base | (paddr & ~IO_PAGE_MASK);
|
|
|
|
sg->dma_length = slen;
|
|
|
|
|
|
|
|
paddr &= IO_PAGE_MASK;
|
|
|
|
while (this_npages--) {
|
|
|
|
err = iommu_batch_add(paddr);
|
|
|
|
if (unlikely(err < 0L)) {
|
|
|
|
local_irq_restore(flags);
|
|
|
|
goto iommu_map_failed;
|
|
|
|
}
|
|
|
|
|
|
|
|
paddr += IO_PAGE_SIZE;
|
|
|
|
dma_base += IO_PAGE_SIZE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
err = iommu_batch_end();
|
|
|
|
|
|
|
|
local_irq_restore(flags);
|
|
|
|
|
2006-02-20 06:21:32 +00:00
|
|
|
if (unlikely(err < 0L))
|
|
|
|
goto iommu_map_failed;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2008-02-06 11:50:26 +00:00
|
|
|
return nelems;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
bad:
|
|
|
|
if (printk_ratelimit())
|
|
|
|
WARN_ON(1);
|
|
|
|
return 0;
|
2006-02-20 06:21:32 +00:00
|
|
|
|
|
|
|
iommu_map_failed:
|
|
|
|
spin_lock_irqsave(&iommu->lock, flags);
|
2008-02-09 02:05:46 +00:00
|
|
|
iommu_range_free(iommu, orig_dma_base, npages);
|
2006-02-20 06:21:32 +00:00
|
|
|
spin_unlock_irqrestore(&iommu->lock, flags);
|
|
|
|
|
|
|
|
return 0;
|
2006-02-10 05:32:07 +00:00
|
|
|
}
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
static void dma_4v_unmap_sg(struct device *dev, struct scatterlist *sglist,
|
|
|
|
int nelems, enum dma_data_direction direction)
|
2006-02-10 05:32:07 +00:00
|
|
|
{
|
2008-02-06 11:50:26 +00:00
|
|
|
unsigned long flags, npages;
|
2007-03-01 07:35:04 +00:00
|
|
|
struct pci_pbm_info *pbm;
|
2008-02-06 11:50:26 +00:00
|
|
|
u32 devhandle, bus_addr;
|
2007-04-27 04:08:21 +00:00
|
|
|
struct iommu *iommu;
|
2006-02-10 08:08:26 +00:00
|
|
|
long entry;
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
if (unlikely(direction == DMA_NONE)) {
|
2006-02-10 08:08:26 +00:00
|
|
|
if (printk_ratelimit())
|
|
|
|
WARN_ON(1);
|
|
|
|
}
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
iommu = dev->archdata.iommu;
|
|
|
|
pbm = dev->archdata.host_controller;
|
2007-03-01 07:35:04 +00:00
|
|
|
devhandle = pbm->devhandle;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
bus_addr = sglist->dma_address & IO_PAGE_MASK;
|
2007-08-07 07:37:10 +00:00
|
|
|
|
2008-02-06 11:50:26 +00:00
|
|
|
npages = calc_npages(sglist, nelems);
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
entry = ((bus_addr - iommu->page_table_map_base) >> IO_PAGE_SHIFT);
|
|
|
|
|
|
|
|
spin_lock_irqsave(&iommu->lock, flags);
|
|
|
|
|
2008-02-09 02:05:46 +00:00
|
|
|
iommu_range_free(iommu, bus_addr, npages);
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
do {
|
|
|
|
unsigned long num;
|
|
|
|
|
|
|
|
num = pci_sun4v_iommu_demap(devhandle, HV_PCI_TSBID(0, entry),
|
|
|
|
npages);
|
|
|
|
entry += num;
|
|
|
|
npages -= num;
|
|
|
|
} while (npages != 0);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&iommu->lock, flags);
|
2006-02-10 05:32:07 +00:00
|
|
|
}
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
static void dma_4v_sync_single_for_cpu(struct device *dev,
|
|
|
|
dma_addr_t bus_addr, size_t sz,
|
|
|
|
enum dma_data_direction direction)
|
2006-02-10 05:32:07 +00:00
|
|
|
{
|
2006-02-10 08:08:26 +00:00
|
|
|
/* Nothing to do... */
|
2006-02-10 05:32:07 +00:00
|
|
|
}
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
static void dma_4v_sync_sg_for_cpu(struct device *dev,
|
|
|
|
struct scatterlist *sglist, int nelems,
|
|
|
|
enum dma_data_direction direction)
|
2006-02-10 05:32:07 +00:00
|
|
|
{
|
2006-02-10 08:08:26 +00:00
|
|
|
/* Nothing to do... */
|
2006-02-10 05:32:07 +00:00
|
|
|
}
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
const struct dma_ops sun4v_dma_ops = {
|
|
|
|
.alloc_coherent = dma_4v_alloc_coherent,
|
|
|
|
.free_coherent = dma_4v_free_coherent,
|
|
|
|
.map_single = dma_4v_map_single,
|
|
|
|
.unmap_single = dma_4v_unmap_single,
|
|
|
|
.map_sg = dma_4v_map_sg,
|
|
|
|
.unmap_sg = dma_4v_unmap_sg,
|
|
|
|
.sync_single_for_cpu = dma_4v_sync_single_for_cpu,
|
|
|
|
.sync_sg_for_cpu = dma_4v_sync_sg_for_cpu,
|
2006-02-10 05:32:07 +00:00
|
|
|
};
|
|
|
|
|
2008-01-22 01:22:46 +00:00
|
|
|
static void __init pci_sun4v_scan_bus(struct pci_pbm_info *pbm)
|
2006-02-10 06:05:54 +00:00
|
|
|
{
|
2006-06-22 01:18:47 +00:00
|
|
|
struct property *prop;
|
|
|
|
struct device_node *dp;
|
|
|
|
|
2007-05-08 06:06:27 +00:00
|
|
|
dp = pbm->prom_node;
|
|
|
|
prop = of_find_property(dp, "66mhz-capable", NULL);
|
|
|
|
pbm->is_66mhz_capable = (prop != NULL);
|
|
|
|
pbm->pci_bus = pci_scan_one_pbm(pbm);
|
2006-02-13 06:18:52 +00:00
|
|
|
|
|
|
|
/* XXX register error interrupt handlers XXX */
|
2006-02-10 06:05:54 +00:00
|
|
|
}
|
|
|
|
|
2008-02-05 11:01:43 +00:00
|
|
|
static unsigned long __init probe_existing_entries(struct pci_pbm_info *pbm,
|
|
|
|
struct iommu *iommu)
|
2006-02-10 08:08:26 +00:00
|
|
|
{
|
2007-04-25 06:51:18 +00:00
|
|
|
struct iommu_arena *arena = &iommu->arena;
|
2006-02-16 06:25:27 +00:00
|
|
|
unsigned long i, cnt = 0;
|
2006-02-14 05:50:27 +00:00
|
|
|
u32 devhandle;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
devhandle = pbm->devhandle;
|
|
|
|
for (i = 0; i < arena->limit; i++) {
|
|
|
|
unsigned long ret, io_attrs, ra;
|
|
|
|
|
|
|
|
ret = pci_sun4v_iommu_getmap(devhandle,
|
|
|
|
HV_PCI_TSBID(0, i),
|
|
|
|
&io_attrs, &ra);
|
2006-02-16 06:25:27 +00:00
|
|
|
if (ret == HV_EOK) {
|
2006-06-22 07:01:56 +00:00
|
|
|
if (page_in_phys_avail(ra)) {
|
|
|
|
pci_sun4v_iommu_demap(devhandle,
|
|
|
|
HV_PCI_TSBID(0, i), 1);
|
|
|
|
} else {
|
|
|
|
cnt++;
|
|
|
|
__set_bit(i, arena->map);
|
|
|
|
}
|
2006-02-16 06:25:27 +00:00
|
|
|
}
|
2006-02-10 08:08:26 +00:00
|
|
|
}
|
2006-02-16 06:25:27 +00:00
|
|
|
|
|
|
|
return cnt;
|
2006-02-10 08:08:26 +00:00
|
|
|
}
|
|
|
|
|
2008-02-05 11:01:43 +00:00
|
|
|
static void __init pci_sun4v_iommu_init(struct pci_pbm_info *pbm)
|
2006-02-10 06:05:54 +00:00
|
|
|
{
|
2007-04-27 04:08:21 +00:00
|
|
|
struct iommu *iommu = pbm->iommu;
|
2006-06-22 01:18:47 +00:00
|
|
|
struct property *prop;
|
2007-05-24 01:00:46 +00:00
|
|
|
unsigned long num_tsb_entries, sz, tsbsize;
|
2006-02-10 08:08:26 +00:00
|
|
|
u32 vdma[2], dma_mask, dma_offset;
|
2006-06-22 01:18:47 +00:00
|
|
|
|
|
|
|
prop = of_find_property(pbm->prom_node, "virtual-dma", NULL);
|
|
|
|
if (prop) {
|
|
|
|
u32 *val = prop->value;
|
2006-02-10 08:08:26 +00:00
|
|
|
|
2006-06-22 01:18:47 +00:00
|
|
|
vdma[0] = val[0];
|
|
|
|
vdma[1] = val[1];
|
|
|
|
} else {
|
2006-02-10 08:08:26 +00:00
|
|
|
/* No property, use default values. */
|
|
|
|
vdma[0] = 0x80000000;
|
|
|
|
vdma[1] = 0x80000000;
|
|
|
|
}
|
|
|
|
|
2007-05-24 01:00:46 +00:00
|
|
|
if ((vdma[0] | vdma[1]) & ~IO_PAGE_MASK) {
|
|
|
|
prom_printf("PCI-SUN4V: strange virtual-dma[%08x:%08x].\n",
|
|
|
|
vdma[0], vdma[1]);
|
|
|
|
prom_halt();
|
2006-02-10 08:08:26 +00:00
|
|
|
};
|
|
|
|
|
2007-05-24 01:00:46 +00:00
|
|
|
dma_mask = (roundup_pow_of_two(vdma[1]) - 1UL);
|
|
|
|
num_tsb_entries = vdma[1] / IO_PAGE_SIZE;
|
|
|
|
tsbsize = num_tsb_entries * sizeof(iopte_t);
|
2006-02-10 08:08:26 +00:00
|
|
|
|
|
|
|
dma_offset = vdma[0];
|
|
|
|
|
|
|
|
/* Setup initial software IOMMU state. */
|
|
|
|
spin_lock_init(&iommu->lock);
|
|
|
|
iommu->ctx_lowest_free = 1;
|
|
|
|
iommu->page_table_map_base = dma_offset;
|
|
|
|
iommu->dma_addr_mask = dma_mask;
|
|
|
|
|
|
|
|
/* Allocate and initialize the free area map. */
|
2007-05-24 01:00:46 +00:00
|
|
|
sz = (num_tsb_entries + 7) / 8;
|
2006-02-10 08:08:26 +00:00
|
|
|
sz = (sz + 7UL) & ~7UL;
|
2006-12-01 01:13:09 +00:00
|
|
|
iommu->arena.map = kzalloc(sz, GFP_KERNEL);
|
2006-02-10 08:08:26 +00:00
|
|
|
if (!iommu->arena.map) {
|
|
|
|
prom_printf("PCI_IOMMU: Error, kmalloc(arena.map) failed.\n");
|
|
|
|
prom_halt();
|
|
|
|
}
|
|
|
|
iommu->arena.limit = num_tsb_entries;
|
|
|
|
|
2006-02-16 06:25:27 +00:00
|
|
|
sz = probe_existing_entries(pbm, iommu);
|
2006-06-22 07:01:56 +00:00
|
|
|
if (sz)
|
|
|
|
printk("%s: Imported %lu TSB entries from OBP\n",
|
|
|
|
pbm->name, sz);
|
2006-02-10 06:05:54 +00:00
|
|
|
}
|
|
|
|
|
[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
|
|
|
#ifdef CONFIG_PCI_MSI
|
|
|
|
struct pci_sun4v_msiq_entry {
|
|
|
|
u64 version_type;
|
|
|
|
#define MSIQ_VERSION_MASK 0xffffffff00000000UL
|
|
|
|
#define MSIQ_VERSION_SHIFT 32
|
|
|
|
#define MSIQ_TYPE_MASK 0x00000000000000ffUL
|
|
|
|
#define MSIQ_TYPE_SHIFT 0
|
|
|
|
#define MSIQ_TYPE_NONE 0x00
|
|
|
|
#define MSIQ_TYPE_MSG 0x01
|
|
|
|
#define MSIQ_TYPE_MSI32 0x02
|
|
|
|
#define MSIQ_TYPE_MSI64 0x03
|
|
|
|
#define MSIQ_TYPE_INTX 0x08
|
|
|
|
#define MSIQ_TYPE_NONE2 0xff
|
|
|
|
|
|
|
|
u64 intx_sysino;
|
|
|
|
u64 reserved1;
|
|
|
|
u64 stick;
|
|
|
|
u64 req_id; /* bus/device/func */
|
|
|
|
#define MSIQ_REQID_BUS_MASK 0xff00UL
|
|
|
|
#define MSIQ_REQID_BUS_SHIFT 8
|
|
|
|
#define MSIQ_REQID_DEVICE_MASK 0x00f8UL
|
|
|
|
#define MSIQ_REQID_DEVICE_SHIFT 3
|
|
|
|
#define MSIQ_REQID_FUNC_MASK 0x0007UL
|
|
|
|
#define MSIQ_REQID_FUNC_SHIFT 0
|
|
|
|
|
|
|
|
u64 msi_address;
|
|
|
|
|
2007-05-11 20:52:08 +00:00
|
|
|
/* The format of this value is message type dependent.
|
[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
|
|
|
* For MSI bits 15:0 are the data from the MSI packet.
|
|
|
|
* For MSI-X bits 31:0 are the data from the MSI packet.
|
|
|
|
* For MSG, the message code and message routing code where:
|
|
|
|
* bits 39:32 is the bus/device/fn of the msg target-id
|
|
|
|
* bits 18:16 is the message routing code
|
|
|
|
* bits 7:0 is the message code
|
|
|
|
* For INTx the low order 2-bits are:
|
|
|
|
* 00 - INTA
|
|
|
|
* 01 - INTB
|
|
|
|
* 10 - INTC
|
|
|
|
* 11 - INTD
|
|
|
|
*/
|
|
|
|
u64 msi_data;
|
|
|
|
|
|
|
|
u64 reserved2;
|
|
|
|
};
|
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
static int pci_sun4v_get_head(struct pci_pbm_info *pbm, unsigned long msiqid,
|
|
|
|
unsigned long *head)
|
[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
|
|
|
{
|
2007-10-11 10:16:13 +00:00
|
|
|
unsigned long err, limit;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
err = pci_sun4v_msiq_gethead(pbm->devhandle, msiqid, head);
|
[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
|
|
|
if (unlikely(err))
|
2007-10-11 10:16:13 +00:00
|
|
|
return -ENXIO;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
limit = pbm->msiq_ent_count * sizeof(struct pci_sun4v_msiq_entry);
|
|
|
|
if (unlikely(*head >= limit))
|
|
|
|
return -EFBIG;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_sun4v_dequeue_msi(struct pci_pbm_info *pbm,
|
|
|
|
unsigned long msiqid, unsigned long *head,
|
|
|
|
unsigned long *msi)
|
|
|
|
{
|
|
|
|
struct pci_sun4v_msiq_entry *ep;
|
|
|
|
unsigned long err, type;
|
|
|
|
|
|
|
|
/* Note: void pointer arithmetic, 'head' is a byte offset */
|
|
|
|
ep = (pbm->msi_queues + ((msiqid - pbm->msiq_first) *
|
|
|
|
(pbm->msiq_ent_count *
|
|
|
|
sizeof(struct pci_sun4v_msiq_entry))) +
|
|
|
|
*head);
|
|
|
|
|
|
|
|
if ((ep->version_type & MSIQ_TYPE_MASK) == 0)
|
|
|
|
return 0;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
type = (ep->version_type & MSIQ_TYPE_MASK) >> MSIQ_TYPE_SHIFT;
|
|
|
|
if (unlikely(type != MSIQ_TYPE_MSI32 &&
|
|
|
|
type != MSIQ_TYPE_MSI64))
|
|
|
|
return -EINVAL;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
*msi = ep->msi_data;
|
|
|
|
|
|
|
|
err = pci_sun4v_msi_setstate(pbm->devhandle,
|
|
|
|
ep->msi_data /* msi_num */,
|
|
|
|
HV_MSISTATE_IDLE);
|
|
|
|
if (unlikely(err))
|
|
|
|
return -ENXIO;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
/* Clear the entry. */
|
|
|
|
ep->version_type &= ~MSIQ_TYPE_MASK;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
(*head) += sizeof(struct pci_sun4v_msiq_entry);
|
|
|
|
if (*head >=
|
|
|
|
(pbm->msiq_ent_count * sizeof(struct pci_sun4v_msiq_entry)))
|
|
|
|
*head = 0;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
return 1;
|
[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
|
|
|
}
|
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
static int pci_sun4v_set_head(struct pci_pbm_info *pbm, unsigned long msiqid,
|
|
|
|
unsigned long head)
|
[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
|
|
|
{
|
2007-10-11 10:16:13 +00:00
|
|
|
unsigned long err;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
err = pci_sun4v_msiq_sethead(pbm->devhandle, msiqid, head);
|
|
|
|
if (unlikely(err))
|
|
|
|
return -EINVAL;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
return 0;
|
|
|
|
}
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
static int pci_sun4v_msi_setup(struct pci_pbm_info *pbm, unsigned long msiqid,
|
|
|
|
unsigned long msi, int is_msi64)
|
|
|
|
{
|
|
|
|
if (pci_sun4v_msi_setmsiq(pbm->devhandle, msi, msiqid,
|
|
|
|
(is_msi64 ?
|
|
|
|
HV_MSITYPE_MSI64 : HV_MSITYPE_MSI32)))
|
|
|
|
return -ENXIO;
|
|
|
|
if (pci_sun4v_msi_setstate(pbm->devhandle, msi, HV_MSISTATE_IDLE))
|
|
|
|
return -ENXIO;
|
|
|
|
if (pci_sun4v_msi_setvalid(pbm->devhandle, msi, HV_MSIVALID_VALID))
|
|
|
|
return -ENXIO;
|
[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
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
static int pci_sun4v_msi_teardown(struct pci_pbm_info *pbm, unsigned long msi)
|
[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
|
|
|
{
|
2007-10-11 10:16:13 +00:00
|
|
|
unsigned long err, msiqid;
|
|
|
|
|
|
|
|
err = pci_sun4v_msi_getmsiq(pbm->devhandle, msi, &msiqid);
|
|
|
|
if (err)
|
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
pci_sun4v_msi_setvalid(pbm->devhandle, msi, HV_MSIVALID_INVALID);
|
|
|
|
|
|
|
|
return 0;
|
[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
|
|
|
}
|
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
static int pci_sun4v_msiq_alloc(struct pci_pbm_info *pbm)
|
[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 q_size, alloc_size, pages, order;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
q_size = pbm->msiq_ent_count * sizeof(struct pci_sun4v_msiq_entry);
|
|
|
|
alloc_size = (pbm->msiq_num * q_size);
|
|
|
|
order = get_order(alloc_size);
|
|
|
|
pages = __get_free_pages(GFP_KERNEL | __GFP_COMP, order);
|
|
|
|
if (pages == 0UL) {
|
|
|
|
printk(KERN_ERR "MSI: Cannot allocate MSI queues (o=%lu).\n",
|
|
|
|
order);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
memset((char *)pages, 0, PAGE_SIZE << order);
|
|
|
|
pbm->msi_queues = (void *) pages;
|
|
|
|
|
|
|
|
for (i = 0; i < pbm->msiq_num; i++) {
|
|
|
|
unsigned long err, base = __pa(pages + (i * q_size));
|
|
|
|
unsigned long ret1, ret2;
|
|
|
|
|
|
|
|
err = pci_sun4v_msiq_conf(pbm->devhandle,
|
|
|
|
pbm->msiq_first + i,
|
|
|
|
base, pbm->msiq_ent_count);
|
|
|
|
if (err) {
|
|
|
|
printk(KERN_ERR "MSI: msiq register fails (err=%lu)\n",
|
|
|
|
err);
|
|
|
|
goto h_error;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = pci_sun4v_msiq_info(pbm->devhandle,
|
|
|
|
pbm->msiq_first + i,
|
|
|
|
&ret1, &ret2);
|
|
|
|
if (err) {
|
|
|
|
printk(KERN_ERR "MSI: Cannot read msiq (err=%lu)\n",
|
|
|
|
err);
|
|
|
|
goto h_error;
|
|
|
|
}
|
|
|
|
if (ret1 != base || ret2 != pbm->msiq_ent_count) {
|
|
|
|
printk(KERN_ERR "MSI: Bogus qconf "
|
|
|
|
"expected[%lx:%x] got[%lx:%lx]\n",
|
|
|
|
base, pbm->msiq_ent_count,
|
|
|
|
ret1, ret2);
|
|
|
|
goto h_error;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
h_error:
|
|
|
|
free_pages(pages, order);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
static void pci_sun4v_msiq_free(struct pci_pbm_info *pbm)
|
[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
|
|
|
{
|
2007-10-11 10:16:13 +00:00
|
|
|
unsigned long q_size, alloc_size, pages, order;
|
[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
|
|
|
int i;
|
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
for (i = 0; i < pbm->msiq_num; i++) {
|
|
|
|
unsigned long msiqid = pbm->msiq_first + i;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
(void) pci_sun4v_msiq_conf(pbm->devhandle, msiqid, 0UL, 0);
|
[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
|
|
|
}
|
2007-04-18 09:39:21 +00:00
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
q_size = pbm->msiq_ent_count * sizeof(struct pci_sun4v_msiq_entry);
|
|
|
|
alloc_size = (pbm->msiq_num * q_size);
|
|
|
|
order = get_order(alloc_size);
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
pages = (unsigned long) pbm->msi_queues;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
free_pages(pages, order);
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
pbm->msi_queues = NULL;
|
[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
|
|
|
}
|
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
static int pci_sun4v_msiq_build_irq(struct pci_pbm_info *pbm,
|
|
|
|
unsigned long msiqid,
|
|
|
|
unsigned long devino)
|
[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
|
|
|
{
|
2007-10-11 10:16:13 +00:00
|
|
|
unsigned int virt_irq = sun4v_build_irq(pbm->devhandle, devino);
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
if (!virt_irq)
|
|
|
|
return -ENOMEM;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
if (pci_sun4v_msiq_setstate(pbm->devhandle, msiqid, HV_MSIQSTATE_IDLE))
|
|
|
|
return -EINVAL;
|
|
|
|
if (pci_sun4v_msiq_setvalid(pbm->devhandle, msiqid, HV_MSIQ_VALID))
|
|
|
|
return -EINVAL;
|
[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
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
return virt_irq;
|
[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
|
|
|
}
|
2007-05-08 06:28:50 +00:00
|
|
|
|
2007-10-11 10:16:13 +00:00
|
|
|
static const struct sparc64_msiq_ops pci_sun4v_msiq_ops = {
|
|
|
|
.get_head = pci_sun4v_get_head,
|
|
|
|
.dequeue_msi = pci_sun4v_dequeue_msi,
|
|
|
|
.set_head = pci_sun4v_set_head,
|
|
|
|
.msi_setup = pci_sun4v_msi_setup,
|
|
|
|
.msi_teardown = pci_sun4v_msi_teardown,
|
|
|
|
.msiq_alloc = pci_sun4v_msiq_alloc,
|
|
|
|
.msiq_free = pci_sun4v_msiq_free,
|
|
|
|
.msiq_build_irq = pci_sun4v_msiq_build_irq,
|
|
|
|
};
|
|
|
|
|
2007-05-08 06:28:50 +00:00
|
|
|
static void pci_sun4v_msi_init(struct pci_pbm_info *pbm)
|
|
|
|
{
|
2007-10-11 10:16:13 +00:00
|
|
|
sparc64_pbm_msi_init(pbm, &pci_sun4v_msiq_ops);
|
2007-05-08 06:28:50 +00:00
|
|
|
}
|
[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
|
|
|
#else /* CONFIG_PCI_MSI */
|
|
|
|
static void pci_sun4v_msi_init(struct pci_pbm_info *pbm)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif /* !(CONFIG_PCI_MSI) */
|
|
|
|
|
2008-01-22 01:22:46 +00:00
|
|
|
static void __init pci_sun4v_pbm_init(struct pci_controller_info *p,
|
|
|
|
struct device_node *dp, u32 devhandle)
|
2006-02-10 06:05:54 +00:00
|
|
|
{
|
|
|
|
struct pci_pbm_info *pbm;
|
|
|
|
|
2006-02-13 06:06:53 +00:00
|
|
|
if (devhandle & 0x40)
|
|
|
|
pbm = &p->pbm_B;
|
|
|
|
else
|
|
|
|
pbm = &p->pbm_A;
|
2006-02-10 06:05:54 +00:00
|
|
|
|
2007-05-08 06:06:27 +00:00
|
|
|
pbm->next = pci_pbm_root;
|
|
|
|
pci_pbm_root = pbm;
|
|
|
|
|
|
|
|
pbm->scan_bus = pci_sun4v_scan_bus;
|
2007-05-09 09:35:27 +00:00
|
|
|
pbm->pci_ops = &sun4v_pci_ops;
|
|
|
|
pbm->config_space_reg_bits = 12;
|
2007-05-08 06:06:27 +00:00
|
|
|
|
2007-05-08 06:49:01 +00:00
|
|
|
pbm->index = pci_num_pbms++;
|
|
|
|
|
2006-02-10 06:05:54 +00:00
|
|
|
pbm->parent = p;
|
2006-06-22 01:18:47 +00:00
|
|
|
pbm->prom_node = dp;
|
2006-02-10 06:05:54 +00:00
|
|
|
|
2006-02-13 06:06:53 +00:00
|
|
|
pbm->devhandle = devhandle;
|
2006-02-10 06:05:54 +00:00
|
|
|
|
2006-06-22 01:18:47 +00:00
|
|
|
pbm->name = dp->full_name;
|
2006-02-10 06:05:54 +00:00
|
|
|
|
2006-06-22 01:18:47 +00:00
|
|
|
printk("%s: SUN4V PCI Bus Module\n", pbm->name);
|
2006-02-10 06:05:54 +00:00
|
|
|
|
2007-03-09 05:55:49 +00:00
|
|
|
pci_determine_mem_io_space(pbm);
|
2006-02-10 06:05:54 +00:00
|
|
|
|
2007-05-08 04:51:41 +00:00
|
|
|
pci_get_pbm_props(pbm);
|
2006-02-10 06:05:54 +00:00
|
|
|
pci_sun4v_iommu_init(pbm);
|
[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
|
|
|
pci_sun4v_msi_init(pbm);
|
2006-02-10 06:05:54 +00:00
|
|
|
}
|
|
|
|
|
2007-07-21 00:19:56 +00:00
|
|
|
void __init sun4v_pci_init(struct device_node *dp, char *model_name)
|
2006-02-10 05:32:07 +00:00
|
|
|
{
|
2007-05-25 08:04:15 +00:00
|
|
|
static int hvapi_negotiated = 0;
|
2006-02-10 06:05:54 +00:00
|
|
|
struct pci_controller_info *p;
|
2007-05-08 06:06:27 +00:00
|
|
|
struct pci_pbm_info *pbm;
|
2007-04-27 04:08:21 +00:00
|
|
|
struct iommu *iommu;
|
2006-06-22 01:18:47 +00:00
|
|
|
struct property *prop;
|
|
|
|
struct linux_prom64_registers *regs;
|
2006-02-14 05:50:27 +00:00
|
|
|
u32 devhandle;
|
|
|
|
int i;
|
2006-02-13 06:06:53 +00:00
|
|
|
|
2007-05-25 08:04:15 +00:00
|
|
|
if (!hvapi_negotiated++) {
|
|
|
|
int err = sun4v_hvapi_register(HV_GRP_PCI,
|
|
|
|
vpci_major,
|
|
|
|
&vpci_minor);
|
|
|
|
|
|
|
|
if (err) {
|
|
|
|
prom_printf("SUN4V_PCI: Could not register hvapi, "
|
|
|
|
"err=%d\n", err);
|
|
|
|
prom_halt();
|
|
|
|
}
|
|
|
|
printk("SUN4V_PCI: Registered hvapi major[%lu] minor[%lu]\n",
|
|
|
|
vpci_major, vpci_minor);
|
2007-07-28 05:39:14 +00:00
|
|
|
|
|
|
|
dma_ops = &sun4v_dma_ops;
|
2007-05-25 08:04:15 +00:00
|
|
|
}
|
|
|
|
|
2006-06-22 01:18:47 +00:00
|
|
|
prop = of_find_property(dp, "reg", NULL);
|
2007-11-21 01:32:19 +00:00
|
|
|
if (!prop) {
|
|
|
|
prom_printf("SUN4V_PCI: Could not find config registers\n");
|
|
|
|
prom_halt();
|
|
|
|
}
|
2006-06-22 01:18:47 +00:00
|
|
|
regs = prop->value;
|
|
|
|
|
|
|
|
devhandle = (regs->phys_addr >> 32UL) & 0x0fffffff;
|
2006-02-13 06:06:53 +00:00
|
|
|
|
2007-05-08 06:06:27 +00:00
|
|
|
for (pbm = pci_pbm_root; pbm; pbm = pbm->next) {
|
2006-02-13 06:29:36 +00:00
|
|
|
if (pbm->devhandle == (devhandle ^ 0x40)) {
|
2007-05-08 06:06:27 +00:00
|
|
|
pci_sun4v_pbm_init(pbm->parent, dp, devhandle);
|
2006-02-13 06:29:36 +00:00
|
|
|
return;
|
|
|
|
}
|
2006-02-13 06:06:53 +00:00
|
|
|
}
|
2006-02-10 06:05:54 +00:00
|
|
|
|
2006-04-11 05:52:52 +00:00
|
|
|
for_each_possible_cpu(i) {
|
2006-02-14 05:50:27 +00:00
|
|
|
unsigned long page = get_zeroed_page(GFP_ATOMIC);
|
|
|
|
|
|
|
|
if (!page)
|
|
|
|
goto fatal_memory_error;
|
|
|
|
|
2007-07-28 05:39:14 +00:00
|
|
|
per_cpu(iommu_batch, i).pglist = (u64 *) page;
|
2006-02-10 06:05:54 +00:00
|
|
|
}
|
2006-02-14 05:50:27 +00:00
|
|
|
|
2006-12-01 01:13:09 +00:00
|
|
|
p = kzalloc(sizeof(struct pci_controller_info), GFP_ATOMIC);
|
2006-02-14 05:50:27 +00:00
|
|
|
if (!p)
|
|
|
|
goto fatal_memory_error;
|
|
|
|
|
2007-04-27 04:08:21 +00:00
|
|
|
iommu = kzalloc(sizeof(struct iommu), GFP_ATOMIC);
|
2006-02-14 05:50:27 +00:00
|
|
|
if (!iommu)
|
|
|
|
goto fatal_memory_error;
|
|
|
|
|
2006-02-10 06:05:54 +00:00
|
|
|
p->pbm_A.iommu = iommu;
|
|
|
|
|
2007-04-27 04:08:21 +00:00
|
|
|
iommu = kzalloc(sizeof(struct iommu), GFP_ATOMIC);
|
2006-02-14 05:50:27 +00:00
|
|
|
if (!iommu)
|
|
|
|
goto fatal_memory_error;
|
|
|
|
|
2006-02-10 06:05:54 +00:00
|
|
|
p->pbm_B.iommu = iommu;
|
|
|
|
|
2006-06-22 01:18:47 +00:00
|
|
|
pci_sun4v_pbm_init(p, dp, devhandle);
|
2006-02-14 05:50:27 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
fatal_memory_error:
|
|
|
|
prom_printf("SUN4V_PCI: Fatal memory allocation error.\n");
|
|
|
|
prom_halt();
|
2006-02-10 05:32:07 +00:00
|
|
|
}
|