* [PATCH v5 1/5] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
From: Krishna Reddy @ 2020-05-21 23:31 UTC (permalink / raw)
Cc: snikam, mperttunen, bhuntsman, will, joro, linux-kernel,
praithatha, talho, iommu, nicolinc, linux-tegra, yhsu, treding,
robin.murphy, linux-arm-kernel, bbiswas
In-Reply-To: <20200521233107.11968-1-vdumpa@nvidia.com>
NVIDIA's Tegra194 soc uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 soc.
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
---
MAINTAINERS | 2 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/arm-smmu-impl.c | 3 +
drivers/iommu/arm-smmu-nvidia.c | 161 ++++++++++++++++++++++++++++++++
drivers/iommu/arm-smmu.h | 1 +
5 files changed, 168 insertions(+), 1 deletion(-)
create mode 100644 drivers/iommu/arm-smmu-nvidia.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ecc0749810b0..0d8c966ecf17 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16560,9 +16560,11 @@ F: drivers/i2c/busses/i2c-tegra.c
TEGRA IOMMU DRIVERS
M: Thierry Reding <thierry.reding@gmail.com>
+R: Krishna Reddy <vdumpa@nvidia.com>
L: linux-tegra@vger.kernel.org
S: Supported
F: drivers/iommu/tegra*
+F: drivers/iommu/arm-smmu-nvidia.c
TEGRA KBC DRIVER
M: Laxman Dewangan <ldewangan@nvidia.com>
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 57cf4ba5e27c..35542df00da7 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o amd_iommu_init.o amd_iommu_quirks.o
obj-$(CONFIG_AMD_IOMMU_DEBUGFS) += amd_iommu_debugfs.o
obj-$(CONFIG_AMD_IOMMU_V2) += amd_iommu_v2.o
obj-$(CONFIG_ARM_SMMU) += arm_smmu.o
-arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-qcom.o
+arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-qcom.o arm-smmu-nvidia.o
obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o
obj-$(CONFIG_DMAR_TABLE) += dmar.o
obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o intel-pasid.o
diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
index 74d97a886e93..dcdd513323aa 100644
--- a/drivers/iommu/arm-smmu-impl.c
+++ b/drivers/iommu/arm-smmu-impl.c
@@ -158,6 +158,9 @@ struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
*/
switch (smmu->model) {
case ARM_MMU500:
+ if (of_device_is_compatible(smmu->dev->of_node,
+ "nvidia,tegra194-smmu-500"))
+ return nvidia_smmu_impl_init(smmu);
smmu->impl = &arm_mmu500_impl;
break;
case CAVIUM_SMMUV2:
diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu/arm-smmu-nvidia.c
new file mode 100644
index 000000000000..dafc293a4521
--- /dev/null
+++ b/drivers/iommu/arm-smmu-nvidia.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Nvidia ARM SMMU v2 implementation quirks
+// Copyright (C) 2019 NVIDIA CORPORATION. All rights reserved.
+
+#define pr_fmt(fmt) "nvidia-smmu: " fmt
+
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "arm-smmu.h"
+
+/* Tegra194 has three ARM MMU-500 Instances.
+ * Two of them are used together for Interleaved IOVA accesses and
+ * used by Non-Isochronous Hw devices for SMMU translations.
+ * Third one is used for SMMU translations from Isochronous HW devices.
+ * It is possible to use this Implementation to program either
+ * all three or two of the instances identically as desired through
+ * DT node.
+ *
+ * Programming all the three instances identically comes with redundant tlb
+ * invalidations as all three never need to be tlb invalidated for a HW device.
+ *
+ * When Linux Kernel supports multiple SMMU devices, The SMMU device used for
+ * Isochornous HW devices should be added as a separate ARM MMU-500 device
+ * in DT and be programmed independently for efficient tlb invalidates.
+ *
+ */
+#define MAX_SMMU_INSTANCES 3
+
+#define TLB_LOOP_TIMEOUT 1000000 /* 1s! */
+#define TLB_SPIN_COUNT 10
+
+struct nvidia_smmu {
+ struct arm_smmu_device smmu;
+ unsigned int num_inst;
+ void __iomem *bases[MAX_SMMU_INSTANCES];
+};
+
+#define to_nvidia_smmu(s) container_of(s, struct nvidia_smmu, smmu)
+
+#define nsmmu_page(smmu, inst, page) \
+ (((inst) ? to_nvidia_smmu(smmu)->bases[(inst)] : smmu->base) + \
+ ((page) << smmu->pgshift))
+
+static u32 nsmmu_read_reg(struct arm_smmu_device *smmu,
+ int page, int offset)
+{
+ return readl_relaxed(nsmmu_page(smmu, 0, page) + offset);
+}
+
+static void nsmmu_write_reg(struct arm_smmu_device *smmu,
+ int page, int offset, u32 val)
+{
+ unsigned int i;
+
+ for (i = 0; i < to_nvidia_smmu(smmu)->num_inst; i++)
+ writel_relaxed(val, nsmmu_page(smmu, i, page) + offset);
+}
+
+static u64 nsmmu_read_reg64(struct arm_smmu_device *smmu,
+ int page, int offset)
+{
+ return readq_relaxed(nsmmu_page(smmu, 0, page) + offset);
+}
+
+static void nsmmu_write_reg64(struct arm_smmu_device *smmu,
+ int page, int offset, u64 val)
+{
+ unsigned int i;
+
+ for (i = 0; i < to_nvidia_smmu(smmu)->num_inst; i++)
+ writeq_relaxed(val, nsmmu_page(smmu, i, page) + offset);
+}
+
+static void nsmmu_tlb_sync(struct arm_smmu_device *smmu, int page,
+ int sync, int status)
+{
+ u32 reg;
+ unsigned int i;
+ unsigned int spin_cnt, delay;
+
+ arm_smmu_writel(smmu, page, sync, 0);
+
+ for (delay = 1; delay < TLB_LOOP_TIMEOUT; delay *= 2) {
+ for (spin_cnt = TLB_SPIN_COUNT; spin_cnt > 0; spin_cnt--) {
+ reg = 0;
+ for (i = 0; i < to_nvidia_smmu(smmu)->num_inst; i++) {
+ reg |= readl_relaxed(
+ nsmmu_page(smmu, i, page) + status);
+ }
+ if (!(reg & ARM_SMMU_sTLBGSTATUS_GSACTIVE))
+ return;
+ cpu_relax();
+ }
+ udelay(delay);
+ }
+ dev_err_ratelimited(smmu->dev,
+ "TLB sync timed out -- SMMU may be deadlocked\n");
+}
+
+static int nsmmu_reset(struct arm_smmu_device *smmu)
+{
+ u32 reg;
+ unsigned int i;
+
+ for (i = 0; i < to_nvidia_smmu(smmu)->num_inst; i++) {
+ /* clear global FSR */
+ reg = readl_relaxed(nsmmu_page(smmu, i, ARM_SMMU_GR0) +
+ ARM_SMMU_GR0_sGFSR);
+ writel_relaxed(reg, nsmmu_page(smmu, i, ARM_SMMU_GR0) +
+ ARM_SMMU_GR0_sGFSR);
+ }
+
+ return 0;
+}
+
+static const struct arm_smmu_impl nvidia_smmu_impl = {
+ .read_reg = nsmmu_read_reg,
+ .write_reg = nsmmu_write_reg,
+ .read_reg64 = nsmmu_read_reg64,
+ .write_reg64 = nsmmu_write_reg64,
+ .reset = nsmmu_reset,
+ .tlb_sync = nsmmu_tlb_sync,
+};
+
+struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu)
+{
+ unsigned int i;
+ struct nvidia_smmu *nsmmu;
+ struct resource *res;
+ struct device *dev = smmu->dev;
+ struct platform_device *pdev = to_platform_device(smmu->dev);
+
+ nsmmu = devm_kzalloc(smmu->dev, sizeof(*nsmmu), GFP_KERNEL);
+ if (!nsmmu)
+ return ERR_PTR(-ENOMEM);
+
+ nsmmu->smmu = *smmu;
+ /* Instance 0 is ioremapped by arm-smmu.c */
+ nsmmu->num_inst = 1;
+
+ for (i = 1; i < MAX_SMMU_INSTANCES; i++) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ if (!res)
+ break;
+ nsmmu->bases[i] = devm_ioremap_resource(dev, res);
+ if (IS_ERR(nsmmu->bases[i]))
+ return (struct arm_smmu_device *)nsmmu->bases[i];
+ nsmmu->num_inst++;
+ }
+
+ nsmmu->smmu.impl = &nvidia_smmu_impl;
+ devm_kfree(smmu->dev, smmu);
+ pr_info("NVIDIA ARM SMMU Implementation, Instances=%d\n",
+ nsmmu->num_inst);
+
+ return &nsmmu->smmu;
+}
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index 8d1cd54d82a6..67c3c6f5c49e 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -450,6 +450,7 @@ static inline void arm_smmu_writeq(struct arm_smmu_device *smmu, int page,
struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu);
struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu);
+struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu);
int arm_mmu500_reset(struct arm_smmu_device *smmu);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 3/5] iommu/arm-smmu: Add global/context fault implementation hooks
From: Krishna Reddy @ 2020-05-21 23:31 UTC (permalink / raw)
Cc: snikam, mperttunen, bhuntsman, will, joro, linux-kernel,
praithatha, talho, iommu, nicolinc, linux-tegra, yhsu, treding,
robin.murphy, linux-arm-kernel, bbiswas
In-Reply-To: <20200521233107.11968-1-vdumpa@nvidia.com>
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
---
drivers/iommu/arm-smmu-nvidia.c | 100 ++++++++++++++++++++++++++++++++
drivers/iommu/arm-smmu.c | 11 +++-
drivers/iommu/arm-smmu.h | 3 +
3 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu/arm-smmu-nvidia.c
index dafc293a4521..5999b6a77099 100644
--- a/drivers/iommu/arm-smmu-nvidia.c
+++ b/drivers/iommu/arm-smmu-nvidia.c
@@ -117,6 +117,104 @@ static int nsmmu_reset(struct arm_smmu_device *smmu)
return 0;
}
+static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
+{
+ return container_of(dom, struct arm_smmu_domain, domain);
+}
+
+static irqreturn_t nsmmu_global_fault_inst(int irq,
+ struct arm_smmu_device *smmu,
+ int inst)
+{
+ u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
+
+ gfsr = readl_relaxed(nsmmu_page(smmu, inst, 0) + ARM_SMMU_GR0_sGFSR);
+ gfsynr0 = readl_relaxed(nsmmu_page(smmu, inst, 0) +
+ ARM_SMMU_GR0_sGFSYNR0);
+ gfsynr1 = readl_relaxed(nsmmu_page(smmu, inst, 0) +
+ ARM_SMMU_GR0_sGFSYNR1);
+ gfsynr2 = readl_relaxed(nsmmu_page(smmu, inst, 0) +
+ ARM_SMMU_GR0_sGFSYNR2);
+
+ if (!gfsr)
+ return IRQ_NONE;
+
+ dev_err_ratelimited(smmu->dev,
+ "Unexpected global fault, this could be serious\n");
+ dev_err_ratelimited(smmu->dev,
+ "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
+ gfsr, gfsynr0, gfsynr1, gfsynr2);
+
+ writel_relaxed(gfsr, nsmmu_page(smmu, inst, 0) + ARM_SMMU_GR0_sGFSR);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t nsmmu_global_fault(int irq, void *dev)
+{
+ int inst;
+ irqreturn_t irq_ret = IRQ_NONE;
+ struct arm_smmu_device *smmu = dev;
+
+ for (inst = 0; inst < to_nvidia_smmu(smmu)->num_inst; inst++) {
+ irq_ret = nsmmu_global_fault_inst(irq, smmu, inst);
+ if (irq_ret == IRQ_HANDLED)
+ return irq_ret;
+ }
+
+ return irq_ret;
+}
+
+static irqreturn_t nsmmu_context_fault_bank(int irq,
+ struct arm_smmu_device *smmu,
+ int idx, int inst)
+{
+ u32 fsr, fsynr, cbfrsynra;
+ unsigned long iova;
+
+ fsr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSR);
+ if (!(fsr & ARM_SMMU_FSR_FAULT))
+ return IRQ_NONE;
+
+ fsynr = readl_relaxed(nsmmu_page(smmu, inst, smmu->numpage + idx) +
+ ARM_SMMU_CB_FSYNR0);
+ iova = readq_relaxed(nsmmu_page(smmu, inst, smmu->numpage + idx) +
+ ARM_SMMU_CB_FAR);
+ cbfrsynra = readl_relaxed(nsmmu_page(smmu, inst, 1) +
+ ARM_SMMU_GR1_CBFRSYNRA(idx));
+
+ dev_err_ratelimited(smmu->dev,
+ "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x, cbfrsynra=0x%x, cb=%d\n",
+ fsr, iova, fsynr, cbfrsynra, idx);
+
+ writel_relaxed(fsr, nsmmu_page(smmu, inst, smmu->numpage + idx) +
+ ARM_SMMU_CB_FSR);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t nsmmu_context_fault(int irq, void *dev)
+{
+ int inst, idx;
+ irqreturn_t irq_ret = IRQ_NONE;
+ struct iommu_domain *domain = dev;
+ struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+ struct arm_smmu_device *smmu = smmu_domain->smmu;
+
+ for (inst = 0; inst < to_nvidia_smmu(smmu)->num_inst; inst++) {
+ /* Interrupt line shared between all context faults.
+ * Check for faults across all contexts.
+ */
+ for (idx = 0; idx < smmu->num_context_banks; idx++) {
+ irq_ret = nsmmu_context_fault_bank(irq, smmu,
+ idx, inst);
+
+ if (irq_ret == IRQ_HANDLED)
+ return irq_ret;
+ }
+ }
+
+ return irq_ret;
+}
+
static const struct arm_smmu_impl nvidia_smmu_impl = {
.read_reg = nsmmu_read_reg,
.write_reg = nsmmu_write_reg,
@@ -124,6 +222,8 @@ static const struct arm_smmu_impl nvidia_smmu_impl = {
.write_reg64 = nsmmu_write_reg64,
.reset = nsmmu_reset,
.tlb_sync = nsmmu_tlb_sync,
+ .global_fault = nsmmu_global_fault,
+ .context_fault = nsmmu_context_fault,
};
struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index e622f4e33379..975faa57b659 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -673,6 +673,7 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
enum io_pgtable_fmt fmt;
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+ irqreturn_t (*context_fault)(int irq, void *dev);
mutex_lock(&smmu_domain->init_mutex);
if (smmu_domain->smmu)
@@ -835,7 +836,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
* handler seeing a half-initialised domain state.
*/
irq = smmu->irqs[smmu->num_global_irqs + cfg->irptndx];
- ret = devm_request_irq(smmu->dev, irq, arm_smmu_context_fault,
+ context_fault = (smmu->impl && smmu->impl->context_fault) ?
+ smmu->impl->context_fault : arm_smmu_context_fault;
+ ret = devm_request_irq(smmu->dev, irq, context_fault,
IRQF_SHARED, "arm-smmu-context-fault", domain);
if (ret < 0) {
dev_err(smmu->dev, "failed to request context IRQ %d (%u)\n",
@@ -2095,6 +2098,7 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
struct arm_smmu_device *smmu;
struct device *dev = &pdev->dev;
int num_irqs, i, err;
+ irqreturn_t (*global_fault)(int irq, void *dev);
smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
if (!smmu) {
@@ -2181,9 +2185,12 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
smmu->num_context_irqs = smmu->num_context_banks;
}
+ global_fault = (smmu->impl && smmu->impl->global_fault) ?
+ smmu->impl->global_fault : arm_smmu_global_fault;
+
for (i = 0; i < smmu->num_global_irqs; ++i) {
err = devm_request_irq(smmu->dev, smmu->irqs[i],
- arm_smmu_global_fault,
+ global_fault,
IRQF_SHARED,
"arm-smmu global fault",
smmu);
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index 67c3c6f5c49e..27d786afc56a 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -18,6 +18,7 @@
#include <linux/io-64-nonatomic-hi-lo.h>
#include <linux/io-pgtable.h>
#include <linux/iommu.h>
+#include <linux/irqreturn.h>
#include <linux/mutex.h>
#include <linux/spinlock.h>
#include <linux/types.h>
@@ -386,6 +387,8 @@ struct arm_smmu_impl {
int (*init_context)(struct arm_smmu_domain *smmu_domain);
void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
int status);
+ irqreturn_t (*global_fault)(int irq, void *dev);
+ irqreturn_t (*context_fault)(int irq, void *dev);
};
static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 4/5] arm64: tegra: Add DT node for T194 SMMU
From: Krishna Reddy @ 2020-05-21 23:31 UTC (permalink / raw)
Cc: snikam, mperttunen, bhuntsman, will, joro, linux-kernel,
praithatha, talho, iommu, nicolinc, linux-tegra, yhsu, treding,
robin.murphy, linux-arm-kernel, bbiswas
In-Reply-To: <20200521233107.11968-1-vdumpa@nvidia.com>
Add DT node for T194 SMMU to enable SMMU support.
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 77 ++++++++++++++++++++++++
1 file changed, 77 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index f4ede86e32b4..f7c4399afb55 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1620,6 +1620,83 @@ pcie@141a0000 {
0x82000000 0x0 0x40000000 0x1f 0x40000000 0x0 0xc0000000>; /* non-prefetchable memory (3GB) */
};
+ smmu: iommu@12000000 {
+ compatible = "arm,mmu-500","nvidia,tegra194-smmu-500";
+ reg = <0 0x12000000 0 0x800000>,
+ <0 0x11000000 0 0x800000>,
+ <0 0x10000000 0 0x800000>;
+ interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
+ stream-match-mask = <0x7f80>;
+ #global-interrupts = <3>;
+ #iommu-cells = <1>;
+ };
+
pcie_ep@14160000 {
compatible = "nvidia,tegra194-pcie-ep", "snps,dw-pcie-ep";
power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX4A>;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 5/5] arm64: tegra: enable SMMU for SDHCI and EQOS on T194
From: Krishna Reddy @ 2020-05-21 23:31 UTC (permalink / raw)
Cc: snikam, mperttunen, bhuntsman, will, joro, linux-kernel,
praithatha, talho, iommu, nicolinc, linux-tegra, yhsu, treding,
robin.murphy, linux-arm-kernel, bbiswas
In-Reply-To: <20200521233107.11968-1-vdumpa@nvidia.com>
Enable SMMU translations for SDHCI and EQOS transactions on T194.
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index f7c4399afb55..706bbb439dcd 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -59,6 +59,7 @@ ethernet@2490000 {
clock-names = "master_bus", "slave_bus", "rx", "tx", "ptp_ref";
resets = <&bpmp TEGRA194_RESET_EQOS>;
reset-names = "eqos";
+ iommus = <&smmu TEGRA194_SID_EQOS>;
status = "disabled";
snps,write-requests = <1>;
@@ -457,6 +458,7 @@ sdmmc1: sdhci@3400000 {
clock-names = "sdhci";
resets = <&bpmp TEGRA194_RESET_SDMMC1>;
reset-names = "sdhci";
+ iommus = <&smmu TEGRA194_SID_SDMMC1>;
nvidia,pad-autocal-pull-up-offset-3v3-timeout =
<0x07>;
nvidia,pad-autocal-pull-down-offset-3v3-timeout =
@@ -479,6 +481,7 @@ sdmmc3: sdhci@3440000 {
clock-names = "sdhci";
resets = <&bpmp TEGRA194_RESET_SDMMC3>;
reset-names = "sdhci";
+ iommus = <&smmu TEGRA194_SID_SDMMC3>;
nvidia,pad-autocal-pull-up-offset-1v8 = <0x00>;
nvidia,pad-autocal-pull-down-offset-1v8 = <0x7a>;
nvidia,pad-autocal-pull-up-offset-3v3-timeout = <0x07>;
@@ -506,6 +509,7 @@ sdmmc4: sdhci@3460000 {
<&bpmp TEGRA194_CLK_PLLC4>;
resets = <&bpmp TEGRA194_RESET_SDMMC4>;
reset-names = "sdhci";
+ iommus = <&smmu TEGRA194_SID_SDMMC4>;
nvidia,pad-autocal-pull-up-offset-hs400 = <0x00>;
nvidia,pad-autocal-pull-down-offset-hs400 = <0x00>;
nvidia,pad-autocal-pull-up-offset-1v8-timeout = <0x0a>;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 0/5] Nvidia Arm SMMUv2 Implementation
From: Krishna Reddy @ 2020-05-21 23:31 UTC (permalink / raw)
Cc: snikam, mperttunen, bhuntsman, will, joro, linux-kernel,
praithatha, talho, iommu, nicolinc, linux-tegra, yhsu, treding,
robin.murphy, linux-arm-kernel, bbiswas
Changes in v5:
Rebased on top of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
v4 - https://lkml.org/lkml/2019/10/30/1054
v3 - https://lkml.org/lkml/2019/10/18/1601
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (5):
iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
dt-bindings: arm-smmu: Add binding for Tegra194 SMMU
iommu/arm-smmu: Add global/context fault implementation hooks
arm64: tegra: Add DT node for T194 SMMU
arm64: tegra: enable SMMU for SDHCI and EQOS on T194
.../devicetree/bindings/iommu/arm,smmu.yaml | 5 +
MAINTAINERS | 2 +
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 81 ++++++
drivers/iommu/Makefile | 2 +-
drivers/iommu/arm-smmu-impl.c | 3 +
drivers/iommu/arm-smmu-nvidia.c | 261 ++++++++++++++++++
drivers/iommu/arm-smmu.c | 11 +-
drivers/iommu/arm-smmu.h | 4 +
8 files changed, 366 insertions(+), 3 deletions(-)
create mode 100644 drivers/iommu/arm-smmu-nvidia.c
base-commit: 365f8d504da50feaebf826d180113529c9383670
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 2/5] dt-bindings: arm-smmu: Add binding for Tegra194 SMMU
From: Krishna Reddy @ 2020-05-21 23:31 UTC (permalink / raw)
Cc: snikam, mperttunen, bhuntsman, will, joro, linux-kernel,
praithatha, talho, iommu, nicolinc, linux-tegra, yhsu, treding,
robin.murphy, linux-arm-kernel, bbiswas
In-Reply-To: <20200521233107.11968-1-vdumpa@nvidia.com>
Add binding for NVIDIA's Tegra194 Soc SMMU that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
---
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 6515dbe47508..78aba7dd5a61 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -37,6 +37,11 @@ properties:
- qcom,sc7180-smmu-500
- qcom,sdm845-smmu-500
- const: arm,mmu-500
+ - description: NVIDIA SoCs that use more than one "arm,mmu-500"
+ items:
+ - enum:
+ - nvdia,tegra194-smmu-500
+ - const: arm,mmu-500
- items:
- const: arm,mmu-500
- const: arm,smmu-v2
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 10/12] of/irq: Make of_msi_map_rid() PCI bus agnostic
From: Rob Herring @ 2020-05-21 23:17 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: devicetree, Sudeep Holla, Catalin Marinas, Will Deacon,
Diana Craciun, Marc Zyngier, Joerg Roedel, Hanjun Guo,
Rafael J. Wysocki, Makarand Pawagi, linux-acpi, Linux IOMMU, PCI,
Bjorn Helgaas, Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-11-lorenzo.pieralisi@arm.com>
On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> There is nothing PCI bus specific in the of_msi_map_rid()
> implementation other than the requester ID tag for the input
> ID space. Rename requester ID to a more generic ID so that
> the translation code can be used by all busses that require
> input/output ID translations.
>
> Leave a wrapper function of_msi_map_rid() in place to keep
> existing PCI code mapping requester ID syntactically unchanged.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> ---
> drivers/of/irq.c | 28 ++++++++++++++--------------
> include/linux/of_irq.h | 14 ++++++++++++--
> 2 files changed, 26 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 48a40326984f..25d17b8a1a1a 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -576,43 +576,43 @@ void __init of_irq_init(const struct of_device_id *matches)
> }
> }
>
> -static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
> - u32 rid_in)
> +static u32 __of_msi_map_id(struct device *dev, struct device_node **np,
> + u32 id_in)
> {
> struct device *parent_dev;
> - u32 rid_out = rid_in;
> + u32 id_out = id_in;
>
> /*
> * Walk up the device parent links looking for one with a
> * "msi-map" property.
> */
> for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
> - if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
> - "msi-map-mask", np, &rid_out))
> + if (!of_map_id(parent_dev->of_node, id_in, "msi-map",
> + "msi-map-mask", np, &id_out))
> break;
> - return rid_out;
> + return id_out;
> }
>
> /**
> - * of_msi_map_rid - Map a MSI requester ID for a device.
> + * of_msi_map_id - Map a MSI ID for a device.
> * @dev: device for which the mapping is to be done.
> * @msi_np: device node of the expected msi controller.
> - * @rid_in: unmapped MSI requester ID for the device.
> + * @id_in: unmapped MSI ID for the device.
> *
> * Walk up the device hierarchy looking for devices with a "msi-map"
> - * property. If found, apply the mapping to @rid_in.
> + * property. If found, apply the mapping to @id_in.
> *
> - * Returns the mapped MSI requester ID.
> + * Returns the mapped MSI ID.
> */
> -u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in)
> +u32 of_msi_map_id(struct device *dev, struct device_node *msi_np, u32 id_in)
> {
> - return __of_msi_map_rid(dev, &msi_np, rid_in);
> + return __of_msi_map_id(dev, &msi_np, id_in);
> }
>
> /**
> * of_msi_map_get_device_domain - Use msi-map to find the relevant MSI domain
> * @dev: device for which the mapping is to be done.
> - * @rid: Requester ID for the device.
> + * @id: Device ID.
> * @bus_token: Bus token
> *
> * Walk up the device hierarchy looking for devices with a "msi-map"
> @@ -625,7 +625,7 @@ struct irq_domain *of_msi_map_get_device_domain(struct device *dev, u32 id,
> {
> struct device_node *np = NULL;
>
> - __of_msi_map_rid(dev, &np, id);
> + __of_msi_map_id(dev, &np, id);
> return irq_find_matching_host(np, bus_token);
> }
>
> diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> index 7142a3722758..cf9cb1e545ce 100644
> --- a/include/linux/of_irq.h
> +++ b/include/linux/of_irq.h
> @@ -55,7 +55,12 @@ extern struct irq_domain *of_msi_map_get_device_domain(struct device *dev,
> u32 id,
> u32 bus_token);
> extern void of_msi_configure(struct device *dev, struct device_node *np);
> -u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in);
> +u32 of_msi_map_id(struct device *dev, struct device_node *msi_np, u32 id_in);
> +static inline u32 of_msi_map_rid(struct device *dev,
> + struct device_node *msi_np, u32 rid_in)
> +{
> + return of_msi_map_id(dev, msi_np, rid_in);
> +}
> #else
> static inline int of_irq_count(struct device_node *dev)
> {
> @@ -93,10 +98,15 @@ static inline struct irq_domain *of_msi_map_get_device_domain(struct device *dev
> static inline void of_msi_configure(struct device *dev, struct device_node *np)
> {
> }
> +static inline u32 of_msi_map_id(struct device *dev,
> + struct device_node *msi_np, u32 id_in)
> +{
> + return id_in;
> +}
> static inline u32 of_msi_map_rid(struct device *dev,
> struct device_node *msi_np, u32 rid_in)
Move this out of the ifdef and you only need it declared once.
But again, I think I'd just kill of_msi_map_rid.
> {
> - return rid_in;
> + return of_msi_map_id(dev, msi_np, rid_in);
> }
> #endif
>
> --
> 2.26.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 09/12] dt-bindings: arm: fsl: Add msi-map device-tree binding for fsl-mc bus
From: Rob Herring @ 2020-05-21 23:10 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: devicetree, Catalin Marinas, Will Deacon, Diana Craciun, PCI,
Joerg Roedel, Sudeep Holla, Rafael J. Wysocki, Makarand Pawagi,
linux-acpi, Linux IOMMU, Marc Zyngier, Hanjun Guo, Bjorn Helgaas,
Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-10-lorenzo.pieralisi@arm.com>
On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>
> The existing bindings cannot be used to specify the relationship
> between fsl-mc devices and GIC ITSes.
>
> Add a generic binding for mapping fsl-mc devices to GIC ITSes, using
> msi-map property.
>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> ---
> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 30 +++++++++++++++++--
> 1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> index 9134e9bcca56..b0813b2d0493 100644
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -18,9 +18,9 @@ same hardware "isolation context" and a 10-bit value called an ICID
> the requester.
>
> The generic 'iommus' property is insufficient to describe the relationship
> -between ICIDs and IOMMUs, so an iommu-map property is used to define
> -the set of possible ICIDs under a root DPRC and how they map to
> -an IOMMU.
> +between ICIDs and IOMMUs, so the iommu-map and msi-map properties are used
> +to define the set of possible ICIDs under a root DPRC and how they map to
> +an IOMMU and a GIC ITS respectively.
>
> For generic IOMMU bindings, see
> Documentation/devicetree/bindings/iommu/iommu.txt.
> @@ -28,6 +28,9 @@ Documentation/devicetree/bindings/iommu/iommu.txt.
> For arm-smmu binding, see:
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml.
>
> +For GICv3 and GIC ITS bindings, see:
> +Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml.
> +
> Required properties:
>
> - compatible
> @@ -119,6 +122,15 @@ Optional properties:
> associated with the listed IOMMU, with the iommu-specifier
> (i - icid-base + iommu-base).
>
> +- msi-map: Maps an ICID to a GIC ITS and associated iommu-specifier
> + data.
> +
> + The property is an arbitrary number of tuples of
> + (icid-base,iommu,iommu-base,length).
I'm confused because the example has GIC ITS phandle, not an IOMMU.
What is an iommu-base?
> +
> + Any ICID in the interval [icid-base, icid-base + length) is
> + associated with the listed GIC ITS, with the iommu-specifier
> + (i - icid-base + iommu-base).
> Example:
>
> smmu: iommu@5000000 {
> @@ -128,6 +140,16 @@ Example:
> ...
> };
>
> + gic: interrupt-controller@6000000 {
> + compatible = "arm,gic-v3";
> + ...
> + its: gic-its@6020000 {
> + compatible = "arm,gic-v3-its";
> + msi-controller;
> + ...
> + };
> + };
> +
> fsl_mc: fsl-mc@80c000000 {
> compatible = "fsl,qoriq-mc";
> reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
> @@ -135,6 +157,8 @@ Example:
> msi-parent = <&its>;
> /* define map for ICIDs 23-64 */
> iommu-map = <23 &smmu 23 41>;
> + /* define msi map for ICIDs 23-64 */
> + msi-map = <23 &its 23 41>;
Seeing 23 twice is odd. The numbers to the right of 'its' should be an
ITS number space.
> #address-cells = <3>;
> #size-cells = <1>;
>
> --
> 2.26.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 07/12] of/device: Add input id to of_dma_configure()
From: Rob Herring @ 2020-05-21 23:02 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: devicetree, Catalin Marinas, Will Deacon, Diana Craciun, PCI,
Joerg Roedel, Sudeep Holla, Rafael J. Wysocki, Makarand Pawagi,
linux-acpi, Linux IOMMU, Marc Zyngier, Hanjun Guo, Bjorn Helgaas,
Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-8-lorenzo.pieralisi@arm.com>
On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> Devices sitting on proprietary busses have a device ID space that
> is owned by the respective bus and related firmware bindings. In order
> to let the generic OF layer handle the input translations to
> an IOMMU id, for such busses the current of_dma_configure() interface
> should be extended in order to allow the bus layer to provide the
> device input id parameter - that is retrieved/assigned in bus
> specific code and firmware.
>
> Augment of_dma_configure() to add an optional input_id parameter,
> leaving current functionality unchanged.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---
> drivers/bus/fsl-mc/fsl-mc-bus.c | 4 ++-
> drivers/iommu/of_iommu.c | 53 +++++++++++++++++++++------------
> drivers/of/device.c | 8 +++--
> include/linux/of_device.h | 16 ++++++++--
> include/linux/of_iommu.h | 6 ++--
> 5 files changed, 60 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index 40526da5c6a6..8ead3f0238f2 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -118,11 +118,13 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
> static int fsl_mc_dma_configure(struct device *dev)
> {
> struct device *dma_dev = dev;
> + struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
> + u32 input_id = mc_dev->icid;
>
> while (dev_is_fsl_mc(dma_dev))
> dma_dev = dma_dev->parent;
>
> - return of_dma_configure(dev, dma_dev->of_node, 0);
> + return of_dma_configure_id(dev, dma_dev->of_node, 0, &input_id);
> }
>
> static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index ad96b87137d6..4516d5bf6cc9 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -139,25 +139,53 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
> return err;
> }
>
> -static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
> - struct device_node *master_np)
> +static int of_iommu_configure_dev_id(struct device_node *master_np,
> + struct device *dev,
> + const u32 *id)
Should have read this patch before #6. I guess you could still make
of_pci_iommu_init() call
of_iommu_configure_dev_id.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH][v2] iommu: arm-smmu-v3: Copy SMMU table for kdump kernel
From: Bjorn Helgaas @ 2020-05-21 22:49 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Kuppuswamy Sathyanarayanan, Ganapatrao Prabhakerrao Kulkarni,
Myron Stowe, Vijay Mohan Pandarathil, Marc Zyngier,
Bhupesh Sharma, kexec mailing list, Robin Murphy, linux-pci,
Prabhakar Kushwaha, Will Deacon, linux-arm-kernel
In-Reply-To: <CAJ2QiJLqaJ+uftEkRZ_n1FGUMigpk6_0wkvUfUDgcyfYNOpx8w@mail.gmail.com>
On Thu, May 21, 2020 at 09:28:20AM +0530, Prabhakar Kushwaha wrote:
> On Wed, May 20, 2020 at 4:52 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Thu, May 14, 2020 at 12:47:02PM +0530, Prabhakar Kushwaha wrote:
> > > On Wed, May 13, 2020 at 3:33 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Mon, May 11, 2020 at 07:46:06PM -0700, Prabhakar Kushwaha wrote:
> > > > > An SMMU Stream table is created by the primary kernel. This table is
> > > > > used by the SMMU to perform address translations for device-originated
> > > > > transactions. Any crash (if happened) launches the kdump kernel which
> > > > > re-creates the SMMU Stream table. New transactions will be translated
> > > > > via this new table..
> > > > >
> > > > > There are scenarios, where devices are still having old pending
> > > > > transactions (configured in the primary kernel). These transactions
> > > > > come in-between Stream table creation and device-driver probe.
> > > > > As new stream table does not have entry for older transactions,
> > > > > it will be aborted by SMMU.
> > > > >
> > > > > Similar observations were found with PCIe-Intel 82576 Gigabit
> > > > > Network card. It sends old Memory Read transaction in kdump kernel.
> > > > > Transactions configured for older Stream table entries, that do not
> > > > > exist any longer in the new table, will cause a PCIe Completion Abort.
> > > >
> > > > That sounds like exactly what we want, doesn't it?
> > > >
> > > > Or do you *want* DMA from the previous kernel to complete? That will
> > > > read or scribble on something, but maybe that's not terrible as long
> > > > as it's not memory used by the kdump kernel.
> > >
> > > Yes, Abort should happen. But it should happen in context of driver.
> > > But current abort is happening because of SMMU and no driver/pcie
> > > setup present at this moment.
> >
> > I don't understand what you mean by "in context of driver." The whole
> > problem is that we can't control *when* the abort happens, so it may
> > happen in *any* context. It may happen when a NIC receives a packet
> > or at some other unpredictable time.
> >
> > > Solution of this issue should be at 2 place
> > > a) SMMU level: I still believe, this patch has potential to overcome
> > > issue till finally driver's probe takeover.
> > > b) Device level: Even if something goes wrong. Driver/device should
> > > able to recover.
> > >
> > > > > Returned PCIe completion abort further leads to AER Errors from APEI
> > > > > Generic Hardware Error Source (GHES) with completion timeout.
> > > > > A network device hang is observed even after continuous
> > > > > reset/recovery from driver, Hence device is no more usable.
> > > >
> > > > The fact that the device is no longer usable is definitely a problem.
> > > > But in principle we *should* be able to recover from these errors. If
> > > > we could recover and reliably use the device after the error, that
> > > > seems like it would be a more robust solution that having to add
> > > > special cases in every IOMMU driver.
> > > >
> > > > If you have details about this sort of error, I'd like to try to fix
> > > > it because we want to recover from that sort of error in normal
> > > > (non-crash) situations as well.
> > > >
> > > Completion abort case should be gracefully handled. And device should
> > > always remain usable.
> > >
> > > There are 2 scenario which I am testing with Ethernet card PCIe-Intel
> > > 82576 Gigabit Network card.
> > >
> > > I) Crash testing using kdump root file system: De-facto scenario
> > > - kdump file system does not have Ethernet driver
> > > - A lot of AER prints [1], making it impossible to work on shell
> > > of kdump root file system.
> >
> > In this case, I think report_error_detected() is deciding that because
> > the device has no driver, we can't do anything. The flow is like
> > this:
> >
> > aer_recover_work_func # aer_recover_work
> > kfifo_get(aer_recover_ring, entry)
> > dev = pci_get_domain_bus_and_slot
> > cper_print_aer(dev, ...)
> > pci_err("AER: aer_status:")
> > pci_err("AER: [14] CmpltTO")
> > pci_err("AER: aer_layer=")
> > if (AER_NONFATAL)
> > pcie_do_recovery(dev, pci_channel_io_normal)
> > status = CAN_RECOVER
> > pci_walk_bus(report_normal_detected)
> > report_error_detected
> > if (!dev->driver)
> > vote = NO_AER_DRIVER
> > pci_info("can't recover (no error_detected callback)")
> > *result = merge_result(*, NO_AER_DRIVER)
> > # always NO_AER_DRIVER
> > status is now NO_AER_DRIVER
> >
> > So pcie_do_recovery() does not call .report_mmio_enabled() or .slot_reset(),
> > and status is not RECOVERED, so it skips .resume().
> >
> > I don't remember the history there, but if a device has no driver and
> > the device generates errors, it seems like we ought to be able to
> > reset it.
>
> But how to reset the device considering there is no driver.
> Hypothetically, this case should be taken care by PCIe subsystem to
> perform reset at PCIe level.
I don't understand your question. The PCI core (not the device
driver) already does the reset. When pcie_do_recovery() calls
reset_link(), all devices on the other side of the link are reset.
> > We should be able to field one (or a few) AER errors, reset the
> > device, and you should be able to use the shell in the kdump kernel.
> >
> here kdump shell is usable only problem is a "lot of AER Errors". One
> cannot see what they are typing.
Right, that's what I expect. If the PCI core resets the device, you
should get just a few AER errors, and they should stop after the
device is reset.
> > > - Note kdump shell allows to use makedumpfile, vmcore-dmesg applications.
> > >
> > > II) Crash testing using default root file system: Specific case to
> > > test Ethernet driver in second kernel
> > > - Default root file system have Ethernet driver
> > > - AER error comes even before the driver probe starts.
> > > - Driver does reset Ethernet card as part of probe but no success.
> > > - AER also tries to recover. but no success. [2]
> > > - I also tries to remove AER errors by using "pci=noaer" bootargs
> > > and commenting ghes_handle_aer() from GHES driver..
> > > than different set of errors come which also never able to recover [3]
> > >
>
> Please suggest your view on this case. Here driver is preset.
> (driver/net/ethernet/intel/igb/igb_main.c)
> In this case AER errors starts even before driver probe starts.
> After probe, driver does the device reset with no success and even AER
> recovery does not work.
This case should be the same as the one above. If we can change the
PCI core so it can reset the device when there's no driver, that would
apply to case I (where there will never be a driver) and to case II
(where there is no driver now, but a driver will probe the device
later).
> Problem mentioned in case I and II goes away if do pci_reset_function
> during enumeration phase of kdump kernel.
> can we thought of doing pci_reset_function for all devices in kdump
> kernel or device specific quirk.
>
> --pk
>
>
> > > As per my understanding, possible solutions are
> > > - Copy SMMU table i.e. this patch
> > > OR
> > > - Doing pci_reset_function() during enumeration phase.
> > > I also tried clearing "M" bit using pci_clear_master during
> > > enumeration but it did not help. Because driver re-set M bit causing
> > > same AER error again.
> > >
> > >
> > > -pk
> > >
> > > ---------------------------------------------------------------------------------------------------------------------------
> > > [1] with bootargs having pci=noaer
> > >
> > > [ 22.494648] {4}[Hardware Error]: Hardware error from APEI Generic
> > > Hardware Error Source: 1
> > > [ 22.512773] {4}[Hardware Error]: event severity: recoverable
> > > [ 22.518419] {4}[Hardware Error]: Error 0, type: recoverable
> > > [ 22.544804] {4}[Hardware Error]: section_type: PCIe error
> > > [ 22.550363] {4}[Hardware Error]: port_type: 0, PCIe end point
> > > [ 22.556268] {4}[Hardware Error]: version: 3.0
> > > [ 22.560785] {4}[Hardware Error]: command: 0x0507, status: 0x4010
> > > [ 22.576852] {4}[Hardware Error]: device_id: 0000:09:00.1
> > > [ 22.582323] {4}[Hardware Error]: slot: 0
> > > [ 22.586406] {4}[Hardware Error]: secondary_bus: 0x00
> > > [ 22.591530] {4}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> > > [ 22.608900] {4}[Hardware Error]: class_code: 000002
> > > [ 22.613938] {4}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> > > [ 22.803534] pci 0000:09:00.1: AER: aer_status: 0x00004000,
> > > aer_mask: 0x00000000
> > > [ 22.810838] pci 0000:09:00.1: AER: [14] CmpltTO (First)
> > > [ 22.817613] pci 0000:09:00.1: AER: aer_layer=Transaction Layer,
> > > aer_agent=Requester ID
> > > [ 22.847374] pci 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> > > [ 22.866161] mpt3sas_cm0: 63 BIT PCI BUS DMA ADDRESSING SUPPORTED,
> > > total mem (8153768 kB)
> > > [ 22.946178] pci 0000:09:00.0: AER: can't recover (no error_detected callback)
> > > [ 22.995142] pci 0000:09:00.1: AER: can't recover (no error_detected callback)
> > > [ 23.002300] pcieport 0000:00:09.0: AER: device recovery failed
> > > [ 23.027607] pci 0000:09:00.1: AER: aer_status: 0x00004000,
> > > aer_mask: 0x00000000
> > > [ 23.044109] pci 0000:09:00.1: AER: [14] CmpltTO (First)
> > > [ 23.060713] pci 0000:09:00.1: AER: aer_layer=Transaction Layer,
> > > aer_agent=Requester ID
> > > [ 23.068616] pci 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> > > [ 23.122056] pci 0000:09:00.0: AER: can't recover (no error_detected callback)
> > >
> > >
> > > ----------------------------------------------------------------------------------------------------------------------------
> > > [2] Normal bootargs.
> > >
> > > [ 54.252454] {6}[Hardware Error]: Hardware error from APEI Generic
> > > Hardware Error Source: 1
> > > [ 54.265827] {6}[Hardware Error]: event severity: recoverable
> > > [ 54.271473] {6}[Hardware Error]: Error 0, type: recoverable
> > > [ 54.281605] {6}[Hardware Error]: section_type: PCIe error
> > > [ 54.287163] {6}[Hardware Error]: port_type: 0, PCIe end point
> > > [ 54.296955] {6}[Hardware Error]: version: 3.0
> > > [ 54.301471] {6}[Hardware Error]: command: 0x0507, status: 0x4010
> > > [ 54.312520] {6}[Hardware Error]: device_id: 0000:09:00.1
> > > [ 54.317991] {6}[Hardware Error]: slot: 0
> > > [ 54.322074] {6}[Hardware Error]: secondary_bus: 0x00
> > > [ 54.327197] {6}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> > > [ 54.333797] {6}[Hardware Error]: class_code: 000002
> > > [ 54.351312] {6}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> > > [ 54.358001] AER: AER recover: Buffer overflow when recovering AER
> > > for 0000:09:00:1
> > > [ 54.376852] pcieport 0000:00:09.0: AER: device recovery successful
> > > [ 54.383034] igb 0000:09:00.1: AER: aer_status: 0x00004000,
> > > aer_mask: 0x00000000
> > > [ 54.390348] igb 0000:09:00.1: AER: [14] CmpltTO (First)
> > > [ 54.397144] igb 0000:09:00.1: AER: aer_layer=Transaction Layer,
> > > aer_agent=Requester ID
> > > [ 54.409555] igb 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> > > [ 54.551370] AER: AER recover: Buffer overflow when recovering AER
> > > for 0000:09:00:1
> > > [ 54.705214] AER: AER recover: Buffer overflow when recovering AER
> > > for 0000:09:00:1
> > > [ 54.758703] AER: AER recover: Buffer overflow when recovering AER
> > > for 0000:09:00:1
> > > [ 54.865445] AER: AER recover: Buffer overflow when recovering AER
> > > for 0000:09:00:1
> > > [ 54.888751] pcieport 0000:00:09.0: AER: device recovery successful
> > > [ 54.894933] igb 0000:09:00.1: AER: aer_status: 0x00004000,
> > > aer_mask: 0x00000000
> > > [ 54.902228] igb 0000:09:00.1: AER: [14] CmpltTO (First)
> > > [ 54.916059] igb 0000:09:00.1: AER: aer_layer=Transaction Layer,
> > > aer_agent=Requester ID
> > > [ 54.923972] igb 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> > > [ 55.057272] AER: AER recover: Buffer overflow when recovering AER
> > > for 0000:09:00:1
> > > [ 274.571401] AER: AER recover: Buffer overflow when recovering AER
> > > for 0000:09:00:1
> > > [ 274.686138] AER: AER recover: Buffer overflow when recovering AER
> > > for 0000:09:00:1
> > > [ 274.786134] AER: AER recover: Buffer overflow when recovering AER
> > > for 0000:09:00:1
> > > [ 274.886141] AER: AER recover: Buffer overflow when recovering AER
> > > for 0000:09:00:1
> > > [ 397.792897] Workqueue: events aer_recover_work_func
> > > [ 397.797760] Call trace:
> > > [ 397.800199] __switch_to+0xcc/0x108
> > > [ 397.803675] __schedule+0x2c0/0x700
> > > [ 397.807150] schedule+0x58/0xe8
> > > [ 397.810283] schedule_preempt_disabled+0x18/0x28
> > > [ 397.810788] AER: AER recover: Buffer overflow when recovering AER
> > > for 0000:09:00:1
> > > [ 397.814887] __mutex_lock.isra.9+0x288/0x5c8
> > > [ 397.814890] __mutex_lock_slowpath+0x1c/0x28
> > > [ 397.830962] mutex_lock+0x4c/0x68
> > > [ 397.834264] report_slot_reset+0x30/0xa0
> > > [ 397.838178] pci_walk_bus+0x68/0xc0
> > > [ 397.841653] pcie_do_recovery+0xe8/0x248
> > > [ 397.845562] aer_recover_work_func+0x100/0x138
> > > [ 397.849995] process_one_work+0x1bc/0x458
> > > [ 397.853991] worker_thread+0x150/0x500
> > > [ 397.857727] kthread+0x114/0x118
> > > [ 397.860945] ret_from_fork+0x10/0x18
> > > [ 397.864525] INFO: task kworker/223:2:2939 blocked for more than 122 seconds.
> > > [ 397.871564] Not tainted 5.7.0-rc3+ #68
> > > [ 397.875819] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> > > disables this message.
> > > [ 397.883638] kworker/223:2 D 0 2939 2 0x00000228
> > > [ 397.889121] Workqueue: ipv6_addrconf addrconf_verify_work
> > > [ 397.894505] Call trace:
> > > [ 397.896940] __switch_to+0xcc/0x108
> > > [ 397.900419] __schedule+0x2c0/0x700
> > > [ 397.903894] schedule+0x58/0xe8
> > > [ 397.907023] schedule_preempt_disabled+0x18/0x28
> > > [ 397.910798] AER: AER recover: Buffer overflow when recovering AER
> > > for 0000:09:00:1
> > > [ 397.911630] __mutex_lock.isra.9+0x288/0x5c8
> > > [ 397.923440] __mutex_lock_slowpath+0x1c/0x28
> > > [ 397.927696] mutex_lock+0x4c/0x68
> > > [ 397.931005] rtnl_lock+0x24/0x30
> > > [ 397.934220] addrconf_verify_work+0x18/0x30
> > > [ 397.938394] process_one_work+0x1bc/0x458
> > > [ 397.942390] worker_thread+0x150/0x500
> > > [ 397.946126] kthread+0x114/0x118
> > > [ 397.949345] ret_from_fork+0x10/0x18
> > >
> > > ---------------------------------------------------------------------------------------------------------------------------------
> > > [3] with bootargs as pci=noaer and comment ghes_halder_aer() from AER driver
> > >
> > > [ 69.037035] igb 0000:09:00.1 enp9s0f1: Reset adapter
> > > [ 69.348446] {9}[Hardware Error]: Hardware error from APEI Generic
> > > Hardware Error Source: 0
> > > [ 69.356698] {9}[Hardware Error]: It has been corrected by h/w and
> > > requires no further action
> > > [ 69.365121] {9}[Hardware Error]: event severity: corrected
> > > [ 69.370593] {9}[Hardware Error]: Error 0, type: corrected
> > > [ 69.376064] {9}[Hardware Error]: section_type: PCIe error
> > > [ 69.381623] {9}[Hardware Error]: port_type: 4, root port
> > > [ 69.387094] {9}[Hardware Error]: version: 3.0
> > > [ 69.391611] {9}[Hardware Error]: command: 0x0106, status: 0x4010
> > > [ 69.397777] {9}[Hardware Error]: device_id: 0000:00:09.0
> > > [ 69.403248] {9}[Hardware Error]: slot: 0
> > > [ 69.407331] {9}[Hardware Error]: secondary_bus: 0x09
> > > [ 69.412455] {9}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> > > [ 69.419055] {9}[Hardware Error]: class_code: 000406
> > > [ 69.424093] {9}[Hardware Error]: bridge: secondary_status:
> > > 0x6000, control: 0x0002
> > > [ 72.118132] igb 0000:09:00.1 enp9s0f1: igb: enp9s0f1 NIC Link is Up
> > > 1000 Mbps Full Duplex, Flow Control: RX
> > > [ 73.995068] igb 0000:09:00.1: Detected Tx Unit Hang
> > > [ 73.995068] Tx Queue <2>
> > > [ 73.995068] TDH <0>
> > > [ 73.995068] TDT <1>
> > > [ 73.995068] next_to_use <1>
> > > [ 73.995068] next_to_clean <0>
> > > [ 73.995068] buffer_info[next_to_clean]
> > > [ 73.995068] time_stamp <ffff9c1a>
> > > [ 73.995068] next_to_watch <0000000097d42934>
> > > [ 73.995068] jiffies <ffff9cd0>
> > > [ 73.995068] desc.status <168000>
> > > [ 75.987323] igb 0000:09:00.1: Detected Tx Unit Hang
> > > [ 75.987323] Tx Queue <2>
> > > [ 75.987323] TDH <0>
> > > [ 75.987323] TDT <1>
> > > [ 75.987323] next_to_use <1>
> > > [ 75.987323] next_to_clean <0>
> > > [ 75.987323] buffer_info[next_to_clean]
> > > [ 75.987323] time_stamp <ffff9c1a>
> > > [ 75.987323] next_to_watch <0000000097d42934>
> > > [ 75.987323] jiffies <ffff9d98>
> > > [ 75.987323] desc.status <168000>
> > > [ 77.952661] {10}[Hardware Error]: Hardware error from APEI Generic
> > > Hardware Error Source: 1
> > > [ 77.971790] {10}[Hardware Error]: event severity: recoverable
> > > [ 77.977522] {10}[Hardware Error]: Error 0, type: recoverable
> > > [ 77.983254] {10}[Hardware Error]: section_type: PCIe error
> > > [ 77.999930] {10}[Hardware Error]: port_type: 0, PCIe end point
> > > [ 78.005922] {10}[Hardware Error]: version: 3.0
> > > [ 78.010526] {10}[Hardware Error]: command: 0x0507, status: 0x4010
> > > [ 78.016779] {10}[Hardware Error]: device_id: 0000:09:00.1
> > > [ 78.033107] {10}[Hardware Error]: slot: 0
> > > [ 78.037276] {10}[Hardware Error]: secondary_bus: 0x00
> > > [ 78.066253] {10}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> > > [ 78.072940] {10}[Hardware Error]: class_code: 000002
> > > [ 78.078064] {10}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> > > [ 78.096202] igb 0000:09:00.1: Detected Tx Unit Hang
> > > [ 78.096202] Tx Queue <2>
> > > [ 78.096202] TDH <0>
> > > [ 78.096202] TDT <1>
> > > [ 78.096202] next_to_use <1>
> > > [ 78.096202] next_to_clean <0>
> > > [ 78.096202] buffer_info[next_to_clean]
> > > [ 78.096202] time_stamp <ffff9c1a>
> > > [ 78.096202] next_to_watch <0000000097d42934>
> > > [ 78.096202] jiffies <ffff9e6a>
> > > [ 78.096202] desc.status <168000>
> > > [ 79.587406] {11}[Hardware Error]: Hardware error from APEI Generic
> > > Hardware Error Source: 0
> > > [ 79.595744] {11}[Hardware Error]: It has been corrected by h/w and
> > > requires no further action
> > > [ 79.604254] {11}[Hardware Error]: event severity: corrected
> > > [ 79.609813] {11}[Hardware Error]: Error 0, type: corrected
> > > [ 79.615371] {11}[Hardware Error]: section_type: PCIe error
> > > [ 79.621016] {11}[Hardware Error]: port_type: 4, root port
> > > [ 79.626574] {11}[Hardware Error]: version: 3.0
> > > [ 79.631177] {11}[Hardware Error]: command: 0x0106, status: 0x4010
> > > [ 79.637430] {11}[Hardware Error]: device_id: 0000:00:09.0
> > > [ 79.642988] {11}[Hardware Error]: slot: 0
> > > [ 79.647157] {11}[Hardware Error]: secondary_bus: 0x09
> > > [ 79.652368] {11}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> > > [ 79.659055] {11}[Hardware Error]: class_code: 000406
> > > [ 79.664180] {11}[Hardware Error]: bridge: secondary_status:
> > > 0x6000, control: 0x0002
> > > [ 79.987052] igb 0000:09:00.1: Detected Tx Unit Hang
> > > [ 79.987052] Tx Queue <2>
> > > [ 79.987052] TDH <0>
> > > [ 79.987052] TDT <1>
> > > [ 79.987052] next_to_use <1>
> > > [ 79.987052] next_to_clean <0>
> > > [ 79.987052] buffer_info[next_to_clean]
> > > [ 79.987052] time_stamp <ffff9c1a>
> > > [ 79.987052] next_to_watch <0000000097d42934>
> > > [ 79.987052] jiffies <ffff9f28>
> > > [ 79.987052] desc.status <168000>
> > > [ 79.987056] igb 0000:09:00.1: Detected Tx Unit Hang
> > > [ 79.987056] Tx Queue <3>
> > > [ 79.987056] TDH <0>
> > > [ 79.987056] TDT <1>
> > > [ 79.987056] next_to_use <1>
> > > [ 79.987056] next_to_clean <0>
> > > [ 79.987056] buffer_info[next_to_clean]
> > > [ 79.987056] time_stamp <ffff9e43>
> > > [ 79.987056] next_to_watch <000000008da33deb>
> > > [ 79.987056] jiffies <ffff9f28>
> > > [ 79.987056] desc.status <514000>
> > > [ 81.986688] igb 0000:09:00.1 enp9s0f1: Reset adapter
> > > [ 81.986842] igb 0000:09:00.1: Detected Tx Unit Hang
> > > [ 81.986842] Tx Queue <2>
> > > [ 81.986842] TDH <0>
> > > [ 81.986842] TDT <1>
> > > [ 81.986842] next_to_use <1>
> > > [ 81.986842] next_to_clean <0>
> > > [ 81.986842] buffer_info[next_to_clean]
> > > [ 81.986842] time_stamp <ffff9c1a>
> > > [ 81.986842] next_to_watch <0000000097d42934>
> > > [ 81.986842] jiffies <ffff9ff0>
> > > [ 81.986842] desc.status <168000>
> > > [ 81.986844] igb 0000:09:00.1: Detected Tx Unit Hang
> > > [ 81.986844] Tx Queue <3>
> > > [ 81.986844] TDH <0>
> > > [ 81.986844] TDT <1>
> > > [ 81.986844] next_to_use <1>
> > > [ 81.986844] next_to_clean <0>
> > > [ 81.986844] buffer_info[next_to_clean]
> > > [ 81.986844] time_stamp <ffff9e43>
> > > [ 81.986844] next_to_watch <000000008da33deb>
> > > [ 81.986844] jiffies <ffff9ff0>
> > > [ 81.986844] desc.status <514000>
> > > [ 85.346515] {12}[Hardware Error]: Hardware error from APEI Generic
> > > Hardware Error Source: 0
> > > [ 85.354854] {12}[Hardware Error]: It has been corrected by h/w and
> > > requires no further action
> > > [ 85.363365] {12}[Hardware Error]: event severity: corrected
> > > [ 85.368924] {12}[Hardware Error]: Error 0, type: corrected
> > > [ 85.374483] {12}[Hardware Error]: section_type: PCIe error
> > > [ 85.380129] {12}[Hardware Error]: port_type: 0, PCIe end point
> > > [ 85.386121] {12}[Hardware Error]: version: 3.0
> > > [ 85.390725] {12}[Hardware Error]: command: 0x0507, status: 0x0010
> > > [ 85.396980] {12}[Hardware Error]: device_id: 0000:09:00.0
> > > [ 85.402540] {12}[Hardware Error]: slot: 0
> > > [ 85.406710] {12}[Hardware Error]: secondary_bus: 0x00
> > > [ 85.411921] {12}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> > > [ 85.418609] {12}[Hardware Error]: class_code: 000002
> > > [ 85.423733] {12}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> > > [ 85.826695] igb 0000:09:00.1 enp9s0f1: igb: enp9s0f1 NIC Link is Up
> > > 1000 Mbps Full Duplex, Flow Control: RX
> > >
> > >
> > >
> > >
> > >
> > > > > So, If we are in a kdump kernel try to copy SMMU Stream table from
> > > > > primary/old kernel to preserve the mappings until the device driver
> > > > > takes over.
> > > > >
> > > > > Signed-off-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
> > > > > ---
> > > > > Changes for v2: Used memremap in-place of ioremap
> > > > >
> > > > > V2 patch has been sanity tested.
> > > > >
> > > > > V1 patch has been tested with
> > > > > A) PCIe-Intel 82576 Gigabit Network card in following
> > > > > configurations with "no AER error". Each iteration has
> > > > > been tested on both Suse kdump rfs And default Centos distro rfs.
> > > > >
> > > > > 1) with 2 level stream table
> > > > > ----------------------------------------------------
> > > > > SMMU | Normal Ping | Flood Ping
> > > > > -----------------------------------------------------
> > > > > Default Operation | 100 times | 10 times
> > > > > -----------------------------------------------------
> > > > > IOMMU bypass | 41 times | 10 times
> > > > > -----------------------------------------------------
> > > > >
> > > > > 2) with Linear stream table.
> > > > > -----------------------------------------------------
> > > > > SMMU | Normal Ping | Flood Ping
> > > > > ------------------------------------------------------
> > > > > Default Operation | 100 times | 10 times
> > > > > ------------------------------------------------------
> > > > > IOMMU bypass | 55 times | 10 times
> > > > > -------------------------------------------------------
> > > > >
> > > > > B) This patch is also tested with Micron Technology Inc 9200 PRO NVMe
> > > > > SSD card with 2 level stream table using "fio" in mixed read/write and
> > > > > only read configurations. It is tested for both Default Operation and
> > > > > IOMMU bypass mode for minimum 10 iterations across Centos kdump rfs and
> > > > > default Centos ditstro rfs.
> > > > >
> > > > > This patch is not full proof solution. Issue can still come
> > > > > from the point device is discovered and driver probe called.
> > > > > This patch has reduced window of scenario from "SMMU Stream table
> > > > > creation - device-driver" to "device discovery - device-driver".
> > > > > Usually, device discovery to device-driver is very small time. So
> > > > > the probability is very low.
> > > > >
> > > > > Note: device-discovery will overwrite existing stream table entries
> > > > > with both SMMU stage as by-pass.
> > > > >
> > > > >
> > > > > drivers/iommu/arm-smmu-v3.c | 36 +++++++++++++++++++++++++++++++++++-
> > > > > 1 file changed, 35 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> > > > > index 82508730feb7..d492d92c2dd7 100644
> > > > > --- a/drivers/iommu/arm-smmu-v3.c
> > > > > +++ b/drivers/iommu/arm-smmu-v3.c
> > > > > @@ -1847,7 +1847,13 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
> > > > > break;
> > > > > case STRTAB_STE_0_CFG_S1_TRANS:
> > > > > case STRTAB_STE_0_CFG_S2_TRANS:
> > > > > - ste_live = true;
> > > > > + /*
> > > > > + * As kdump kernel copy STE table from previous
> > > > > + * kernel. It still may have valid stream table entries.
> > > > > + * Forcing entry as false to allow overwrite.
> > > > > + */
> > > > > + if (!is_kdump_kernel())
> > > > > + ste_live = true;
> > > > > break;
> > > > > case STRTAB_STE_0_CFG_ABORT:
> > > > > BUG_ON(!disable_bypass);
> > > > > @@ -3264,6 +3270,9 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu)
> > > > > return -ENOMEM;
> > > > > }
> > > > >
> > > > > + if (is_kdump_kernel())
> > > > > + return 0;
> > > > > +
> > > > > for (i = 0; i < cfg->num_l1_ents; ++i) {
> > > > > arm_smmu_write_strtab_l1_desc(strtab, &cfg->l1_desc[i]);
> > > > > strtab += STRTAB_L1_DESC_DWORDS << 3;
> > > > > @@ -3272,6 +3281,23 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu)
> > > > > return 0;
> > > > > }
> > > > >
> > > > > +static void arm_smmu_copy_table(struct arm_smmu_device *smmu,
> > > > > + struct arm_smmu_strtab_cfg *cfg, u32 size)
> > > > > +{
> > > > > + struct arm_smmu_strtab_cfg rdcfg;
> > > > > +
> > > > > + rdcfg.strtab_dma = readq_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE);
> > > > > + rdcfg.strtab_base_cfg = readq_relaxed(smmu->base
> > > > > + + ARM_SMMU_STRTAB_BASE_CFG);
> > > > > +
> > > > > + rdcfg.strtab_dma &= STRTAB_BASE_ADDR_MASK;
> > > > > + rdcfg.strtab = memremap(rdcfg.strtab_dma, size, MEMREMAP_WB);
> > > > > +
> > > > > + memcpy_fromio(cfg->strtab, rdcfg.strtab, size);
> > > > > +
> > > > > + cfg->strtab_base_cfg = rdcfg.strtab_base_cfg;
> > > > > +}
> > > > > +
> > > > > static int arm_smmu_init_strtab_2lvl(struct arm_smmu_device *smmu)
> > > > > {
> > > > > void *strtab;
> > > > > @@ -3307,6 +3333,9 @@ static int arm_smmu_init_strtab_2lvl(struct arm_smmu_device *smmu)
> > > > > reg |= FIELD_PREP(STRTAB_BASE_CFG_SPLIT, STRTAB_SPLIT);
> > > > > cfg->strtab_base_cfg = reg;
> > > > >
> > > > > + if (is_kdump_kernel())
> > > > > + arm_smmu_copy_table(smmu, cfg, l1size);
> > > > > +
> > > > > return arm_smmu_init_l1_strtab(smmu);
> > > > > }
> > > > >
> > > > > @@ -3334,6 +3363,11 @@ static int arm_smmu_init_strtab_linear(struct arm_smmu_device *smmu)
> > > > > reg |= FIELD_PREP(STRTAB_BASE_CFG_LOG2SIZE, smmu->sid_bits);
> > > > > cfg->strtab_base_cfg = reg;
> > > > >
> > > > > + if (is_kdump_kernel()) {
> > > > > + arm_smmu_copy_table(smmu, cfg, size);
> > > > > + return 0;
> > > > > + }
> > > > > +
> > > > > arm_smmu_init_bypass_stes(strtab, cfg->num_l1_ents);
> > > > > return 0;
> > > > > }
> > > > > --
> > > > > 2.18.2
> > > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 06/12] of/iommu: Make of_map_rid() PCI agnostic
From: Rob Herring @ 2020-05-21 22:47 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: devicetree, Sudeep Holla, Catalin Marinas, Will Deacon,
Diana Craciun, Marc Zyngier, Joerg Roedel, Hanjun Guo,
Rafael J. Wysocki, Makarand Pawagi, linux-acpi, Linux IOMMU, PCI,
Bjorn Helgaas, Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-7-lorenzo.pieralisi@arm.com>
On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> There is nothing PCI specific (other than the RID - requester ID)
> in the of_map_rid() implementation, so the same function can be
> reused for input/output IDs mapping for other busses just as well.
>
> Rename the RID instances/names to a generic "id" tag and provide
> an of_map_rid() wrapper function so that we can leave the existing
> (and legitimate) callers unchanged.
It's not all that clear to a casual observer that RID is a PCI thing,
so I don't know that keeping it buys much. And there's only 3 callers.
> No functionality change intended.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> ---
> drivers/iommu/of_iommu.c | 2 +-
> drivers/of/base.c | 42 ++++++++++++++++++++--------------------
> include/linux/of.h | 17 +++++++++++++++-
> 3 files changed, 38 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 20738aacac89..ad96b87137d6 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -145,7 +145,7 @@ static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
> struct of_phandle_args iommu_spec = { .args_count = 1 };
> int err;
>
> - err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
> + err = of_map_id(master_np, mc_dev->icid, "iommu-map",
I'm not sure this is an improvement because I'd refactor this function
and of_pci_iommu_init() into a single function:
of_bus_iommu_init(struct device *dev, struct device_node *np, u32 id)
Then of_pci_iommu_init() becomes:
of_pci_iommu_init()
{
return of_bus_iommu_init(info->dev, info->np, alias);
}
And replace of_fsl_mc_iommu_init call with:
err = of_bus_iommu_init(dev, master_np, to_fsl_mc_device(dev)->icid);
> "iommu-map-mask", &iommu_spec.np,
> iommu_spec.args);
> if (err)
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index ae03b1218b06..e000e17bd602 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2201,15 +2201,15 @@ int of_find_last_cache_level(unsigned int cpu)
> }
>
> /**
> - * of_map_rid - Translate a requester ID through a downstream mapping.
> + * of_map_id - Translate a requester ID through a downstream mapping.
Still a requester ID?
> * @np: root complex device node.
> - * @rid: device requester ID to map.
> + * @id: device ID to map.
> * @map_name: property name of the map to use.
> * @map_mask_name: optional property name of the mask to use.
> * @target: optional pointer to a target device node.
> * @id_out: optional pointer to receive the translated ID.
> *
> - * Given a device requester ID, look up the appropriate implementation-defined
> + * Given a device ID, look up the appropriate implementation-defined
> * platform ID and/or the target device which receives transactions on that
> * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
> * @id_out may be NULL if only the other is required. If @target points to
> @@ -2219,11 +2219,11 @@ int of_find_last_cache_level(unsigned int cpu)
> *
> * Return: 0 on success or a standard error code on failure.
> */
> -int of_map_rid(struct device_node *np, u32 rid,
> +int of_map_id(struct device_node *np, u32 id,
> const char *map_name, const char *map_mask_name,
> struct device_node **target, u32 *id_out)
> {
> - u32 map_mask, masked_rid;
> + u32 map_mask, masked_id;
> int map_len;
> const __be32 *map = NULL;
>
> @@ -2235,7 +2235,7 @@ int of_map_rid(struct device_node *np, u32 rid,
> if (target)
> return -ENODEV;
> /* Otherwise, no map implies no translation */
> - *id_out = rid;
> + *id_out = id;
> return 0;
> }
>
> @@ -2255,22 +2255,22 @@ int of_map_rid(struct device_node *np, u32 rid,
> if (map_mask_name)
> of_property_read_u32(np, map_mask_name, &map_mask);
>
> - masked_rid = map_mask & rid;
> + masked_id = map_mask & id;
> for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> struct device_node *phandle_node;
> - u32 rid_base = be32_to_cpup(map + 0);
> + u32 id_base = be32_to_cpup(map + 0);
> u32 phandle = be32_to_cpup(map + 1);
> u32 out_base = be32_to_cpup(map + 2);
> - u32 rid_len = be32_to_cpup(map + 3);
> + u32 id_len = be32_to_cpup(map + 3);
>
> - if (rid_base & ~map_mask) {
> - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
> + if (id_base & ~map_mask) {
> + pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores id-base (0x%x)\n",
> np, map_name, map_name,
> - map_mask, rid_base);
> + map_mask, id_base);
> return -EFAULT;
> }
>
> - if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> + if (masked_id < id_base || masked_id >= id_base + id_len)
> continue;
>
> phandle_node = of_find_node_by_phandle(phandle);
> @@ -2288,20 +2288,20 @@ int of_map_rid(struct device_node *np, u32 rid,
> }
>
> if (id_out)
> - *id_out = masked_rid - rid_base + out_base;
> + *id_out = masked_id - id_base + out_base;
>
> - pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
> - np, map_name, map_mask, rid_base, out_base,
> - rid_len, rid, masked_rid - rid_base + out_base);
> + pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
> + np, map_name, map_mask, id_base, out_base,
> + id_len, id, masked_id - id_base + out_base);
> return 0;
> }
>
> - pr_info("%pOF: no %s translation for rid 0x%x on %pOF\n", np, map_name,
> - rid, target && *target ? *target : NULL);
> + pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name,
> + id, target && *target ? *target : NULL);
>
> /* Bypasses translation */
> if (id_out)
> - *id_out = rid;
> + *id_out = id;
> return 0;
> }
> -EXPORT_SYMBOL_GPL(of_map_rid);
> +EXPORT_SYMBOL_GPL(of_map_id);
> diff --git a/include/linux/of.h b/include/linux/of.h
> index c669c0a4732f..b7934566a1aa 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -554,10 +554,18 @@ bool of_console_check(struct device_node *dn, char *name, int index);
>
> extern int of_cpu_node_to_id(struct device_node *np);
>
> -int of_map_rid(struct device_node *np, u32 rid,
> +int of_map_id(struct device_node *np, u32 id,
> const char *map_name, const char *map_mask_name,
> struct device_node **target, u32 *id_out);
>
> +static inline int of_map_rid(struct device_node *np, u32 rid,
> + const char *map_name,
> + const char *map_mask_name,
> + struct device_node **target, u32 *id_out)
> +{
> + return of_map_id(np, rid, map_name, map_mask_name, target, id_out);
> +}
> +
> #else /* CONFIG_OF */
>
> static inline void of_core_init(void)
> @@ -978,6 +986,13 @@ static inline int of_cpu_node_to_id(struct device_node *np)
> return -ENODEV;
> }
>
> +static inline int of_map_id(struct device_node *np, u32 id,
> + const char *map_name, const char *map_mask_name,
> + struct device_node **target, u32 *id_out)
> +{
> + return -EINVAL;
> +}
> +
> static inline int of_map_rid(struct device_node *np, u32 rid,
> const char *map_name, const char *map_mask_name,
> struct device_node **target, u32 *id_out)
> --
> 2.26.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
From: Al Viro @ 2020-05-21 22:46 UTC (permalink / raw)
To: Guenter Roeck
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
linux-mips, James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, ira.weiny, Dan Williams, Helge Deller,
x86, linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Chris Zankel, Thomas Bogendoerfer, linux-parisc,
linux-kernel, Christian Koenig, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <bdc8dc64-622c-3b0d-1ae1-48222cf34358@roeck-us.net>
On Thu, May 21, 2020 at 03:20:46PM -0700, Guenter Roeck wrote:
> On 5/21/20 10:27 AM, Al Viro wrote:
> > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> >> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.weiny@intel.com wrote:
> >>> From: Ira Weiny <ira.weiny@intel.com>
> >>>
> >>> The kunmap_atomic clean up failed to remove one set of pagefault/preempt
> >>> enables when vaddr is not in the fixmap.
> >>>
> >>> Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
> >>> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> >>
> >> microblazeel works with this patch, as do the nosmp sparc32 boot tests,
> >> but sparc32 boot tests with SMP enabled still fail with lots of messages
> >> such as:
> >
> > BTW, what's your setup for sparc32 boot tests? IOW, how do you manage to
> > shrink the damn thing enough to have the loader cope with it? I hadn't
> > been able to do that for the current mainline ;-/
> >
>
> defconfig seems to work just fine, even after enabling various debug
> and file system options.
The hell? How do you manage to get the kernel in? sparc32_defconfig
ends up with 5316876 bytes unpacked...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
From: Weiny, Ira @ 2020-05-21 22:36 UTC (permalink / raw)
To: Guenter Roeck
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen,
dri-devel@lists.freedesktop.org, linux-mips@vger.kernel.org,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux@vger.kernel.org, Williams, Dan J,
Helge Deller, x86@kernel.org, linux-csky@vger.kernel.org,
Christoph Hellwig, Ingo Molnar,
linux-snps-arc@lists.infradead.org, linux-xtensa@linux-xtensa.org,
Borislav Petkov, Al Viro, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Chris Zankel,
Thomas Bogendoerfer, linux-parisc@vger.kernel.org,
linux-kernel@vger.kernel.org, Christian Koenig, Andrew Morton,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <9088585b-b52f-39ad-1651-53cfc0abd714@roeck-us.net>
> On 5/21/20 10:42 AM, Ira Weiny wrote:
> > On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
> >> On 5/19/20 10:13 PM, Ira Weiny wrote:
> >>> On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> >>>> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> >>>>> On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> >>>>>> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.weiny@intel.com
> wrote:
> >>>>>>> From: Ira Weiny <ira.weiny@intel.com>
> >>>>>>>
> >>>>>>> The kunmap_atomic clean up failed to remove one set of
> >>>>>>> pagefault/preempt enables when vaddr is not in the fixmap.
> >>>>>>>
> >>>>>>> Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate
> >>>>>>> code")
> >>>>>>> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> >>>>>>
> >>>>>> microblazeel works with this patch,
> >>>>>
> >>>>> Awesome... Andrew in my rush yesterday I should have put a
> >>>>> reported by on the patch for Guenter as well.
> >>>>>
> >>>>> Sorry about that Guenter,
> >>>>
> >>>> No worries.
> >>>>
> >>>>> Ira
> >>>>>
> >>>>>> as do the nosmp sparc32 boot tests, but sparc32 boot tests with
> >>>>>> SMP enabled still fail with lots of messages such as:
> >>>>>>
> >>>>>> BUG: Bad page state in process swapper/0 pfn:006a1
> >>>>>> page:f0933420 refcount:0 mapcount:1 mapping:(ptrval) index:0x1
> >>>>>> flags: 0x0()
> >>>>>> raw: 00000000 00000100 00000122 00000000 00000001 00000000
> >>>>>> 00000000 00000000 page dumped because: nonzero mapcount
> Modules
> >>>>>> linked in:
> >>>>>> CPU: 0 PID: 1 Comm: swapper/0 Tainted: G B 5.7.0-rc6-next-
> 20200518-00002-gb178d2d56f29 #1
> >>>>>> [f00e7ab8 :
> >>>>>> bad_page+0xa8/0x108 ]
> >>>>>> [f00e8b54 :
> >>>>>> free_pcppages_bulk+0x154/0x52c ]
> >>>>>> [f00ea024 :
> >>>>>> free_unref_page+0x54/0x6c ]
> >>>>>> [f00ed864 :
> >>>>>> free_reserved_area+0x58/0xec ]
> >>>>>> [f0527104 :
> >>>>>> kernel_init+0x14/0x110 ]
> >>>>>> [f000b77c :
> >>>>>> ret_from_kernel_thread+0xc/0x38 ]
> >>>>>> [00000000 :
> >>>>>> 0x0 ]
> >>>>>>
> >>>>>> Code path leading to that message is different but always the
> >>>>>> same from free_unref_page().
> >>>
> >>> Actually it occurs to me that the patch consolidating kmap_prot is
> >>> odd for sparc 32 bit...
> >>>
> >>> Its a long shot but could you try reverting this patch?
> >>>
> >>> 4ea7d2419e3f kmap: consolidate kmap_prot definitions
> >>>
> >>
> >> That is not easy to revert, unfortunately, due to several follow-up
> patches.
> >
> > I have gotten your sparc tests to run and they all pass...
> >
> > 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh
> > Build reference: v5.7-rc4-17-g852b6f2edc0f
> >
>
> That doesn't look like it is linux-next, which I guess means that something
> else in linux-next breaks it. What is your qemu version ?
Ah yea that was just 5.7-rc4 with my patch set applied. Yes must be something else or an interaction with my patch set.
Did I see another email with Mike which may fix this?
Ira
>
> Thanks,
> Guenter
>
> > Building sparc32:SPARCClassic:nosmp:scsi:hd ... running ......... passed
> > Building sparc32:SPARCbook:nosmp:scsi:cd ... running ......... passed
> > Building sparc32:LX:nosmp:noapc:scsi:hd ... running ......... passed
> > Building sparc32:SS-4:nosmp:initrd ... running ......... passed
> > Building sparc32:SS-5:nosmp:scsi:hd ... running ......... passed
> > Building sparc32:SS-10:nosmp:scsi:cd ... running ......... passed
> > Building sparc32:SS-20:nosmp:scsi:hd ... running ......... passed
> > Building sparc32:SS-600MP:nosmp:scsi:hd ... running ......... passed
> > Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running ......... passed
> > Building sparc32:SS-4:smp:scsi:hd ... running ......... passed
> > Building sparc32:SS-5:smp:scsi:cd ... running ......... passed
> > Building sparc32:SS-10:smp:scsi:hd ... running ......... passed
> > Building sparc32:SS-20:smp:scsi:hd ... running ......... passed
> > Building sparc32:SS-600MP:smp:scsi:hd ... running ......... passed
> > Building sparc32:Voyager:smp:noapc:scsi:hd ... running ......... passed
> >
> > Is there another test I need to run?
> >
> > Ira
> >
> >
> >>
> >> Guenter
> >>
> >>> Alternately I will need to figure out how to run the sparc on qemu here...
> >>>
> >>> Thanks very much for all the testing though! :-D
> >>>
> >>> Ira
> >>>
> >>>>>>
> >>>>>> Still testing ppc images.
> >>>>>>
> >>>>
> >>>> ppc image tests are passing with this patch.
> >>>>
> >>>> Guenter
> >>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] irqchip/gic-v2, v3: Drop extra IRQ_NOAUTOEN setting for (E)PPIs
From: Valentin Schneider @ 2020-05-21 22:35 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: Marc Zyngier, Thomas Gleixner, Jason Cooper
(E)PPIs are per-CPU interrupts, so we want each CPU to go and enable them
via enable_percpu_irq(); this also means we want IRQ_NOAUTOEN for them as
the autoenable would lead to calling irq_enable() instead of the more
appropriate irq_percpu_enable().
Calling irq_set_percpu_devid() is enough to get just that since it trickles
down to irq_set_percpu_devid_flags(), which gives us IRQ_NOAUTOEN (and a
few others). Setting IRQ_NOAUTOEN *again* right after this call is just
redundant, so don't do it.
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
---
drivers/irqchip/irq-gic-v3.c | 1 -
drivers/irqchip/irq-gic.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index d7006ef18a0d..1ed0cf9c586f 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -1282,7 +1282,6 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
irq_set_percpu_devid(irq);
irq_domain_set_info(d, irq, hw, chip, d->host_data,
handle_percpu_devid_irq, NULL, NULL);
- irq_set_status_flags(irq, IRQ_NOAUTOEN);
break;
case SPI_RANGE:
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 30ab623343d3..00de05abd3c3 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -982,7 +982,6 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
irq_set_percpu_devid(irq);
irq_domain_set_info(d, irq, hw, &gic->chip, d->host_data,
handle_percpu_devid_irq, NULL, NULL);
- irq_set_status_flags(irq, IRQ_NOAUTOEN);
} else {
irq_domain_set_info(d, irq, hw, &gic->chip, d->host_data,
handle_fasteoi_irq, NULL, NULL);
--
2.24.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
From: Guenter Roeck @ 2020-05-21 22:27 UTC (permalink / raw)
To: Ira Weiny
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
linux-mips, James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200521174250.GB176262@iweiny-DESK2.sc.intel.com>
On 5/21/20 10:42 AM, Ira Weiny wrote:
> On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
>> On 5/19/20 10:13 PM, Ira Weiny wrote:
>>> On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
>>>> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
>>>>> On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
>>>>>> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.weiny@intel.com wrote:
>>>>>>> From: Ira Weiny <ira.weiny@intel.com>
>>>>>>>
>>>>>>> The kunmap_atomic clean up failed to remove one set of pagefault/preempt
>>>>>>> enables when vaddr is not in the fixmap.
>>>>>>>
>>>>>>> Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
>>>>>>> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>>>>>>
>>>>>> microblazeel works with this patch,
>>>>>
>>>>> Awesome... Andrew in my rush yesterday I should have put a reported by on the
>>>>> patch for Guenter as well.
>>>>>
>>>>> Sorry about that Guenter,
>>>>
>>>> No worries.
>>>>
>>>>> Ira
>>>>>
>>>>>> as do the nosmp sparc32 boot tests,
>>>>>> but sparc32 boot tests with SMP enabled still fail with lots of messages
>>>>>> such as:
>>>>>>
>>>>>> BUG: Bad page state in process swapper/0 pfn:006a1
>>>>>> page:f0933420 refcount:0 mapcount:1 mapping:(ptrval) index:0x1
>>>>>> flags: 0x0()
>>>>>> raw: 00000000 00000100 00000122 00000000 00000001 00000000 00000000 00000000
>>>>>> page dumped because: nonzero mapcount
>>>>>> Modules linked in:
>>>>>> CPU: 0 PID: 1 Comm: swapper/0 Tainted: G B 5.7.0-rc6-next-20200518-00002-gb178d2d56f29 #1
>>>>>> [f00e7ab8 :
>>>>>> bad_page+0xa8/0x108 ]
>>>>>> [f00e8b54 :
>>>>>> free_pcppages_bulk+0x154/0x52c ]
>>>>>> [f00ea024 :
>>>>>> free_unref_page+0x54/0x6c ]
>>>>>> [f00ed864 :
>>>>>> free_reserved_area+0x58/0xec ]
>>>>>> [f0527104 :
>>>>>> kernel_init+0x14/0x110 ]
>>>>>> [f000b77c :
>>>>>> ret_from_kernel_thread+0xc/0x38 ]
>>>>>> [00000000 :
>>>>>> 0x0 ]
>>>>>>
>>>>>> Code path leading to that message is different but always the same
>>>>>> from free_unref_page().
>>>
>>> Actually it occurs to me that the patch consolidating kmap_prot is odd for
>>> sparc 32 bit...
>>>
>>> Its a long shot but could you try reverting this patch?
>>>
>>> 4ea7d2419e3f kmap: consolidate kmap_prot definitions
>>>
>>
>> That is not easy to revert, unfortunately, due to several follow-up patches.
>
> I have gotten your sparc tests to run and they all pass...
>
> 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh
> Build reference: v5.7-rc4-17-g852b6f2edc0f
>
That doesn't look like it is linux-next, which I guess means that something
else in linux-next breaks it. What is your qemu version ?
Thanks,
Guenter
> Building sparc32:SPARCClassic:nosmp:scsi:hd ... running ......... passed
> Building sparc32:SPARCbook:nosmp:scsi:cd ... running ......... passed
> Building sparc32:LX:nosmp:noapc:scsi:hd ... running ......... passed
> Building sparc32:SS-4:nosmp:initrd ... running ......... passed
> Building sparc32:SS-5:nosmp:scsi:hd ... running ......... passed
> Building sparc32:SS-10:nosmp:scsi:cd ... running ......... passed
> Building sparc32:SS-20:nosmp:scsi:hd ... running ......... passed
> Building sparc32:SS-600MP:nosmp:scsi:hd ... running ......... passed
> Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running ......... passed
> Building sparc32:SS-4:smp:scsi:hd ... running ......... passed
> Building sparc32:SS-5:smp:scsi:cd ... running ......... passed
> Building sparc32:SS-10:smp:scsi:hd ... running ......... passed
> Building sparc32:SS-20:smp:scsi:hd ... running ......... passed
> Building sparc32:SS-600MP:smp:scsi:hd ... running ......... passed
> Building sparc32:Voyager:smp:noapc:scsi:hd ... running ......... passed
>
> Is there another test I need to run?
>
> Ira
>
>
>>
>> Guenter
>>
>>> Alternately I will need to figure out how to run the sparc on qemu here...
>>>
>>> Thanks very much for all the testing though! :-D
>>>
>>> Ira
>>>
>>>>>>
>>>>>> Still testing ppc images.
>>>>>>
>>>>
>>>> ppc image tests are passing with this patch.
>>>>
>>>> Guenter
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* linux-next: Signed-off-by missing for commit in the arm-soc tree
From: Stephen Rothwell @ 2020-05-21 22:24 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, ARM
Cc: Masahiro Yamada, Linux Next Mailing List,
Linux Kernel Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 169 bytes --]
Hi all,
Commit
82ab9b6705bd ("dt-bindings: arm: Add Akebi96 board support")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] TI K3 DSP remoteproc driver for C66x DSPs
From: Mathieu Poirier @ 2020-05-21 22:23 UTC (permalink / raw)
To: Bjorn Andersson
Cc: devicetree, Lokesh Vutla, linux-remoteproc, linux-kernel,
Rob Herring, Suman Anna, linux-arm-kernel
In-Reply-To: <20200521190141.GN408178@builder.lan>
Gents,
On Thu, May 21, 2020 at 12:01:41PM -0700, Bjorn Andersson wrote:
> On Thu 21 May 11:59 PDT 2020, Suman Anna wrote:
>
> > Hi Bjorn,
> >
> > On 5/20/20 7:10 PM, Suman Anna wrote:
> > > Hi All,
> > >
> > > The following is v2 of the K3 DSP remoteproc driver supporting the C66x DSPs
> > > on the TI K3 J721E SoCs. The patches are based on the latest commit on the
> > > rproc-next branch, 7dcef3988eed ("remoteproc: Fix an error code in
> > > devm_rproc_alloc()").
> >
> > I realized I also had the R5F patches on my branch, so the third patch won't
> > apply cleanly (conflict on Makefile). Let me know if you want a new revision
> > posted for you to pick up the series.
> >
>
> That should be fine, thanks for the heads up!
>
> Will give Mathieu a day or two to take a look as well.
I don't see having the time to review this set before the middle/end of next
week. I also understand we are crunched by time if we want to get this in
for the upcoming merge window.
If memory serves me well there wasn't anything controversial about this work.
Under normal circumstances I'd give it a final look but I trust Suman to have
carried out what we agreed on.
Bjorn - if you are happy with this set then go ahead and queue it.
Thanks,
Mathieu
>
> Regards,
> Bjorn
>
> > regards
> > Suman
> >
> > >
> > > v2 includes a new remoteproc core patch (patch 1) that adds an OF helper
> > > for parsing the firmware-name property. This is refactored out to avoid
> > > replicating the code in various remoteproc drivers. Please see the
> > > individual patches for detailed changes.
> > >
> > > The main dependent patches from the previous series are now staged in
> > > rproc-next branch. The only dependency for this series is the common
> > > ti-sci-proc helper between R5 and DSP drivers [1]. Please see the initial
> > > cover-letter [2] for v1 details.
> > >
> > > regards
> > > Suman
> > >
> > > [1] https://patchwork.kernel.org/patch/11456379/
> > > [2] https://patchwork.kernel.org/cover/11458573/
> > >
> > > Suman Anna (4):
> > > remoteproc: Introduce rproc_of_parse_firmware() helper
> > > dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
> > > remoteproc/k3-dsp: Add a remoteproc driver of K3 C66x DSPs
> > > remoteproc/k3-dsp: Add support for L2RAM loading on C66x DSPs
> > >
> > > .../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 190 +++++
> > > drivers/remoteproc/Kconfig | 13 +
> > > drivers/remoteproc/Makefile | 1 +
> > > drivers/remoteproc/remoteproc_core.c | 23 +
> > > drivers/remoteproc/remoteproc_internal.h | 2 +
> > > drivers/remoteproc/ti_k3_dsp_remoteproc.c | 773 ++++++++++++++++++
> > > 6 files changed, 1002 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> > > create mode 100644 drivers/remoteproc/ti_k3_dsp_remoteproc.c
> > >
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
From: Guenter Roeck @ 2020-05-21 22:20 UTC (permalink / raw)
To: Al Viro
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
linux-mips, James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, ira.weiny, Dan Williams, Helge Deller,
x86, linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Chris Zankel, Thomas Bogendoerfer, linux-parisc,
linux-kernel, Christian Koenig, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20200521172704.GF23230@ZenIV.linux.org.uk>
On 5/21/20 10:27 AM, Al Viro wrote:
> On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
>> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.weiny@intel.com wrote:
>>> From: Ira Weiny <ira.weiny@intel.com>
>>>
>>> The kunmap_atomic clean up failed to remove one set of pagefault/preempt
>>> enables when vaddr is not in the fixmap.
>>>
>>> Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
>>> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>>
>> microblazeel works with this patch, as do the nosmp sparc32 boot tests,
>> but sparc32 boot tests with SMP enabled still fail with lots of messages
>> such as:
>
> BTW, what's your setup for sparc32 boot tests? IOW, how do you manage to
> shrink the damn thing enough to have the loader cope with it? I hadn't
> been able to do that for the current mainline ;-/
>
defconfig seems to work just fine, even after enabling various debug
and file system options.
Guenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 03/14] PCI: cadence: Add support to use custom read and write accessors
From: Rob Herring @ 2020-05-21 22:17 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: devicetree, Lorenzo Pieralisi, Arnd Bergmann, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, Tom Joseph, PCI, Bjorn Helgaas,
linux-omap,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <37d2d6c3-232d-adb8-4e0b-e0c699ec435a@ti.com>
On Thu, May 21, 2020 at 7:33 AM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>
> Hi Rob,
>
> On 5/21/2020 3:37 AM, Rob Herring wrote:
> > On Wed, May 06, 2020 at 08:44:18PM +0530, Kishon Vijay Abraham I wrote:
> >> Add support to use custom read and write accessors. Platforms that
> >> don't support half word or byte access or any other constraint
> >> while accessing registers can use this feature to populate custom
> >> read and write accessors. These custom accessors are used for both
> >> standard register access and configuration space register access of
> >> the PCIe host bridge.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> >> ---
> >> drivers/pci/controller/cadence/pcie-cadence.h | 107 +++++++++++++++---
> >> 1 file changed, 94 insertions(+), 13 deletions(-)
> >
> > Actually, take back my R-by...
> >
> >>
> >> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
> >> index df14ad002fe9..70b6b25153e8 100644
> >> --- a/drivers/pci/controller/cadence/pcie-cadence.h
> >> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
> >> @@ -223,6 +223,11 @@ enum cdns_pcie_msg_routing {
> >> MSG_ROUTING_GATHER,
> >> };
> >>
> >> +struct cdns_pcie_ops {
> >> + u32 (*read)(void __iomem *addr, int size);
> >> + void (*write)(void __iomem *addr, int size, u32 value);
> >> +};
> >> +
> >> /**
> >> * struct cdns_pcie - private data for Cadence PCIe controller drivers
> >> * @reg_base: IO mapped register base
> >> @@ -239,7 +244,7 @@ struct cdns_pcie {
> >> int phy_count;
> >> struct phy **phy;
> >> struct device_link **link;
> >> - const struct cdns_pcie_common_ops *ops;
> >> + const struct cdns_pcie_ops *ops;
> >> };
> >>
> >> /**
> >> @@ -299,69 +304,145 @@ struct cdns_pcie_ep {
> >> /* Register access */
> >> static inline void cdns_pcie_writeb(struct cdns_pcie *pcie, u32 reg, u8 value)
> >> {
> >> - writeb(value, pcie->reg_base + reg);
> >> + void __iomem *addr = pcie->reg_base + reg;
> >> +
> >> + if (pcie->ops && pcie->ops->write) {
> >> + pcie->ops->write(addr, 0x1, value);
> >> + return;
> >> + }
> >> +
> >> + writeb(value, addr);
> >> }
> >>
> >> static inline void cdns_pcie_writew(struct cdns_pcie *pcie, u32 reg, u16 value)
> >> {
> >> - writew(value, pcie->reg_base + reg);
> >> + void __iomem *addr = pcie->reg_base + reg;
> >> +
> >> + if (pcie->ops && pcie->ops->write) {
> >> + pcie->ops->write(addr, 0x2, value);
> >> + return;
> >> + }
> >> +
> >> + writew(value, addr);
> >> }
> >
> > cdns_pcie_writeb and cdns_pcie_writew are used, so remove them.
> >
> >>
> >> static inline void cdns_pcie_writel(struct cdns_pcie *pcie, u32 reg, u32 value)
> >> {
> >> - writel(value, pcie->reg_base + reg);
> >> + void __iomem *addr = pcie->reg_base + reg;
> >> +
> >> + if (pcie->ops && pcie->ops->write) {
> >> + pcie->ops->write(addr, 0x4, value);
> >> + return;
> >> + }
> >> +
> >> + writel(value, addr);
> >
> > writel isn't broken for you, so you don't need this either.
> >
> >> }
> >>
> >> static inline u32 cdns_pcie_readl(struct cdns_pcie *pcie, u32 reg)
> >> {
> >> - return readl(pcie->reg_base + reg);
> >> + void __iomem *addr = pcie->reg_base + reg;
> >> +
> >> + if (pcie->ops && pcie->ops->read)
> >> + return pcie->ops->read(addr, 0x4);
> >> +
> >> + return readl(addr);
> >
> > And neither is readl.
>
> Sure, I'll remove all the unused functions and avoid using ops for readl and
> writel.
> >
> >> }
> >>
> >> /* Root Port register access */
> >> static inline void cdns_pcie_rp_writeb(struct cdns_pcie *pcie,
> >> u32 reg, u8 value)
> >> {
> >> - writeb(value, pcie->reg_base + CDNS_PCIE_RP_BASE + reg);
> >> + void __iomem *addr = pcie->reg_base + CDNS_PCIE_RP_BASE + reg;
> >> +
> >> + if (pcie->ops && pcie->ops->write) {
> >> + pcie->ops->write(addr, 0x1, value);
> >> + return;
> >> + }
> >> +
> >> + writeb(value, addr);
> >> }
> >>
> >> static inline void cdns_pcie_rp_writew(struct cdns_pcie *pcie,
> >> u32 reg, u16 value)
> >> {
> >> - writew(value, pcie->reg_base + CDNS_PCIE_RP_BASE + reg);
> >> + void __iomem *addr = pcie->reg_base + CDNS_PCIE_RP_BASE + reg;
> >> +
> >> + if (pcie->ops && pcie->ops->write) {
> >> + pcie->ops->write(addr, 0x2, value);
> >> + return;
> >> + }
> >> +
> >> + writew(value, addr);
> >
> > You removed 2 out of 3 calls to this. I think I'd just make the root
> > port writes always be 32-bit. It is all just one time init stuff
> > anyways.
> >
> > Either rework the calls to assemble the data into 32-bits or keep these
> > functions and do the RMW here.
>
> The problem with assembling data into 32-bits is we have to read/write with
> different offsets. We'll give PCI_VENDOR_ID offset for modifying deviceID,
> PCI_INTERRUPT_LINE for modifying INTERRUPT_PIN which might get non-intuitive.
> Similarly in endpoint we read and write to MSI_FLAGS (which is at offset 2) we
> have to directly use MSI capability offset.
>
> And doing RMW in the accessors would mean the same RMW op is repeated. So if we
> just have cdns_pcie_rp_writeb() and cdns_pcie_rp_writew(), the same code will
> be repeated here twice.
Why repeated? Just copy what the config accessors do:
static inline void cdns_pcie_write_sz(u32 val, void __iomem *addr, int size)
{
u32 tmp, mask, where = (unsigned long)addr & 0x3;
addr -= where;
mask = ~(((1 << (size * 8)) - 1) << (where * 8));
tmp = readl(addr) & mask;
tmp |= val << (where * 8);
writel(tmp, addr);
}
/* Root Port register access */
static inline void cdns_pcie_rp_writeb(struct cdns_pcie *pcie,
u32 reg, u8 value)
{
cdns_pcie_write_sz(value, pcie->reg_base + CDNS_PCIE_RP_BASE + reg, 1);
}
static inline void cdns_pcie_rp_writew(struct cdns_pcie *pcie,
u32 reg, u16 value)
{
cdns_pcie_write_sz(value, pcie->reg_base + CDNS_PCIE_RP_BASE + reg, 2);
}
>
> IMHO using ops is a lot cleaner for these cases. IMHO except for removing
> unused functions and not changing readl/writel, others should use ops.
Trying to read the DW PCI driver I don't agree...
Again, unless doing RMW is fundamentally broken (like it is for config
space at runtime), then you only want to do it on broken h/w and ops
would be appropriate. It is all mostly one time setup, so doing a few
extra reads isn't a big deal. If you really care about speed on that,
probably should use the _relaxed accessor variants.
I'm being hopeful the Cadence IP doesn't become the mess that DW is.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 07/15] PCI: brcmstb: Add control of rescal reset
From: Jim Quinlan @ 2020-05-21 21:48 UTC (permalink / raw)
To: Philipp Zabel
Cc: moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Rob Herring, Lorenzo Pieralisi,
open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS, open list,
Florian Fainelli, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Bjorn Helgaas, Nicolas Saenz Julienne
In-Reply-To: <20200520072747.GB5213@pengutronix.de>
On Wed, May 20, 2020 at 3:27 AM Philipp Zabel <pza@pengutronix.de> wrote:
>
> Hi Jim,
>
> On Tue, May 19, 2020 at 04:34:05PM -0400, Jim Quinlan wrote:
> > From: Jim Quinlan <jquinlan@broadcom.com>
> >
> > Some STB chips have a special purpose reset controller named
> > RESCAL (reset calibration). This commit adds the control
> > of RESCAL as well as the ability to start and stop its
> > operation for PCIe HW.
> >
> > Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> > ---
> > drivers/pci/controller/pcie-brcmstb.c | 81 ++++++++++++++++++++++++++-
> > 1 file changed, 80 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> > index 2c470104ba38..0787e8f6f7e5 100644
> > --- a/drivers/pci/controller/pcie-brcmstb.c
> > +++ b/drivers/pci/controller/pcie-brcmstb.c
> [...]
> > @@ -1100,6 +1164,21 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> > dev_err(&pdev->dev, "could not enable clock\n");
> > return ret;
> > }
> > + pcie->rescal = devm_reset_control_get_shared(&pdev->dev, "rescal");
> > + if (IS_ERR(pcie->rescal)) {
> > + if (PTR_ERR(pcie->rescal) == -EPROBE_DEFER)
> > + return -EPROBE_DEFER;
> > + pcie->rescal = NULL;
>
> This is effectively an optional reset control, so it is better to use:
> ↵
> pcie->rescal = devm_reset_control_get_optional_shared(&pdev->dev,
> "rescal");↵
> if (IS_ERR(pcie->rescal))
> return PTR_ERR(pcie->rescal);
>
> > + } else {
> > + ret = reset_control_deassert(pcie->rescal);
> > + if (ret)
> > + dev_err(&pdev->dev, "failed to deassert 'rescal'\n");
> > + }
>
> reset_control_* can handle rstc == NULL parameters for optional reset
> controls, so this can be done unconditionally:
>
> ret = reset_control_deassert(pcie->rescal);↵
> if (ret)↵
> dev_err(&pdev->dev, "failed to deassert 'rescal'\n");↵
>
> Is rescal handled by the reset-brcmstb-rescal driver? Since that only
> implements the .reset op, I would expect reset_control_reset() here.
Where exactly? "reset.h" says that "Calling reset_control_rese()t is
not allowed on a shared reset control." so I'm not sure why you would
want me to invoke it.
> Otherwise this looks like it'd be missing a reset_control_assert in
> remove.
I can add this.
Thanks,
Jim
>
> regards
> Philipp
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 4/4] soc: amlogic: driver updates for v5.8
From: Kevin Hilman @ 2020-05-21 21:41 UTC (permalink / raw)
To: soc, arm; +Cc: linux-amlogic, linux-arm-kernel
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-drivers
for you to fetch changes up to 53773f2dfd9c847304b184d5617e36aeafdf5d87:
soc: amlogic: meson-ee-pwrc: add support for the Meson GX SoCs (2020-05-19 16:02:14 -0700)
----------------------------------------------------------------
soc: amlogic: driver updates for v5.8
- support GX SoCs in the EE power-controller driver
----------------------------------------------------------------
Martin Blumenstingl (4):
dt-bindings: power: meson-ee-pwrc: add support for Meson8/8b/8m2
dt-bindings: power: meson-ee-pwrc: add support for the Meson GX SoCs
soc: amlogic: meson-ee-pwrc: add support for Meson8/Meson8b/Meson8m2
soc: amlogic: meson-ee-pwrc: add support for the Meson GX SoCs
Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml | 102 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
drivers/soc/amlogic/meson-ee-pwrc.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------
include/dt-bindings/power/meson-gxbb-power.h | 13 +++++++++
include/dt-bindings/power/meson8-power.h | 13 +++++++++
4 files changed, 214 insertions(+), 26 deletions(-)
create mode 100644 include/dt-bindings/power/meson-gxbb-power.h
create mode 100644 include/dt-bindings/power/meson8-power.h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 3/4] arm64: dts: Amlogic updates for v5.8
From: Kevin Hilman @ 2020-05-21 21:40 UTC (permalink / raw)
To: soc, arm; +Cc: linux-amlogic, linux-arm-kernel
Arnd, Olof,
Note this PR has a dependency a stable branch from the reset tree
(already queued for v5.8) which used by some new audio devices added this
cycle.
Kevin
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64
for you to fetch changes up to 0b928e4e412b1eb9e79e02cf3580b9254d338aae:
arm64: dts: meson-g12b-gtking-pro: add initial device-tree (2020-05-20 14:43:48 -0700)
----------------------------------------------------------------
arm64: dts: Amlogic updates for v5.8
Highlights:
- new boards :Beelink GT-King Pro (G12B SoC), Smartlabs SML-5442TW
(S905D), Hardkernel ODROID-C4 (SM1)
- audio: support for GX-family SoCs
- audio: internal DAC support
- use the new USB control driver for GXL and GXM
----------------------------------------------------------------
Christian Hewitt (9):
dt-bindings: add vendor prefix for Smartlabs LLC
dt-bindings: arm: amlogic: add support for the Smartlabs SML-5442TW
arm64: dts: meson: add support for the Smartlabs SML-5442TW
arm64: dts: meson: add ethernet interrupt to wetek dtsi
arm64: dts: meson: convert ugoos-am6 to common w400 dtsi
dt-bindings: arm: amlogic: add support for the Beelink GT-King
arm64: dts: meson-g12b-gtking: add initial device-tree
dt-bindings: arm: amlogic: add support for the Beelink GT-King Pro
arm64: dts: meson-g12b-gtking-pro: add initial device-tree
Dongjin Kim (1):
arm64: dts: meson-sm1: add support for Hardkernel ODROID-C4
Jerome Brunet (14):
arm64: dts: meson: kvim3: move hdmi to tdm a
dt-bindings: reset: meson: add gxl internal dac reset
arm64: dts: meson-gx: add aiu support
arm64: dts: meson: p230-q200: add initial audio playback support
arm64: dts: meson: libretech-cc: add initial audio playback support
arm64: dts: meson: libretech-ac: add initial audio playback support
arm64: dts: meson: libretech-pc: add initial audio playback support
arm64: dts: meson: gxl: add acodec support
arm64: dts: meson: p230-q200: add internal DAC support
arm64: dts: meson: libretech-cc: add internal DAC support
arm64: dts: meson: libretech-ac: add internal DAC support
arm64: dts: meson: libretech-pc: add internal DAC support
arm64: dts: meson: g12: add internal DAC
arm64: dts: meson: g12: add internal DAC glue
Kevin Hilman (1):
Merge branch 'reset/meson-gxl-dac' of git://git.pengutronix.de/pza/linux into HEAD
Martin Blumenstingl (1):
arm64: dts: amlogic: use the new USB control driver for GXL and GXM
Neil Armstrong (7):
arm64: dts: meson: fixup SCP sram nodes
arm64: dts: meson-g12b-ugoos-am6: fix board compatible
arm64: dts: meson-gxbb-kii-pro: fix board compatible
arm64: dts: meson: fix leds subnodes name
arm64: dts: meson-g12b: move G12B thermal nodes to meson-g12b.dtsi
arm64: dts: meson-sm1: add cpu thermal nodes
dt-bindings: arm: amlogic: add odroid-c4 bindings
Tim Lewis (1):
arm64: dts: meson: S922X: extend cpu opp-points
Documentation/devicetree/bindings/arm/amlogic.yaml | 4 +
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/amlogic/Makefile | 4 +
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 6 +-
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 11 +++
arch/arm64/boot/dts/amlogic/meson-g12.dtsi | 32 ++-----
arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts | 125 +++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts | 145 +++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi | 18 ++--
arch/arm64/boot/dts/amlogic/meson-g12b-s922x.dtsi | 15 +++
arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts | 377 +-------------------------------------------------------------------------
arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi | 423 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 22 +++++
arch/arm64/boot/dts/amlogic/meson-gx-libretech-pc.dtsi | 78 +++++++++++++++-
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 98 +++++++++++++++++++-
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 23 ++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts | 4 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi | 6 +-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 23 +++++
arch/arm64/boot/dts/amlogic/meson-gxl-s805x-libretech-ac.dts | 73 ++++++++++++++-
arch/arm64/boot/dts/amlogic/meson-gxl-s805x-p241.dts | 3 +-
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-phicomm-n1.dts | 4 +
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-sml5442tw.dts | 80 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905w-p281.dts | 4 +
arch/arm64/boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts | 4 +
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts | 4 +
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts | 77 +++++++++++++++-
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts | 3 +-
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 3 +-
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 79 ++++++++++++----
arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 3 +-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 3 +-
arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts | 4 +-
arch/arm64/boot/dts/amlogic/meson-gxm-vega-s96.dts | 4 +
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 7 +-
arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi | 4 +-
arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts | 402 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 24 +++++
include/dt-bindings/reset/amlogic,meson-gxbb-reset.h | 2 +-
45 files changed, 1751 insertions(+), 464 deletions(-)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gtking-pro.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-sml5442tw.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 2/4] ARM: dts: Amlogic updates for v5.8
From: Kevin Hilman @ 2020-05-21 21:39 UTC (permalink / raw)
To: soc, arm; +Cc: linux-amlogic, linux-arm-kernel
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt
for you to fetch changes up to 005231128e9e97461e81fa32421957a7664317ca:
ARM: dts: meson: Switch existing boards with RGMII PHY to "rgmii-id" (2020-05-19 16:18:59 -0700)
----------------------------------------------------------------
ARM: dts: Amlogic updates for v5.8
- eth PHY and USB PHY updates
----------------------------------------------------------------
Martin Blumenstingl (4):
ARM: dts: meson: add the gadget mode properties to the USB0 controller
ARM: dts: meson8m2: Use the Meson8m2 specific USB2 PHY compatible
ARM: dts: meson: Add the Ethernet "timing-adjustment" clock
ARM: dts: meson: Switch existing boards with RGMII PHY to "rgmii-id"
arch/arm/boot/dts/meson.dtsi | 3 +++
arch/arm/boot/dts/meson8b-odroidc1.dts | 3 +--
arch/arm/boot/dts/meson8b.dtsi | 5 +++--
arch/arm/boot/dts/meson8m2-mxiii-plus.dts | 4 +---
arch/arm/boot/dts/meson8m2.dtsi | 13 +++++++++++--
5 files changed, 19 insertions(+), 9 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 1/4] arm64: defconfig: Amlogic updates for v5.8
From: Kevin Hilman @ 2020-05-21 21:39 UTC (permalink / raw)
To: soc, arm; +Cc: linux-amlogic, linux-arm-kernel
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-defconfig
for you to fetch changes up to 38f58fc51d12b25f9aab9afa2e6f58227c950d9e:
arm64: defconfig: enable meson gx audio as module (2020-04-30 07:53:22 -0700)
----------------------------------------------------------------
arm64: defconfig: Amlogic updates for v5.8
- enable meson gx audio as module
----------------------------------------------------------------
Jerome Brunet (1):
arm64: defconfig: enable meson gx audio as module
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
From: Wolfram Sang @ 2020-05-21 21:21 UTC (permalink / raw)
To: Andy Shevchenko
Cc: devicetree, linux-kernel, tmaimon77, yuenn, avifishman70, venture,
openbmc, brendanhiggins, ofery, Tali Perry, kfting, robh+dt,
linux-i2c, linux-arm-kernel, benjaminfair
In-Reply-To: <20200521143100.GA16812@ninjato>
[-- Attachment #1.1: Type: text/plain, Size: 192 bytes --]
> From a glimpse, this looks good to go. I will have a close look later
> today.
Phew, this driver is huge. I won't finish my review today, but I am
working on it and am maybe 2/3 through.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox