From: Will Deacon <will@kernel.org>
To: Vivek Gautam <vivek.gautam@codeaurora.org>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Will Deacon <will.deacon@arm.com>,
open list <linux-kernel@vger.kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
David Brown <david.brown@linaro.org>,
"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
" <iommu@lists.linux-foundation.org>,
robh+dt <robh+dt@kernel.org>, Andy Gross <agross@kernel.org>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v3 3/4] iommu/arm-smmu: Add support to handle Qcom's wait-for-safe logic
Date: Mon, 24 Jun 2019 18:03:49 +0100 [thread overview]
Message-ID: <20190624170348.7dncuc5qezqeyvq2@willie-the-truck> (raw)
In-Reply-To: <CAFp+6iEynLa=Jt_-oAwt4zmzxzhEXtWNCmghz6rFzcpQVGwrMg@mail.gmail.com>
[+Krishna]
Hi Vivek,
On Mon, Jun 24, 2019 at 03:58:32PM +0530, Vivek Gautam wrote:
> On Tue, Jun 18, 2019 at 11:22 PM Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Jun 14, 2019 at 02:48:07PM +0530, Vivek Gautam wrote:
> > > On 6/14/2019 9:35 AM, Bjorn Andersson wrote:
> > > > On Wed 12 Jun 00:15 PDT 2019, Vivek Gautam wrote:
> > > > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > > > > index 0ad086da399c..3c3ad43eda97 100644
> > > > > --- a/drivers/iommu/arm-smmu.c
> > > > > +++ b/drivers/iommu/arm-smmu.c
> > > > > @@ -39,6 +39,7 @@
> > > > > #include <linux/pci.h>
> > > > > #include <linux/platform_device.h>
> > > > > #include <linux/pm_runtime.h>
> > > > > +#include <linux/qcom_scm.h>
> > > > > #include <linux/slab.h>
> > > > > #include <linux/spinlock.h>
> > > > > @@ -177,6 +178,7 @@ struct arm_smmu_device {
> > > > > u32 features;
> > > > > #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
> > > > > +#define ARM_SMMU_OPT_QCOM_FW_IMPL_SAFE_ERRATA (1 << 1)
> > > > > u32 options;
> > > > > enum arm_smmu_arch_version version;
> > > > > enum arm_smmu_implementation model;
> > > > > @@ -262,6 +264,7 @@ static bool using_legacy_binding, using_generic_binding;
> > > > > static struct arm_smmu_option_prop arm_smmu_options[] = {
> > > > > { ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
> > > > > + { ARM_SMMU_OPT_QCOM_FW_IMPL_SAFE_ERRATA, "qcom,smmu-500-fw-impl-safe-errata" },
> > > > This should be added to the DT binding as well.
> > >
> > > Ah right. I missed that. Will add this and respin unless Robin and Will have
> > > concerns with this change.
> >
> > My only concern really is whether it's safe for us to turn this off. It's
> > clear that somebody went to a lot of effort to add this extra goodness to
> > the IP, but your benchmarks suggest they never actually tried it out after
> > they finished building it.
> >
> > Is there some downside I'm not seeing from disabling this stuff?
>
> This wait-for-safe is a TLB invalidation enhancement to help display
> and camera devices.
> The SMMU hardware throttles the invalidations so that clients such as
> display and camera can indicate when to start the invalidation.
> So the SMMU essentially reduces the rate at which invalidations are
> serviced from its queue. This also throttles the invalidations from
> other masters too.
>
> On sdm845, the software is expected to serialize the invalidation
> command loading into SMMU invalidation FIFO using hardware locks
> (downstream code [2]), and is also expected to throttle non-real time
> clients while waiting for SAFE==1 (downstream code[2]). We don't do
> any of these yet, and as per my understanding as this wait-for-safe is
> enabled by the bootloader in a one time config, this logic reduces
> performance of devices such as usb and ufs.
>
> There's isn't any downside from disabling this logic until we have all
> the pieces together from downstream in upstream kernels, and until we
> have sdm845 devices that are running with full display/gfx stack
> running. That's when we plan to revisit this and enable all the pieces
> to get display and USB/UFS working with their optimum performance.
Generally, I'd agree that approaching this incrementally makes sense, but
in this case you're adding new device-tree properties
("qcom,smmu-500-fw-impl-safe-errata") in order to do so, which seems
questionable if they're only going to be used in the short-term and will
be obsolete once Linux knows how to drive the device properly.
Instead, I think this needs to be part of a separate file that is maintained
by you, which follows on from the work that Krishna is doing for nvidia
built on top of Robin's prototype patches:
http://linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/smmu-impl
Once we have that, you can key this behaviour off the compatible string
rather than having to add quirk properties to reflect the transient needs of
Linux.
Krishna -- how have you been getting on with the branch above?
Will
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-06-24 17:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 7:15 [PATCH v3 0/4] Qcom smmu-500 wait-for-safe handling for sdm845 Vivek Gautam
2019-06-12 7:15 ` [PATCH v3 1/4] firmware: qcom_scm-64: Add atomic version of qcom_scm_call Vivek Gautam
2019-06-18 17:55 ` Will Deacon
2019-06-19 11:34 ` Vivek Gautam
2019-08-05 22:27 ` Bjorn Andersson
2019-08-08 11:35 ` Vivek Gautam
2019-08-08 16:30 ` Will Deacon
2019-06-12 7:15 ` [PATCH v3 2/4] firmware/qcom_scm: Add scm call to handle smmu errata Vivek Gautam
2019-06-12 7:15 ` [PATCH v3 3/4] iommu/arm-smmu: Add support to handle Qcom's wait-for-safe logic Vivek Gautam
2019-06-14 4:05 ` Bjorn Andersson
2019-06-14 9:18 ` Vivek Gautam
2019-06-18 17:52 ` Will Deacon
2019-06-24 10:28 ` Vivek Gautam
2019-06-24 17:03 ` Will Deacon [this message]
2019-06-25 7:04 ` Vivek Gautam
2019-06-25 13:39 ` Will Deacon
2019-06-26 6:33 ` Vivek Gautam
2019-06-26 14:48 ` Will Deacon
2019-06-27 7:05 ` Vivek Gautam
2019-06-12 7:15 ` [PATCH v3 4/4] arm64: dts/sdm845: Enable FW implemented safe sequence handler on MTP Vivek Gautam
2019-06-14 4:06 ` Bjorn Andersson
2019-06-14 9:01 ` Vivek Gautam
2019-08-05 22:26 ` Bjorn Andersson
2019-08-11 16:08 ` Vivek Gautam
2019-08-11 19:01 ` Bjorn Andersson
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=20190624170348.7dncuc5qezqeyvq2@willie-the-truck \
--to=will@kernel.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=david.brown@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=vivek.gautam@codeaurora.org \
--cc=will.deacon@arm.com \
/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).