License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 21:07:57 +07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
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>
|
2018-04-03 20:34:58 +07:00
|
|
|
#include <asm/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"
|
2017-05-22 14:11:30 +07:00
|
|
|
#include "kernel.h"
|
2006-02-10 12:32:07 +07:00
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2019-04-04 02:34:34 +07:00
|
|
|
static inline bool iommu_use_atu(struct iommu *iommu, u64 mask)
|
|
|
|
{
|
|
|
|
return iommu->atu && mask > DMA_BIT_MASK(32);
|
|
|
|
}
|
|
|
|
|
2006-02-20 13:21:32 +07:00
|
|
|
/* Interrupts must be disabled. */
|
2016-10-29 00:12:44 +07:00
|
|
|
static long iommu_batch_flush(struct iommu_batch *p, u64 mask)
|
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;
|
2016-10-29 00:12:44 +07:00
|
|
|
u64 *pglist = p->pglist;
|
|
|
|
u64 index_count;
|
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;
|
|
|
|
unsigned long npages = p->npages;
|
2016-10-29 00:12:44 +07:00
|
|
|
unsigned long iotsb_num;
|
|
|
|
unsigned long ret;
|
|
|
|
long num;
|
2006-02-20 13:21:32 +07:00
|
|
|
|
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) {
|
2019-04-04 02:34:34 +07:00
|
|
|
if (!iommu_use_atu(pbm->iommu, mask)) {
|
2016-10-29 00:12:44 +07:00
|
|
|
num = pci_sun4v_iommu_map(devhandle,
|
|
|
|
HV_PCI_TSBID(0, entry),
|
|
|
|
npages,
|
|
|
|
prot,
|
|
|
|
__pa(pglist));
|
|
|
|
if (unlikely(num < 0)) {
|
|
|
|
pr_err_ratelimited("%s: IOMMU map of [%08lx:%08llx:%lx:%lx:%lx] failed with status %ld\n",
|
|
|
|
__func__,
|
|
|
|
devhandle,
|
|
|
|
HV_PCI_TSBID(0, entry),
|
|
|
|
npages, prot, __pa(pglist),
|
|
|
|
num);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
index_count = HV_PCI_IOTSB_INDEX_COUNT(npages, entry),
|
|
|
|
iotsb_num = pbm->iommu->atu->iotsb->iotsb_num;
|
|
|
|
ret = pci_sun4v_iotsb_map(devhandle,
|
|
|
|
iotsb_num,
|
|
|
|
index_count,
|
|
|
|
prot,
|
|
|
|
__pa(pglist),
|
|
|
|
&num);
|
|
|
|
if (unlikely(ret != HV_EOK)) {
|
|
|
|
pr_err_ratelimited("%s: ATU map of [%08lx:%lx:%llx:%lx:%lx] failed with status %ld\n",
|
|
|
|
__func__,
|
|
|
|
devhandle, iotsb_num,
|
|
|
|
index_count, prot,
|
|
|
|
__pa(pglist), ret);
|
|
|
|
return -1;
|
|
|
|
}
|
2006-02-20 13:21:32 +07:00
|
|
|
}
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:12:44 +07:00
|
|
|
static inline void iommu_batch_new_entry(unsigned long entry, u64 mask)
|
2008-02-09 18:11:01 +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);
|
2008-02-09 18:11:01 +07:00
|
|
|
|
|
|
|
if (p->entry + p->npages == entry)
|
|
|
|
return;
|
|
|
|
if (p->entry != ~0UL)
|
2016-10-29 00:12:44 +07:00
|
|
|
iommu_batch_flush(p, mask);
|
2008-02-09 18:11:01 +07:00
|
|
|
p->entry = entry;
|
|
|
|
}
|
|
|
|
|
2006-02-20 13:21:32 +07:00
|
|
|
/* Interrupts must be disabled. */
|
2016-10-29 00:12:44 +07:00
|
|
|
static inline long iommu_batch_add(u64 phys_page, u64 mask)
|
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)
|
2016-10-29 00:12:44 +07:00
|
|
|
return iommu_batch_flush(p, mask);
|
2006-02-20 13:21:32 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Interrupts must be disabled. */
|
2016-10-29 00:12:44 +07:00
|
|
|
static inline long iommu_batch_end(u64 mask)
|
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);
|
|
|
|
|
2016-10-29 00:12:44 +07:00
|
|
|
return iommu_batch_flush(p, mask);
|
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
|
|
|
{
|
2016-10-29 00:12:44 +07:00
|
|
|
u64 mask;
|
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;
|
2016-10-29 00:12:44 +07:00
|
|
|
struct iommu_map_table *tbl;
|
2008-03-19 18:52:48 +07:00
|
|
|
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;
|
2016-10-29 00:12:44 +07:00
|
|
|
mask = dev->coherent_dma_mask;
|
2019-04-04 02:34:34 +07:00
|
|
|
if (!iommu_use_atu(iommu, mask))
|
2016-10-29 00:12:44 +07:00
|
|
|
tbl = &iommu->tbl;
|
|
|
|
else
|
2019-04-04 02:34:34 +07:00
|
|
|
tbl = &iommu->atu->tbl;
|
2016-10-29 00:12:44 +07:00
|
|
|
|
|
|
|
entry = iommu_tbl_range_alloc(dev, tbl, npages, NULL,
|
2015-04-10 02:33:31 +07:00
|
|
|
(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
|
|
|
|
2016-10-29 00:12:44 +07:00
|
|
|
*dma_addrp = (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++) {
|
2016-10-29 00:12:44 +07:00
|
|
|
long err = iommu_batch_add(first_page + (n * PAGE_SIZE), mask);
|
2006-02-20 13:21:32 +07:00
|
|
|
if (unlikely(err < 0L))
|
|
|
|
goto iommu_map_fail;
|
|
|
|
}
|
2006-02-10 15:08:26 +07:00
|
|
|
|
2016-10-29 00:12:44 +07:00
|
|
|
if (unlikely(iommu_batch_end(mask) < 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:
|
2016-11-26 04:15:37 +07:00
|
|
|
local_irq_restore(flags);
|
2016-10-29 00:12:44 +07:00
|
|
|
iommu_tbl_range_free(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;
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:12:44 +07:00
|
|
|
static void dma_4v_iommu_demap(struct device *dev, unsigned long devhandle,
|
|
|
|
dma_addr_t dvma, unsigned long iotsb_num,
|
|
|
|
unsigned long entry, unsigned long npages)
|
2015-04-10 02:33:31 +07:00
|
|
|
{
|
|
|
|
unsigned long num, flags;
|
2016-10-29 00:12:44 +07:00
|
|
|
unsigned long ret;
|
2015-04-10 02:33:31 +07:00
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
do {
|
2016-10-29 00:12:44 +07:00
|
|
|
if (dvma <= DMA_BIT_MASK(32)) {
|
|
|
|
num = pci_sun4v_iommu_demap(devhandle,
|
|
|
|
HV_PCI_TSBID(0, entry),
|
|
|
|
npages);
|
|
|
|
} else {
|
|
|
|
ret = pci_sun4v_iotsb_demap(devhandle, iotsb_num,
|
|
|
|
entry, npages, &num);
|
|
|
|
if (unlikely(ret != HV_EOK)) {
|
|
|
|
pr_err_ratelimited("pci_iotsb_demap() failed with error: %ld\n",
|
|
|
|
ret);
|
|
|
|
}
|
|
|
|
}
|
2015-04-10 02:33:31 +07:00
|
|
|
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;
|
2016-10-29 00:12:44 +07:00
|
|
|
struct atu *atu;
|
|
|
|
struct iommu_map_table *tbl;
|
2015-04-10 02:33:31 +07:00
|
|
|
unsigned long order, npages, entry;
|
2016-10-29 00:12:44 +07:00
|
|
|
unsigned long iotsb_num;
|
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;
|
2016-10-29 00:12:44 +07:00
|
|
|
atu = iommu->atu;
|
2007-03-01 14:35:04 +07:00
|
|
|
devhandle = pbm->devhandle;
|
2016-10-29 00:12:44 +07:00
|
|
|
|
2019-04-04 02:34:34 +07:00
|
|
|
if (!iommu_use_atu(iommu, dvma)) {
|
2016-10-29 00:12:44 +07:00
|
|
|
tbl = &iommu->tbl;
|
|
|
|
iotsb_num = 0; /* we don't care for legacy iommu */
|
|
|
|
} else {
|
|
|
|
tbl = &atu->tbl;
|
|
|
|
iotsb_num = atu->iotsb->iotsb_num;
|
|
|
|
}
|
|
|
|
entry = ((dvma - tbl->table_map_base) >> IO_PAGE_SHIFT);
|
|
|
|
dma_4v_iommu_demap(dev, devhandle, dvma, iotsb_num, entry, npages);
|
|
|
|
iommu_tbl_range_free(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;
|
2016-10-29 00:12:44 +07:00
|
|
|
struct atu *atu;
|
|
|
|
struct iommu_map_table *tbl;
|
|
|
|
u64 mask;
|
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-10 15:08:26 +07:00
|
|
|
unsigned long prot;
|
2016-10-29 00:12:44 +07:00
|
|
|
dma_addr_t bus_addr, ret;
|
2006-02-10 15:08:26 +07:00
|
|
|
long entry;
|
|
|
|
|
2007-07-28 12:39:14 +07:00
|
|
|
iommu = dev->archdata.iommu;
|
2016-10-29 00:12:44 +07:00
|
|
|
atu = iommu->atu;
|
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;
|
|
|
|
|
2016-10-29 00:12:44 +07:00
|
|
|
mask = *dev->dma_mask;
|
2019-04-04 02:34:34 +07:00
|
|
|
if (!iommu_use_atu(iommu, mask))
|
2016-10-29 00:12:44 +07:00
|
|
|
tbl = &iommu->tbl;
|
|
|
|
else
|
|
|
|
tbl = &atu->tbl;
|
|
|
|
|
|
|
|
entry = iommu_tbl_range_alloc(dev, tbl, npages, NULL,
|
2015-04-10 02:33:31 +07:00
|
|
|
(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;
|
|
|
|
|
2016-10-29 00:12:44 +07:00
|
|
|
bus_addr = (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) {
|
2016-10-29 00:12:44 +07:00
|
|
|
long err = iommu_batch_add(base_paddr, mask);
|
2006-02-20 13:21:32 +07:00
|
|
|
if (unlikely(err < 0L))
|
|
|
|
goto iommu_map_fail;
|
|
|
|
}
|
2016-10-29 00:12:44 +07:00
|
|
|
if (unlikely(iommu_batch_end(mask) < 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);
|
2018-11-22 00:59:05 +07:00
|
|
|
return DMA_MAPPING_ERROR;
|
2006-02-20 13:21:32 +07:00
|
|
|
|
|
|
|
iommu_map_fail:
|
2016-11-26 04:15:37 +07:00
|
|
|
local_irq_restore(flags);
|
2016-10-29 00:12:44 +07:00
|
|
|
iommu_tbl_range_free(tbl, bus_addr, npages, IOMMU_ERROR_CODE);
|
2018-11-22 00:59:05 +07:00
|
|
|
return DMA_MAPPING_ERROR;
|
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;
|
2016-10-29 00:12:44 +07:00
|
|
|
struct atu *atu;
|
|
|
|
struct iommu_map_table *tbl;
|
2015-04-10 02:33:31 +07:00
|
|
|
unsigned long npages;
|
2016-10-29 00:12:44 +07:00
|
|
|
unsigned long iotsb_num;
|
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;
|
2016-10-29 00:12:44 +07:00
|
|
|
atu = iommu->atu;
|
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;
|
2016-10-29 00:12:44 +07:00
|
|
|
|
|
|
|
if (bus_addr <= DMA_BIT_MASK(32)) {
|
|
|
|
iotsb_num = 0; /* we don't care for legacy iommu */
|
|
|
|
tbl = &iommu->tbl;
|
|
|
|
} else {
|
|
|
|
iotsb_num = atu->iotsb->iotsb_num;
|
|
|
|
tbl = &atu->tbl;
|
|
|
|
}
|
|
|
|
entry = (bus_addr - tbl->table_map_base) >> IO_PAGE_SHIFT;
|
|
|
|
dma_4v_iommu_demap(dev, devhandle, bus_addr, iotsb_num, entry, npages);
|
|
|
|
iommu_tbl_range_free(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;
|
2016-10-29 00:12:44 +07:00
|
|
|
struct atu *atu;
|
|
|
|
struct iommu_map_table *tbl;
|
|
|
|
u64 mask;
|
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;
|
2016-11-25 18:01:32 +07:00
|
|
|
atu = iommu->atu;
|
|
|
|
|
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;
|
2016-10-29 00:12:44 +07:00
|
|
|
|
|
|
|
mask = *dev->dma_mask;
|
2019-04-04 02:34:34 +07:00
|
|
|
if (!iommu_use_atu(iommu, mask))
|
2016-10-29 00:12:44 +07:00
|
|
|
tbl = &iommu->tbl;
|
|
|
|
else
|
|
|
|
tbl = &atu->tbl;
|
|
|
|
|
|
|
|
base_shift = 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);
|
2016-10-29 00:12:44 +07:00
|
|
|
entry = iommu_tbl_range_alloc(dev, tbl, npages,
|
2015-04-10 02:33:31 +07:00
|
|
|
&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)) {
|
2016-10-29 00:12:44 +07:00
|
|
|
pr_err_ratelimited("iommu_alloc failed, iommu %p paddr %lx npages %lx\n",
|
|
|
|
tbl, paddr, npages);
|
2008-02-09 18:11:01 +07:00
|
|
|
goto iommu_map_failed;
|
|
|
|
}
|
2008-02-06 18:50:26 +07:00
|
|
|
|
2016-10-29 00:12:44 +07:00
|
|
|
iommu_batch_new_entry(entry, mask);
|
2008-02-06 18:50:26 +07:00
|
|
|
|
2008-02-09 18:11:01 +07:00
|
|
|
/* Convert entry to a dma_addr_t */
|
2016-10-29 00:12:44 +07:00
|
|
|
dma_addr = 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--) {
|
2016-10-29 00:12:44 +07:00
|
|
|
err = iommu_batch_add(paddr, mask);
|
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
|
|
|
}
|
|
|
|
|
2016-10-29 00:12:44 +07:00
|
|
|
err = iommu_batch_end(mask);
|
2008-02-06 18:50:26 +07:00
|
|
|
|
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);
|
2018-11-22 00:59:05 +07:00
|
|
|
outs->dma_address = DMA_MAPPING_ERROR;
|
2008-02-09 18:11:01 +07:00
|
|
|
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);
|
2016-10-29 00:12:44 +07:00
|
|
|
iommu_tbl_range_free(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 */
|
2018-11-22 00:59:05 +07:00
|
|
|
s->dma_address = DMA_MAPPING_ERROR;
|
2008-02-09 18:11:01 +07:00
|
|
|
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;
|
2016-10-29 00:12:44 +07:00
|
|
|
struct atu *atu;
|
2015-04-10 02:33:31 +07:00
|
|
|
unsigned long flags, entry;
|
2016-10-29 00:12:44 +07:00
|
|
|
unsigned long iotsb_num;
|
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;
|
2016-10-29 00:12:44 +07:00
|
|
|
atu = iommu->atu;
|
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;
|
2016-10-29 00:12:44 +07:00
|
|
|
struct iommu_map_table *tbl;
|
2015-04-10 02:33:31 +07:00
|
|
|
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);
|
2016-10-29 00:12:44 +07:00
|
|
|
|
|
|
|
if (dma_handle <= DMA_BIT_MASK(32)) {
|
|
|
|
iotsb_num = 0; /* we don't care for legacy iommu */
|
|
|
|
tbl = &iommu->tbl;
|
|
|
|
} else {
|
|
|
|
iotsb_num = atu->iotsb->iotsb_num;
|
|
|
|
tbl = &atu->tbl;
|
|
|
|
}
|
2015-04-10 02:33:31 +07:00
|
|
|
entry = ((dma_handle - tbl->table_map_base) >> shift);
|
2016-10-29 00:12:44 +07:00
|
|
|
dma_4v_iommu_demap(dev, devhandle, dma_handle, iotsb_num,
|
|
|
|
entry, npages);
|
|
|
|
iommu_tbl_range_free(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
|
|
|
}
|
|
|
|
|
2017-05-22 14:11:30 +07:00
|
|
|
static int dma_4v_supported(struct device *dev, u64 device_mask)
|
|
|
|
{
|
|
|
|
struct iommu *iommu = dev->archdata.iommu;
|
|
|
|
|
2019-02-15 15:06:31 +07:00
|
|
|
if (ali_sound_dma_hack(dev, device_mask))
|
|
|
|
return 1;
|
2019-02-15 15:30:28 +07:00
|
|
|
if (device_mask < iommu->dma_addr_mask)
|
|
|
|
return 0;
|
|
|
|
return 1;
|
2017-05-22 14:11:30 +07:00
|
|
|
}
|
|
|
|
|
2017-01-21 04:04:01 +07:00
|
|
|
static const 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,
|
2017-05-22 14:11:30 +07:00
|
|
|
.dma_supported = dma_4v_supported,
|
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;
|
|
|
|
} 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);
|