All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Gautam <vivek.gautam@codeaurora.org>
To: agross@kernel.org, robh+dt@kernel.org, will.deacon@arm.com,
	robin.murphy@arm.com, joro@8bytes.org,
	bjorn.andersson@linaro.org, linux-arm-msm@vger.kernel.org,
	devicetree@vger.kernel.org, iommu@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org, david.brown@linaro.org,
	Vivek Gautam <vivek.gautam@codeaurora.org>
Subject: [PATCH v3 3/4] iommu/arm-smmu: Add support to handle Qcom's wait-for-safe logic
Date: Wed, 12 Jun 2019 12:45:53 +0530	[thread overview]
Message-ID: <20190612071554.13573-4-vivek.gautam@codeaurora.org> (raw)
In-Reply-To: <20190612071554.13573-1-vivek.gautam@codeaurora.org>

Qcom's implementation of arm,mmu-500 adds a WAIT-FOR-SAFE logic
to address under-performance issues in real-time clients, such as
Display, and Camera.
On receiving an invalidation requests, the SMMU forwards SAFE request
to these clients and waits for SAFE ack signal from real-time clients.
The SAFE signal from such clients is used to qualify the start of
invalidation.
This logic is controlled by chicken bits, one for each - MDP (display),
IFE0, and IFE1 (camera), that can be accessed only from secure software
on sdm845.

This configuration, however, degrades the performance of non-real time
clients, such as USB, and UFS etc. This happens because, with wait-for-safe
logic enabled the hardware tries to throttle non-real time clients while
waiting for SAFE ack signals from real-time clients.

On MTP sdm845 devices, with wait-for-safe logic enabled at the boot time
by the bootloaders we see degraded performance of USB and UFS when kernel
enables the smmu stage-1 translations for these clients.
Turn off this wait-for-safe logic from the kernel gets us back the perf
of USB and UFS devices until we re-visit this when we start seeing perf
issues on display/camera on upstream supported SDM845 platforms.

Now, different bootloaders with their access control policies allow this
register access differently through secure monitor calls -
1) With one we can issue io-read/write secure monitor call (qcom-scm)
   to update the register, while,
2) With other, such as one on MTP sdm845 we should use the specific
   qcom-scm command to send request to do the complete register
   configuration.
Adding a separate device tree flag for arm-smmu to identify which
firmware configuration of the two mentioned above we use.
Not adding code change to allow type-(1) bootloaders to toggle the
safe using io-read/write qcom-scm call.

This change is inspired by the downstream change from Patrick Daly
to address performance issues with display and camera by handling
this wait-for-safe within separte io-pagetable ops to do TLB
maintenance. So a big thanks to him for the change.

Without this change the UFS reads are pretty slow:
$ time dd if=/dev/sda of=/dev/zero bs=1048576 count=10 conv=sync
10+0 records in
10+0 records out
10485760 bytes (10.0MB) copied, 22.394903 seconds, 457.2KB/s
real    0m 22.39s
user    0m 0.00s
sys     0m 0.01s

With this change they are back to rock!
$ time dd if=/dev/sda of=/dev/zero bs=1048576 count=300 conv=sync
300+0 records in
300+0 records out
314572800 bytes (300.0MB) copied, 1.030541 seconds, 291.1MB/s
real    0m 1.03s
user    0m 0.00s
sys     0m 0.54s

Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
---
 drivers/iommu/arm-smmu.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

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" },
 	{ 0, NULL},
 };
 
@@ -2292,6 +2295,19 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
 	arm_smmu_device_reset(smmu);
 	arm_smmu_test_smr_masks(smmu);
 
+	/*
+	 * To address performance degradation in non-real time clients,
+	 * such as USB and UFS, turn off wait-for-safe on sdm845 platforms,
+	 * such as MTP, whose firmwares implement corresponding secure monitor
+	 * call handlers.
+	 */
+	if (of_device_is_compatible(smmu->dev->of_node, "qcom,sdm845-smmu-500") &&
+	    smmu->options & ARM_SMMU_OPT_QCOM_FW_IMPL_SAFE_ERRATA) {
+		err = qcom_scm_qsmmu500_wait_safe_toggle(0);
+		if (err)
+			dev_warn(dev, "Failed to turn off SAFE logic\n");
+	}
+
 	/*
 	 * We want to avoid touching dev->power.lock in fastpaths unless
 	 * it's really going to do something useful - pm_runtime_enabled()
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation


WARNING: multiple messages have this Message-ID (diff)
From: Vivek Gautam <vivek.gautam@codeaurora.org>
To: agross@kernel.org, robh+dt@kernel.org, will.deacon@arm.com,
	robin.murphy@arm.com, joro@8bytes.org,
	bjorn.andersson@linaro.org, linux-arm-msm@vger.kernel.org,
	devicetree@vger.kernel.org, iommu@lists.linux-foundation.org
Cc: david.brown@linaro.org, linux-kernel@vger.kernel.org
Subject: [PATCH v3 3/4] iommu/arm-smmu: Add support to handle Qcom's wait-for-safe logic
Date: Wed, 12 Jun 2019 12:45:53 +0530	[thread overview]
Message-ID: <20190612071554.13573-4-vivek.gautam@codeaurora.org> (raw)
In-Reply-To: <20190612071554.13573-1-vivek.gautam@codeaurora.org>

Qcom's implementation of arm,mmu-500 adds a WAIT-FOR-SAFE logic
to address under-performance issues in real-time clients, such as
Display, and Camera.
On receiving an invalidation requests, the SMMU forwards SAFE request
to these clients and waits for SAFE ack signal from real-time clients.
The SAFE signal from such clients is used to qualify the start of
invalidation.
This logic is controlled by chicken bits, one for each - MDP (display),
IFE0, and IFE1 (camera), that can be accessed only from secure software
on sdm845.

This configuration, however, degrades the performance of non-real time
clients, such as USB, and UFS etc. This happens because, with wait-for-safe
logic enabled the hardware tries to throttle non-real time clients while
waiting for SAFE ack signals from real-time clients.

On MTP sdm845 devices, with wait-for-safe logic enabled at the boot time
by the bootloaders we see degraded performance of USB and UFS when kernel
enables the smmu stage-1 translations for these clients.
Turn off this wait-for-safe logic from the kernel gets us back the perf
of USB and UFS devices until we re-visit this when we start seeing perf
issues on display/camera on upstream supported SDM845 platforms.

Now, different bootloaders with their access control policies allow this
register access differently through secure monitor calls -
1) With one we can issue io-read/write secure monitor call (qcom-scm)
   to update the register, while,
2) With other, such as one on MTP sdm845 we should use the specific
   qcom-scm command to send request to do the complete register
   configuration.
Adding a separate device tree flag for arm-smmu to identify which
firmware configuration of the two mentioned above we use.
Not adding code change to allow type-(1) bootloaders to toggle the
safe using io-read/write qcom-scm call.

This change is inspired by the downstream change from Patrick Daly
to address performance issues with display and camera by handling
this wait-for-safe within separte io-pagetable ops to do TLB
maintenance. So a big thanks to him for the change.

Without this change the UFS reads are pretty slow:
$ time dd if=/dev/sda of=/dev/zero bs=1048576 count=10 conv=sync
10+0 records in
10+0 records out
10485760 bytes (10.0MB) copied, 22.394903 seconds, 457.2KB/s
real    0m 22.39s
user    0m 0.00s
sys     0m 0.01s

With this change they are back to rock!
$ time dd if=/dev/sda of=/dev/zero bs=1048576 count=300 conv=sync
300+0 records in
300+0 records out
314572800 bytes (300.0MB) copied, 1.030541 seconds, 291.1MB/s
real    0m 1.03s
user    0m 0.00s
sys     0m 0.54s

Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
---
 drivers/iommu/arm-smmu.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

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" },
 	{ 0, NULL},
 };
 
@@ -2292,6 +2295,19 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
 	arm_smmu_device_reset(smmu);
 	arm_smmu_test_smr_masks(smmu);
 
+	/*
+	 * To address performance degradation in non-real time clients,
+	 * such as USB and UFS, turn off wait-for-safe on sdm845 platforms,
+	 * such as MTP, whose firmwares implement corresponding secure monitor
+	 * call handlers.
+	 */
+	if (of_device_is_compatible(smmu->dev->of_node, "qcom,sdm845-smmu-500") &&
+	    smmu->options & ARM_SMMU_OPT_QCOM_FW_IMPL_SAFE_ERRATA) {
+		err = qcom_scm_qsmmu500_wait_safe_toggle(0);
+		if (err)
+			dev_warn(dev, "Failed to turn off SAFE logic\n");
+	}
+
 	/*
 	 * We want to avoid touching dev->power.lock in fastpaths unless
 	 * it's really going to do something useful - pm_runtime_enabled()
-- 
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

  parent reply	other threads:[~2019-06-12  7:16 UTC|newest]

Thread overview: 73+ 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 ` 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-12  7:15   ` Vivek Gautam
2019-06-18 17:55   ` Will Deacon
2019-06-18 17:55     ` Will Deacon
2019-06-19 11:34     ` Vivek Gautam
2019-06-19 11:34       ` Vivek Gautam
2019-06-19 11:34       ` Vivek Gautam
2019-08-05 22:27       ` Bjorn Andersson
2019-08-05 22:27         ` Bjorn Andersson
2019-08-05 22:27         ` Bjorn Andersson
2019-08-08 11:35         ` Vivek Gautam
2019-08-08 11:35           ` Vivek Gautam
2019-08-08 11:35           ` Vivek Gautam
2019-08-08 16:30           ` Will Deacon
2019-08-08 16:30             ` Will Deacon
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   ` Vivek Gautam
2019-06-12  7:15 ` Vivek Gautam [this message]
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  4:05     ` Bjorn Andersson
2019-06-14  4:05     ` Bjorn Andersson
2019-06-14  9:18     ` Vivek Gautam
2019-06-14  9:18       ` Vivek Gautam
2019-06-18 17:52       ` Will Deacon
2019-06-18 17:52         ` Will Deacon
2019-06-24 10:28         ` Vivek Gautam
2019-06-24 10:28           ` Vivek Gautam
2019-06-24 10:28           ` Vivek Gautam
2019-06-24 17:03           ` Will Deacon
2019-06-24 17:03             ` Will Deacon
2019-06-24 17:03             ` Will Deacon
2019-06-25  7:04             ` Vivek Gautam
2019-06-25  7:04               ` Vivek Gautam
2019-06-25  7:04               ` Vivek Gautam
2019-06-25 13:39               ` Will Deacon
2019-06-25 13:39                 ` Will Deacon
2019-06-25 13:39                 ` Will Deacon
2019-06-26  6:33                 ` Vivek Gautam
2019-06-26  6:33                   ` Vivek Gautam
2019-06-26  6:33                   ` Vivek Gautam
2019-06-26 14:48                   ` Will Deacon
2019-06-26 14:48                     ` Will Deacon
2019-06-26 14:48                     ` Will Deacon
2019-06-27  7:05                     ` Vivek Gautam
2019-06-27  7:05                       ` Vivek Gautam
2019-06-27  7:05                       ` Vivek Gautam
2019-06-14 13:15   ` Marc Gonzalez
2019-06-14 13:15     ` Marc Gonzalez
2019-06-17  9:50     ` Vivek Gautam
2019-06-17  9:50       ` Vivek Gautam
2019-06-17 10:48       ` Marc Gonzalez
2019-06-17 10:48         ` Marc Gonzalez
2019-06-12  7:15 ` [PATCH v3 4/4] arm64: dts/sdm845: Enable FW implemented safe sequence handler on MTP Vivek Gautam
2019-06-12  7:15   ` Vivek Gautam
2019-06-14  4:06   ` Bjorn Andersson
2019-06-14  4:06     ` Bjorn Andersson
2019-06-14  4:06     ` Bjorn Andersson
2019-06-14  9:01     ` Vivek Gautam
2019-06-14  9:01       ` Vivek Gautam
2019-06-14  9:01       ` Vivek Gautam
2019-08-05 22:26   ` Bjorn Andersson
2019-08-05 22:26     ` Bjorn Andersson
2019-08-05 22:26     ` Bjorn Andersson
2019-08-11 16:08     ` Vivek Gautam
2019-08-11 16:08       ` Vivek Gautam
2019-08-11 16:08       ` Vivek Gautam
2019-08-11 19:01       ` Bjorn Andersson
2019-08-11 19:01         ` Bjorn Andersson
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=20190612071554.13573-4-vivek.gautam@codeaurora.org \
    --to=vivek.gautam@codeaurora.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=joro@8bytes.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=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 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.