Re: [PATCH v3 1/2] dt-bindings: iommu: add bindings for sprd iommu
On Tue, 16 Feb 2021 at 23:10, Robin Murphy wrote:
>
> On 2021-02-10 19:21, Rob Herring wrote:
> > On Fri, Feb 5, 2021 at 1:21 AM Chunyan Zhang wrote:
> >>
> >> Hi Rob,
> >>
> >> On Fri, 5 Feb 2021 at 07:25, Rob Herring wrote:
> >>>
> >>> On Wed, Feb 03, 2021 at 05:07:26PM +0800, Chunyan Zhang wrote:
> From: Chunyan Zhang
>
> This iommu module can be used by Unisoc's multimedia devices, such as
> display, Image codec(jpeg) and a few signal processors, including
> VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor),
> etc.
>
> Signed-off-by: Chunyan Zhang
> ---
> .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++
> 1 file changed, 72 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
>
> diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> new file mode 100644
> index ..4fc99e81fa66
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright 2020 Unisoc Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc IOMMU and Multi-media MMU
> +
> +maintainers:
> + - Chunyan Zhang
> +
> +properties:
> + compatible:
> +enum:
> + - sprd,iommu-v1
> +
> + "#iommu-cells":
> +const: 0
> +description:
> + Unisoc IOMMUs are all single-master IOMMU devices, therefore no
> + additional information needs to associate with its master device.
> + Please refer to the generic bindings document for more details,
> + Documentation/devicetree/bindings/iommu/iommu.txt
> +
> + reg:
> +maxItems: 1
> +description:
> + Not required if 'sprd,iommu-regs' is defined.
> +
> + clocks:
> +description:
> + Reference to a gate clock phandle, since access to some of IOMMUs
> are
> + controlled by gate clock, but this is not required.
> +
> + sprd,iommu-regs:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +description:
> + Reference to a syscon phandle plus 1 cell, the syscon defines the
> + register range used by the iommu and the media device, the cell
> + defines the offset for iommu registers. Since iommu module shares
> + the same register range with the media device which uses it.
> +
> +required:
> + - compatible
> + - "#iommu-cells"
>
> OK, so apparently the hardware is not quite as trivial as my initial
> impression, and you should have interrupts as well.
Ok, I will have a look.
>
> +
> +oneOf:
> + - required:
> + - reg
> + - required:
> + - sprd,iommu-regs
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +iommu_disp: iommu-disp {
> + compatible = "sprd,iommu-v1";
> + sprd,iommu-regs = <&dpu_regs 0x800>;
> >>>
> >>> If the IOMMU is contained within another device, then it should just be
> >>> a child node of that device.
> >>
> >> Yes, actually IOMMU can be seen as a child of multimedia devices, I
> >> considered moving IOMMU under into multimedia device node, but
> >> multimedia devices need IOMMU when probe[1], so I dropped that idea.
> >
> > Don't design your binding around working-around linux issues.
>
> Having stumbled across the DRM driver patches the other day, I now see
> where this is coming from, and it's even worse than that - this whole
> binding seems to be largely working around bad driver design.
>
I guess you mean bad h/w design (not bad driver design)?
Having this syscon node just because I don't want a same register
range to be mapped to multiple virtual address ranges, and that's the
case for many media devices and their IOMMUs. If this issue exsists
for one device only, I can even endure, but that's not unfortunately.
But anyway, as you all think this is not a good way, I will change to
use reg property.
> >> And they share the same register base, e.g.
> >>
> >> + mm {
> >> + compatible = "simple-bus";
> >> + #address-cells = <2>;
> >> + #size-cells = <2>;
> >> + ranges;
> >> +
> >> + dpu_regs: syscon@6300 {
> >
> > Drop this node.
> >
> >> + compatible = "sprd,sc9863a-dpuregs",
> >> "syscon";
> >> + reg = <0 0x6300 0 0x1000>;
> >> + };
> >> +
> >> +
Re: [PATCH v3 1/2] dt-bindings: iommu: add bindings for sprd iommu
On Thu, 11 Feb 2021 at 03:21, Rob Herring wrote:
>
> On Fri, Feb 5, 2021 at 1:21 AM Chunyan Zhang wrote:
> >
> > Hi Rob,
> >
> > On Fri, 5 Feb 2021 at 07:25, Rob Herring wrote:
> > >
> > > On Wed, Feb 03, 2021 at 05:07:26PM +0800, Chunyan Zhang wrote:
> > > > From: Chunyan Zhang
> > > >
> > > > This iommu module can be used by Unisoc's multimedia devices, such as
> > > > display, Image codec(jpeg) and a few signal processors, including
> > > > VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor),
> > > > etc.
> > > >
> > > > Signed-off-by: Chunyan Zhang
> > > > ---
> > > > .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++
> > > > 1 file changed, 72 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > > > b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > > > new file mode 100644
> > > > index ..4fc99e81fa66
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > > > @@ -0,0 +1,72 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +# Copyright 2020 Unisoc Inc.
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Unisoc IOMMU and Multi-media MMU
> > > > +
> > > > +maintainers:
> > > > + - Chunyan Zhang
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > +enum:
> > > > + - sprd,iommu-v1
> > > > +
> > > > + "#iommu-cells":
> > > > +const: 0
> > > > +description:
> > > > + Unisoc IOMMUs are all single-master IOMMU devices, therefore no
> > > > + additional information needs to associate with its master device.
> > > > + Please refer to the generic bindings document for more details,
> > > > + Documentation/devicetree/bindings/iommu/iommu.txt
> > > > +
> > > > + reg:
> > > > +maxItems: 1
> > > > +description:
> > > > + Not required if 'sprd,iommu-regs' is defined.
> > > > +
> > > > + clocks:
> > > > +description:
> > > > + Reference to a gate clock phandle, since access to some of
> > > > IOMMUs are
> > > > + controlled by gate clock, but this is not required.
> > > > +
> > > > + sprd,iommu-regs:
> > > > +$ref: /schemas/types.yaml#/definitions/phandle-array
> > > > +description:
> > > > + Reference to a syscon phandle plus 1 cell, the syscon defines the
> > > > + register range used by the iommu and the media device, the cell
> > > > + defines the offset for iommu registers. Since iommu module shares
> > > > + the same register range with the media device which uses it.
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - "#iommu-cells"
> > > > +
> > > > +oneOf:
> > > > + - required:
> > > > + - reg
> > > > + - required:
> > > > + - sprd,iommu-regs
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > + - |
> > > > +iommu_disp: iommu-disp {
> > > > + compatible = "sprd,iommu-v1";
> > > > + sprd,iommu-regs = <&dpu_regs 0x800>;
> > >
> > > If the IOMMU is contained within another device, then it should just be
> > > a child node of that device.
> >
> > Yes, actually IOMMU can be seen as a child of multimedia devices, I
> > considered moving IOMMU under into multimedia device node, but
> > multimedia devices need IOMMU when probe[1], so I dropped that idea.
>
> Don't design your binding around working-around linux issues.
>
> > And they share the same register base, e.g.
> >
> > + mm {
> > + compatible = "simple-bus";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + dpu_regs: syscon@6300 {
>
> Drop this node.
>
> > + compatible = "sprd,sc9863a-dpuregs",
> > "syscon";
> > + reg = <0 0x6300 0 0x1000>;
> > + };
> > +
> > + dpu: dpu@6300 {
> > + compatible = "sprd,sharkl3-dpu";
> > + sprd,disp-regs = <&dpu_regs>;
>
> reg = <0 0x6300 0 0x800>;
>
> > + iommus = <&iommu_dispc>;
> > + };
> > +
> > + iommu_dispc: iommu@6300 {
> > + compatible = "sprd,iommu-v1";
> > + sprd,iommu-regs = <&dpu_regs 0x800>;
>
> reg = <0 0x63000800 0 0x800>;
Alright, considering you deprecate using syscon to map registers here,
I will drop that.
But that would cause the same physical address to be mapped two times at least.
And this is not a single case, since there are a few media devices and
the
Re: [PATCH v4 12/14] swiotlb: Add restricted DMA alloc/free support.
On Fri, Feb 26, 2021 at 12:17:50PM +0800, Claire Chang wrote: > Do you think I should fix this and rebase on the latest linux-next > now? I wonder if there are more factor and clean up coming and I > should wait after that. Here is my preferred plan: 1) wait for my series to support the min alignment in swiotlb to land in Linus tree 2) I'll resend my series with the further swiotlb cleanup and refactoring, which includes a slightly rebased version of your patch to add the io_tlb_mem structure 3) resend your series on top of that as a baseline This is my current WIP tree for 2: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/swiotlb-struct ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 12/14] swiotlb: Add restricted DMA alloc/free support.
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index fd9c1bd183ac..8b77fd64199e 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -836,6 +836,40 @@ late_initcall(swiotlb_create_default_debugfs);
> #endif
>
> #ifdef CONFIG_DMA_RESTRICTED_POOL
> +struct page *dev_swiotlb_alloc(struct device *dev, size_t size, gfp_t gfp)
> +{
> + struct swiotlb *swiotlb;
> + phys_addr_t tlb_addr;
> + unsigned int index;
> +
> + /* dev_swiotlb_alloc can be used only in the context which permits
> sleeping. */
> + if (!dev->dev_swiotlb || !gfpflags_allow_blocking(gfp))
Just noticed that !gfpflags_allow_blocking(gfp) shouldn't be here.
Hi Christoph,
Do you think I should fix this and rebase on the latest linux-next
now? I wonder if there are more factor and clean up coming and I
should wait after that.
Thanks,
Claire
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 08/12] fork: Clear PASID for new mm
Hi, Jean, On Wed, Feb 24, 2021 at 11:19:27AM +0100, Jean-Philippe Brucker wrote: > Hi Fenghua, > > [Trimmed the Cc list] > > On Mon, Jul 13, 2020 at 04:48:03PM -0700, Fenghua Yu wrote: > > When a new mm is created, its PASID should be cleared, i.e. the PASID is > > initialized to its init state 0 on both ARM and X86. > > I just noticed this patch was dropped in v7, and am wondering whether we > could still upstream it. Does x86 need a child with a new address space > (!CLONE_VM) to inherit the PASID of the parent? That doesn't make much > sense with regard to IOMMU structures - same PASID indexing multiple PGDs? You are right: x86 should clear mm->pasid when a new mm is created. This patch somehow is losted:( > > Currently iommu_sva_alloc_pasid() assumes mm->pasid is always initialized > to 0 and fails on forked tasks. I'm trying to figure out how to fix this. > Could we clear the pasid on fork or does it break the x86 model? x86 calls ioasid_alloc() instead of iommu_sva_alloc_pasid(). So functionality is not a problem without this patch on x86. But I think we do need to have this patch in the kernel because PASID is per addr space and two addr spaces shouldn't have the same PASID. Who will accept this patch? Thanks. -Fenghua ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] iommu/arm-smmu-qcom: Move the adreno smmu specific impl earlier
On Thu, Feb 25, 2021 at 03:54:10PM +0530, Sai Prakash Ranjan wrote:
> Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
> both implement "arm,mmu-500" in some QTI SoCs and to run through
> adreno smmu specific implementation such as enabling split pagetables
> support, we need to match the "qcom,adreno-smmu" compatible first
> before apss smmu or else we will be running apps smmu implementation
> for adreno smmu and the additional features for adreno smmu is never
> set. For ex: we have "qcom,sc7280-smmu-500" compatible for both apps
> and adreno smmu implementing "arm,mmu-500", so the adreno smmu
> implementation is never reached because the current sequence checks
> for apps smmu compatible(qcom,sc7280-smmu-500) first and runs that
> specific impl and we never reach adreno smmu specific implementation.
>
> Suggested-by: Akhil P Oommen
> Signed-off-by: Sai Prakash Ranjan
> ---
>
> Its either this or we add a new compatible for adreno smmu implementing
> arm,mmu-500 like "qcom,sc7280-adreno-smmu-500".
>
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index bea3ee0dabc2..7d0fc2c8e72f 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -345,11 +345,11 @@ struct arm_smmu_device *qcom_smmu_impl_init(struct
> arm_smmu_device *smmu)
> {
> const struct device_node *np = smmu->dev->of_node;
>
> - if (of_match_node(qcom_smmu_impl_of_match, np))
> - return qcom_smmu_create(smmu, &qcom_smmu_impl);
> -
> if (of_device_is_compatible(np, "qcom,adreno-smmu"))
> return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl);
>
> + if (of_match_node(qcom_smmu_impl_of_match, np))
> + return qcom_smmu_create(smmu, &qcom_smmu_impl);
> +
It would be good to add a comment here explaining the order here so we
don't accidentally reorganize ourselves back into a problem later.
Jordan
> return smmu;
> }
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
> ___
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 2/3] drm/msm: Add an adreno-smmu-priv callback to get pagefault info
Add a callback in adreno-smmu-priv to read interesting SMMU
registers to provide an opportunity for a richer debug experience
in the GPU driver.
Signed-off-by: Jordan Crouse
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 19 +
drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
include/linux/adreno-smmu-priv.h | 31 +-
3 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 98b3a1c2a181..8413bfbafed4 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -32,6 +32,24 @@ static void qcom_adreno_smmu_write_sctlr(struct
arm_smmu_device *smmu, int idx,
arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_SCTLR, reg);
}
+static void qcom_adreno_smmu_get_fault_info(const void *cookie,
+ struct adreno_smmu_fault_info *info)
+{
+ struct arm_smmu_domain *smmu_domain = (void *)cookie;
+ struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+ struct arm_smmu_device *smmu = smmu_domain->smmu;
+
+ info->fsr = arm_smmu_cb_read(smmu, cfg->cbndx, ARM_SMMU_CB_FSR);
+ /* FIXME: return error here if we aren't really in a fault? */
+
+ info->fsynr0 = arm_smmu_cb_read(smmu, cfg->cbndx, ARM_SMMU_CB_FSYNR0);
+ info->fsynr1 = arm_smmu_cb_read(smmu, cfg->cbndx, ARM_SMMU_CB_FSYNR1);
+ info->far = arm_smmu_cb_readq(smmu, cfg->cbndx, ARM_SMMU_CB_FAR);
+ info->cbfrsynra = arm_smmu_gr1_read(smmu,
ARM_SMMU_GR1_CBFRSYNRA(cfg->cbndx));
+ info->ttbr0 = arm_smmu_cb_read(smmu, cfg->cbndx, ARM_SMMU_CB_TTBR0);
+ info->contextidr = arm_smmu_cb_read(smmu, cfg->cbndx,
ARM_SMMU_CB_CONTEXTIDR);
+}
+
#define QCOM_ADRENO_SMMU_GPU_SID 0
static bool qcom_adreno_smmu_is_gpu_device(struct device *dev)
@@ -156,6 +174,7 @@ static int qcom_adreno_smmu_init_context(struct
arm_smmu_domain *smmu_domain,
priv->cookie = smmu_domain;
priv->get_ttbr1_cfg = qcom_adreno_smmu_get_ttbr1_cfg;
priv->set_ttbr0_cfg = qcom_adreno_smmu_set_ttbr0_cfg;
+ priv->get_fault_info = qcom_adreno_smmu_get_fault_info;
return 0;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index d2a2d1bc58ba..9e84daf27dab 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -224,6 +224,8 @@ enum arm_smmu_cbar_type {
#define ARM_SMMU_CB_FSYNR0 0x68
#define ARM_SMMU_FSYNR0_WNRBIT(4)
+#define ARM_SMMU_CB_FSYNR1 0x6c
+
#define ARM_SMMU_CB_S1_TLBIVA 0x600
#define ARM_SMMU_CB_S1_TLBIASID0x610
#define ARM_SMMU_CB_S1_TLBIVAL 0x620
diff --git a/include/linux/adreno-smmu-priv.h b/include/linux/adreno-smmu-priv.h
index a889f28afb42..53fe32fb9214 100644
--- a/include/linux/adreno-smmu-priv.h
+++ b/include/linux/adreno-smmu-priv.h
@@ -8,6 +8,32 @@
#include
+/**
+ * struct adreno_smmu_fault_info - container for key fault information
+ *
+ * @far: The faulting IOVA from ARM_SMMU_CB_FAR
+ * @ttbr0: The current TTBR0 pagetable from ARM_SMMU_CB_TTBR0
+ * @contextidr: The value of ARM_SMMU_CB_CONTEXTIDR
+ * @fsr: The fault status from ARM_SMMU_CB_FSR
+ * @fsynr0: The value of FSYNR0 from ARM_SMMU_CB_FSYNR0
+ * @fsynr1: The value of FSYNR1 from ARM_SMMU_CB_FSYNR0
+ * @cbfrsynra: The value of CBFRSYNRA from ARM_SMMU_GR1_CBFRSYNRA(idx)
+ *
+ * This struct passes back key page fault information to the GPU driver
+ * through the get_fault_info function pointer.
+ * The GPU driver can use this information to print informative
+ * log messages and provide deeper GPU specific insight into the fault.
+ */
+struct adreno_smmu_fault_info {
+ u64 far;
+ u64 ttbr0;
+ u32 contextidr;
+ u32 fsr;
+ u32 fsynr0;
+ u32 fsynr1;
+ u32 cbfrsynra;
+};
+
/**
* struct adreno_smmu_priv - private interface between adreno-smmu and GPU
*
@@ -17,6 +43,8 @@
* @set_ttbr0_cfg: Set the TTBR0 config for the GPUs context bank. A
* NULL config disables TTBR0 translation, otherwise
* TTBR0 translation is enabled with the specified cfg
+ * @get_fault_info: Called by the GPU fault handler to get information about
+ * the fault
*
* The GPU driver (drm/msm) and adreno-smmu work together for controlling
* the GPU's SMMU instance. This is by necessity, as the GPU is directly
@@ -31,6 +59,7 @@ struct adreno_smmu_priv {
const void *cookie;
const struct io_pgtable_cfg *(*get_ttbr1_cfg)(const void *cookie);
int (*set_ttbr0_cfg)(const void *cookie, const struct io_pgtable_cfg *cfg);
+void (*get_fault_info)(const void *cookie, struct adreno_smmu_fault_info
*info);
};
-#endif /* __ADRENO_SMMU_PRIV_H */
\ No newline at end of file
+#endif /* __ADRENO_SMMU_PRIV_H */
--
2.25.1
___
iommu mailing list
iommu@lis
[PATCH v3 3/3] drm/msm: Improve the a6xx page fault handler
Use the new adreno-smmu-priv fault info function to get more SMMU
debug registers and print the current TTBR0 to debug per-instance
pagetables and figure out which GPU block generated the request.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 76 +--
drivers/gpu/drm/msm/msm_iommu.c | 11 +++-
drivers/gpu/drm/msm/msm_mmu.h | 4 +-
4 files changed, 87 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 7e553d3efeb2..56b548921c4e 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1075,7 +1075,7 @@ bool a5xx_idle(struct msm_gpu *gpu, struct msm_ringbuffer
*ring)
return true;
}
-static int a5xx_fault_handler(void *arg, unsigned long iova, int flags)
+static int a5xx_fault_handler(void *arg, unsigned long iova, int flags, void
*data)
{
struct msm_gpu *gpu = arg;
pr_warn_ratelimited("*** gpu fault: iova=%08lx, flags=%d
(%u,%u,%u,%u)\n",
@@ -1085,7 +1085,7 @@ static int a5xx_fault_handler(void *arg, unsigned long
iova, int flags)
gpu_read(gpu, REG_A5XX_CP_SCRATCH_REG(6)),
gpu_read(gpu, REG_A5XX_CP_SCRATCH_REG(7)));
- return -EFAULT;
+ return 0;
}
static void a5xx_cp_err_irq(struct msm_gpu *gpu)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 064b7face504..97eabd87740c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -959,18 +959,88 @@ static void a6xx_recover(struct msm_gpu *gpu)
msm_gpu_hw_init(gpu);
}
-static int a6xx_fault_handler(void *arg, unsigned long iova, int flags)
+static const char *a6xx_uche_fault_block(struct msm_gpu *gpu, u32 mid)
+{
+ static const char *uche_clients[7] = {
+ "VFD", "SP", "VSC", "VPC", "HLSQ", "PC", "LRZ",
+ };
+ u32 val;
+
+ if (mid < 1 || mid > 3)
+ return "UNKNOWN";
+
+ /*
+* The source of the data depends on the mid ID read from FSYNR1.
+* and the client ID read from the UCHE block
+*/
+ val = gpu_read(gpu, REG_A6XX_UCHE_CLIENT_PF);
+
+ /* mid = 3 is most precise and refers to only one block per client */
+ if (mid == 3)
+ return uche_clients[val & 7];
+
+ /* For mid=2 the source is TP or VFD except when the client id is 0 */
+ if (mid == 2)
+ return ((val & 7) == 0) ? "TP" : "TP|VFD";
+
+ /* For mid=1 just return "UCHE" as a catchall for everything else */
+ return "UCHE";
+}
+
+static const char *a6xx_fault_block(struct msm_gpu *gpu, u32 id)
+{
+ if (id == 0)
+ return "CP";
+ else if (id == 4)
+ return "CCU";
+ else if (id == 6)
+ return "CDP Prefetch";
+
+ return a6xx_uche_fault_block(gpu, id);
+}
+
+#define ARM_SMMU_FSR_TF BIT(1)
+#define ARM_SMMU_FSR_PFBIT(3)
+#define ARM_SMMU_FSR_EFBIT(4)
+
+static int a6xx_fault_handler(void *arg, unsigned long iova, int flags, void
*data)
{
struct msm_gpu *gpu = arg;
+ struct adreno_smmu_fault_info *info = data;
+ const char *type = "UNKNOWN";
- pr_warn_ratelimited("*** gpu fault: iova=%08lx, flags=%d
(%u,%u,%u,%u)\n",
+ /*
+* Print a default message if we couldn't get the data from the
+* adreno-smmu-priv
+*/
+ if (!info) {
+ pr_warn_ratelimited("*** gpu fault: iova=%.16lx flags=%d
(%u,%u,%u,%u)\n",
iova, flags,
gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(4)),
gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(5)),
gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(6)),
gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(7)));
- return -EFAULT;
+ return 0;
+ }
+
+ if (info->fsr & ARM_SMMU_FSR_TF)
+ type = "TRANSLATION";
+ else if (info->fsr & ARM_SMMU_FSR_PF)
+ type = "PERMISSION";
+ else if (info->fsr & ARM_SMMU_FSR_EF)
+ type = "EXTERNAL";
+
+ pr_warn_ratelimited("*** gpu fault: ttbr0=%.16llx iova=%.16lx dir=%s
type=%s source=%s (%u,%u,%u,%u)\n",
+ info->ttbr0, iova,
+ flags & IOMMU_FAULT_WRITE ? "WRITE" : "READ", type,
+ a6xx_fault_block(gpu, info->fsynr1 & 0xff),
+ gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(4)),
+ gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(5)),
+ gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(6)),
+ gpu_read(gpu, REG_A6XX_CP_SCRATCH_REG(7)));
+
+ return 0;
}
static void a6xx_cp_hw_err_irq(struct msm_gpu *gpu)
[PATCH v3 0/3] iommu/arm-smmu: adreno-smmu page fault handling
(resending for the 5.13 cycle) This is a stack to add an Adreno GPU specific handler for pagefaults. The first patch starts by wiring up report_iommu_fault for arm-smmu. The next patch adds a adreno-smmu-priv function hook to capture a handful of important debugging registers such as TTBR0, CONTEXTIDR, FSYNR0 and others. This is used by the third patch to print more detailed information on page fault such as the TTBR0 for the pagetable that caused the fault and the source of the fault as determined by a combination of the FSYNR1 register and an internal GPU register. This code provides a solid base that we can expand on later for even more extensive GPU side page fault debugging capabilities. v3: Always clear FSR even if the target driver is going to handle resume v2: Fix comment wording and function pointer check per Rob Clark Jordan Crouse (3): iommu/arm-smmu: Add support for driver IOMMU fault handlers drm/msm: Add an adreno-smmu-priv callback to get pagefault info drm/msm: Improve the a6xx page fault handler drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 76 +- drivers/gpu/drm/msm/msm_iommu.c| 11 +++- drivers/gpu/drm/msm/msm_mmu.h | 4 +- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 19 ++ drivers/iommu/arm/arm-smmu/arm-smmu.c | 9 ++- drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 + include/linux/adreno-smmu-priv.h | 31 - 8 files changed, 145 insertions(+), 11 deletions(-) -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 1/3] iommu/arm-smmu: Add support for driver IOMMU fault handlers
Call report_iommu_fault() to allow upper-level drivers to register their own fault handlers. Signed-off-by: Jordan Crouse --- drivers/iommu/arm/arm-smmu/arm-smmu.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c index d8c6bfde6a61..0f3a9b5f3284 100644 --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c @@ -408,6 +408,7 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev) struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); struct arm_smmu_device *smmu = smmu_domain->smmu; int idx = smmu_domain->cfg.cbndx; + int ret; fsr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSR); if (!(fsr & ARM_SMMU_FSR_FAULT)) @@ -417,8 +418,12 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev) iova = arm_smmu_cb_readq(smmu, idx, ARM_SMMU_CB_FAR); cbfrsynra = arm_smmu_gr1_read(smmu, 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", + ret = report_iommu_fault(domain, dev, iova, + fsynr & ARM_SMMU_FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ); + + if (ret == -ENOSYS) + 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); arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_FSR, fsr); -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v14 00/13] SMMUv3 Nested Stage Setup (IOMMU part)
Hi Shameer, all On 2/23/21 9:56 PM, Eric Auger wrote: > This series brings the IOMMU part of HW nested paging support > in the SMMUv3. The VFIO part is submitted separately. > > This is based on Jean-Philippe's > [PATCH v12 00/10] iommu: I/O page faults for SMMUv3 > https://lore.kernel.org/linux-arm-kernel/YBfij71tyYvh8LhB@myrica/T/ > > The IOMMU API is extended to support 2 new API functionalities: > 1) pass the guest stage 1 configuration > 2) pass stage 1 MSI bindings > > Then those capabilities gets implemented in the SMMUv3 driver. > > The virtualizer passes information through the VFIO user API > which cascades them to the iommu subsystem. This allows the guest > to own stage 1 tables and context descriptors (so-called PASID > table) while the host owns stage 2 tables and main configuration > structures (STE). > > Best Regards > > Eric > > This series can be found at: > https://github.com/eauger/linux/tree/v5.11-stallv12-2stage-v14 > (including the VFIO part in its last version: v12) As committed, I have rebased the iommu + vfio part on top of Jean's sva/current (5.11-rc4). https://github.com/eauger/linux/tree/jean_sva_current_2stage_v14 I have not tested the SVA bits but I have tested there is no regression from my pov. >From the QEMU perspective is works off the shelf with that branch but if you want to use other SVA related IOCTLs please remind of updating the linux headers. Again thank you to all of you who reviewed and tested the previous version. Thanks Eric > > The VFIO series is sent separately. > > History: > > Previous version (v13): > https://github.com/eauger/linux/tree/5.10-rc4-2stage-v13 > > v13 -> v14: > - Took into account all received comments I think. Great > thanks to all the testers for their effort and sometimes > fixes. I am really grateful to you! > - numerous fixes including guest running in > noiommu, iommu.strict=0, iommu.passthrough=on, > enable_unsafe_noiommu_mode > > v12 -> v13: > - fixed compilation issue with CONFIG_ARM_SMMU_V3_SVA > reported by Shameer. This urged me to revisit patch 4 into > iommu/smmuv3: Allow s1 and s2 configs to coexist where > s1_cfg and s2_cfg are not dynamically allocated anymore. > Instead I use a new set field in existing structs > - fixed 2 others config checks > - Updated "iommu/arm-smmu-v3: Maintain a SID->device structure" > according to the last version > > v11 -> v12: > - rebase on top of v5.10-rc4 > > Eric Auger (13): > iommu: Introduce attach/detach_pasid_table API > iommu: Introduce bind/unbind_guest_msi > iommu/smmuv3: Allow s1 and s2 configs to coexist > iommu/smmuv3: Get prepared for nested stage support > iommu/smmuv3: Implement attach/detach_pasid_table > iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs > iommu/smmuv3: Implement cache_invalidate > dma-iommu: Implement NESTED_MSI cookie > iommu/smmuv3: Nested mode single MSI doorbell per domain enforcement > iommu/smmuv3: Enforce incompatibility between nested mode and HW MSI > regions > iommu/smmuv3: Implement bind/unbind_guest_msi > iommu/smmuv3: report additional recoverable faults > iommu/smmuv3: Accept configs with more than one context descriptor > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 444 ++-- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 +- > drivers/iommu/dma-iommu.c | 142 ++- > drivers/iommu/iommu.c | 106 + > include/linux/dma-iommu.h | 16 + > include/linux/iommu.h | 47 +++ > include/uapi/linux/iommu.h | 54 +++ > 7 files changed, 781 insertions(+), 42 deletions(-) > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] Revert "iommu/iova: Retry from last rb tree node if iova search fails"
On 29/01/2021 12:03, Robin Murphy wrote: On 2021-01-29 09:48, Leizhen (ThunderTown) wrote: Currently, we are thinking about the solution to the problem. However, because the end time of v5.11 is approaching, this patch is sent first. However, that commit was made for a reason - how do we justify that one thing being slow is more important than another thing being completely broken? It's not practical to just keep doing the patch hokey-cokey based on whoever shouts loudest :( On 2021/1/29 17:21, Zhen Lei wrote: This reverts commit 4e89dce725213d3d0b0475211b500eda4ef4bf2f. We find that this patch has a great impact on performance. According to our test: the iops decreases from 1655.6K to 893.5K, about half. Hardware: 1 SAS expander with 12 SAS SSD Command: Only the main parameters are listed. fio bs=4k rw=read iodepth=128 cpus_allowed=0-127 FWIW, I'm 99% sure that what you really want is [1], but then you get to battle against an unknown quantity of dodgy firmware instead. Something which has not been said before is that this only happens for strict mode. Anyway, we see ~50% throughput regression, which is intolerable. As seen in [0], I put this down to the fact that we have so many IOVA requests which exceed the rcache size limit, which means many RB tree accesses for non-cacheble IOVAs, which are now slower. On another point, as for longterm IOVA aging issue, it seems that there is no conclusion there. However I did mention the issue of IOVA sizes exceeding rcache size for that issue, so maybe we can find a common solution. Similar to a fixed rcache depot size, it seems that having a fixed rcache max size range value (at 6) doesn't scale either. As for 4e89dce72521, so even if it's proper to retry for a failed alloc, it is not always necessary. I mean, if we're limiting ourselves to 32b subspace for this SAC trick and we fail the alloc, then we can try the space above 32b first (if usable). If that fails, then retry there. I don't see a need to retry the 32b subspace if we're not limited to it. How about it? We tried that idea and it looks to just about restore performance. Thanks, John [0] https://raw.githubusercontent.com/hisilicon/kernel-dev/topic-iommu-5.10-iova-debug-v3/aging_test ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: next/master bisection: baseline.login on r8a77960-ulcb
Hi all, Am Do., 25. Feb. 2021 um 12:50 Uhr schrieb Thierry Reding : > > On Thu, Feb 25, 2021 at 11:14:57AM +, Robin Murphy wrote: > > On 2021-02-25 11:09, Thierry Reding wrote: > > > On Wed, Feb 24, 2021 at 10:39:42PM +0100, Heiko Thiery wrote: > > > > Hi Christoph and all, > > > > > > > > On 23.02.21 10:56, Guillaume Tucker wrote: > > > > > Hi Christoph, > > > > > > > > > > Please see the bisection report below about a boot failure on > > > > > r8a77960-ulcb on next-20210222. > > > > > > > > > > Reports aren't automatically sent to the public while we're > > > > > trialing new bisection features on kernelci.org but this one > > > > > looks valid. > > > > > > > > > > The log shows a kernel panic, more details can be found here: > > > > > > > > > > https://kernelci.org/test/case/id/6034bde034504edc9faddd2c/ > > > > > > > > > > Please let us know if you need any help to debug the issue or try > > > > > a fix on this platform. > > > > > > > > I am also seeing this problem on an iMX8MQ board and can help test if > > > > you > > > > have a fix. > > > > > > This is also causing boot failures on Jetson AGX Xavier. The origin is > > > slightly different from the above kernelci.org report, but the BUG_ON is > > > the same: > > > > > > [2.650447] [ cut here ] > > > [2.650588] kernel BUG at include/linux/iommu-helper.h:23! > > > [2.650729] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > > > [2.654330] Modules linked in: > > > [2.657474] CPU: 2 PID: 67 Comm: kworker/2:1 Not tainted > > > 5.11.0-next-20210225-00025-gfd15609b3a81-dirty #120 > > > [2.667367] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit > > > (DT) > > > [2.674096] Workqueue: events deferred_probe_work_func > > > [2.679169] pstate: 40400089 (nZcv daIf +PAN -UAO -TCO BTYPE=--) > > > [2.684949] pc : find_slots.isra.0+0x118/0x2f0 > > > [2.689494] lr : find_slots.isra.0+0x88/0x2f0 > > > [2.693696] sp : 800011faf950 > > > [2.697281] x29: 800011faf950 x28: 0001 > > > [2.702537] x27: 0001 x26: > > > [2.708131] x25: 0001 x24: 000105f03148 > > > [2.713556] x23: 0001 x22: 800011559000 > > > [2.718835] x21: 800011559a80 x20: edc0 > > > [2.724493] x19: x18: 0020 > > > [2.729770] x17: 0003ffd7d160 x16: 0068 > > > [2.735173] x15: 80b43150 x14: > > > [2.740944] x13: 82b5d791 x12: 0040 > > > [2.746113] x11: a248 x10: > > > [2.751882] x9 : x8 : 0003fed3 > > > [2.757139] x7 : x6 : > > > [2.762818] x5 : x4 : > > > [2.767984] x3 : 0001e8303148 x2 : 8000 > > > [2.773580] x1 : x0 : 001db800 > > > [2.778662] Call trace: > > > [2.781136] find_slots.isra.0+0x118/0x2f0 > > > [2.785137] swiotlb_tbl_map_single+0x80/0x1b4 > > > [2.789858] swiotlb_map+0x58/0x200 > > > [2.793355] dma_direct_map_page+0x148/0x1c0 > > > [2.797386] dma_map_page_attrs+0x2c/0x54 > > > [2.801411] dw_pcie_host_init+0x40c/0x4c0 > > > [2.805633] tegra_pcie_config_rp+0x7c/0x1f4 > > > [2.810155] tegra_pcie_dw_probe+0x3d0/0x60c > > > [2.814185] platform_probe+0x68/0xe0 > > > [2.817688] really_probe+0xe4/0x4c0 > > > [2.821362] driver_probe_device+0x58/0xc0 > > > [2.825386] __device_attach_driver+0xa8/0x104 > > > [2.829953] bus_for_each_drv+0x78/0xd0 > > > [2.833434] __device_attach+0xdc/0x17c > > > [2.837631] device_initial_probe+0x14/0x20 > > > [2.841680] bus_probe_device+0x9c/0xa4 > > > [2.845160] deferred_probe_work_func+0x74/0xb0 > > > [2.849734] process_one_work+0x1cc/0x350 > > > [2.853
Re: next/master bisection: baseline.login on r8a77960-ulcb
On Thu, Feb 25, 2021 at 11:14:57AM +, Robin Murphy wrote: > On 2021-02-25 11:09, Thierry Reding wrote: > > On Wed, Feb 24, 2021 at 10:39:42PM +0100, Heiko Thiery wrote: > > > Hi Christoph and all, > > > > > > On 23.02.21 10:56, Guillaume Tucker wrote: > > > > Hi Christoph, > > > > > > > > Please see the bisection report below about a boot failure on > > > > r8a77960-ulcb on next-20210222. > > > > > > > > Reports aren't automatically sent to the public while we're > > > > trialing new bisection features on kernelci.org but this one > > > > looks valid. > > > > > > > > The log shows a kernel panic, more details can be found here: > > > > > > > > https://kernelci.org/test/case/id/6034bde034504edc9faddd2c/ > > > > > > > > Please let us know if you need any help to debug the issue or try > > > > a fix on this platform. > > > > > > I am also seeing this problem on an iMX8MQ board and can help test if you > > > have a fix. > > > > This is also causing boot failures on Jetson AGX Xavier. The origin is > > slightly different from the above kernelci.org report, but the BUG_ON is > > the same: > > > > [2.650447] [ cut here ]---- > > [2.650588] kernel BUG at include/linux/iommu-helper.h:23! > > [2.650729] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > > [2.654330] Modules linked in: > > [2.657474] CPU: 2 PID: 67 Comm: kworker/2:1 Not tainted > > 5.11.0-next-20210225-00025-gfd15609b3a81-dirty #120 > > [2.667367] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit > > (DT) > > [2.674096] Workqueue: events deferred_probe_work_func > > [2.679169] pstate: 40400089 (nZcv daIf +PAN -UAO -TCO BTYPE=--) > > [2.684949] pc : find_slots.isra.0+0x118/0x2f0 > > [2.689494] lr : find_slots.isra.0+0x88/0x2f0 > > [2.693696] sp : 800011faf950 > > [2.697281] x29: 800011faf950 x28: 0001 > > [2.702537] x27: 0001 x26: > > [2.708131] x25: 0001 x24: 000105f03148 > > [2.713556] x23: 0001 x22: 800011559000 > > [2.718835] x21: 800011559a80 x20: edc0 > > [2.724493] x19: x18: 0020 > > [2.729770] x17: 0003ffd7d160 x16: 0068 > > [2.735173] x15: 80b43150 x14: > > [2.740944] x13: 82b5d791 x12: 0040 > > [2.746113] x11: a248 x10: > > [2.751882] x9 : x8 : 0003fed3 > > [2.757139] x7 : x6 : > > [2.762818] x5 : x4 : > > [2.767984] x3 : 0001e8303148 x2 : 8000 > > [2.773580] x1 : x0 : 001db800 > > [2.778662] Call trace: > > [2.781136] find_slots.isra.0+0x118/0x2f0 > > [2.785137] swiotlb_tbl_map_single+0x80/0x1b4 > > [2.789858] swiotlb_map+0x58/0x200 > > [2.793355] dma_direct_map_page+0x148/0x1c0 > > [2.797386] dma_map_page_attrs+0x2c/0x54 > > [2.801411] dw_pcie_host_init+0x40c/0x4c0 > > [2.805633] tegra_pcie_config_rp+0x7c/0x1f4 > > [2.810155] tegra_pcie_dw_probe+0x3d0/0x60c > > [2.814185] platform_probe+0x68/0xe0 > > [2.817688] really_probe+0xe4/0x4c0 > > [2.821362] driver_probe_device+0x58/0xc0 > > [2.825386] __device_attach_driver+0xa8/0x104 > > [2.829953] bus_for_each_drv+0x78/0xd0 > > [2.833434] __device_attach+0xdc/0x17c > > [2.837631] device_initial_probe+0x14/0x20 > > [2.841680] bus_probe_device+0x9c/0xa4 > > [2.845160] deferred_probe_work_func+0x74/0xb0 > > [2.849734] process_one_work+0x1cc/0x350 > > [2.853822] worker_thread+0x20c/0x3ac > > [2.858018] kthread+0x128/0x134 > > [2.860997] ret_from_fork+0x10/0x34 > > [2.864508] Code: ca180063 ea06007f 54fffee1 b50001e7 (d421) > > [2.870547] ---[ end trace e5c50bdcf12b316e ]--- > > [2.875087] note: kworker/2:1[67] exited with preempt_count 2 > > [2.880836] [ cut here ] > > > > I've confirmed that
Re: next/master bisection: baseline.login on r8a77960-ulcb
On 2021-02-25 11:09, Thierry Reding wrote:
On Wed, Feb 24, 2021 at 10:39:42PM +0100, Heiko Thiery wrote:
Hi Christoph and all,
On 23.02.21 10:56, Guillaume Tucker wrote:
Hi Christoph,
Please see the bisection report below about a boot failure on
r8a77960-ulcb on next-20210222.
Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org but this one
looks valid.
The log shows a kernel panic, more details can be found here:
https://kernelci.org/test/case/id/6034bde034504edc9faddd2c/
Please let us know if you need any help to debug the issue or try
a fix on this platform.
I am also seeing this problem on an iMX8MQ board and can help test if you
have a fix.
This is also causing boot failures on Jetson AGX Xavier. The origin is
slightly different from the above kernelci.org report, but the BUG_ON is
the same:
[2.650447] [ cut here ]
[2.650588] kernel BUG at include/linux/iommu-helper.h:23!
[2.650729] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[2.654330] Modules linked in:
[2.657474] CPU: 2 PID: 67 Comm: kworker/2:1 Not tainted
5.11.0-next-20210225-00025-gfd15609b3a81-dirty #120
[2.667367] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
[2.674096] Workqueue: events deferred_probe_work_func
[2.679169] pstate: 40400089 (nZcv daIf +PAN -UAO -TCO BTYPE=--)
[2.684949] pc : find_slots.isra.0+0x118/0x2f0
[2.689494] lr : find_slots.isra.0+0x88/0x2f0
[2.693696] sp : 800011faf950
[2.697281] x29: 800011faf950 x28: 0001
[2.702537] x27: 0001 x26:
[2.708131] x25: 0001 x24: 000105f03148
[2.713556] x23: 0001 x22: 800011559000
[2.718835] x21: 800011559a80 x20: edc0
[2.724493] x19: x18: 0020
[2.729770] x17: 0003ffd7d160 x16: 0068
[2.735173] x15: 80b43150 x14:
[2.740944] x13: 82b5d791 x12: 0040
[2.746113] x11: a248 x10:
[2.751882] x9 : x8 : 0003fed3
[2.757139] x7 : x6 :
[2.762818] x5 : x4 :
[2.767984] x3 : 0001e8303148 x2 : 8000
[2.773580] x1 : x0 : 001db800
[2.778662] Call trace:
[2.781136] find_slots.isra.0+0x118/0x2f0
[2.785137] swiotlb_tbl_map_single+0x80/0x1b4
[2.789858] swiotlb_map+0x58/0x200
[2.793355] dma_direct_map_page+0x148/0x1c0
[2.797386] dma_map_page_attrs+0x2c/0x54
[2.801411] dw_pcie_host_init+0x40c/0x4c0
[2.805633] tegra_pcie_config_rp+0x7c/0x1f4
[2.810155] tegra_pcie_dw_probe+0x3d0/0x60c
[2.814185] platform_probe+0x68/0xe0
[2.817688] really_probe+0xe4/0x4c0
[2.821362] driver_probe_device+0x58/0xc0
[2.825386] __device_attach_driver+0xa8/0x104
[2.829953] bus_for_each_drv+0x78/0xd0
[2.833434] __device_attach+0xdc/0x17c
[2.837631] device_initial_probe+0x14/0x20
[2.841680] bus_probe_device+0x9c/0xa4
[2.845160] deferred_probe_work_func+0x74/0xb0
[2.849734] process_one_work+0x1cc/0x350
[2.853822] worker_thread+0x20c/0x3ac
[2.858018] kthread+0x128/0x134
[2.860997] ret_from_fork+0x10/0x34
[2.864508] Code: ca180063 ea06007f 54fffee1 b50001e7 (d421)
[2.870547] ---[ end trace e5c50bdcf12b316e ]---
[2.875087] note: kworker/2:1[67] exited with preempt_count 2
[2.880836] [ cut here ]
I've confirmed that reverting the following commits makes the system
boot again:
47cfc5be1934 ("swiotlb: Validate bounce size in the sync/unmap path")
c6f50c7719e7 ("swiotlb: respect min_align_mask")
e952d9a1bc20 ("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single")
567d877f9a7d ("swiotlb: refactor swiotlb_tbl_map_single")
Let me know if I can help test any fixes for this.
FWIW, this sounds like it's probably the same thing for which a fix
should be pending:
https://lore.kernel.org/linux-iommu/20210223072514.ga18...@lst.de/T/#u
Robin.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: next/master bisection: baseline.login on r8a77960-ulcb
On Wed, Feb 24, 2021 at 10:39:42PM +0100, Heiko Thiery wrote:
> Hi Christoph and all,
>
> On 23.02.21 10:56, Guillaume Tucker wrote:
> > Hi Christoph,
> >
> > Please see the bisection report below about a boot failure on
> > r8a77960-ulcb on next-20210222.
> >
> > Reports aren't automatically sent to the public while we're
> > trialing new bisection features on kernelci.org but this one
> > looks valid.
> >
> > The log shows a kernel panic, more details can be found here:
> >
> >https://kernelci.org/test/case/id/6034bde034504edc9faddd2c/
> >
> > Please let us know if you need any help to debug the issue or try
> > a fix on this platform.
>
> I am also seeing this problem on an iMX8MQ board and can help test if you
> have a fix.
This is also causing boot failures on Jetson AGX Xavier. The origin is
slightly different from the above kernelci.org report, but the BUG_ON is
the same:
[2.650447] [ cut here ]
[2.650588] kernel BUG at include/linux/iommu-helper.h:23!
[2.650729] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[2.654330] Modules linked in:
[2.657474] CPU: 2 PID: 67 Comm: kworker/2:1 Not tainted
5.11.0-next-20210225-00025-gfd15609b3a81-dirty #120
[2.667367] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
[2.674096] Workqueue: events deferred_probe_work_func
[2.679169] pstate: 40400089 (nZcv daIf +PAN -UAO -TCO BTYPE=--)
[2.684949] pc : find_slots.isra.0+0x118/0x2f0
[2.689494] lr : find_slots.isra.0+0x88/0x2f0
[2.693696] sp : 800011faf950
[2.697281] x29: 800011faf950 x28: 0001
[2.702537] x27: 0001 x26:
[2.708131] x25: 0001 x24: 000105f03148
[2.713556] x23: 0001 x22: 800011559000
[2.718835] x21: 800011559a80 x20: edc0
[2.724493] x19: x18: 0020
[2.729770] x17: 0003ffd7d160 x16: 0068
[2.735173] x15: 80b43150 x14:
[2.740944] x13: 82b5d791 x12: 0040
[2.746113] x11: a248 x10:
[2.751882] x9 : x8 : 0003fed3
[2.757139] x7 : x6 :
[2.762818] x5 : x4 :
[2.767984] x3 : 0001e8303148 x2 : 8000
[2.773580] x1 : x0 : 001db800
[2.778662] Call trace:
[2.781136] find_slots.isra.0+0x118/0x2f0
[2.785137] swiotlb_tbl_map_single+0x80/0x1b4
[2.789858] swiotlb_map+0x58/0x200
[2.793355] dma_direct_map_page+0x148/0x1c0
[2.797386] dma_map_page_attrs+0x2c/0x54
[2.801411] dw_pcie_host_init+0x40c/0x4c0
[2.805633] tegra_pcie_config_rp+0x7c/0x1f4
[2.810155] tegra_pcie_dw_probe+0x3d0/0x60c
[2.814185] platform_probe+0x68/0xe0
[2.817688] really_probe+0xe4/0x4c0
[2.821362] driver_probe_device+0x58/0xc0
[2.825386] __device_attach_driver+0xa8/0x104
[2.829953] bus_for_each_drv+0x78/0xd0
[2.833434] __device_attach+0xdc/0x17c
[2.837631] device_initial_probe+0x14/0x20
[2.841680] bus_probe_device+0x9c/0xa4
[2.845160] deferred_probe_work_func+0x74/0xb0
[2.849734] process_one_work+0x1cc/0x350
[2.853822] worker_thread+0x20c/0x3ac
[2.858018] kthread+0x128/0x134
[2.860997] ret_from_fork+0x10/0x34
[2.864508] Code: ca180063 ea06007f 54fffee1 b50001e7 (d421)
[2.870547] ---[ end trace e5c50bdcf12b316e ]---
[2.875087] note: kworker/2:1[67] exited with preempt_count 2
[2.880836] [ cut here ]
I've confirmed that reverting the following commits makes the system
boot again:
47cfc5be1934 ("swiotlb: Validate bounce size in the sync/unmap path")
c6f50c7719e7 ("swiotlb: respect min_align_mask")
e952d9a1bc20 ("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single")
567d877f9a7d ("swiotlb: refactor swiotlb_tbl_map_single")
Let me know if I can help test any fixes for this.
Thierry
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/2] iommu/arm-smmu-qcom: Move the adreno smmu specific impl earlier
Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
both implement "arm,mmu-500" in some QTI SoCs and to run through
adreno smmu specific implementation such as enabling split pagetables
support, we need to match the "qcom,adreno-smmu" compatible first
before apss smmu or else we will be running apps smmu implementation
for adreno smmu and the additional features for adreno smmu is never
set. For ex: we have "qcom,sc7280-smmu-500" compatible for both apps
and adreno smmu implementing "arm,mmu-500", so the adreno smmu
implementation is never reached because the current sequence checks
for apps smmu compatible(qcom,sc7280-smmu-500) first and runs that
specific impl and we never reach adreno smmu specific implementation.
Suggested-by: Akhil P Oommen
Signed-off-by: Sai Prakash Ranjan
---
Its either this or we add a new compatible for adreno smmu implementing
arm,mmu-500 like "qcom,sc7280-adreno-smmu-500".
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index bea3ee0dabc2..7d0fc2c8e72f 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -345,11 +345,11 @@ struct arm_smmu_device *qcom_smmu_impl_init(struct
arm_smmu_device *smmu)
{
const struct device_node *np = smmu->dev->of_node;
- if (of_match_node(qcom_smmu_impl_of_match, np))
- return qcom_smmu_create(smmu, &qcom_smmu_impl);
-
if (of_device_is_compatible(np, "qcom,adreno-smmu"))
return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl);
+ if (of_match_node(qcom_smmu_impl_of_match, np))
+ return qcom_smmu_create(smmu, &qcom_smmu_impl);
+
return smmu;
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/2] iommu/arm-smmu-qcom: Add SC7280 SMMU compatible
Add compatible for SC7280 SMMU to use the Qualcomm Technologies, Inc.
specific implementation.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 98b3a1c2a181..bea3ee0dabc2 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -166,6 +166,7 @@ static const struct of_device_id
qcom_smmu_client_of_match[] __maybe_unused = {
{ .compatible = "qcom,mdss" },
{ .compatible = "qcom,sc7180-mdss" },
{ .compatible = "qcom,sc7180-mss-pil" },
+ { .compatible = "qcom,sc7280-mdss" },
{ .compatible = "qcom,sc8180x-mdss" },
{ .compatible = "qcom,sdm845-mdss" },
{ .compatible = "qcom,sdm845-mss-pil" },
@@ -330,6 +331,7 @@ static struct arm_smmu_device *qcom_smmu_create(struct
arm_smmu_device *smmu,
static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
{ .compatible = "qcom,msm8998-smmu-v2" },
{ .compatible = "qcom,sc7180-smmu-500" },
+ { .compatible = "qcom,sc7280-smmu-500" },
{ .compatible = "qcom,sc8180x-smmu-500" },
{ .compatible = "qcom,sdm630-smmu-v2" },
{ .compatible = "qcom,sdm845-smmu-500" },
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 0/2] iommu/arm-smmu-qcom: Add SC7280 support
Patch 1 adds the sc7280 smmu compatible. Patch 2 moves the adreno smmu check before apss smmu to enable adreno smmu specific implementation. Sai Prakash Ranjan (2): iommu/arm-smmu-qcom: Add SC7280 SMMU compatible iommu/arm-smmu-qcom: Move the adreno smmu specific impl earlier drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) base-commit: 7060377ce06f9cd3ed6274c0f2310463feb5baec -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
