On Tue, Apr 29, 2014 at 10:46:18PM +0200, Arnd Bergmann wrote:
On Tuesday 29 April 2014 19:16:02 Dave Martin wrote:
[...]
For example, suppose devices can post MSIs to an interrupt controller
via a mailbox accessed through the IOMMU. Suppose also that the IOMMU
generates MSIs itself in
On Mon, 28 Apr 2014 16:08:14 +0530, Tushar Behera wrote:
On 04/27/2014 01:07 PM, Shaik Ameer Basha wrote:
From: Cho KyongHo pullip@samsung.com
Some master device descriptor like fimc-is which is an abstraction
of very complex H/W may have multiple System MMUs. For those devices,
On Thursday 01 May 2014 23:02:14 Cho KyongHo wrote:
- device can only do DMA to a limited address range
- DMA is noncoherent and needs manual cache management
- DMA address is at an offset from physical address
- some devices have an IOMMU
- some IOMMUs are shared between devices
-
On Mon, 28 Apr 2014 16:13:19 -0700, Doug Anderson wrote:
Vikas,
On Sun, Apr 27, 2014 at 10:39 AM, Vikas Sajjan sajjan.li...@gmail.com wrote:
Hi shaik,
+Doug, Abhilash,
On Sun, Apr 27, 2014 at 1:08 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
From: Cho KyongHo
On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote:
On Thursday 01 May 2014 12:15:35 Dave Martin wrote:
On Tue, Apr 29, 2014 at 10:46:18PM +0200, Arnd Bergmann wrote:
On Tuesday 29 April 2014 19:16:02 Dave Martin wrote:
[...]
For example, suppose devices can post MSIs
On Thu, May 01, 2014 at 11:02:14PM +0900, Cho KyongHo wrote:
On Tue, 29 Apr 2014 23:00:29 +0200, Arnd Bergmann wrote:
On Tuesday 29 April 2014 13:07:54 Grant Grundler wrote:
On Tue, Apr 29, 2014 at 11:16 AM, Dave Martin dave.mar...@arm.com wrote:
...
An IOMMU is really a specialised
On 01/05/14 15:36, Dave Martin wrote:
On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote:
On Thursday 01 May 2014 12:15:35 Dave Martin wrote:
On Tue, Apr 29, 2014 at 10:46:18PM +0200, Arnd Bergmann wrote:
On Tuesday 29 April 2014 19:16:02 Dave Martin wrote:
[...]
For example,
On Thursday 01 May 2014 15:36:54 Dave Martin wrote:
On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote:
On Thursday 01 May 2014 12:15:35 Dave Martin wrote:
I'm not sure whether there is actually a SoC today that is MSI-capable
and contains an IOMMU, but all the components
On Thursday 01 May 2014 16:11:48 Marc Zyngier wrote:
On 01/05/14 15:36, Dave Martin wrote:
On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote:
On Thursday 01 May 2014 12:15:35 Dave Martin wrote:
On Tue, Apr 29, 2014 at 10:46:18PM +0200, Arnd Bergmann wrote:
I don't understand.
On 01/05/14 16:53, Arnd Bergmann wrote:
On Thursday 01 May 2014 16:11:48 Marc Zyngier wrote:
On 01/05/14 15:36, Dave Martin wrote:
On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote:
On Thursday 01 May 2014 12:15:35 Dave Martin wrote:
On Tue, Apr 29, 2014 at 10:46:18PM +0200, Arnd
There are a few broken devices that use the requester ID of a different
function in the slot for their DMA. To handle these, add a bitmap to
struct pci_dev (using an alignment gap) that quirks can populate. As
we iterate over the device and bus DMA aliases, also iterate over any
bits in the map.
Several Marvell devices and a JMicron device have a similar DMA
requester ID problem to Ricoh, except they use function 1 as the
PCIe requester ID. Add a quirk for these to populate the DMA
function alias bitmap.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/quirks.c
AMD-Vi already has a concept of an alias provided via the IVRS table.
This alias only handles topology based aliases, such as PCIe-to-PCI
bridges. When such an alias is present, we continue to use it. When
a platform alias is not present, we can now add a check of the device
dma_func_alias to
The existing quirk for these devices doesn't really solve the problem,
re-implement it using the DMA alias iterator. We'll come back later
and remove the existing quirk and dma_source interface.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/quirks.c | 16
Drop custom code that attempts to do the exact same thing and use
PCI provided isolation root support. Existing IOMMU group laytout
should not change.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: David Woodhouse david.woodho...@intel.com
---
drivers/iommu/intel-iommu.c | 71
VT-d code currently makes use of pci_find_upstream_pcie_bridge() in
order to find the topology based alias of a device. This function has
a few problems. First, it doesn't check the entire alias path of the
device to the root bus, therefore if a PCIe device is masked upstream,
the wrong result
Drop custom code and use PCI provided isolation root support.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: Varun Sethi varun.se...@freescale.com
---
drivers/iommu/fsl_pamu_domain.c | 67 ++-
1 file changed, 3 insertions(+), 64 deletions(-)
The IVRS tables provides aliases, but not to the extent now provided
by PCI core with DMA alias support and pci_find_dma_isolation_root().
The expectation is that the kernel and IVRS will produce the same
result for topology based aliases while the kernel will also include
device specific DMA
Each of the IOMMU drivers supporting IOMMU groups has their own
implementation of an algorithm to find the base device for an IOMMU
group. This N:1 function takes into account visibility of a PCI
device on the bus using DMA aliases, as well as the isolation of
devices using ACS. Since these are
It's broken and has no users.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/search.c | 35 ---
include/linux/pci.h | 11 ---
2 files changed, 46 deletions(-)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index
The single helper here no longer has any users.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: Joerg Roedel j...@8bytes.org
---
drivers/iommu/pci.h | 29 -
1 file changed, 29 deletions(-)
delete mode 100644 drivers/iommu/pci.h
diff --git
It has no users; replaced by dma_func_alias.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/quirks.c | 51 --
include/linux/pci.h |5 -
2 files changed, 56 deletions(-)
diff --git a/drivers/pci/quirks.c
On Thu, May 1, 2014 at 6:29 AM, Arnd Bergmann a...@arndb.de wrote:
...
GICv3 can descriminate between different MSI senders based on ID
signals on the bus.
Any idea what this is good for? Do we have to use it? It probably doesn't
fit very well into the way Linux handles MSIs today.
I can see
In a mixed PCI/PCI-X/PCI-e topology, bridges can take ownership of
transactions, replacing the original requester ID with their own.
Sometimes we just want to know the resulting device or resulting
alias, sometimes we want each step in the chain. This iterator
allows either usage. When an
On 04/29/2014 03:00 PM, Arnd Bergmann wrote:
...
Yes. It's very complicated unfortunately, because we have to be
able to deal with arbitrary combinations of a lot of oddball cases
that can show up in random SoCs:
...
- a device may have DMA access to a bus that is invisible to the CPU
The
25 matches
Mail list logo
