From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 3/6] iommu/arm-smmu: add support for iova_to_phys through ATS1PR
Date: Tue, 26 Aug 2014 14:54:51 +0100 [thread overview]
Message-ID: <20140826135451.GQ23445@arm.com> (raw)
In-Reply-To: <vnkwa970qrfq.fsf@mitchelh-linux.qualcomm.com>
Hi Mitch,
On Tue, Aug 19, 2014 at 07:12:41PM +0100, Mitchel Humpherys wrote:
> On Tue, Aug 19 2014 at 05:44:32 AM, Will Deacon <will.deacon@arm•com> wrote:
> > We don't have writeq for arch/arm/.
>
> Ah yes looks like this is an MSM-ism that never made it upstream since
> it wouldn't be guaranteed to be atomic. I'll make sure to do arm32
> compiles on upstream kernels for future patches, sorry!
>
> I guess we could use <asm-generic/io-64-nonatomic-lo-hi.h> but I can
> also re-work this to be two separate writel's.
Yeah, just do two writels.
> >> + }
> >> +
> >> + mb();
> >
> > Why?
>
> My thought was that if we start polling ATSR_ACTIVE prematurely (before
> the write to ATS1PR actually finishes) all heck could break loose? Not
> sure if that's a bogus assumption due to device memory being strongly
> ordered?
I think the device-memory guarantees should be enough. If not, we need a
comment explaining why.
> >> + while (readl_relaxed(cb_base + ARM_SMMU_CB_ATSR) & ATSR_ACTIVE) {
> >> + if (++count == ATSR_LOOP_TIMEOUT) {
> >> + dev_err(dev,
> >> + "iova to phys timed out on 0x%pa for %s. Falling back to software table walk.\n",
> >> + &iova, dev_name(dev));
> >> + arm_smmu_disable_clocks(smmu);
> >> + return arm_smmu_iova_to_phys_soft(domain, iova);
> >> + }
> >> + cpu_relax();
> >> + }
> >
> > Do you know what happened to Olav's patches to make this sort of code
> > generic?
>
> I assume you're talking about this, right?
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267943.html
>
> Yeah looks like he never sent an update since it was part of a series
> that wasn't going to make it in (the qsmmu driver). I can always bring
> that patch (actually Matt Wagantall's patch) in here and rework this to
> use that.
Yup, I think it would be useful to revive that as a separate series.
> >
> >> @@ -2005,6 +2073,11 @@ int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
> >> return -ENODEV;
> >> }
> >>
> >> + if (smmu->version == 1 || (!(id & ID0_ATOSNS) && (id & ID0_S1TS))) {
> >
> > Are you sure about this? The v2 spec says that is ATOSNS is clear then S1TS
> > is also clear.
>
> I was looking at Section 4.1.1 of ARM IHI 0062C ID091613 which states:
>
> In SMMUv2, the address translation registers are OPTIONAL. The
> address translation registers are implemented only when both:
>
> o The SMMU_IDR0.S1TS bit is set to 1.
> o The SMMU_IDR0.ATOSNS bit is set to 0.
>
> I assume you're referring to section 9.6.1 of the same document:
>
> ATOSNS, bit[26]
> Address Translation Operations Not Supported. The possible values of
> this bit are:
>
> 0 Address translation operations are supported. Stage 1
> translation is not supported, that is, the S1TS bit is set to 0.
>
> 1 Address translation operations are not supported. Stage 1
> translation is supported, that is, the S1TS bit is set to 1.
>
> If that really means that S1TS and ATOSNS always have the same value
> then Section 4.1.1 doesn't make any sense. Or am I missing something?
I'll get this checked, as those two paragraphs don't make an awful lot of
sense together.
Will
next prev parent reply other threads:[~2014-08-26 13:54 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 0:51 [PATCH 0/6] iommu/arm-smmu: misc features, new DT bindings Mitchel Humpherys
2014-08-13 0:51 ` [PATCH 1/6] iommu/arm-smmu: add support for specifying clocks Mitchel Humpherys
2014-08-13 21:07 ` Mitchel Humpherys
2014-08-19 12:58 ` Will Deacon
2014-08-19 19:03 ` Olav Haugan
2014-08-26 14:27 ` Will Deacon
2014-09-10 1:29 ` Mitchel Humpherys
2014-09-10 18:27 ` Will Deacon
2014-09-10 19:09 ` Mitchel Humpherys
2014-09-15 18:38 ` Mitchel Humpherys
2014-08-19 19:28 ` Mitchel Humpherys
2014-08-13 0:51 ` [PATCH 2/6] iommu/arm-smmu: add support for specifying regulators Mitchel Humpherys
2014-08-13 21:17 ` Mitchel Humpherys
2014-08-19 13:00 ` Will Deacon
2014-08-13 0:51 ` [PATCH 3/6] iommu/arm-smmu: add support for iova_to_phys through ATS1PR Mitchel Humpherys
2014-08-19 12:44 ` Will Deacon
2014-08-19 18:12 ` Mitchel Humpherys
2014-08-26 13:54 ` Will Deacon [this message]
2014-09-01 16:15 ` Will Deacon
2014-08-13 0:51 ` [PATCH 4/6] iommu/arm-smmu: implement generic DT bindings Mitchel Humpherys
2014-08-13 16:53 ` Mitchel Humpherys
2014-08-19 12:54 ` Will Deacon
2014-08-19 15:54 ` Hiroshi Doyu
2014-08-20 3:18 ` Arnd Bergmann
2014-08-13 0:51 ` [PATCH 5/6] iommu/arm-smmu: support buggy implementations with invalidate-on-map Mitchel Humpherys
2014-11-12 18:26 ` Will Deacon
2014-11-12 18:58 ` Mitchel Humpherys
2014-11-13 9:48 ` Will Deacon
2014-11-14 23:08 ` Mitchel Humpherys
2014-08-13 0:51 ` [PATCH 6/6] iommu/arm-smmu: add .domain_{set, get}_attr for coherent walk control Mitchel Humpherys
2014-08-19 12:48 ` [PATCH 6/6] iommu/arm-smmu: add .domain_{set,get}_attr " Will Deacon
2014-08-19 19:19 ` [PATCH 6/6] iommu/arm-smmu: add .domain_{set, get}_attr " Mitchel Humpherys
2014-08-13 17:22 ` [PATCH 0/6] iommu/arm-smmu: misc features, new DT bindings Mitchel Humpherys
2014-08-15 17:25 ` Will Deacon
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=20140826135451.GQ23445@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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