From: Robin Murphy <robin.murphy@arm.com> To: Vladimir Oltean <vladimir.oltean@nxp.com> Cc: devicetree@vger.kernel.org, iommu@lists.linux.dev, Laurentiu Tudor <laurentiu.tudor@nxp.com>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org, Shawn Guo <shawnguo@kernel.org>, Li Yang <leoyang.li@nxp.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, linux-kernel@vger.kernel.org, Michael Walle <michael@walle.cc> Subject: Re: [RFC PATCH] arm64: dts: ls1028a: mark ARM SMMU as DMA coherent Date: Tue, 3 Jan 2023 18:12:29 +0000 [thread overview] Message-ID: <67ae3a53-3db9-c1bc-2b67-08df14bc15cc@arm.com> (raw) In-Reply-To: <20221219121618.z3dcyob542cnmdnk@skbuf> On 19/12/2022 12:16 pm, Vladimir Oltean wrote: > Hi Robin, > > On Wed, Dec 14, 2022 at 08:33:10PM +0000, Robin Murphy wrote: >>> Does looking at the CTTW bit make any sense for MMU-500? >> >> In general, yes. The result above does imply that NXP have inadvertently set >> cfg_cttw wrong. For the avoidance of doubt, here's another MMU-500 showing >> SMMU_IDR0.CTTW set: >> >> [ 3.014972] arm-smmu arm-smmu.0.auto: probing hardware configuration... >> [ 3.014974] arm-smmu arm-smmu.0.auto: SMMUv2 with: >> [ 3.014976] arm-smmu arm-smmu.0.auto: stage 2 translation >> [ 3.014977] arm-smmu arm-smmu.0.auto: coherent table walk >> [ 3.014979] arm-smmu arm-smmu.0.auto: stream matching with 128 register groups >> [ 3.014981] arm-smmu arm-smmu.0.auto: 128 context banks (128 stage-2 only) >> [ 3.014984] arm-smmu arm-smmu.0.auto: Supported page sizes: 0x60211000 >> [ 3.014986] arm-smmu arm-smmu.0.auto: Stage-2: 48-bit IPA -> 48-bit PA > > Thanks for the explanations and the patch you've sent separately. > > I have a side question, why is the dev_name() of your SMMU set to > "arm-smmu.0.auto" (determined by PLATFORM_DEVID_AUTO if I'm not mistaken)? This is an ACPI-based machine, where platform device discovery and creation is... different :) SMMUs are among those managed by drivers/acpi/arm64/iort.c > I'm asking because I would like to study the mechanism through which > your SMMU platform device get probed, to make sure that it's not > possible, during shutdown, for both platform_driver :: shutdown() > and platform_driver :: remove() methods to get called by the driver core. > This is generally not disallowed, and even possible if the entity who > registers these platform devices has its ->shutdown() method pointing > at ->remove(). Yikes, I'd very much hope that that's not a thing! Cheers, Robin.
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com> To: Vladimir Oltean <vladimir.oltean@nxp.com> Cc: devicetree@vger.kernel.org, iommu@lists.linux.dev, Laurentiu Tudor <laurentiu.tudor@nxp.com>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org, Shawn Guo <shawnguo@kernel.org>, Li Yang <leoyang.li@nxp.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, linux-kernel@vger.kernel.org, Michael Walle <michael@walle.cc> Subject: Re: [RFC PATCH] arm64: dts: ls1028a: mark ARM SMMU as DMA coherent Date: Tue, 3 Jan 2023 18:12:29 +0000 [thread overview] Message-ID: <67ae3a53-3db9-c1bc-2b67-08df14bc15cc@arm.com> (raw) In-Reply-To: <20221219121618.z3dcyob542cnmdnk@skbuf> On 19/12/2022 12:16 pm, Vladimir Oltean wrote: > Hi Robin, > > On Wed, Dec 14, 2022 at 08:33:10PM +0000, Robin Murphy wrote: >>> Does looking at the CTTW bit make any sense for MMU-500? >> >> In general, yes. The result above does imply that NXP have inadvertently set >> cfg_cttw wrong. For the avoidance of doubt, here's another MMU-500 showing >> SMMU_IDR0.CTTW set: >> >> [ 3.014972] arm-smmu arm-smmu.0.auto: probing hardware configuration... >> [ 3.014974] arm-smmu arm-smmu.0.auto: SMMUv2 with: >> [ 3.014976] arm-smmu arm-smmu.0.auto: stage 2 translation >> [ 3.014977] arm-smmu arm-smmu.0.auto: coherent table walk >> [ 3.014979] arm-smmu arm-smmu.0.auto: stream matching with 128 register groups >> [ 3.014981] arm-smmu arm-smmu.0.auto: 128 context banks (128 stage-2 only) >> [ 3.014984] arm-smmu arm-smmu.0.auto: Supported page sizes: 0x60211000 >> [ 3.014986] arm-smmu arm-smmu.0.auto: Stage-2: 48-bit IPA -> 48-bit PA > > Thanks for the explanations and the patch you've sent separately. > > I have a side question, why is the dev_name() of your SMMU set to > "arm-smmu.0.auto" (determined by PLATFORM_DEVID_AUTO if I'm not mistaken)? This is an ACPI-based machine, where platform device discovery and creation is... different :) SMMUs are among those managed by drivers/acpi/arm64/iort.c > I'm asking because I would like to study the mechanism through which > your SMMU platform device get probed, to make sure that it's not > possible, during shutdown, for both platform_driver :: shutdown() > and platform_driver :: remove() methods to get called by the driver core. > This is generally not disallowed, and even possible if the entity who > registers these platform devices has its ->shutdown() method pointing > at ->remove(). Yikes, I'd very much hope that that's not a thing! Cheers, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-01-03 18:12 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-08 15:15 [RFC PATCH] arm64: dts: ls1028a: mark ARM SMMU as DMA coherent Vladimir Oltean 2022-12-08 15:15 ` Vladimir Oltean 2022-12-08 19:01 ` Robin Murphy 2022-12-08 19:01 ` Robin Murphy 2022-12-14 16:53 ` Vladimir Oltean 2022-12-14 16:53 ` Vladimir Oltean 2022-12-14 20:33 ` Robin Murphy 2022-12-14 20:33 ` Robin Murphy 2022-12-19 12:16 ` Vladimir Oltean 2022-12-19 12:16 ` Vladimir Oltean 2023-01-03 18:12 ` Robin Murphy [this message] 2023-01-03 18:12 ` Robin Murphy 2023-01-05 12:04 ` Vladimir Oltean 2023-01-05 12:04 ` Vladimir Oltean
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=67ae3a53-3db9-c1bc-2b67-08df14bc15cc@arm.com \ --to=robin.murphy@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=iommu@lists.linux.dev \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=laurentiu.tudor@nxp.com \ --cc=leoyang.li@nxp.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=michael@walle.cc \ --cc=robh+dt@kernel.org \ --cc=shawnguo@kernel.org \ --cc=vladimir.oltean@nxp.com \ --cc=will@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.