2006-02-10 12:32:07 +07:00
|
|
|
/* pci_sun4v.c: SUN4V specific PCI controller support.
|
|
|
|
*
|
2008-02-09 09:05:46 +07:00
|
|
|
* Copyright (C) 2006, 2007, 2008 David S. Miller (davem@davemloft.net)
|
2006-02-10 12:32:07 +07: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 15:08:26 +07: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 08:41:02 +07:00
|
|
|
#include <linux/irq.h>
|
|
|
|
#include <linux/msi.h>
|
2011-07-19 02:57:46 +07:00
|
|
|
#include <linux/export.h>
|
2007-05-24 08:00:46 +07:00
|
|
|
#include <linux/log2.h>
|
2008-08-30 16:50:29 +07:00
|
|
|
#include <linux/of_device.h>
|
2015-04-10 02:33:31 +07:00
|
|
|
#include <linux/iommu-common.h>
|
2006-02-10 12:32:07 +07:00
|
|
|
|
|
|
|
#include <asm/iommu.h>
|
|
|
|
#include <asm/irq.h>
|
|
|
|
#include <asm/hypervisor.h>
|
2006-06-22 08:18:47 +07:00
|
|
|
#include <asm/prom.h>
|
2006-02-10 12:32:07 +07:00
|
|
|
|
|
|
|
#include "pci_impl.h"
|
|
|
|
#include "iommu_common.h"
|
|
|
|
|
2006-02-10 13:05:54 +07:00
|
|
|
#include "pci_sun4v.h"
|
|
|
|
|
2008-08-30 16:50:29 +07:00
|
|
|
#define DRIVER_NAME "pci_sun4v"
|
|
|
|
#define PFX DRIVER_NAME ": "
|
|
|
|
|
2016-09-29 02:19:45 +07:00
|
|
|
static unsigned long vpci_major;
|
|
|
|
static unsigned long vpci_minor;
|
|
|
|
|
|
|
|
struct vpci_version {
|
|
|
|
unsigned long major;
|
|
|
|
unsigned long minor;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Ordered from largest major to lowest */
|
|
|
|
static struct vpci_version vpci_versions[] = {
|
|
|
|
{ .major = 2, .minor = 0 },
|
|
|
|
{ .major = 1, .minor = 1 },
|
|
|
|
};
|
2007-05-25 15:04:15 +07:00
|
|
|
|
2016-10-29 00:12:41 +07:00
|
|
|
static unsigned long vatu_major = 1;
|
|
|
|
static unsigned long vatu_minor = 1;
|
|
|
|
|
2006-02-14 12:50:27 +07:00
|
|
|
#define PGLIST_NENTS (PAGE_SIZE / sizeof(u64))
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2007-04-27 11:08:21 +07:00
|
|
|
struct iommu_batch {
|
2007-07-28 12:39:14 +07:00
|
|
|
struct device *dev; /* Device mapping is for. */
|
2006-02-20 13:21:32 +07: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 15:08:26 +07:00
|
|
|
};
|
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
static DEFINE_PER_CPU(struct iommu_batch, iommu_batch);
|
2008-09-10 13:54:02 +07:00
|
|
|
static int iommu_batch_initialized;
|
2006-02-20 13:21:32 +07:00
|
|
|
|
|
|
|
/* Interrupts must be disabled. */
|
2007-07-28 12:39:14 +07:00
|
|
|
static inline void iommu_batch_start(struct device *dev, unsigned long prot, unsigned long entry)
|
2006-02-20 13:21:32 +07:00
|
|
|
{
|
sparc: Replace __get_cpu_var uses
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving data from the current
processors percpu area. __get_cpu_var() can be used as an lvalue when
writing data or on the right side of an assignment.
__get_cpu_var() is defined as :
#define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
__get_cpu_var() always only does an address determination. However, store
and retrieve operations could use a segment prefix (or global register on
other platforms) to avoid the address calculation.
this_cpu_write() and this_cpu_read() can directly take an offset into a
percpu area and use optimized assembly code to read and write per cpu
variables.
This patch converts __get_cpu_var into either an explicit address
calculation using this_cpu_ptr() or into a use of this_cpu operations that
use the offset. Thereby address calculations are avoided and less registers
are used when code is generated.
At the end of the patch set all uses of __get_cpu_var have been removed so
the macro is removed too.
The patch set includes passes over all arches as well. Once these operations
are used throughout then specialized macros can be defined in non -x86
arches as well in order to optimize per cpu access by f.e. using a global
register that may be set to the per cpu base.
Transformations done to __get_cpu_var()
1. Determine the address of the percpu instance of the current processor.
DEFINE_PER_CPU(int, y);
int *x = &__get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(&y);
2. Same as #1 but this time an array structure is involved.
DEFINE_PER_CPU(int, y[20]);
int *x = __get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(y);
3. Retrieve the content of the current processors instance of a per cpu
variable.
DEFINE_PER_CPU(int, y);
int x = __get_cpu_var(y)
Converts to
int x = __this_cpu_read(y);
4. Retrieve the content of a percpu struct
DEFINE_PER_CPU(struct mystruct, y);
struct mystruct x = __get_cpu_var(y);
Converts to
memcpy(&x, this_cpu_ptr(&y), sizeof(x));
5. Assignment to a per cpu variable
DEFINE_PER_CPU(int, y)
__get_cpu_var(y) = x;
Converts to
__this_cpu_write(y, x);
6. Increment/Decrement etc of a per cpu variable
DEFINE_PER_CPU(int, y);
__get_cpu_var(y)++
Converts to
__this_cpu_inc(y)
Cc: sparclinux@vger.kernel.org
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2014-08-18 00:30:54 +07:00
|
|
|
struct iommu_batch *p = this_cpu_ptr(&iommu_batch);
|
2006-02-20 13:21:32 +07:00
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
p->dev = dev;
|
2006-02-20 13:21:32 +07:00
|
|
|
p->prot = prot;
|
|
|
|
p->entry = entry;
|
|
|
|
p->npages = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Interrupts must be disabled. */
|
2007-07-28 12:39:14 +07:00
|
|
|
static long iommu_batch_flush(struct iommu_batch *p)
|
2006-02-20 13:21:32 +07:00
|
|
|
{
|
2007-07-28 12:39:14 +07:00
|
|
|
struct pci_pbm_info *pbm = p->dev->archdata.host_controller;
|
2007-03-01 14:35:04 +07:00
|
|
|
unsigned long devhandle = pbm->devhandle;
|
2006-02-20 13:21:32 +07:00
|
|
|
unsigned long prot = p->prot;
|
|
|
|
unsigned long entry = p->entry;
|
|
|
|
u64 *pglist = p->pglist;
|
|
|
|
unsigned long npages = p->npages;
|
|
|
|
|
2016-09-29 02:19:50 +07:00
|
|
|
/* VPCI maj=1, min=[0,1] only supports read and write */
|
|
|
|
if (vpci_major < 2)
|
|
|
|
prot &= (HV_PCI_MAP_ATTR_READ | HV_PCI_MAP_ATTR_WRITE);
|
|
|
|
|
2006-02-20 16:42:51 +07:00
|
|
|
while (npages != 0) {
|
2006-02-20 13:21:32 +07: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 12:39:14 +07:00
|
|
|
printk("iommu_batch_flush: IOMMU map of "
|
2009-01-07 04:19:28 +07:00
|
|
|
"[%08lx:%08llx:%lx:%lx:%lx] failed with "
|
2006-02-20 13:21:32 +07:00
|
|
|
"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 16:42:51 +07:00
|
|
|
}
|
2006-02-20 13:21:32 +07:00
|
|
|
|
|
|
|
p->entry = entry;
|
|
|
|
p->npages = 0;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
static inline void iommu_batch_new_entry(unsigned long entry)
|
|
|
|
{
|
sparc: Replace __get_cpu_var uses
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving data from the current
processors percpu area. __get_cpu_var() can be used as an lvalue when
writing data or on the right side of an assignment.
__get_cpu_var() is defined as :
#define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
__get_cpu_var() always only does an address determination. However, store
and retrieve operations could use a segment prefix (or global register on
other platforms) to avoid the address calculation.
this_cpu_write() and this_cpu_read() can directly take an offset into a
percpu area and use optimized assembly code to read and write per cpu
variables.
This patch converts __get_cpu_var into either an explicit address
calculation using this_cpu_ptr() or into a use of this_cpu operations that
use the offset. Thereby address calculations are avoided and less registers
are used when code is generated.
At the end of the patch set all uses of __get_cpu_var have been removed so
the macro is removed too.
The patch set includes passes over all arches as well. Once these operations
are used throughout then specialized macros can be defined in non -x86
arches as well in order to optimize per cpu access by f.e. using a global
register that may be set to the per cpu base.
Transformations done to __get_cpu_var()
1. Determine the address of the percpu instance of the current processor.
DEFINE_PER_CPU(int, y);
int *x = &__get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(&y);
2. Same as #1 but this time an array structure is involved.
DEFINE_PER_CPU(int, y[20]);
int *x = __get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(y);
3. Retrieve the content of the current processors instance of a per cpu
variable.
DEFINE_PER_CPU(int, y);
int x = __get_cpu_var(y)
Converts to
int x = __this_cpu_read(y);
4. Retrieve the content of a percpu struct
DEFINE_PER_CPU(struct mystruct, y);
struct mystruct x = __get_cpu_var(y);
Converts to
memcpy(&x, this_cpu_ptr(&y), sizeof(x));
5. Assignment to a per cpu variable
DEFINE_PER_CPU(int, y)
__get_cpu_var(y) = x;
Converts to
__this_cpu_write(y, x);
6. Increment/Decrement etc of a per cpu variable
DEFINE_PER_CPU(int, y);
__get_cpu_var(y)++
Converts to
__this_cpu_inc(y)
Cc: sparclinux@vger.kernel.org
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2014-08-18 00:30:54 +07:00
|
|
|
struct iommu_batch *p = this_cpu_ptr(&iommu_batch);
|
2008-02-09 18:11:01 +07:00
|
|
|
|
|
|
|
if (p->entry + p->npages == entry)
|
|
|
|
return;
|
|
|
|
if (p->entry != ~0UL)
|
|
|
|
iommu_batch_flush(p);
|
|
|
|
p->entry = entry;
|
|
|
|
}
|
|
|
|
|
2006-02-20 13:21:32 +07:00
|
|
|
/* Interrupts must be disabled. */
|
2007-07-28 12:39:14 +07:00
|
|
|
static inline long iommu_batch_add(u64 phys_page)
|
2006-02-20 13:21:32 +07:00
|
|
|
{
|
sparc: Replace __get_cpu_var uses
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving data from the current
processors percpu area. __get_cpu_var() can be used as an lvalue when
writing data or on the right side of an assignment.
__get_cpu_var() is defined as :
#define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
__get_cpu_var() always only does an address determination. However, store
and retrieve operations could use a segment prefix (or global register on
other platforms) to avoid the address calculation.
this_cpu_write() and this_cpu_read() can directly take an offset into a
percpu area and use optimized assembly code to read and write per cpu
variables.
This patch converts __get_cpu_var into either an explicit address
calculation using this_cpu_ptr() or into a use of this_cpu operations that
use the offset. Thereby address calculations are avoided and less registers
are used when code is generated.
At the end of the patch set all uses of __get_cpu_var have been removed so
the macro is removed too.
The patch set includes passes over all arches as well. Once these operations
are used throughout then specialized macros can be defined in non -x86
arches as well in order to optimize per cpu access by f.e. using a global
register that may be set to the per cpu base.
Transformations done to __get_cpu_var()
1. Determine the address of the percpu instance of the current processor.
DEFINE_PER_CPU(int, y);
int *x = &__get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(&y);
2. Same as #1 but this time an array structure is involved.
DEFINE_PER_CPU(int, y[20]);
int *x = __get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(y);
3. Retrieve the content of the current processors instance of a per cpu
variable.
DEFINE_PER_CPU(int, y);
int x = __get_cpu_var(y)
Converts to
int x = __this_cpu_read(y);
4. Retrieve the content of a percpu struct
DEFINE_PER_CPU(struct mystruct, y);
struct mystruct x = __get_cpu_var(y);
Converts to
memcpy(&x, this_cpu_ptr(&y), sizeof(x));
5. Assignment to a per cpu variable
DEFINE_PER_CPU(int, y)
__get_cpu_var(y) = x;
Converts to
__this_cpu_write(y, x);
6. Increment/Decrement etc of a per cpu variable
DEFINE_PER_CPU(int, y);
__get_cpu_var(y)++
Converts to
__this_cpu_inc(y)
Cc: sparclinux@vger.kernel.org
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2014-08-18 00:30:54 +07:00
|
|
|
struct iommu_batch *p = this_cpu_ptr(&iommu_batch);
|
2006-02-20 13:21:32 +07:00
|
|
|
|
|
|
|
BUG_ON(p->npages >= PGLIST_NENTS);
|
|
|
|
|
|
|
|
p->pglist[p->npages++] = phys_page;
|
|
|
|
if (p->npages == PGLIST_NENTS)
|
2007-07-28 12:39:14 +07:00
|
|
|
return iommu_batch_flush(p);
|
2006-02-20 13:21:32 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Interrupts must be disabled. */
|
2007-07-28 12:39:14 +07:00
|
|
|
static inline long iommu_batch_end(void)
|
2006-02-20 13:21:32 +07:00
|
|
|
{
|
sparc: Replace __get_cpu_var uses
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving data from the current
processors percpu area. __get_cpu_var() can be used as an lvalue when
writing data or on the right side of an assignment.
__get_cpu_var() is defined as :
#define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
__get_cpu_var() always only does an address determination. However, store
and retrieve operations could use a segment prefix (or global register on
other platforms) to avoid the address calculation.
this_cpu_write() and this_cpu_read() can directly take an offset into a
percpu area and use optimized assembly code to read and write per cpu
variables.
This patch converts __get_cpu_var into either an explicit address
calculation using this_cpu_ptr() or into a use of this_cpu operations that
use the offset. Thereby address calculations are avoided and less registers
are used when code is generated.
At the end of the patch set all uses of __get_cpu_var have been removed so
the macro is removed too.
The patch set includes passes over all arches as well. Once these operations
are used throughout then specialized macros can be defined in non -x86
arches as well in order to optimize per cpu access by f.e. using a global
register that may be set to the per cpu base.
Transformations done to __get_cpu_var()
1. Determine the address of the percpu instance of the current processor.
DEFINE_PER_CPU(int, y);
int *x = &__get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(&y);
2. Same as #1 but this time an array structure is involved.
DEFINE_PER_CPU(int, y[20]);
int *x = __get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(y);
3. Retrieve the content of the current processors instance of a per cpu
variable.
DEFINE_PER_CPU(int, y);
int x = __get_cpu_var(y)
Converts to
int x = __this_cpu_read(y);
4. Retrieve the content of a percpu struct
DEFINE_PER_CPU(struct mystruct, y);
struct mystruct x = __get_cpu_var(y);
Converts to
memcpy(&x, this_cpu_ptr(&y), sizeof(x));
5. Assignment to a per cpu variable
DEFINE_PER_CPU(int, y)
__get_cpu_var(y) = x;
Converts to
__this_cpu_write(y, x);
6. Increment/Decrement etc of a per cpu variable
DEFINE_PER_CPU(int, y);
__get_cpu_var(y)++
Converts to
__this_cpu_inc(y)
Cc: sparclinux@vger.kernel.org
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2014-08-18 00:30:54 +07:00
|
|
|
struct iommu_batch *p = this_cpu_ptr(&iommu_batch);
|
2006-02-20 13:21:32 +07:00
|
|
|
|
|
|
|
BUG_ON(p->npages >= PGLIST_NENTS);
|
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
return iommu_batch_flush(p);
|
2006-02-20 13:21:32 +07:00
|
|
|
}
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
static void *dma_4v_alloc_coherent(struct device *dev, size_t size,
|
2012-03-27 19:56:55 +07:00
|
|
|
dma_addr_t *dma_addrp, gfp_t gfp,
|
2016-08-04 03:46:00 +07:00
|
|
|
unsigned long attrs)
|
2006-02-10 12:32:07 +07:00
|
|
|
{
|
2006-02-14 12:50:27 +07:00
|
|
|
unsigned long flags, order, first_page, npages, n;
|
2016-09-29 02:19:50 +07:00
|
|
|
unsigned long prot = 0;
|
2008-03-19 18:52:48 +07:00
|
|
|
struct iommu *iommu;
|
|
|
|
struct page *page;
|
2006-02-10 15:08:26 +07:00
|
|
|
void *ret;
|
|
|
|
long entry;
|
2008-03-19 18:52:48 +07:00
|
|
|
int nid;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
|
|
|
size = IO_PAGE_ALIGN(size);
|
|
|
|
order = get_order(size);
|
2006-02-20 13:21:32 +07:00
|
|
|
if (unlikely(order >= MAX_ORDER))
|
2006-02-10 15:08:26 +07:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
npages = size >> IO_PAGE_SHIFT;
|
|
|
|
|
2016-09-29 02:19:50 +07:00
|
|
|
if (attrs & DMA_ATTR_WEAK_ORDERING)
|
|
|
|
prot = HV_PCI_MAP_ATTR_RELAXED_ORDER;
|
|
|
|
|
2008-03-19 18:52:48 +07:00
|
|
|
nid = dev->archdata.numa_node;
|
|
|
|
page = alloc_pages_node(nid, gfp, order);
|
|
|
|
if (unlikely(!page))
|
2006-02-10 15:08:26 +07:00
|
|
|
return NULL;
|
2006-02-16 13:25:27 +07:00
|
|
|
|
2008-03-19 18:52:48 +07:00
|
|
|
first_page = (unsigned long) page_address(page);
|
2006-02-10 15:08:26 +07:00
|
|
|
memset((char *)first_page, 0, PAGE_SIZE << order);
|
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
iommu = dev->archdata.iommu;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2015-04-10 02:33:31 +07:00
|
|
|
entry = iommu_tbl_range_alloc(dev, &iommu->tbl, npages, NULL,
|
|
|
|
(unsigned long)(-1), 0);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2015-11-05 02:30:57 +07:00
|
|
|
if (unlikely(entry == IOMMU_ERROR_CODE))
|
2008-02-09 09:05:46 +07:00
|
|
|
goto range_alloc_fail;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2015-04-10 02:33:31 +07:00
|
|
|
*dma_addrp = (iommu->tbl.table_map_base + (entry << IO_PAGE_SHIFT));
|
2006-02-10 15:08:26 +07:00
|
|
|
ret = (void *) first_page;
|
|
|
|
first_page = __pa(first_page);
|
|
|
|
|
2006-02-20 13:21:32 +07:00
|
|
|
local_irq_save(flags);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
iommu_batch_start(dev,
|
2016-09-29 02:19:50 +07:00
|
|
|
(HV_PCI_MAP_ATTR_READ | prot |
|
2007-07-28 12:39:14 +07:00
|
|
|
HV_PCI_MAP_ATTR_WRITE),
|
|
|
|
entry);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2006-02-20 13:21:32 +07:00
|
|
|
for (n = 0; n < npages; n++) {
|
2007-07-28 12:39:14 +07:00
|
|
|
long err = iommu_batch_add(first_page + (n * PAGE_SIZE));
|
2006-02-20 13:21:32 +07:00
|
|
|
if (unlikely(err < 0L))
|
|
|
|
goto iommu_map_fail;
|
|
|
|
}
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
if (unlikely(iommu_batch_end() < 0L))
|
2006-02-20 13:21:32 +07:00
|
|
|
goto iommu_map_fail;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2006-02-20 13:21:32 +07:00
|
|
|
local_irq_restore(flags);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
|
|
|
return ret;
|
2006-02-20 13:21:32 +07:00
|
|
|
|
|
|
|
iommu_map_fail:
|
2015-11-05 02:30:57 +07:00
|
|
|
iommu_tbl_range_free(&iommu->tbl, *dma_addrp, npages, IOMMU_ERROR_CODE);
|
2006-02-20 13:21:32 +07:00
|
|
|
|
2008-02-09 09:05:46 +07:00
|
|
|
range_alloc_fail:
|
2006-02-20 13:21:32 +07:00
|
|
|
free_pages(first_page, order);
|
|
|
|
return NULL;
|
2006-02-10 12:32:07 +07:00
|
|
|
}
|
|
|
|
|
2016-10-29 00:12:43 +07:00
|
|
|
unsigned long dma_4v_iotsb_bind(unsigned long devhandle,
|
|
|
|
unsigned long iotsb_num,
|
|
|
|
struct pci_bus *bus_dev)
|
|
|
|
{
|
|
|
|
struct pci_dev *pdev;
|
|
|
|
unsigned long err;
|
|
|
|
unsigned int bus;
|
|
|
|
unsigned int device;
|
|
|
|
unsigned int fun;
|
|
|
|
|
|
|
|
list_for_each_entry(pdev, &bus_dev->devices, bus_list) {
|
|
|
|
if (pdev->subordinate) {
|
|
|
|
/* No need to bind pci bridge */
|
|
|
|
dma_4v_iotsb_bind(devhandle, iotsb_num,
|
|
|
|
pdev->subordinate);
|
|
|
|
} else {
|
|
|
|
bus = bus_dev->number;
|
|
|
|
device = PCI_SLOT(pdev->devfn);
|
|
|
|
fun = PCI_FUNC(pdev->devfn);
|
|
|
|
err = pci_sun4v_iotsb_bind(devhandle, iotsb_num,
|
|
|
|
HV_PCI_DEVICE_BUILD(bus,
|
|
|
|
device,
|
|
|
|
fun));
|
|
|
|
|
|
|
|
/* If bind fails for one device it is going to fail
|
|
|
|
* for rest of the devices because we are sharing
|
|
|
|
* IOTSB. So in case of failure simply return with
|
|
|
|
* error.
|
|
|
|
*/
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-04-10 02:33:31 +07:00
|
|
|
static void dma_4v_iommu_demap(void *demap_arg, unsigned long entry,
|
|
|
|
unsigned long npages)
|
|
|
|
{
|
|
|
|
u32 devhandle = *(u32 *)demap_arg;
|
|
|
|
unsigned long num, flags;
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
do {
|
|
|
|
num = pci_sun4v_iommu_demap(devhandle,
|
|
|
|
HV_PCI_TSBID(0, entry),
|
|
|
|
npages);
|
|
|
|
|
|
|
|
entry += num;
|
|
|
|
npages -= num;
|
|
|
|
} while (npages != 0);
|
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
static void dma_4v_free_coherent(struct device *dev, size_t size, void *cpu,
|
2016-08-04 03:46:00 +07:00
|
|
|
dma_addr_t dvma, unsigned long attrs)
|
2006-02-10 12:32:07 +07:00
|
|
|
{
|
2007-03-01 14:35:04 +07:00
|
|
|
struct pci_pbm_info *pbm;
|
2007-04-27 11:08:21 +07:00
|
|
|
struct iommu *iommu;
|
2015-04-10 02:33:31 +07:00
|
|
|
unsigned long order, npages, entry;
|
2006-02-14 12:50:27 +07:00
|
|
|
u32 devhandle;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
|
|
|
npages = IO_PAGE_ALIGN(size) >> IO_PAGE_SHIFT;
|
2007-07-28 12:39:14 +07:00
|
|
|
iommu = dev->archdata.iommu;
|
|
|
|
pbm = dev->archdata.host_controller;
|
2007-03-01 14:35:04 +07:00
|
|
|
devhandle = pbm->devhandle;
|
2015-04-10 02:33:31 +07:00
|
|
|
entry = ((dvma - iommu->tbl.table_map_base) >> IO_PAGE_SHIFT);
|
|
|
|
dma_4v_iommu_demap(&devhandle, entry, npages);
|
2015-11-05 02:30:57 +07:00
|
|
|
iommu_tbl_range_free(&iommu->tbl, dvma, npages, IOMMU_ERROR_CODE);
|
2006-02-10 15:08:26 +07:00
|
|
|
order = get_order(size);
|
|
|
|
if (order < 10)
|
|
|
|
free_pages((unsigned long)cpu, order);
|
2006-02-10 12:32:07 +07:00
|
|
|
}
|
|
|
|
|
2009-05-14 23:23:10 +07:00
|
|
|
static dma_addr_t dma_4v_map_page(struct device *dev, struct page *page,
|
|
|
|
unsigned long offset, size_t sz,
|
2009-08-10 09:53:12 +07:00
|
|
|
enum dma_data_direction direction,
|
2016-08-04 03:46:00 +07:00
|
|
|
unsigned long attrs)
|
2006-02-10 12:32:07 +07:00
|
|
|
{
|
2007-04-27 11:08:21 +07:00
|
|
|
struct iommu *iommu;
|
2006-02-10 15:08:26 +07:00
|
|
|
unsigned long flags, npages, oaddr;
|
2006-02-14 12:50:27 +07:00
|
|
|
unsigned long i, base_paddr;
|
2006-02-20 13:21:32 +07:00
|
|
|
u32 bus_addr, ret;
|
2006-02-10 15:08:26 +07:00
|
|
|
unsigned long prot;
|
|
|
|
long entry;
|
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
iommu = dev->archdata.iommu;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
if (unlikely(direction == DMA_NONE))
|
2006-02-10 15:08:26 +07:00
|
|
|
goto bad;
|
|
|
|
|
2009-05-14 23:23:10 +07:00
|
|
|
oaddr = (unsigned long)(page_address(page) + offset);
|
2006-02-10 15:08:26 +07:00
|
|
|
npages = IO_PAGE_ALIGN(oaddr + sz) - (oaddr & IO_PAGE_MASK);
|
|
|
|
npages >>= IO_PAGE_SHIFT;
|
|
|
|
|
2015-04-10 02:33:31 +07:00
|
|
|
entry = iommu_tbl_range_alloc(dev, &iommu->tbl, npages, NULL,
|
|
|
|
(unsigned long)(-1), 0);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2015-11-05 02:30:57 +07:00
|
|
|
if (unlikely(entry == IOMMU_ERROR_CODE))
|
2006-02-10 15:08:26 +07:00
|
|
|
goto bad;
|
|
|
|
|
2015-04-10 02:33:31 +07:00
|
|
|
bus_addr = (iommu->tbl.table_map_base + (entry << IO_PAGE_SHIFT));
|
2006-02-10 15:08:26 +07:00
|
|
|
ret = bus_addr | (oaddr & ~IO_PAGE_MASK);
|
|
|
|
base_paddr = __pa(oaddr & IO_PAGE_MASK);
|
|
|
|
prot = HV_PCI_MAP_ATTR_READ;
|
2007-07-28 12:39:14 +07:00
|
|
|
if (direction != DMA_TO_DEVICE)
|
2006-02-10 15:08:26 +07:00
|
|
|
prot |= HV_PCI_MAP_ATTR_WRITE;
|
|
|
|
|
2016-09-29 02:19:50 +07:00
|
|
|
if (attrs & DMA_ATTR_WEAK_ORDERING)
|
|
|
|
prot |= HV_PCI_MAP_ATTR_RELAXED_ORDER;
|
|
|
|
|
2006-02-20 13:21:32 +07:00
|
|
|
local_irq_save(flags);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
iommu_batch_start(dev, prot, entry);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2006-02-20 13:21:32 +07:00
|
|
|
for (i = 0; i < npages; i++, base_paddr += IO_PAGE_SIZE) {
|
2007-07-28 12:39:14 +07:00
|
|
|
long err = iommu_batch_add(base_paddr);
|
2006-02-20 13:21:32 +07:00
|
|
|
if (unlikely(err < 0L))
|
|
|
|
goto iommu_map_fail;
|
|
|
|
}
|
2007-07-28 12:39:14 +07:00
|
|
|
if (unlikely(iommu_batch_end() < 0L))
|
2006-02-20 13:21:32 +07:00
|
|
|
goto iommu_map_fail;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2006-02-20 13:21:32 +07:00
|
|
|
local_irq_restore(flags);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
bad:
|
|
|
|
if (printk_ratelimit())
|
|
|
|
WARN_ON(1);
|
2007-07-28 12:39:14 +07:00
|
|
|
return DMA_ERROR_CODE;
|
2006-02-20 13:21:32 +07:00
|
|
|
|
|
|
|
iommu_map_fail:
|
2015-11-05 02:30:57 +07:00
|
|
|
iommu_tbl_range_free(&iommu->tbl, bus_addr, npages, IOMMU_ERROR_CODE);
|
2007-07-28 12:39:14 +07:00
|
|
|
return DMA_ERROR_CODE;
|
2006-02-10 12:32:07 +07:00
|
|
|
}
|
|
|
|
|
2009-05-14 23:23:10 +07:00
|
|
|
static void dma_4v_unmap_page(struct device *dev, dma_addr_t bus_addr,
|
2009-08-10 09:53:12 +07:00
|
|
|
size_t sz, enum dma_data_direction direction,
|
2016-08-04 03:46:00 +07:00
|
|
|
unsigned long attrs)
|
2006-02-10 12:32:07 +07:00
|
|
|
{
|
2007-03-01 14:35:04 +07:00
|
|
|
struct pci_pbm_info *pbm;
|
2007-04-27 11:08:21 +07:00
|
|
|
struct iommu *iommu;
|
2015-04-10 02:33:31 +07:00
|
|
|
unsigned long npages;
|
2006-02-10 15:08:26 +07:00
|
|
|
long entry;
|
2006-02-14 12:50:27 +07:00
|
|
|
u32 devhandle;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
if (unlikely(direction == DMA_NONE)) {
|
2006-02-10 15:08:26 +07:00
|
|
|
if (printk_ratelimit())
|
|
|
|
WARN_ON(1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
iommu = dev->archdata.iommu;
|
|
|
|
pbm = dev->archdata.host_controller;
|
2007-03-01 14:35:04 +07:00
|
|
|
devhandle = pbm->devhandle;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
|
|
|
npages = IO_PAGE_ALIGN(bus_addr + sz) - (bus_addr & IO_PAGE_MASK);
|
|
|
|
npages >>= IO_PAGE_SHIFT;
|
|
|
|
bus_addr &= IO_PAGE_MASK;
|
2015-04-10 02:33:31 +07:00
|
|
|
entry = (bus_addr - iommu->tbl.table_map_base) >> IO_PAGE_SHIFT;
|
|
|
|
dma_4v_iommu_demap(&devhandle, entry, npages);
|
2015-11-05 02:30:57 +07:00
|
|
|
iommu_tbl_range_free(&iommu->tbl, bus_addr, npages, IOMMU_ERROR_CODE);
|
2006-02-10 15:08:26 +07:00
|
|
|
}
|
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
static int dma_4v_map_sg(struct device *dev, struct scatterlist *sglist,
|
2009-08-10 09:53:12 +07:00
|
|
|
int nelems, enum dma_data_direction direction,
|
2016-08-04 03:46:00 +07:00
|
|
|
unsigned long attrs)
|
2006-02-10 12:32:07 +07:00
|
|
|
{
|
2008-02-09 18:11:01 +07:00
|
|
|
struct scatterlist *s, *outs, *segstart;
|
|
|
|
unsigned long flags, handle, prot;
|
|
|
|
dma_addr_t dma_next = 0, dma_addr;
|
|
|
|
unsigned int max_seg_size;
|
2008-03-29 05:55:41 +07:00
|
|
|
unsigned long seg_boundary_size;
|
2008-02-09 18:11:01 +07:00
|
|
|
int outcount, incount, i;
|
2007-04-27 11:08:21 +07:00
|
|
|
struct iommu *iommu;
|
2008-03-29 05:55:41 +07:00
|
|
|
unsigned long base_shift;
|
2008-02-09 18:11:01 +07:00
|
|
|
long err;
|
|
|
|
|
|
|
|
BUG_ON(direction == DMA_NONE);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
iommu = dev->archdata.iommu;
|
2008-02-09 18:11:01 +07:00
|
|
|
if (nelems == 0 || !iommu)
|
|
|
|
return 0;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
prot = HV_PCI_MAP_ATTR_READ;
|
|
|
|
if (direction != DMA_TO_DEVICE)
|
|
|
|
prot |= HV_PCI_MAP_ATTR_WRITE;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2016-09-29 02:19:50 +07:00
|
|
|
if (attrs & DMA_ATTR_WEAK_ORDERING)
|
|
|
|
prot |= HV_PCI_MAP_ATTR_RELAXED_ORDER;
|
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
outs = s = segstart = &sglist[0];
|
|
|
|
outcount = 1;
|
|
|
|
incount = nelems;
|
|
|
|
handle = 0;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
/* Init first segment length for backout at failure */
|
|
|
|
outs->dma_length = 0;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2015-04-10 02:33:31 +07:00
|
|
|
local_irq_save(flags);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
iommu_batch_start(dev, prot, ~0UL);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
max_seg_size = dma_get_max_seg_size(dev);
|
2008-03-29 05:55:41 +07:00
|
|
|
seg_boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
|
|
|
|
IO_PAGE_SIZE) >> IO_PAGE_SHIFT;
|
2015-04-10 02:33:31 +07:00
|
|
|
base_shift = iommu->tbl.table_map_base >> IO_PAGE_SHIFT;
|
2008-02-09 18:11:01 +07:00
|
|
|
for_each_sg(sglist, s, nelems, i) {
|
2008-03-29 05:55:41 +07:00
|
|
|
unsigned long paddr, npages, entry, out_entry = 0, slen;
|
2008-02-06 18:50:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
slen = s->length;
|
|
|
|
/* Sanity check */
|
|
|
|
if (slen == 0) {
|
|
|
|
dma_next = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
/* Allocate iommu entries for that segment */
|
|
|
|
paddr = (unsigned long) SG_ENT_PHYS_ADDRESS(s);
|
2008-10-16 12:02:14 +07:00
|
|
|
npages = iommu_num_pages(paddr, slen, IO_PAGE_SIZE);
|
2015-04-10 02:33:31 +07:00
|
|
|
entry = iommu_tbl_range_alloc(dev, &iommu->tbl, npages,
|
|
|
|
&handle, (unsigned long)(-1), 0);
|
2008-02-06 18:50:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
/* Handle failure */
|
2015-11-05 02:30:57 +07:00
|
|
|
if (unlikely(entry == IOMMU_ERROR_CODE)) {
|
2008-02-09 18:11:01 +07:00
|
|
|
if (printk_ratelimit())
|
|
|
|
printk(KERN_INFO "iommu_alloc failed, iommu %p paddr %lx"
|
|
|
|
" npages %lx\n", iommu, paddr, npages);
|
|
|
|
goto iommu_map_failed;
|
|
|
|
}
|
2008-02-06 18:50:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
iommu_batch_new_entry(entry);
|
2008-02-06 18:50:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
/* Convert entry to a dma_addr_t */
|
2015-04-10 02:33:31 +07:00
|
|
|
dma_addr = iommu->tbl.table_map_base + (entry << IO_PAGE_SHIFT);
|
2008-02-09 18:11:01 +07:00
|
|
|
dma_addr |= (s->offset & ~IO_PAGE_MASK);
|
2008-02-06 18:50:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
/* Insert into HW table */
|
2008-02-06 18:50:26 +07:00
|
|
|
paddr &= IO_PAGE_MASK;
|
2008-02-09 18:11:01 +07:00
|
|
|
while (npages--) {
|
2008-02-06 18:50:26 +07:00
|
|
|
err = iommu_batch_add(paddr);
|
2008-02-09 18:11:01 +07:00
|
|
|
if (unlikely(err < 0L))
|
2008-02-06 18:50:26 +07:00
|
|
|
goto iommu_map_failed;
|
2008-02-09 18:11:01 +07:00
|
|
|
paddr += IO_PAGE_SIZE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If we are in an open segment, try merging */
|
|
|
|
if (segstart != s) {
|
|
|
|
/* We cannot merge if:
|
|
|
|
* - allocated dma_addr isn't contiguous to previous allocation
|
|
|
|
*/
|
|
|
|
if ((dma_addr != dma_next) ||
|
2008-03-29 05:55:41 +07:00
|
|
|
(outs->dma_length + s->length > max_seg_size) ||
|
|
|
|
(is_span_boundary(out_entry, base_shift,
|
|
|
|
seg_boundary_size, outs, s))) {
|
2008-02-09 18:11:01 +07:00
|
|
|
/* Can't merge: create a new segment */
|
|
|
|
segstart = s;
|
|
|
|
outcount++;
|
|
|
|
outs = sg_next(outs);
|
|
|
|
} else {
|
|
|
|
outs->dma_length += s->length;
|
2008-02-06 18:50:26 +07:00
|
|
|
}
|
2008-02-09 18:11:01 +07:00
|
|
|
}
|
2008-02-06 18:50:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
if (segstart == s) {
|
|
|
|
/* This is a new segment, fill entries */
|
|
|
|
outs->dma_address = dma_addr;
|
|
|
|
outs->dma_length = slen;
|
2008-03-29 05:55:41 +07:00
|
|
|
out_entry = entry;
|
2008-02-06 18:50:26 +07:00
|
|
|
}
|
2008-02-09 18:11:01 +07:00
|
|
|
|
|
|
|
/* Calculate next page pointer for contiguous check */
|
|
|
|
dma_next = dma_addr + slen;
|
2008-02-06 18:50:26 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
err = iommu_batch_end();
|
|
|
|
|
2006-02-20 13:21:32 +07:00
|
|
|
if (unlikely(err < 0L))
|
|
|
|
goto iommu_map_failed;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2015-04-10 02:33:31 +07:00
|
|
|
local_irq_restore(flags);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
if (outcount < incount) {
|
|
|
|
outs = sg_next(outs);
|
|
|
|
outs->dma_address = DMA_ERROR_CODE;
|
|
|
|
outs->dma_length = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return outcount;
|
2006-02-20 13:21:32 +07:00
|
|
|
|
|
|
|
iommu_map_failed:
|
2008-02-09 18:11:01 +07:00
|
|
|
for_each_sg(sglist, s, nelems, i) {
|
|
|
|
if (s->dma_length != 0) {
|
|
|
|
unsigned long vaddr, npages;
|
|
|
|
|
|
|
|
vaddr = s->dma_address & IO_PAGE_MASK;
|
2008-10-16 12:02:14 +07:00
|
|
|
npages = iommu_num_pages(s->dma_address, s->dma_length,
|
|
|
|
IO_PAGE_SIZE);
|
2015-04-10 02:33:31 +07:00
|
|
|
iommu_tbl_range_free(&iommu->tbl, vaddr, npages,
|
2015-11-05 02:30:57 +07:00
|
|
|
IOMMU_ERROR_CODE);
|
2008-02-09 18:11:01 +07:00
|
|
|
/* XXX demap? XXX */
|
|
|
|
s->dma_address = DMA_ERROR_CODE;
|
|
|
|
s->dma_length = 0;
|
|
|
|
}
|
|
|
|
if (s == outs)
|
|
|
|
break;
|
|
|
|
}
|
2015-04-10 02:33:31 +07:00
|
|
|
local_irq_restore(flags);
|
2006-02-20 13:21:32 +07:00
|
|
|
|
|
|
|
return 0;
|
2006-02-10 12:32:07 +07:00
|
|
|
}
|
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
static void dma_4v_unmap_sg(struct device *dev, struct scatterlist *sglist,
|
2009-08-10 09:53:12 +07:00
|
|
|
int nelems, enum dma_data_direction direction,
|
2016-08-04 03:46:00 +07:00
|
|
|
unsigned long attrs)
|
2006-02-10 12:32:07 +07:00
|
|
|
{
|
2007-03-01 14:35:04 +07:00
|
|
|
struct pci_pbm_info *pbm;
|
2008-02-09 18:11:01 +07:00
|
|
|
struct scatterlist *sg;
|
2007-04-27 11:08:21 +07:00
|
|
|
struct iommu *iommu;
|
2015-04-10 02:33:31 +07:00
|
|
|
unsigned long flags, entry;
|
2008-02-09 18:11:01 +07:00
|
|
|
u32 devhandle;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
BUG_ON(direction == DMA_NONE);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
iommu = dev->archdata.iommu;
|
|
|
|
pbm = dev->archdata.host_controller;
|
2007-03-01 14:35:04 +07:00
|
|
|
devhandle = pbm->devhandle;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2015-04-10 02:33:31 +07:00
|
|
|
local_irq_save(flags);
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
sg = sglist;
|
|
|
|
while (nelems--) {
|
|
|
|
dma_addr_t dma_handle = sg->dma_address;
|
|
|
|
unsigned int len = sg->dma_length;
|
2015-04-10 02:33:31 +07:00
|
|
|
unsigned long npages;
|
|
|
|
struct iommu_map_table *tbl = &iommu->tbl;
|
|
|
|
unsigned long shift = IO_PAGE_SHIFT;
|
2008-02-09 18:11:01 +07:00
|
|
|
|
|
|
|
if (!len)
|
|
|
|
break;
|
2008-10-16 12:02:14 +07:00
|
|
|
npages = iommu_num_pages(dma_handle, len, IO_PAGE_SIZE);
|
2015-04-10 02:33:31 +07:00
|
|
|
entry = ((dma_handle - tbl->table_map_base) >> shift);
|
|
|
|
dma_4v_iommu_demap(&devhandle, entry, npages);
|
|
|
|
iommu_tbl_range_free(&iommu->tbl, dma_handle, npages,
|
2015-11-05 02:30:57 +07:00
|
|
|
IOMMU_ERROR_CODE);
|
2008-02-09 18:11:01 +07:00
|
|
|
sg = sg_next(sg);
|
|
|
|
}
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2015-04-10 02:33:31 +07:00
|
|
|
local_irq_restore(flags);
|
2006-02-10 12:32:07 +07:00
|
|
|
}
|
|
|
|
|
2009-08-10 09:53:13 +07:00
|
|
|
static struct dma_map_ops sun4v_dma_ops = {
|
2012-03-27 19:56:55 +07:00
|
|
|
.alloc = dma_4v_alloc_coherent,
|
|
|
|
.free = dma_4v_free_coherent,
|
2009-05-14 23:23:10 +07:00
|
|
|
.map_page = dma_4v_map_page,
|
|
|
|
.unmap_page = dma_4v_unmap_page,
|
2007-07-28 12:39:14 +07:00
|
|
|
.map_sg = dma_4v_map_sg,
|
|
|
|
.unmap_sg = dma_4v_unmap_sg,
|
2006-02-10 12:32:07 +07:00
|
|
|
};
|
|
|
|
|
2012-12-22 05:03:26 +07:00
|
|
|
static void pci_sun4v_scan_bus(struct pci_pbm_info *pbm, struct device *parent)
|
2006-02-10 13:05:54 +07:00
|
|
|
{
|
2006-06-22 08:18:47 +07:00
|
|
|
struct property *prop;
|
|
|
|
struct device_node *dp;
|
|
|
|
|
2010-04-14 06:12:29 +07:00
|
|
|
dp = pbm->op->dev.of_node;
|
2007-05-08 13:06:27 +07:00
|
|
|
prop = of_find_property(dp, "66mhz-capable", NULL);
|
|
|
|
pbm->is_66mhz_capable = (prop != NULL);
|
2008-09-02 08:32:22 +07:00
|
|
|
pbm->pci_bus = pci_scan_one_pbm(pbm, parent);
|
2006-02-13 13:18:52 +07:00
|
|
|
|
|
|
|
/* XXX register error interrupt handlers XXX */
|
2006-02-10 13:05:54 +07:00
|
|
|
}
|
|
|
|
|
2012-12-22 05:03:26 +07:00
|
|
|
static unsigned long probe_existing_entries(struct pci_pbm_info *pbm,
|
2015-04-10 02:33:31 +07:00
|
|
|
struct iommu_map_table *iommu)
|
2006-02-10 15:08:26 +07:00
|
|
|
{
|
2015-04-10 02:33:31 +07:00
|
|
|
struct iommu_pool *pool;
|
|
|
|
unsigned long i, pool_nr, cnt = 0;
|
2006-02-14 12:50:27 +07:00
|
|
|
u32 devhandle;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
|
|
|
devhandle = pbm->devhandle;
|
2015-04-10 02:33:31 +07:00
|
|
|
for (pool_nr = 0; pool_nr < iommu->nr_pools; pool_nr++) {
|
|
|
|
pool = &(iommu->pools[pool_nr]);
|
|
|
|
for (i = pool->start; i <= pool->end; i++) {
|
|
|
|
unsigned long ret, io_attrs, ra;
|
|
|
|
|
|
|
|
ret = pci_sun4v_iommu_getmap(devhandle,
|
|
|
|
HV_PCI_TSBID(0, i),
|
|
|
|
&io_attrs, &ra);
|
|
|
|
if (ret == HV_EOK) {
|
|
|
|
if (page_in_phys_avail(ra)) {
|
|
|
|
pci_sun4v_iommu_demap(devhandle,
|
|
|
|
HV_PCI_TSBID(0,
|
|
|
|
i), 1);
|
|
|
|
} else {
|
|
|
|
cnt++;
|
|
|
|
__set_bit(i, iommu->map);
|
|
|
|
}
|
2006-06-22 14:01:56 +07:00
|
|
|
}
|
2006-02-16 13:25:27 +07:00
|
|
|
}
|
2006-02-10 15:08:26 +07:00
|
|
|
}
|
2006-02-16 13:25:27 +07:00
|
|
|
return cnt;
|
2006-02-10 15:08:26 +07:00
|
|
|
}
|
|
|
|
|
2016-10-29 00:12:41 +07:00
|
|
|
static int pci_sun4v_atu_alloc_iotsb(struct pci_pbm_info *pbm)
|
|
|
|
{
|
|
|
|
struct atu *atu = pbm->iommu->atu;
|
|
|
|
struct atu_iotsb *iotsb;
|
|
|
|
void *table;
|
|
|
|
u64 table_size;
|
|
|
|
u64 iotsb_num;
|
|
|
|
unsigned long order;
|
|
|
|
unsigned long err;
|
|
|
|
|
|
|
|
iotsb = kzalloc(sizeof(*iotsb), GFP_KERNEL);
|
|
|
|
if (!iotsb) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto out_err;
|
|
|
|
}
|
|
|
|
atu->iotsb = iotsb;
|
|
|
|
|
|
|
|
/* calculate size of IOTSB */
|
|
|
|
table_size = (atu->size / IO_PAGE_SIZE) * 8;
|
|
|
|
order = get_order(table_size);
|
|
|
|
table = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
|
|
|
|
if (!table) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto table_failed;
|
|
|
|
}
|
|
|
|
iotsb->table = table;
|
|
|
|
iotsb->ra = __pa(table);
|
|
|
|
iotsb->dvma_size = atu->size;
|
|
|
|
iotsb->dvma_base = atu->base;
|
|
|
|
iotsb->table_size = table_size;
|
|
|
|
iotsb->page_size = IO_PAGE_SIZE;
|
|
|
|
|
|
|
|
/* configure and register IOTSB with HV */
|
|
|
|
err = pci_sun4v_iotsb_conf(pbm->devhandle,
|
|
|
|
iotsb->ra,
|
|
|
|
iotsb->table_size,
|
|
|
|
iotsb->page_size,
|
|
|
|
iotsb->dvma_base,
|
|
|
|
&iotsb_num);
|
|
|
|
if (err) {
|
|
|
|
pr_err(PFX "pci_iotsb_conf failed error: %ld\n", err);
|
|
|
|
goto iotsb_conf_failed;
|
|
|
|
}
|
|
|
|
iotsb->iotsb_num = iotsb_num;
|
|
|
|
|
2016-10-29 00:12:43 +07:00
|
|
|
err = dma_4v_iotsb_bind(pbm->devhandle, iotsb_num, pbm->pci_bus);
|
|
|
|
if (err) {
|
|
|
|
pr_err(PFX "pci_iotsb_bind failed error: %ld\n", err);
|
|
|
|
goto iotsb_conf_failed;
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:12:41 +07:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
iotsb_conf_failed:
|
|
|
|
free_pages((unsigned long)table, order);
|
|
|
|
table_failed:
|
|
|
|
kfree(iotsb);
|
|
|
|
out_err:
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pci_sun4v_atu_init(struct pci_pbm_info *pbm)
|
|
|
|
{
|
|
|
|
struct atu *atu = pbm->iommu->atu;
|
|
|
|
unsigned long err;
|
|
|
|
const u64 *ranges;
|
2016-10-29 00:12:42 +07:00
|
|
|
u64 map_size, num_iotte;
|
|
|
|
u64 dma_mask;
|
2016-10-29 00:12:41 +07:00
|
|
|
const u32 *page_size;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
ranges = of_get_property(pbm->op->dev.of_node, "iommu-address-ranges",
|
|
|
|
&len);
|
|
|
|
if (!ranges) {
|
|
|
|
pr_err(PFX "No iommu-address-ranges\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
page_size = of_get_property(pbm->op->dev.of_node, "iommu-pagesizes",
|
|
|
|
NULL);
|
|
|
|
if (!page_size) {
|
|
|
|
pr_err(PFX "No iommu-pagesizes\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* There are 4 iommu-address-ranges supported. Each range is pair of
|
|
|
|
* {base, size}. The ranges[0] and ranges[1] are 32bit address space
|
|
|
|
* while ranges[2] and ranges[3] are 64bit space. We want to use 64bit
|
|
|
|
* address ranges to support 64bit addressing. Because 'size' for
|
|
|
|
* address ranges[2] and ranges[3] are same we can select either of
|
|
|
|
* ranges[2] or ranges[3] for mapping. However due to 'size' is too
|
|
|
|
* large for OS to allocate IOTSB we are using fix size 32G
|
|
|
|
* (ATU_64_SPACE_SIZE) which is more than enough for all PCIe devices
|
|
|
|
* to share.
|
|
|
|
*/
|
|
|
|
atu->ranges = (struct atu_ranges *)ranges;
|
|
|
|
atu->base = atu->ranges[3].base;
|
|
|
|
atu->size = ATU_64_SPACE_SIZE;
|
|
|
|
|
|
|
|
/* Create IOTSB */
|
|
|
|
err = pci_sun4v_atu_alloc_iotsb(pbm);
|
|
|
|
if (err) {
|
|
|
|
pr_err(PFX "Error creating ATU IOTSB\n");
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:12:42 +07:00
|
|
|
/* Create ATU iommu map.
|
|
|
|
* One bit represents one iotte in IOTSB table.
|
|
|
|
*/
|
|
|
|
dma_mask = (roundup_pow_of_two(atu->size) - 1UL);
|
|
|
|
num_iotte = atu->size / IO_PAGE_SIZE;
|
|
|
|
map_size = num_iotte / 8;
|
|
|
|
atu->tbl.table_map_base = atu->base;
|
|
|
|
atu->dma_addr_mask = dma_mask;
|
|
|
|
atu->tbl.map = kzalloc(map_size, GFP_KERNEL);
|
|
|
|
if (!atu->tbl.map)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
iommu_tbl_pool_init(&atu->tbl, num_iotte, IO_PAGE_SHIFT,
|
|
|
|
NULL, false /* no large_pool */,
|
|
|
|
0 /* default npools */,
|
|
|
|
false /* want span boundary checking */);
|
|
|
|
|
2016-10-29 00:12:41 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-12-22 05:03:26 +07:00
|
|
|
static int pci_sun4v_iommu_init(struct pci_pbm_info *pbm)
|
2006-02-10 13:05:54 +07:00
|
|
|
{
|
2008-09-02 10:23:18 +07:00
|
|
|
static const u32 vdma_default[] = { 0x80000000, 0x80000000 };
|
2007-04-27 11:08:21 +07:00
|
|
|
struct iommu *iommu = pbm->iommu;
|
2011-02-27 14:40:02 +07:00
|
|
|
unsigned long num_tsb_entries, sz;
|
2008-09-02 10:23:18 +07:00
|
|
|
u32 dma_mask, dma_offset;
|
|
|
|
const u32 *vdma;
|
|
|
|
|
2010-04-14 06:12:29 +07:00
|
|
|
vdma = of_get_property(pbm->op->dev.of_node, "virtual-dma", NULL);
|
2008-09-02 10:23:18 +07:00
|
|
|
if (!vdma)
|
|
|
|
vdma = vdma_default;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2007-05-24 08:00:46 +07:00
|
|
|
if ((vdma[0] | vdma[1]) & ~IO_PAGE_MASK) {
|
2008-08-30 16:50:29 +07:00
|
|
|
printk(KERN_ERR PFX "Strange virtual-dma[%08x:%08x].\n",
|
|
|
|
vdma[0], vdma[1]);
|
|
|
|
return -EINVAL;
|
2012-09-12 14:03:11 +07:00
|
|
|
}
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2007-05-24 08:00:46 +07:00
|
|
|
dma_mask = (roundup_pow_of_two(vdma[1]) - 1UL);
|
|
|
|
num_tsb_entries = vdma[1] / IO_PAGE_SIZE;
|
2006-02-10 15:08:26 +07:00
|
|
|
|
|
|
|
dma_offset = vdma[0];
|
|
|
|
|
|
|
|
/* Setup initial software IOMMU state. */
|
2015-04-19 02:31:25 +07:00
|
|
|
spin_lock_init(&iommu->lock);
|
2006-02-10 15:08:26 +07:00
|
|
|
iommu->ctx_lowest_free = 1;
|
2015-04-10 02:33:31 +07:00
|
|
|
iommu->tbl.table_map_base = dma_offset;
|
2006-02-10 15:08:26 +07:00
|
|
|
iommu->dma_addr_mask = dma_mask;
|
|
|
|
|
|
|
|
/* Allocate and initialize the free area map. */
|
2007-05-24 08:00:46 +07:00
|
|
|
sz = (num_tsb_entries + 7) / 8;
|
2006-02-10 15:08:26 +07:00
|
|
|
sz = (sz + 7UL) & ~7UL;
|
2015-04-10 02:33:31 +07:00
|
|
|
iommu->tbl.map = kzalloc(sz, GFP_KERNEL);
|
|
|
|
if (!iommu->tbl.map) {
|
2008-08-30 16:50:29 +07:00
|
|
|
printk(KERN_ERR PFX "Error, kmalloc(arena.map) failed.\n");
|
|
|
|
return -ENOMEM;
|
2006-02-10 15:08:26 +07:00
|
|
|
}
|
2015-04-10 02:33:31 +07:00
|
|
|
iommu_tbl_pool_init(&iommu->tbl, num_tsb_entries, IO_PAGE_SHIFT,
|
|
|
|
NULL, false /* no large_pool */,
|
|
|
|
0 /* default npools */,
|
|
|
|
false /* want span boundary checking */);
|
|
|
|
sz = probe_existing_entries(pbm, &iommu->tbl);
|
2006-06-22 14:01:56 +07:00
|
|
|
if (sz)
|
|
|
|
printk("%s: Imported %lu TSB entries from OBP\n",
|
|
|
|
pbm->name, sz);
|
2008-08-30 16:50:29 +07:00
|
|
|
|
|
|
|
return 0;
|
2006-02-10 13:05:54 +07: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 08:41:02 +07: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-12 03:52:08 +07: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 08:41:02 +07: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 17:16:13 +07: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 08:41:02 +07:00
|
|
|
{
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
if (unlikely(err))
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
}
|
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
{
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
{
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
}
|
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07: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 17:16:13 +07: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 08:41:02 +07:00
|
|
|
{
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
int i;
|
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
}
|
2007-04-18 16:39:21 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
}
|
|
|
|
|
2007-10-11 17:16:13 +07: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 08:41:02 +07:00
|
|
|
{
|
2011-01-22 18:32:20 +07:00
|
|
|
unsigned int 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 08:41:02 +07:00
|
|
|
|
2011-01-22 18:32:20 +07:00
|
|
|
if (!irq)
|
2007-10-11 17:16:13 +07:00
|
|
|
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 08:41:02 +07:00
|
|
|
|
2007-10-11 17:16:13 +07:00
|
|
|
if (pci_sun4v_msiq_setvalid(pbm->devhandle, msiqid, HV_MSIQ_VALID))
|
|
|
|
return -EINVAL;
|
2011-12-23 04:23:59 +07:00
|
|
|
if (pci_sun4v_msiq_setstate(pbm->devhandle, msiqid, HV_MSIQSTATE_IDLE))
|
|
|
|
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 08:41:02 +07:00
|
|
|
|
2011-01-22 18:32:20 +07:00
|
|
|
return 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 08:41:02 +07:00
|
|
|
}
|
2007-05-08 13:28:50 +07:00
|
|
|
|
2007-10-11 17:16:13 +07: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 13:28:50 +07:00
|
|
|
static void pci_sun4v_msi_init(struct pci_pbm_info *pbm)
|
|
|
|
{
|
2007-10-11 17:16:13 +07:00
|
|
|
sparc64_pbm_msi_init(pbm, &pci_sun4v_msiq_ops);
|
2007-05-08 13:28:50 +07: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 08:41:02 +07:00
|
|
|
#else /* CONFIG_PCI_MSI */
|
|
|
|
static void pci_sun4v_msi_init(struct pci_pbm_info *pbm)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif /* !(CONFIG_PCI_MSI) */
|
|
|
|
|
2012-12-22 05:03:26 +07:00
|
|
|
static int pci_sun4v_pbm_init(struct pci_pbm_info *pbm,
|
|
|
|
struct platform_device *op, u32 devhandle)
|
2006-02-10 13:05:54 +07:00
|
|
|
{
|
2010-04-14 06:12:29 +07:00
|
|
|
struct device_node *dp = op->dev.of_node;
|
2008-08-30 16:50:29 +07:00
|
|
|
int err;
|
2006-02-10 13:05:54 +07:00
|
|
|
|
2008-03-19 18:52:48 +07:00
|
|
|
pbm->numa_node = of_node_to_nid(dp);
|
|
|
|
|
2007-05-09 16:35:27 +07:00
|
|
|
pbm->pci_ops = &sun4v_pci_ops;
|
|
|
|
pbm->config_space_reg_bits = 12;
|
2007-05-08 13:06:27 +07:00
|
|
|
|
2007-05-08 13:49:01 +07:00
|
|
|
pbm->index = pci_num_pbms++;
|
|
|
|
|
2008-09-10 14:19:28 +07:00
|
|
|
pbm->op = op;
|
2006-02-10 13:05:54 +07:00
|
|
|
|
2006-02-13 13:06:53 +07:00
|
|
|
pbm->devhandle = devhandle;
|
2006-02-10 13:05:54 +07:00
|
|
|
|
2006-06-22 08:18:47 +07:00
|
|
|
pbm->name = dp->full_name;
|
2006-02-10 13:05:54 +07:00
|
|
|
|
2006-06-22 08:18:47 +07:00
|
|
|
printk("%s: SUN4V PCI Bus Module\n", pbm->name);
|
2008-03-19 18:52:48 +07:00
|
|
|
printk("%s: On NUMA node %d\n", pbm->name, pbm->numa_node);
|
2006-02-10 13:05:54 +07:00
|
|
|
|
2007-03-09 12:55:49 +07:00
|
|
|
pci_determine_mem_io_space(pbm);
|
2006-02-10 13:05:54 +07:00
|
|
|
|
2007-05-08 11:51:41 +07:00
|
|
|
pci_get_pbm_props(pbm);
|
2008-08-30 16:50:29 +07:00
|
|
|
|
|
|
|
err = pci_sun4v_iommu_init(pbm);
|
|
|
|
if (err)
|
|
|
|
return 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 08:41:02 +07:00
|
|
|
pci_sun4v_msi_init(pbm);
|
2008-08-30 16:50:29 +07:00
|
|
|
|
2008-09-02 08:32:22 +07:00
|
|
|
pci_sun4v_scan_bus(pbm, &op->dev);
|
2008-08-30 16:50:29 +07:00
|
|
|
|
2016-10-29 00:12:41 +07:00
|
|
|
/* if atu_init fails its not complete failure.
|
|
|
|
* we can still continue using legacy iommu.
|
|
|
|
*/
|
|
|
|
if (pbm->iommu->atu) {
|
|
|
|
err = pci_sun4v_atu_init(pbm);
|
|
|
|
if (err) {
|
|
|
|
kfree(pbm->iommu->atu);
|
|
|
|
pbm->iommu->atu = NULL;
|
|
|
|
pr_err(PFX "ATU init failed, err=%d\n", err);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-09-10 13:54:02 +07:00
|
|
|
pbm->next = pci_pbm_root;
|
|
|
|
pci_pbm_root = pbm;
|
|
|
|
|
2008-08-30 16:50:29 +07:00
|
|
|
return 0;
|
2006-02-10 13:05:54 +07:00
|
|
|
}
|
|
|
|
|
2012-12-22 05:03:26 +07:00
|
|
|
static int pci_sun4v_probe(struct platform_device *op)
|
2006-02-10 12:32:07 +07:00
|
|
|
{
|
2008-08-30 16:50:29 +07:00
|
|
|
const struct linux_prom64_registers *regs;
|
2007-05-25 15:04:15 +07:00
|
|
|
static int hvapi_negotiated = 0;
|
2007-05-08 13:06:27 +07:00
|
|
|
struct pci_pbm_info *pbm;
|
2008-08-30 16:50:29 +07:00
|
|
|
struct device_node *dp;
|
2007-04-27 11:08:21 +07:00
|
|
|
struct iommu *iommu;
|
2016-10-29 00:12:41 +07:00
|
|
|
struct atu *atu;
|
2006-02-14 12:50:27 +07:00
|
|
|
u32 devhandle;
|
2016-09-29 02:19:45 +07:00
|
|
|
int i, err = -ENODEV;
|
2016-10-29 00:12:41 +07:00
|
|
|
static bool hv_atu = true;
|
2006-02-13 13:06:53 +07:00
|
|
|
|
2010-04-14 06:12:29 +07:00
|
|
|
dp = op->dev.of_node;
|
2008-08-30 16:50:29 +07:00
|
|
|
|
2007-05-25 15:04:15 +07:00
|
|
|
if (!hvapi_negotiated++) {
|
2016-09-29 02:19:45 +07:00
|
|
|
for (i = 0; i < ARRAY_SIZE(vpci_versions); i++) {
|
|
|
|
vpci_major = vpci_versions[i].major;
|
|
|
|
vpci_minor = vpci_versions[i].minor;
|
|
|
|
|
|
|
|
err = sun4v_hvapi_register(HV_GRP_PCI, vpci_major,
|
|
|
|
&vpci_minor);
|
|
|
|
if (!err)
|
|
|
|
break;
|
|
|
|
}
|
2007-05-25 15:04:15 +07:00
|
|
|
|
|
|
|
if (err) {
|
2016-09-29 02:19:45 +07:00
|
|
|
pr_err(PFX "Could not register hvapi, err=%d\n", err);
|
2008-08-30 16:50:29 +07:00
|
|
|
return err;
|
2007-05-25 15:04:15 +07:00
|
|
|
}
|
2016-09-29 02:19:45 +07:00
|
|
|
pr_info(PFX "Registered hvapi major[%lu] minor[%lu]\n",
|
|
|
|
vpci_major, vpci_minor);
|
2007-07-28 12:39:14 +07:00
|
|
|
|
2016-10-29 00:12:41 +07:00
|
|
|
err = sun4v_hvapi_register(HV_GRP_ATU, vatu_major, &vatu_minor);
|
|
|
|
if (err) {
|
|
|
|
/* don't return an error if we fail to register the
|
|
|
|
* ATU group, but ATU hcalls won't be available.
|
|
|
|
*/
|
|
|
|
hv_atu = false;
|
|
|
|
pr_err(PFX "Could not register hvapi ATU err=%d\n",
|
|
|
|
err);
|
|
|
|
} else {
|
|
|
|
pr_info(PFX "Registered hvapi ATU major[%lu] minor[%lu]\n",
|
|
|
|
vatu_major, vatu_minor);
|
|
|
|
}
|
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
dma_ops = &sun4v_dma_ops;
|
2007-05-25 15:04:15 +07:00
|
|
|
}
|
|
|
|
|
2008-08-30 16:50:29 +07:00
|
|
|
regs = of_get_property(dp, "reg", NULL);
|
2008-08-31 15:33:52 +07:00
|
|
|
err = -ENODEV;
|
2008-08-30 16:50:29 +07:00
|
|
|
if (!regs) {
|
|
|
|
printk(KERN_ERR PFX "Could not find config registers\n");
|
2008-08-31 15:33:52 +07:00
|
|
|
goto out_err;
|
2007-11-21 08:32:19 +07:00
|
|
|
}
|
2006-06-22 08:18:47 +07:00
|
|
|
devhandle = (regs->phys_addr >> 32UL) & 0x0fffffff;
|
2006-02-13 13:06:53 +07:00
|
|
|
|
2008-08-31 15:33:52 +07:00
|
|
|
err = -ENOMEM;
|
2008-09-10 13:54:02 +07:00
|
|
|
if (!iommu_batch_initialized) {
|
|
|
|
for_each_possible_cpu(i) {
|
|
|
|
unsigned long page = get_zeroed_page(GFP_KERNEL);
|
2006-02-14 12:50:27 +07:00
|
|
|
|
2008-09-10 13:54:02 +07:00
|
|
|
if (!page)
|
|
|
|
goto out_err;
|
2006-02-14 12:50:27 +07:00
|
|
|
|
2008-09-10 13:54:02 +07:00
|
|
|
per_cpu(iommu_batch, i).pglist = (u64 *) page;
|
|
|
|
}
|
|
|
|
iommu_batch_initialized = 1;
|
2006-02-10 13:05:54 +07:00
|
|
|
}
|
2006-02-14 12:50:27 +07:00
|
|
|
|
2008-09-10 13:54:02 +07:00
|
|
|
pbm = kzalloc(sizeof(*pbm), GFP_KERNEL);
|
|
|
|
if (!pbm) {
|
|
|
|
printk(KERN_ERR PFX "Could not allocate pci_pbm_info\n");
|
2008-08-31 15:33:52 +07:00
|
|
|
goto out_err;
|
2008-08-30 16:50:29 +07:00
|
|
|
}
|
2006-02-14 12:50:27 +07:00
|
|
|
|
2008-09-10 13:54:02 +07:00
|
|
|
iommu = kzalloc(sizeof(struct iommu), GFP_KERNEL);
|
2008-08-30 16:50:29 +07:00
|
|
|
if (!iommu) {
|
2008-09-10 13:54:02 +07:00
|
|
|
printk(KERN_ERR PFX "Could not allocate pbm iommu\n");
|
2008-08-31 15:33:52 +07:00
|
|
|
goto out_free_controller;
|
2008-08-30 16:50:29 +07:00
|
|
|
}
|
2006-02-14 12:50:27 +07:00
|
|
|
|
2008-09-10 13:54:02 +07:00
|
|
|
pbm->iommu = iommu;
|
2016-10-29 00:12:41 +07:00
|
|
|
iommu->atu = NULL;
|
|
|
|
if (hv_atu) {
|
|
|
|
atu = kzalloc(sizeof(*atu), GFP_KERNEL);
|
|
|
|
if (!atu)
|
|
|
|
pr_err(PFX "Could not allocate atu\n");
|
|
|
|
else
|
|
|
|
iommu->atu = atu;
|
|
|
|
}
|
2006-02-10 13:05:54 +07:00
|
|
|
|
2008-09-10 13:54:02 +07:00
|
|
|
err = pci_sun4v_pbm_init(pbm, op, devhandle);
|
|
|
|
if (err)
|
|
|
|
goto out_free_iommu;
|
2006-02-14 12:50:27 +07:00
|
|
|
|
2008-09-10 13:54:02 +07:00
|
|
|
dev_set_drvdata(&op->dev, pbm);
|
2006-02-10 13:05:54 +07:00
|
|
|
|
2008-09-10 13:54:02 +07:00
|
|
|
return 0;
|
2006-02-14 12:50:27 +07:00
|
|
|
|
2008-09-10 13:54:02 +07:00
|
|
|
out_free_iommu:
|
2016-10-29 00:12:41 +07:00
|
|
|
kfree(iommu->atu);
|
2008-09-10 13:54:02 +07:00
|
|
|
kfree(pbm->iommu);
|
2008-08-31 15:33:52 +07:00
|
|
|
|
|
|
|
out_free_controller:
|
2008-09-10 13:54:02 +07:00
|
|
|
kfree(pbm);
|
2008-08-31 15:33:52 +07:00
|
|
|
|
|
|
|
out_err:
|
|
|
|
return err;
|
2006-02-10 12:32:07 +07:00
|
|
|
}
|
2008-08-30 16:50:29 +07:00
|
|
|
|
2011-03-31 07:37:56 +07:00
|
|
|
static const struct of_device_id pci_sun4v_match[] = {
|
2008-08-30 16:50:29 +07:00
|
|
|
{
|
|
|
|
.name = "pci",
|
|
|
|
.compatible = "SUNW,sun4v-pci",
|
|
|
|
},
|
|
|
|
{},
|
|
|
|
};
|
|
|
|
|
2011-02-23 10:01:33 +07:00
|
|
|
static struct platform_driver pci_sun4v_driver = {
|
2010-04-14 06:13:02 +07:00
|
|
|
.driver = {
|
|
|
|
.name = DRIVER_NAME,
|
|
|
|
.of_match_table = pci_sun4v_match,
|
|
|
|
},
|
2008-08-30 16:50:29 +07:00
|
|
|
.probe = pci_sun4v_probe,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __init pci_sun4v_init(void)
|
|
|
|
{
|
2011-02-23 10:01:33 +07:00
|
|
|
return platform_driver_register(&pci_sun4v_driver);
|
2008-08-30 16:50:29 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
subsys_initcall(pci_sun4v_init);
|