From: Daniel Thompson <daniel.thompson@linaro.org>
To: laurentiu.tudor@nxp.com
Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
diana.craciun@nxp.com, ioana.ciornei@nxp.com, jon@solid-run.com,
leoyang.li@nxp.com
Subject: Re: [PATCH 2/8] bus: fsl-mc: handle DMA config deferral in ACPI case
Date: Thu, 11 Nov 2021 17:23:40 +0000 [thread overview]
Message-ID: <20211111172340.fpn4pou2xwm654g5@maple.lan> (raw)
In-Reply-To: <20210715140718.8513-2-laurentiu.tudor@nxp.com>
Hi Laurentiu
On Thu, Jul 15, 2021 at 05:07:12PM +0300, laurentiu.tudor@nxp.com wrote:
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>
> ACPI DMA configure API may return a defer status code, so handle it.
> On top of this, move the MC firmware resume after the DMA setup
> is completed to avoid crashing due to DMA setup not being done yet or
> being deferred.
>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
I saw regressions on my Honeycomb LX2 (NXP LX2060A) when I switched to
v5.15. It seems like it results in so many sMMU errors that the system
cannot function correctly (it's only about a 75% chance the system will
boot to GUI and even if it does boot successfully the system will hang
up soon after).
Bisect took me up a couple of blind alleys (mostly due to unrelated boot
problems in v5.14-rc2) by eventually led me to this patch as the cause.
Applying/unapplying this patch to a v5.14-rc3 tree will provoke/fix the
problem and reverting it against v5.15 also resolves the problem.
Is there some specific firmware version required for this patch to work
correctly?
Daniel.
PS: Below is the revert I applied to the v5.15 kernel (after
a fairly simple merge conflict fix)
From 4162b64e4f361a6a773e065b592dbc5493202524 Mon Sep 17 00:00:00 2001
From: Daniel Thompson <daniel.thompson@linaro.org>
Date: Thu, 11 Nov 2021 16:50:25 +0000
Subject: [PATCH] Revert "bus: fsl-mc: handle DMA config deferral in ACPI case"
This reverts commit d31e7fe20a2251f87adc6ecefbdaf25e6961ce74 because
it was causing regressions on my Honeycomb LX2 (NXP LX2060A).
All kernels where the problem manifests (as either a boot hang or a desktop
hang) issue the following messages in vast number:
~~~
arm-smmu arm-smmu.0.auto: Unhandled context fault: fsr=0x402, iova=0x23e0000100, fsynr=0x20040, cbfrsynra=0x4000, cb=0
arm-smmu arm-smmu.0.auto: Unhandled context fault: fsr=0x402, iova=0x23e0000100, fsynr=0x20040, cbfrsynra=0x4000, cb=0
arm-smmu arm-smmu.0.auto: Unhandled context fault: fsr=0x402, iova=0x23e0000100, fsynr=0x20040, cbfrsynra=0x4000, cb=0
arm-smmu arm-smmu.0.auto: Unhandled context fault: fsr=0x402, iova=0x23e0000100, fsynr=0x20040, cbfrsynra=0x4000, cb=0
arm-smmu arm-smmu.0.auto: Unhandled context fault: fsr=0x402, iova=0x23e0000100, fsynr=0x20040, cbfrsynra=0x4000, cb=0
arm-smmu arm-smmu.0.auto: Unhandled context fault: fsr=0x402, iova=0x23e0000100, fsynr=0x20040, cbfrsynra=0x4000, cb=0
arm-smmu arm-smmu.0.auto: Unhandled context fault: fsr=0x402, iova=0x23e0000100, fsynr=0x20040, cbfrsynra=0x4000, cb=0
arm-smmu arm-smmu.0.auto: Unhandled context fault: fsr=0x402, iova=0x23e0000100, fsynr=0x20040, cbfrsynra=0x4000, cb=0
arm-smmu arm-smmu.0.auto: Unhandled context fault: fsr=0x402, iova=0x23e0000100, fsynr=0x20040, cbfrsynra=0x4000, cb=0
arm-smmu arm-smmu.0.auto: Unhandled context fault: fsr=0x402, iova=0x23e0000100, fsynr=0x20040, cbfrsynra=0x4000, cb=0
arm_smmu_context_fault: 1697259 callbacks suppressed
~~~
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 8fd4a356a86e..429bacc7de20 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -1130,6 +1130,18 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
}
if (mc->fsl_mc_regs) {
+ /*
+ * Some bootloaders pause the MC firmware before booting the
+ * kernel so that MC will not cause faults as soon as the
+ * SMMU probes due to the fact that there's no configuration
+ * in place for MC.
+ * At this point MC should have all its SMMU setup done so make
+ * sure it is resumed.
+ */
+ writel(readl(mc->fsl_mc_regs + FSL_MC_GCR1) &
+ (~(GCR1_P1_STOP | GCR1_P2_STOP)),
+ mc->fsl_mc_regs + FSL_MC_GCR1);
+
if (IS_ENABLED(CONFIG_ACPI) && !dev_of_node(&pdev->dev)) {
mc_stream_id = readl(mc->fsl_mc_regs + FSL_MC_FAPR);
/*
@@ -1143,25 +1155,11 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
error = acpi_dma_configure_id(&pdev->dev,
DEV_DMA_COHERENT,
&mc_stream_id);
- if (error == -EPROBE_DEFER)
- return error;
if (error)
dev_warn(&pdev->dev,
"failed to configure dma: %d.\n",
error);
}
-
- /*
- * Some bootloaders pause the MC firmware before booting the
- * kernel so that MC will not cause faults as soon as the
- * SMMU probes due to the fact that there's no configuration
- * in place for MC.
- * At this point MC should have all its SMMU setup done so make
- * sure it is resumed.
- */
- writel(readl(mc->fsl_mc_regs + FSL_MC_GCR1) &
- (~(GCR1_P1_STOP | GCR1_P2_STOP)),
- mc->fsl_mc_regs + FSL_MC_GCR1);
}
/*
--
2.33.0
next prev parent reply other threads:[~2021-11-11 17:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-15 14:07 [PATCH 1/8] bus: fsl-mc: fix arg in call to dprc_scan_objects() laurentiu.tudor
2021-07-15 14:07 ` [PATCH 2/8] bus: fsl-mc: handle DMA config deferral in ACPI case laurentiu.tudor
2021-11-11 17:23 ` Daniel Thompson [this message]
2021-11-11 17:36 ` Jon Nettleton
2021-11-12 17:31 ` Daniel Thompson
2021-11-17 13:07 ` Laurentiu Tudor
2021-11-17 13:22 ` Jon Nettleton
2021-11-17 13:59 ` Daniel Thompson
2021-11-17 15:30 ` Laurentiu Tudor
2021-11-17 17:00 ` Daniel Thompson
2021-11-18 12:41 ` Laurentiu Tudor
2021-11-17 13:03 ` Laurentiu Tudor
2021-11-17 14:46 ` Daniel Thompson
2021-07-15 14:07 ` [PATCH 3/8] bus: fsl-mc: fully resume the firmware laurentiu.tudor
2021-07-15 14:07 ` [PATCH 4/8] bus: fsl-mc: add .shutdown() op for the bus driver laurentiu.tudor
2021-07-15 14:07 ` [PATCH 5/8] bus: fsl-mc: pause the MC firmware before IOMMU setup laurentiu.tudor
2021-07-15 14:07 ` [PATCH 6/8] bus: fsl-mc: pause the MC firmware when unloading laurentiu.tudor
2021-07-15 14:07 ` [PATCH 7/8] bus: fsl-mc: rescan devices if endpoint not found laurentiu.tudor
2021-07-15 14:07 ` [PATCH 8/8] bus: fsl-mc: fix mmio base address for child DPRCs laurentiu.tudor
2021-07-21 16:11 ` [PATCH 1/8] bus: fsl-mc: fix arg in call to dprc_scan_objects() Diana Madalina Craciun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211111172340.fpn4pou2xwm654g5@maple.lan \
--to=daniel.thompson@linaro.org \
--cc=diana.craciun@nxp.com \
--cc=gregkh@linuxfoundation.org \
--cc=ioana.ciornei@nxp.com \
--cc=jon@solid-run.com \
--cc=laurentiu.tudor@nxp.com \
--cc=leoyang.li@nxp.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).