tion.
Fixes: 83a3545d9c37 ("arm64: dts: marvell: add SMMU support")
Cc: # 5.9+
Signed-off-by: Tomasz Nowicki
---
arch/arm64/boot/dts/marvell/armada-7040.dtsi | 4
arch/arm64/boot/dts/marvell/armada-8040.dtsi | 4
2 files changed, 8 deletions(-)
diff --git a/arch/arm64/boot/dts/
On 10/23/20 12:33 PM, Robin Murphy wrote:
On 2020-10-23 13:19, Tomasz Nowicki wrote:
Hi Denis,
Sorry for late response, we had to check few things. Please see
comments inline.
On 10/6/20 3:16 PM, Denis Odintsov wrote:
Hi,
Am 15.07.2020 um 09:06 schrieb Tomasz Nowicki :
The series
Hi Denis,
Sorry for late response, we had to check few things. Please see comments
inline.
On 10/6/20 3:16 PM, Denis Odintsov wrote:
Hi,
Am 15.07.2020 um 09:06 schrieb Tomasz Nowicki :
The series is meant to support SMMU for AP806 and a workaround
for accessing ARM SMMU 64bit registers
On 15.07.2020 12:36, Robin Murphy wrote:
On 2020-07-15 08:06, Tomasz Nowicki wrote:
Add specific compatible string for Marvell usage due to errata of
accessing 64bits registers of ARM SMMU, in AP806.
AP806 SoC uses the generic ARM-MMU500, and there's no specific
implementation of Marvell
On 15.07.2020 12:32, Robin Murphy wrote:
On 2020-07-15 08:06, Tomasz Nowicki wrote:
From: Hanna Hawa
Due to erratum #582743, the Marvell Armada-AP806 can't access 64bit to
ARM SMMUv2 registers.
Provide implementation relevant hooks:
- split the writeq/readq to two accesses of writel/readl
-by: Gregory CLEMENT
Signed-off-by: Tomasz Nowicki
---
Documentation/arm64/silicon-errata.rst | 3 ++
drivers/iommu/arm-smmu-impl.c | 45 ++
2 files changed, 48 insertions(+)
diff --git a/Documentation/arm64/silicon-errata.rst
b/Documentation/arm64/silicon
Hawa
Signed-off-by: Gregory CLEMENT
Signed-off-by: Tomasz Nowicki
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index
From: Marcin Wojtas
Add IOMMU node for Marvell AP806 based SoCs together with platform
and PCI device Stream ID mapping.
Signed-off-by: Marcin Wojtas
Signed-off-by: Tomasz Nowicki
---
arch/arm64/boot/dts/marvell/armada-7040.dtsi | 28 +
arch/arm64/boot/dts/marvell/armada-8040
nna Hawa (1):
iommu/arm-smmu: Workaround for Marvell Armada-AP806 SoC erratum
#582743
Marcin Wojtas (1):
arm64: dts: marvell: add SMMU support
Tomasz Nowicki (2):
iommu/arm-smmu: Call configuration impl hook before consuming features
dt-bindings: arm-smmu: add compatible string for Marv
we start consuming them.
Since the Cavium quirk (the only user) does not alter features
it is safe to do so.
Suggested-by: Robin Murphy
Signed-off-by: Tomasz Nowicki
---
drivers/iommu/arm-smmu.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/arm
Hi Will,
On 14.07.2020 10:19, Will Deacon wrote:
Hi Tomasz,
On Thu, Jul 02, 2020 at 10:16:29PM +0200, Tomasz Nowicki wrote:
There were already two versions of series to support SMMU for AP806,
including workaround for accessing ARM SMMU 64bit registers.
First [1] by Hanna Hawa and second [2
On 03.07.2020 11:03, Robin Murphy wrote:
On 2020-07-02 21:16, Tomasz Nowicki wrote:
From: Hanna Hawa
Due to erratum #582743, the Marvell Armada-AP806 can't access 64bit to
ARM SMMUv2 registers.
Provide implementation relevant hooks:
- split the writeq/readq to two accesses of writel/readl
On 03.07.2020 11:16, Robin Murphy wrote:
On 2020-07-02 21:16, Tomasz Nowicki wrote:
From: Marcin Wojtas
Add IOMMU node for Marvell AP806 based SoCs together with platform
and PCI device Stream ID mapping.
Signed-off-by: Marcin Wojtas
Signed-off-by: Tomasz Nowicki
---
arch/arm64/boot/dts
On 03.07.2020 11:05, Robin Murphy wrote:
On 2020-07-02 21:16, Tomasz Nowicki wrote:
Add specific compatible string for Marvell usage due to errata of
accessing 64bits registers of ARM SMMU, in AP806.
AP806 SoC uses the generic ARM-MMU500, and there's no specific
implementation of Marvell
On 03.07.2020 10:24, Robin Murphy wrote:
On 2020-07-02 21:16, Tomasz Nowicki wrote:
We already have 'cfg_probe' hook which meant to override and apply
workarounds while probing ID registers. However, 'cfg_probe' is called
at the very end and therefore for some cases fixing up things becomes
CLEMENT
Signed-off-by: Tomasz Nowicki
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index d7ceb4c34423..7beca9c00b12
From: Marcin Wojtas
Add IOMMU node for Marvell AP806 based SoCs together with platform
and PCI device Stream ID mapping.
Signed-off-by: Marcin Wojtas
Signed-off-by: Tomasz Nowicki
---
arch/arm64/boot/dts/marvell/armada-8040.dtsi | 36 +++
arch/arm64/boot/dts/marvell/armada
-by: Gregory CLEMENT
Signed-off-by: Tomasz Nowicki
---
Documentation/arm64/silicon-errata.rst | 3 ++
drivers/iommu/arm-smmu-impl.c | 52 ++
2 files changed, 55 insertions(+)
diff --git a/Documentation/arm64/silicon-errata.rst
b/Documentation/arm64/silicon
for platform devices like SATA and USB.
[1]: https://lkml.org/lkml/2018/10/15/373
[2]: https://lkml.org/lkml/2019/7/11/426
Hanna Hawa (1):
iommu/arm-smmu: Workaround for Marvell Armada-AP806 SoC erratum
#582743
Marcin Wojtas (1):
arm64: dts: marvell: add SMMU support
Tomasz Nowicki (2
and
cleaner to do ID fixup right away. In preparation for adding Marvell
errata add an extra ID2 fixup hook.
Signed-off-by: Tomasz Nowicki
---
drivers/iommu/arm-smmu.c | 3 +++
drivers/iommu/arm-smmu.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm
Hi Mathieu,
On 05.09.2018 22:34, Mathieu Poirier wrote:
Hi Tomasz,
On Tue, Sep 04, 2018 at 04:20:34PM +0200, Tomasz Nowicki wrote:
For non-VHE systems host kernel runs at EL1 and jumps to EL2 whenever
hypervisor code should be executed. In this case ETM4x driver must
restrict configuration
Hi Mathieu,
On 05.09.2018 22:34, Mathieu Poirier wrote:
Hi Tomasz,
On Tue, Sep 04, 2018 at 04:20:34PM +0200, Tomasz Nowicki wrote:
For non-VHE systems host kernel runs at EL1 and jumps to EL2 whenever
hypervisor code should be executed. In this case ETM4x driver must
restrict configuration
at EL2.
This patch fixes configuration of TRCACATRn register for VHE systems
so that ETM_EXLEVEL_NS_HYP bit is used instead of ETM_EXLEVEL_NS_OS
to on/off kernel tracing. At the same time, it moves common code
to new helper.
Signed-off-by: Tomasz Nowicki
---
drivers/hwtracing/coresight/coresight
at EL2.
This patch fixes configuration of TRCACATRn register for VHE systems
so that ETM_EXLEVEL_NS_HYP bit is used instead of ETM_EXLEVEL_NS_OS
to on/off kernel tracing. At the same time, it moves common code
to new helper.
Signed-off-by: Tomasz Nowicki
---
drivers/hwtracing/coresight/coresight
update the scheduler MC domain so that
it generally reflects the LLC unless the LLC is too large for the
NUMA domain (or package).
Tested-by: Tomasz Nowicki <tomasz.nowi...@cavium.com>
Tested on ThunderX2:
Machine (511GB total)
NUMANode L#0 (P#0 256GB)
Package L#0 + L3 L#0 (32MB)
update the scheduler MC domain so that
it generally reflects the LLC unless the LLC is too large for the
NUMA domain (or package).
Tested-by: Tomasz Nowicki
Tested on ThunderX2:
Machine (511GB total)
NUMANode L#0 (P#0 256GB)
Package L#0 + L3 L#0 (32MB)
L2 L#0 (256KB) + L1d L#0 (32KB
Hi Robin,
On 19.12.2017 17:34, Robin Murphy wrote:
Hi Tomasz,
On 19/12/17 15:13, Tomasz Nowicki wrote:
Here is my lspci output of ThunderX2 for which I am observing kernel
panic coming from
SMMUv3 driver -> arm_smmu_write_strtab_ent() -> BUG_ON(ste_live):
# lspci -vt
-[:00]-+-00
Hi Robin,
On 19.12.2017 17:34, Robin Murphy wrote:
Hi Tomasz,
On 19/12/17 15:13, Tomasz Nowicki wrote:
Here is my lspci output of ThunderX2 for which I am observing kernel
panic coming from
SMMUv3 driver -> arm_smmu_write_strtab_ent() -> BUG_ON(ste_live):
# lspci -vt
-[:00]-+-00
On 19.12.2017 17:37, Alex Williamson wrote:
On Tue, 19 Dec 2017 16:20:21 +0100
Tomasz Nowicki <tomasz.nowi...@caviumnetworks.com> wrote:
While iterating over DMA aliases for a PCI device, for some rare cases
(i.e. PCIe-to-PCI/X bridges) we may get exactly the same ID as initial child
On 19.12.2017 17:37, Alex Williamson wrote:
On Tue, 19 Dec 2017 16:20:21 +0100
Tomasz Nowicki wrote:
While iterating over DMA aliases for a PCI device, for some rare cases
(i.e. PCIe-to-PCI/X bridges) we may get exactly the same ID as initial child
device. In turn, the same ID may get
Hi Robin,
On 19.12.2017 17:34, Robin Murphy wrote:
Hi Tomasz,
On 19/12/17 15:13, Tomasz Nowicki wrote:
Here is my lspci output of ThunderX2 for which I am observing kernel
panic coming from
SMMUv3 driver -> arm_smmu_write_strtab_ent() -> BUG_ON(ste_live):
# lspci -vt
-[:00]-+-00
Hi Robin,
On 19.12.2017 17:34, Robin Murphy wrote:
Hi Tomasz,
On 19/12/17 15:13, Tomasz Nowicki wrote:
Here is my lspci output of ThunderX2 for which I am observing kernel
panic coming from
SMMUv3 driver -> arm_smmu_write_strtab_ent() -> BUG_ON(ste_live):
# lspci -vt
-[:00]-+-00
multiple times too which for some IOMMU drivers is illegal and causes kernel
panic.
Rule out ID duplication prior to device ID array registration.
CC: sta...@vger.kernel.org # v4.14+
Signed-off-by: Tomasz Nowicki <tomasz.nowi...@caviumnetworks.com>
---
drivers/iommu/iommu.
multiple times too which for some IOMMU drivers is illegal and causes kernel
panic.
Rule out ID duplication prior to device ID array registration.
CC: sta...@vger.kernel.org # v4.14+
Signed-off-by: Tomasz Nowicki
---
drivers/iommu/iommu.c | 28
1 file changed, 28
ossible to have two identical SIDs. The question is what we
should do about such case. Presented patch prevents from registering the same
ID so that SMMUv3 is not complaining later on.
Tomasz Nowicki (1):
iommu: Make sure device's ID array elements are unique
drivers/iom
ossible to have two identical SIDs. The question is what we
should do about such case. Presented patch prevents from registering the same
ID so that SMMUv3 is not complaining later on.
Tomasz Nowicki (1):
iommu: Make sure device's ID array elements are unique
drivers/iom
Hi John,
On 19.10.2017 12:25, John Garry wrote:
On 19/10/2017 06:18, Tomasz Nowicki wrote:
Summary:
I'm not at all happy with this specification's attempt to leave out
pieces of information which make parsing things more deterministic. In
this case I'm happy to demote the message level
Hi John,
On 19.10.2017 12:25, John Garry wrote:
On 19/10/2017 06:18, Tomasz Nowicki wrote:
Summary:
I'm not at all happy with this specification's attempt to leave out
pieces of information which make parsing things more deterministic. In
this case I'm happy to demote the message level
On 18.10.2017 19:30, Jeremy Linton wrote:
On 10/18/2017 05:24 AM, Tomasz Nowicki wrote:
On 18.10.2017 07:39, Tomasz Nowicki wrote:
Hi,
On 17.10.2017 17:22, Jeremy Linton wrote:
Hi,
On 10/17/2017 08:25 AM, Tomasz Nowicki wrote:
Hi Jeremy,
I did second round of review and have some more
On 18.10.2017 19:30, Jeremy Linton wrote:
On 10/18/2017 05:24 AM, Tomasz Nowicki wrote:
On 18.10.2017 07:39, Tomasz Nowicki wrote:
Hi,
On 17.10.2017 17:22, Jeremy Linton wrote:
Hi,
On 10/17/2017 08:25 AM, Tomasz Nowicki wrote:
Hi Jeremy,
I did second round of review and have some more
On 18.10.2017 07:39, Tomasz Nowicki wrote:
Hi,
On 17.10.2017 17:22, Jeremy Linton wrote:
Hi,
On 10/17/2017 08:25 AM, Tomasz Nowicki wrote:
Hi Jeremy,
I did second round of review and have some more comments, please see
below:
On 12.10.2017 21:48, Jeremy Linton wrote:
ACPI 6.2 adds a new
On 18.10.2017 07:39, Tomasz Nowicki wrote:
Hi,
On 17.10.2017 17:22, Jeremy Linton wrote:
Hi,
On 10/17/2017 08:25 AM, Tomasz Nowicki wrote:
Hi Jeremy,
I did second round of review and have some more comments, please see
below:
On 12.10.2017 21:48, Jeremy Linton wrote:
ACPI 6.2 adds a new
Hi,
On 17.10.2017 17:22, Jeremy Linton wrote:
Hi,
On 10/17/2017 08:25 AM, Tomasz Nowicki wrote:
Hi Jeremy,
I did second round of review and have some more comments, please see
below:
On 12.10.2017 21:48, Jeremy Linton wrote:
ACPI 6.2 adds a new table, which describes how processing units
Hi,
On 17.10.2017 17:22, Jeremy Linton wrote:
Hi,
On 10/17/2017 08:25 AM, Tomasz Nowicki wrote:
Hi Jeremy,
I did second round of review and have some more comments, please see
below:
On 12.10.2017 21:48, Jeremy Linton wrote:
ACPI 6.2 adds a new table, which describes how processing units
Hi Jeremy,
I did second round of review and have some more comments, please see below:
On 12.10.2017 21:48, Jeremy Linton wrote:
ACPI 6.2 adds a new table, which describes how processing units
are related to each other in tree like fashion. Caches are
also sprinkled throughout the tree and
Hi Jeremy,
I did second round of review and have some more comments, please see below:
On 12.10.2017 21:48, Jeremy Linton wrote:
ACPI 6.2 adds a new table, which describes how processing units
are related to each other in tree like fashion. Caches are
also sprinkled throughout the tree and
Hi Joerg,
On 12.10.2017 12:04, Joerg Roedel wrote:
Hi Tomasz,
On Thu, Oct 12, 2017 at 11:40:27AM +0200, Tomasz Nowicki wrote:
Can you please have a look and see if you are fine with this patch?
How do these changes relate to Robin's IOVA optimizations already in the
iommu-tree
Hi Joerg,
On 12.10.2017 12:04, Joerg Roedel wrote:
Hi Tomasz,
On Thu, Oct 12, 2017 at 11:40:27AM +0200, Tomasz Nowicki wrote:
Can you please have a look and see if you are fine with this patch?
How do these changes relate to Robin's IOVA optimizations already in the
iommu-tree
Hi Joerg,
Can you please have a look and see if you are fine with this patch?
Thanks in advance,
Tomasz
On 20.09.2017 10:52, Tomasz Nowicki wrote:
Here is my test setup where I have stareted performance measurements.
PCIe - TX - PCIe
Hi Joerg,
Can you please have a look and see if you are fine with this patch?
Thanks in advance,
Tomasz
On 20.09.2017 10:52, Tomasz Nowicki wrote:
Here is my test setup where I have stareted performance measurements.
PCIe - TX - PCIe
Hi Joerg,
Can you please have a look and see if you are fine with this patch?
Thanks in advance,
Tomasz
On 20.09.2017 10:52, Tomasz Nowicki wrote:
Here is my test setup where I have stareted performance measurements.
PCIe - TX - PCIe
Hi Joerg,
Can you please have a look and see if you are fine with this patch?
Thanks in advance,
Tomasz
On 20.09.2017 10:52, Tomasz Nowicki wrote:
Here is my test setup where I have stareted performance measurements.
PCIe - TX - PCIe
Hi Robin,
On 21.09.2017 17:52, Robin Murphy wrote:
The cached node mechanism provides a significant performance benefit for
allocations using a 32-bit DMA mask, but in the case of non-PCI devices
or where the 32-bit space is full, the loss of this benefit can be
significant - on large systems
Hi Robin,
On 21.09.2017 17:52, Robin Murphy wrote:
The cached node mechanism provides a significant performance benefit for
allocations using a 32-bit DMA mask, but in the case of non-PCI devices
or where the 32-bit space is full, the loss of this benefit can be
significant - on large systems
Hi Robin,
On 19.09.2017 18:31, Robin Murphy wrote:
The cached node mechanism provides a significant performance benefit for
allocations using a 32-bit DMA mask, but in the case of non-PCI devices
or where the 32-bit space is full, the loss of this benefit can be
significant - on large systems
Hi Robin,
On 19.09.2017 18:31, Robin Murphy wrote:
The cached node mechanism provides a significant performance benefit for
allocations using a 32-bit DMA mask, but in the case of non-PCI devices
or where the 32-bit space is full, the loss of this benefit can be
significant - on large systems
pick the slowest option
to proceed.
This patch reworks flushed_rcache local flag to be additional function
argument instead and control rcache flush step. Also, it updates all users
to do the flush as the last chance.
Signed-off-by: Tomasz Nowicki <tomasz.nowi...@caviumnetworks.com&
pick the slowest option
to proceed.
This patch reworks flushed_rcache local flag to be additional function
argument instead and control rcache flush step. Also, it updates all users
to do the flush as the last chance.
Signed-off-by: Tomasz Nowicki
Reviewed-by: Robin Murphy
Tested-by: Nate
solution is that machines with relatively
small numbers of CPUs may get DAC addresses more frequently for PCI
devices. Please let me know your thoughts.
Changelog:
v1 --> v2
- add missing documentation
- fix typo
Tomasz Nowicki (1):
iommu/iova: Make rcache flush optional on IOVA allocatio
solution is that machines with relatively
small numbers of CPUs may get DAC addresses more frequently for PCI
devices. Please let me know your thoughts.
Changelog:
v1 --> v2
- add missing documentation
- fix typo
Tomasz Nowicki (1):
iommu/iova: Make rcache flush optional on IOVA allocatio
Hi Nate,
On 19.09.2017 04:57, Nate Watterson wrote:
Hi Tomasz,
On 9/18/2017 12:02 PM, Robin Murphy wrote:
Hi Tomasz,
On 18/09/17 11:56, Tomasz Nowicki wrote:
Since IOVA allocation failure is not unusual case we need to flush
CPUs' rcache in hope we will succeed in next round.
However
Hi Nate,
On 19.09.2017 04:57, Nate Watterson wrote:
Hi Tomasz,
On 9/18/2017 12:02 PM, Robin Murphy wrote:
Hi Tomasz,
On 18/09/17 11:56, Tomasz Nowicki wrote:
Since IOVA allocation failure is not unusual case we need to flush
CPUs' rcache in hope we will succeed in next round.
However
Hi Robin,
On 18.09.2017 18:02, Robin Murphy wrote:
Hi Tomasz,
On 18/09/17 11:56, Tomasz Nowicki wrote:
Since IOVA allocation failure is not unusual case we need to flush
CPUs' rcache in hope we will succeed in next round.
However, it is useful to decide whether we need rcache flush step
Hi Robin,
On 18.09.2017 18:02, Robin Murphy wrote:
Hi Tomasz,
On 18/09/17 11:56, Tomasz Nowicki wrote:
Since IOVA allocation failure is not unusual case we need to flush
CPUs' rcache in hope we will succeed in next round.
However, it is useful to decide whether we need rcache flush step
pick the slowest option
to proceed.
This patch reworks flushed_rcache local flag to be additional function
argument instead and control rcache flush step. Also, it updates all users
to do the flush as the last chance.
Signed-off-by: Tomasz Nowicki <tomasz.nowi...@caviumnetworks.com>
-
pick the slowest option
to proceed.
This patch reworks flushed_rcache local flag to be additional function
argument instead and control rcache flush step. Also, it updates all users
to do the flush as the last chance.
Signed-off-by: Tomasz Nowicki
---
drivers/iommu/amd_iommu.c | 5 +
solution is that machines with relatively
small numbers of CPUs may get DAC addresses more frequently for PCI
devices. Please let me know your thoughts.
Tomasz Nowicki (1):
iommu/iova: Make rcache flush optional on IOVA allocation failure
drivers/iommu/amd_iommu.c | 5 +++--
drivers/iomm
solution is that machines with relatively
small numbers of CPUs may get DAC addresses more frequently for PCI
devices. Please let me know your thoughts.
Tomasz Nowicki (1):
iommu/iova: Make rcache flush optional on IOVA allocation failure
drivers/iommu/amd_iommu.c | 5 +++--
drivers/iomm
ers that support ECAM */
int pci_host_common_probe(struct platform_device *pdev,
struct pci_ecam_ops *ops);
#endif
-#endif
Thanks for fixing this.
Reviewed-by: Tomasz Nowicki <t...@semihalf.com>
Tested-by: Tomasz Nowicki <t...@semihalf.com>
Tomasz
AM */
int pci_host_common_probe(struct platform_device *pdev,
struct pci_ecam_ops *ops);
#endif
-#endif
Thanks for fixing this.
Reviewed-by: Tomasz Nowicki
Tested-by: Tomasz Nowicki
Tomasz
Hi Bjorn,
On 21.03.2017 14:47, Bjorn Helgaas wrote:
On Tue, Mar 21, 2017 at 07:38:07AM -0400, Jon Masters wrote:
On 03/16/2017 12:25 PM, David Daney wrote:
On 03/16/2017 07:32 AM, Jon Masters wrote:
Yes, it is now contains "CAVxxx" as _HID for device config object.
Which is different
Hi Bjorn,
On 21.03.2017 14:47, Bjorn Helgaas wrote:
On Tue, Mar 21, 2017 at 07:38:07AM -0400, Jon Masters wrote:
On 03/16/2017 12:25 PM, David Daney wrote:
On 03/16/2017 07:32 AM, Jon Masters wrote:
Yes, it is now contains "CAVxxx" as _HID for device config object.
Which is different
On 19.01.2017 11:57, Aleksey Makarov wrote:
Hi Tomasz,
On 01/19/2017 11:55 AM, Tomasz Nowicki wrote:
Hi Aleksey,
On 17.01.2017 16:14, Aleksey Makarov wrote:
Enable the Extended Stream ID feature when available.
This patch on top of series "KVM PCIe/MSI passthrough on ARM/ARM64
and
On 19.01.2017 11:57, Aleksey Makarov wrote:
Hi Tomasz,
On 01/19/2017 11:55 AM, Tomasz Nowicki wrote:
Hi Aleksey,
On 17.01.2017 16:14, Aleksey Makarov wrote:
Enable the Extended Stream ID feature when available.
This patch on top of series "KVM PCIe/MSI passthrough on ARM/ARM64
and
1:1 map). Eventually SMMU drops such device because the stream ID is
out of range. This is the case for all devices connected as external
endpoints on ThunderX.
To fix above issue enable the Extended Stream ID optional feature when
available.
Please add my:
Reviewed-by: To
such device because the stream ID is
out of range. This is the case for all devices connected as external
endpoints on ThunderX.
To fix above issue enable the Extended Stream ID optional feature when
available.
Please add my:
Reviewed-by: Tomasz Nowicki
Tested-by: Tomasz Nowicki
Thank
, let's correct this.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Acked-by: Will Deacon <will.dea...@arm.com>
For patches [15-18]:
Reviewed-by: Tomasz Nowicki <tomasz.nowi...@caviumnetworks.com>
Thanks,
Tomasz
---
v7 -> v8:
- added Will's A-b
---
drivers/io
, let's correct this.
Signed-off-by: Eric Auger
Acked-by: Will Deacon
For patches [15-18]:
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
---
v7 -> v8:
- added Will's A-b
---
drivers/iommu/arm-smmu-v3.c | 2 --
drivers/iommu/arm-smmu.c| 2 --
2 files changed, 4 deletions(-)
diff --
On 17.01.2017 15:06, Tomasz Nowicki wrote:
On 17.01.2017 14:53, Auger Eric wrote:
Hi Tomasz,
On 17/01/2017 14:40, Tomasz Nowicki wrote:
On 11.01.2017 10:41, Eric Auger wrote:
This new function checks whether all MSI irq domains
implement IRQ remapping. This is useful to understand
whether
On 17.01.2017 15:06, Tomasz Nowicki wrote:
On 17.01.2017 14:53, Auger Eric wrote:
Hi Tomasz,
On 17/01/2017 14:40, Tomasz Nowicki wrote:
On 11.01.2017 10:41, Eric Auger wrote:
This new function checks whether all MSI irq domains
implement IRQ remapping. This is useful to understand
whether
yngier <marc.zyng...@arm.com>
Reviewed-by: Tomasz Nowicki <tomasz.nowi...@caviumnetworks.com>
Thanks,
Tomasz
---
v7 -> v8:
- remove h variable in irq_domain_hierarchical_is_msi_remap
- add Marc's R-b
v6:
- add IRQ_DOMAIN_FLAG_MSI as suggested by Marc
- add irq_domain_is_msi, ir
to check all MSI irq domains have
MSI remapping support when assessing the safety of IRQ assignment
to a guest.
irq_domain_hierarchical_is_msi_remap() allows to check if an
irq domain or any parent implements MSI remapping.
Signed-off-by: Eric Auger
Reviewed-by: Marc Zyngier
Reviewed-by: Tomasz
On 11.01.2017 10:41, Eric Auger wrote:
Now we have a flag value indicating an IRQ domain implements MSI,
let's set it on msi_create_irq_domain().
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Reviewed-by: Marc Zyngier <marc.zyng...@arm.com>
Reviewed-by: Tomasz Nowicki
On 11.01.2017 10:41, Eric Auger wrote:
Now we have a flag value indicating an IRQ domain implements MSI,
let's set it on msi_create_irq_domain().
Signed-off-by: Eric Auger
Reviewed-by: Marc Zyngier
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
---
v7 -> v8
- Added Marc's R-b
v6:
sysfs.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Acked-by: Will Deacon <will.dea...@arm.com>
Reviewed-by: Tomasz Nowicki <tomasz.nowi...@caviumnetworks.com>
Thanks,
Tomasz
---
v7 -> v8:
- added Will's A-b
v4: creation
---
drivers/iommu/arm-smmu-v3.c | 28 ++
sysfs.
Signed-off-by: Eric Auger
Acked-by: Will Deacon
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
---
v7 -> v8:
- added Will's A-b
v4: creation
---
drivers/iommu/arm-smmu-v3.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/iommu/arm-smmu-v3.
On 17.01.2017 14:53, Auger Eric wrote:
Hi Tomasz,
On 17/01/2017 14:40, Tomasz Nowicki wrote:
On 11.01.2017 10:41, Eric Auger wrote:
This new function checks whether all MSI irq domains
implement IRQ remapping. This is useful to understand
whether VFIO passthrough is safe with respect
On 17.01.2017 14:53, Auger Eric wrote:
Hi Tomasz,
On 17/01/2017 14:40, Tomasz Nowicki wrote:
On 11.01.2017 10:41, Eric Auger wrote:
This new function checks whether all MSI irq domains
implement IRQ remapping. This is useful to understand
whether VFIO passthrough is safe with respect
On 11.01.2017 10:41, Eric Auger wrote:
This new function checks whether all MSI irq domains
implement IRQ remapping. This is useful to understand
whether VFIO passthrough is safe with respect to interrupts.
On ARM typically an MSI controller can sit downstream
to the IOMMU without preventing
On 11.01.2017 10:41, Eric Auger wrote:
This new function checks whether all MSI irq domains
implement IRQ remapping. This is useful to understand
whether VFIO passthrough is safe with respect to interrupts.
On ARM typically an MSI controller can sit downstream
to the IOMMU without preventing
com>
Reviewed-by: Tomasz Nowicki <tomasz.nowi...@caviumnetworks.com>
Thanks,
Tomasz
---
v3 -> v4:
- do not handle PCI host bridge windows anymore
- encode prot
RFC v2 -> v3:
- use existing get/put_resv_regions
RFC v1 -> v2:
- use defines for MSI IOVA base and length
---
drivers/
On 11.01.2017 10:41, Eric Auger wrote:
The get() populates the list with the MSI IOVA reserved window.
At the moment an arbitray MSI IOVA window is set at 0x800
of size 1MB. This will allow to report those info in iommu-group
sysfs.
Signed-off-by: Eric Auger
Reviewed-by: Tomasz Nowicki
On 11.01.2017 10:41, Eric Auger wrote:
As we introduced new reserved region types which do not require
mapping, let's make sure we only map direct mapped regions.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Reviewed-by: Tomasz Nowicki <tomasz.nowi...@caviumnetworks.com>
Th
On 11.01.2017 10:41, Eric Auger wrote:
As we introduced new reserved region types which do not require
mapping, let's make sure we only map direct mapped regions.
Signed-off-by: Eric Auger
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
---
v3 -> v4:
- use region's type and reword com
-by: Eric Auger <eric.au...@redhat.com>
Reviewed-by: Tomasz Nowicki <tomasz.nowi...@caviumnetworks.com>
Thanks,
Tomasz
---
v6 -> v7:
- avoid merge of regions of different type
v3 -> v4:
- take the iommu_group lock in iommu_get_group_resv_regions
- the list now is sorted and ov
-by: Eric Auger
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
---
v6 -> v7:
- avoid merge of regions of different type
v3 -> v4:
- take the iommu_group lock in iommu_get_group_resv_regions
- the list now is sorted and overlaps are checked
NOTE:
- we do not move list elements from device to
On 11.01.2017 10:41, Eric Auger wrote:
Introduce a new helper serving the purpose to allocate a reserved
region. This will be used in iommu driver implementing reserved
region callbacks.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Reviewed-by: Tomasz Nowicki <to
On 11.01.2017 10:41, Eric Auger wrote:
Introduce a new helper serving the purpose to allocate a reserved
region. This will be used in iommu driver implementing reserved
region callbacks.
Signed-off-by: Eric Auger
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
---
v3 -> v4:
-
address space or because
they are not translated by the IOMMU and need special handling)
So let's rename the struct and also the callbacks.
Signed-off-by: Eric Auger <eric.au...@redhat.com>
Acked-by: Robin Murphy <robin.mur...@arm.com>
Reviewed-by: Tomasz Nowicki <tomasz.nowi...@cav
address space or because
they are not translated by the IOMMU and need special handling)
So let's rename the struct and also the callbacks.
Signed-off-by: Eric Auger
Acked-by: Robin Murphy
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
---
v3 -> v4:
- add Robin's A-b
---
drivers/io
1 - 100 of 1330 matches
Mail list logo
