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
On Thu, May 1, 2014 at 6:29 AM, Arnd Bergmann 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 this b
It has no users; replaced by dma_func_alias.
Signed-off-by: Alex Williamson
---
drivers/pci/quirks.c | 51 --
include/linux/pci.h |5 -
2 files changed, 56 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 82b2
The single helper here no longer has any users.
Signed-off-by: Alex Williamson
Cc: Joerg Roedel
---
drivers/iommu/pci.h | 29 -
1 file changed, 29 deletions(-)
delete mode 100644 drivers/iommu/pci.h
diff --git a/drivers/iommu/pci.h b/drivers/iommu/pci.h
deleted f
It's broken and has no users.
Signed-off-by: Alex Williamson
---
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 1eab231..6d3b9be 100644
---
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 a
Drop custom code and use PCI provided isolation root support.
Signed-off-by: Alex Williamson
Cc: Varun Sethi
---
drivers/iommu/fsl_pamu_domain.c | 67 ++-
1 file changed, 3 insertions(+), 64 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drive
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 quirk
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 is
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
Cc: David Woodhouse
---
drivers/iommu/intel-iommu.c | 71 +--
1 file c
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
---
drivers/pci/quirks.c | 22 +++
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 cre
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
---
drivers/pci/quirks.c | 16
1 file changed, 16
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 endpoin
This series attempts to fix a couple issues we've had outstanding in
the PCI/IOMMU code for a while. The first issue is with devices that
use the wrong requester ID for DMA transactions. We already have a
sort of half-baked attempt to fix this for several Ricoh devices, but
the fix only helps the
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:18P
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'
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
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:
>>>
>>> [...]
>>
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 wrote:
> > > ...
> > > > An IOMMU is really a specialised bridge
>
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
On Mon, 28 Apr 2014 16:13:19 -0700, Doug Anderson wrote:
> Vikas,
>
>
> On Sun, Apr 27, 2014 at 10:39 AM, Vikas Sajjan wrote:
> > Hi shaik,
> >
> > +Doug, Abhilash,
> >
> > On Sun, Apr 27, 2014 at 1:08 PM, Shaik Ameer Basha
> > wrote:
> >> From: Cho KyongHo
> >>
> >> Signed-off-by: Cho KyongHo
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 d
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
> >
> > Some master device descriptor like fimc-is which is an abstraction
> > of very complex H/W may have multiple System MMUs. For those devices,
> > the design of
On Sun, 27 Apr 2014 20:17:48 +0200, Arnd Bergmann wrote:
> On Sunday 27 April 2014 13:07:47 Shaik Ameer Basha wrote:
> > @@ -542,14 +592,41 @@ static int __init exynos_sysmmu_probe(struct
> > platform_device *pdev)
> > }
> > }
> >
> > + /* Relation between master and System MMU
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 wrote:
> > ...
> > > An IOMMU is really a specialised bridge
> >
> > Is a GART a bridge?
> >
> > IOMMUs can provide three basic fun
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 to an interrupt controller
> > > via a mailbox accessed throug
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 itsel
29 matches
Mail list logo
