From: Will Deacon <will@kernel.org>
To: Connor Abbott <cwabbott0@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>, Sean Paul <sean@poorly.run>,
Konrad Dybcio <konradybcio@kernel.org>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Marijn Suijten <marijn.suijten@somainline.org>,
iommu@lists.linux.dev, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
freedreno@lists.freedesktop.org
Subject: Re: [PATCH v4 2/5] iommu/arm-smmu-qcom: Don't read fault registers directly
Date: Tue, 11 Mar 2025 18:08:08 +0000 [thread overview]
Message-ID: <20250311180807.GC5216@willie-the-truck> (raw)
In-Reply-To: <20250304-msm-gpu-fault-fixes-next-v4-2-be14be37f4c3@gmail.com>
On Tue, Mar 04, 2025 at 11:56:48AM -0500, Connor Abbott wrote:
> In some cases drm/msm has to resume a stalled transaction directly in
> its fault handler. Experimentally this doesn't work on SMMU500 if the
> fault hasn't already been acknowledged by clearing FSR. Rather than
> trying to clear FSR in msm's fault handler and implementing a
> tricky handshake to avoid accidentally clearing FSR twice, we want to
> clear FSR before calling the fault handlers, but this means that the
> contents of registers can change underneath us in the fault handler and
> msm currently uses a private function to read the register contents for
> its own purposes in its fault handler, such as using the
> implementation-defined FSYNR1 to determine which block caused the fault.
> Fix this by making msm use the register values already read by arm-smmu
> itself before clearing FSR rather than messing around with reading
> registers directly.
>
> Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 19 +++++++++----------
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 14 +++++++-------
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 21 +++++++++++----------
> 3 files changed, 27 insertions(+), 27 deletions(-)
[...]
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index d3bc77dcd4d40f25bc70f3289616fb866649b022..411d807e0a7033833716635efb3968a0bd3ff237 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -373,6 +373,16 @@ enum arm_smmu_domain_stage {
> ARM_SMMU_DOMAIN_NESTED,
> };
>
> +struct arm_smmu_context_fault_info {
> + unsigned long iova;
> + u64 ttbr0;
> + u32 fsr;
> + u32 fsynr0;
> + u32 fsynr1;
> + u32 cbfrsynra;
> + u32 contextidr;
> +};
> +
> struct arm_smmu_domain {
> struct arm_smmu_device *smmu;
> struct io_pgtable_ops *pgtbl_ops;
> @@ -380,6 +390,7 @@ struct arm_smmu_domain {
> const struct iommu_flush_ops *flush_ops;
> struct arm_smmu_cfg cfg;
> enum arm_smmu_domain_stage stage;
> + struct arm_smmu_context_fault_info cfi;
Does this mean we have to serialise all faults for a given domain? That
can't be right...
Will
next prev parent reply other threads:[~2025-03-11 18:25 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 16:56 [PATCH v4 0/5] iommu/arm-smmu, drm/msm: Fixes for stall-on-fault Connor Abbott
2025-03-04 16:56 ` [PATCH v4 1/5] iommu/arm-smmu: Save additional information on context fault Connor Abbott
2025-03-05 19:09 ` Rob Clark
2025-03-11 18:05 ` Will Deacon
2025-03-11 22:36 ` Connor Abbott
2025-03-12 13:05 ` Will Deacon
2025-03-12 14:59 ` Rob Clark
2025-03-12 16:47 ` Will Deacon
2025-03-12 17:23 ` Rob Clark
2025-03-12 18:01 ` Robin Murphy
2025-03-12 20:20 ` Rob Clark
2025-03-18 15:46 ` Will Deacon
2025-03-04 16:56 ` [PATCH v4 2/5] iommu/arm-smmu-qcom: Don't read fault registers directly Connor Abbott
2025-03-05 19:08 ` Rob Clark
2025-03-11 18:08 ` Will Deacon [this message]
2025-03-11 19:42 ` Connor Abbott
2025-03-11 20:00 ` Rob Clark
2025-03-12 12:57 ` Robin Murphy
2025-03-12 13:06 ` Will Deacon
2025-03-04 16:56 ` [PATCH v4 3/5] iommu/arm-smmu: Fix spurious interrupts with stall-on-fault Connor Abbott
2025-03-05 19:12 ` Rob Clark
2025-03-04 16:56 ` [PATCH v4 4/5] iommu/arm-smmu-qcom: Make set_stall work when the device is on Connor Abbott
2025-03-05 19:09 ` Rob Clark
2025-03-11 18:11 ` Will Deacon
2025-03-11 20:01 ` Connor Abbott
2025-03-12 12:49 ` Will Deacon
2025-03-12 13:30 ` Connor Abbott
2025-03-18 13:36 ` Robin Murphy
2025-03-18 15:47 ` Will Deacon
2025-03-04 16:56 ` [PATCH v4 5/5] drm/msm: Temporarily disable stall-on-fault after a page fault Connor Abbott
2025-03-05 19:07 ` Rob Clark
2025-03-05 19:38 ` Connor Abbott
2025-03-05 19:56 ` Rob Clark
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=20250311180807.GC5216@willie-the-truck \
--to=will@kernel.org \
--cc=cwabbott0@gmail.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=freedreno@lists.freedesktop.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=konradybcio@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=robin.murphy@arm.com \
--cc=sean@poorly.run \
/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