a caution.
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
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 is
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 is
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/
ff-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/si
Hanna 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
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
s
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):
iommu/arm-smmu: Call configuration impl hook before consuming features
dt-bindings: arm-smmu: add compatible string for
cted features before 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
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/
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 fixi
egory 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..7beca9c
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
d-off-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/si
e 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 Nowic
ems it is better 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
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 to
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
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
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
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
driver
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 mes
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
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 desc
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?
Th
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 th
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 th
e we 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:
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.
Howeve
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
e we 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
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
CI controllers 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
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 from
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
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
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(-)
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
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
Reviewed-by: Marc Zyngier
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
---
v7 -> v8
- Added Marc's
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-smm
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 to
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 VFI
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
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
---
v3 -> v4:
- use region's type and
: 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
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
Acked-by: Robin Murphy
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
---
v3 -> v4:
- add Robin's A-b
---
space to a managed cookie, and extend the mapping
routine to implement a trivial linear allocator in such cases, to avoid
the needless overhead of a full-blown IOVA domain.
Signed-off-by: Robin Murphy
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
---
drivers/iommu/dma-iommu.c
My apologise for not adding 2nd version info of this patch to mail subject.
Thanks,
Tomasz
On 16.01.2017 08:16, Tomasz Nowicki wrote:
The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs
are unique across all SMMU instances on affected Cavium systems.
Currently, the
ASIDs consistently for all SMMU instances.
Signed-off-by: Tomasz Nowicki
Reviewed-by: Robin Murphy
Reviewed-by: Tirumalesh Chalamarla
---
drivers/iommu/arm-smmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index a60cded..476fab9
with internal 10G VNIC and Intel IXGBE
NIC. Please feel free to add my:
Tested-by: Tomasz Nowicki
Thanks,
Tomasz
On 12.01.2017 07:41, Tomasz Nowicki wrote:
On 11.01.2017 13:19, Robin Murphy wrote:
On 11/01/17 11:51, Tomasz Nowicki wrote:
The goal of erratum #27704 workaround was to make sure that ASIDs and
VMIDs
are unique across all SMMU instances on affected Cavium systems.
Currently, the workaround
On 11.01.2017 13:19, Robin Murphy wrote:
On 11/01/17 11:51, Tomasz Nowicki wrote:
The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs
are unique across all SMMU instances on affected Cavium systems.
Currently, the workaround code partitions ASIDs and VMIDs by increasing
rt for stage-1
AArch64 contexts for Cavium SMMUv2 model so that we use ASIDs consistently.
Signed-off-by: Tomasz Nowicki
---
drivers/iommu/arm-smmu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index a60cded..ae8f059 100644
--- a/drivers
On 04.01.2017 08:02, Hanjun Guo wrote:
Hi Tomasz,
On 2017/1/3 15:41, Tomasz Nowicki wrote:
Hi,
Can we merge patch 4 & 6 into one patch so that we keep refactoring part
as one piece ? I do not see a reason to keep them separate or have patch
5 in between. You can refactor what needs t
On 03.01.2017 10:37, Tomasz Nowicki wrote:
On 03.01.2017 09:43, Tomasz Nowicki wrote:
On 02.01.2017 14:31, Hanjun Guo wrote:
For devices connecting to ITS, it needs dev id to identify
itself, and this dev id is represented in the IORT table in
named componant node [1] for platform devices, so
On 03.01.2017 09:43, Tomasz Nowicki wrote:
On 02.01.2017 14:31, Hanjun Guo wrote:
For devices connecting to ITS, it needs dev id to identify
itself, and this dev id is represented in the IORT table in
named componant node [1] for platform devices, so in this
patch we will scan the IORT to
oduce iort_pmsi_get_dev_id() with pointer dev passed
in for that purpose.
[1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
Signed-off-by: Hanjun Guo
Tested-by: Sinan Kaya
Tested-by: Majun
Tested-by: Xinwei Kong
Cc: Marc Zyngier
Cc: Lorenzo Pieralisi
Cc: Tomasz Nowicki
Cc: T
-its-platform-msi.c
Thanks,
Tomasz
On 02.01.2017 14:31, Hanjun Guo wrote:
Introduce its_pmsi_init_one() to refactor the code to isolate
ACPI&DT common code to prepare for ACPI later.
Signed-off-by: Hanjun Guo
Tested-by: Sinan Kaya
Tested-by: Majun
Tested-by: Xinwei Kong
Cc: Marc Zyngier
Cc
s_start == bus_res->start &&
+ if (e->segment == seg && e->bus_start <= bus_res->start &&
e->bus_end >= bus_res->end)
return e->addr;
}
Looks good to me.
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
On 02.12.2016 07:42, Duc Dang wrote:
On Thu, Dec 1, 2016 at 9:50 PM, Jon Masters wrote:
On 11/30/2016 07:28 PM, Bjorn Helgaas wrote:
I'm hoping to end up with something like this:
https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=51ad4df79a9b7f2a66b346a46b21a7
Hi Bjorn,
On 01.12.2016 01:28, Bjorn Helgaas wrote:
Hi Tomasz,
On Tue, Nov 15, 2016 at 10:14:57AM +0100, Tomasz Nowicki wrote:
ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
compliant with ECAM standard. It uses non-standard configuration space
accessors (see
On 23.11.2016 19:22, Bjorn Helgaas wrote:
On Wed, Nov 23, 2016 at 12:21:03PM +0100, Tomasz Nowicki wrote:
Hi Bjorn,
On 23.11.2016 00:13, Bjorn Helgaas wrote:
Hi Tomasz,
On Fri, Jun 10, 2016 at 09:55:19PM +0200, Tomasz Nowicki wrote:
Implement pci_acpi_scan_root and other arch-specific call
acpi_pci_root_ops and fill in with data for each bridge. Now it is safe
to have different controller-specific info. As a consequence free
acpi_pci_root_ops when host bridge is released.
No functional changes in this patch.
Signed-off-by: Tomasz Nowicki
---
arch/arm64/kernel/pci.c | 17
Hi Bjorn,
On 23.11.2016 00:13, Bjorn Helgaas wrote:
Hi Tomasz,
On Fri, Jun 10, 2016 at 09:55:19PM +0200, Tomasz Nowicki wrote:
Implement pci_acpi_scan_root and other arch-specific call so that ARM64
can start using ACPI to setup and enumerate PCI buses.
Prior to buses enumeration the
On 22.11.2016 13:08, Dongdong Liu wrote:
PCIe controller in Hip05/HIP06/HIP07 SoCs is not ECAM compliant.
It is non ECAM only for the RC bus config space;for any other bus
underneath the root bus we support ECAM access.
Add specific quirks for PCI config space accessors.This involves:
1. New init
Use _UID to match segment to tell which root bus the PNP0C02
resource belong to.
Signed-off-by: Dongdong Liu
Signed-off-by: Tomasz Nowicki
---
drivers/pci/pci-acpi.c | 69 ++
drivers/pci/pci.h | 4 +++
2 files changed, 73 insertions(+)
diff -
Hi Dongdong,
I rewrite your code so that it could be used for ThunderX as well.
This assumes _UID&segment is the right way of looking up corelated RC.
Of course acpi_get_rc_resources() and its acpi_* helpers should go to
pci-acpi.c.
Tomasz
static int acpi_get_rc_addr(struct acpi_device *adev,
/lpieralisi/linux.git
acpi/iort-smmu-v7
Tested on Juno and FVP models for ARM SMMU v1 and v3 probing path.
For all series:
Reviewed-by: Tomasz Nowicki
Thanks,
Tomasz
entries for each PEM segment. Each contains platform IDs,
mentioned pci_thunder_pem_ops and CFG resources.
Quirk is considered for ThunderX silicon pass2.x only which is identified
via MCFG revision 1.
Signed-off-by: Tomasz Nowicki
---
drivers/acpi/pci_mcfg.c| 20 +++
drivers
using the same way for accessing off-chip devices
(so-called PEM) as silicon pass-2.x so we need to add PEM quirk
entries too.
Quirk is considered for ThunderX silicon pass1.x only which is identified
via MCFG revision 2.
Signed-off-by: Tomasz Nowicki
---
drivers/acpi/pci_mcfg.c
1] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
(pci/ecam-v6)
Tomasz Nowicki (2):
PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon
version
PCI: thunder: Enable ACPI PCI controller for ThunderX pass1.x silicon
version
drivers/acpi/pci_mcfg.c
passthrough mode successfully on ACPI host using ThunderX 1-socket board.
Also, for my tests I used Eric's patches:
https://github.com/eauger/linux/commits/v4.9-rc3-reserved-rfc-v2
Including bug fix above:
Tested-by: Tomasz Nowicki for all series.
+
+ if (!IORT_IRQ_MASK(glb_irq[1])) /*
Hi Bjorn,
On 21.09.2016 21:18, Bjorn Helgaas wrote:
On Wed, Sep 21, 2016 at 11:58:22AM -0700, Duc Dang wrote:
On Wed, Sep 21, 2016 at 11:04 AM, Bjorn Helgaas wrote:
On Wed, Sep 21, 2016 at 03:05:49PM +0100, Lorenzo Pieralisi wrote:
The existing x86 practice is to use PNP0C02 devices for th
On 20.09.2016 15:08, Bjorn Helgaas wrote:
On Tue, Sep 20, 2016 at 09:06:23AM +0200, Tomasz Nowicki wrote:
On 19.09.2016 17:45, Bjorn Helgaas wrote:
On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
On 19.09.2016 20:09, Bjorn Helgaas wrote:
On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote:
thunder-pem driver stands for being ACPI based PCI host controller.
However, there is no standard way to describe its PEM-specific register
ranges in ACPI tables. Thus we add
On 19.09.2016 17:45, Bjorn Helgaas wrote:
On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
compliant with ECAM standard. It uses non-standard configuration space
accessors (see pci_thunder_pem_ops) and
On 13.09.2016 00:24, Duc Dang wrote:
On Fri, Sep 9, 2016 at 12:24 PM, Tomasz Nowicki wrote:
Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite CFG accessors
set and configuration space range.
In first place
Hi Liu,
On 13.09.2016 04:36, Dongdong Liu wrote:
Hi Tomasz
在 2016/9/10 3:24, Tomasz Nowicki 写道:
Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite CFG
accessors
set and configuration space range.
In first
On 13.09.2016 00:47, Duc Dang wrote:
On Mon, Sep 12, 2016 at 3:24 PM, Duc Dang wrote:
On Fri, Sep 9, 2016 at 12:24 PM, Tomasz Nowicki wrote:
Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite CFG accessors
On 12.09.2016 20:54, Tomasz Nowicki wrote:
IORT shows representation of IO topology for ARM based systems.
It describes how various components are connected together on
parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
http://infocenter.arm.com/help/topic/com.arm.doc.de
upport
in this place e.g. GTDT table.
Signed-off-by: Tomasz Nowicki
Acked-by: Rafael J. Wysocki
Reviewed-by: Hanjun Guo
Reviewed-by: Lorenzo Pieralisi
---
drivers/acpi/Kconfig| 4 +
drivers/acpi/Makefile | 2 +
drivers/acpi/arm64/Kconfig | 6 ++
drivers/acpi/arm64/Makefile
al
variable and drop the parameter from its_probe_one. Users can refer to it
in more convenient way then.
Signed-off-by: Hanjun Guo
Signed-off-by: Tomasz Nowicki
---
drivers/irqchip/irq-gic-v3-its.c | 65 ++
drivers/irqchip/irq-gic-v3.c | 7 ++--
include/li
.
Signed-off-by: Tomasz Nowicki
Acked-by: Marc Zyngier
Reviewed-by: Hanjun Guo
---
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-gic-v3-its.c | 61 +++-
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/Kconfig b/drivers
upport
in this place e.g. GTDT table.
Signed-off-by: Tomasz Nowicki
Acked-by: Rafael J. Wysocki
Reviewed-by: Hanjun Guo
Reviewed-by: Lorenzo Pieralisi
---
drivers/acpi/Kconfig| 4 +
drivers/acpi/Makefile | 2 +
drivers/acpi/arm64/Kconfig | 6 ++
drivers/acpi/arm64/Makefile
: Tomasz Nowicki
Acked-by: Marc Zyngier
Reviewed-by: Hanjun Guo
---
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 44
1 file changed, 44 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index d2c2496
Firmware agnostic code lands in common functions which do necessary
domain initialization based on unique domain handler. DT specific
code goes to DT specific init call.
Signed-off-by: Tomasz Nowicki
Acked-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 44
1 - 100 of 675 matches
Mail list logo
