Re: [PATCH v16 3/5] iommu/arm-smmu: add support for PRR bit setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30/10/2024 1:14 pm, Bibek Kumar Patro wrote:


On 10/29/2024 6:59 PM, Robin Murphy wrote:
On 2024-10-08 1:54 pm, Bibek Kumar Patro wrote:
Add an adreno-smmu-priv interface for drm/msm to call
into arm-smmu-qcom and initiate the PRR bit setup or reset
sequence as per request.

This will be used by GPU to setup the PRR bit and related
configuration registers through adreno-smmu private
interface instead of directly poking the smmu hardware.

Suggested-by: Rob Clark <robdclark@xxxxxxxxx>
Signed-off-by: Bibek Kumar Patro <quic_bibekkum@xxxxxxxxxxx>
---
  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 37 ++++++++++++++++++++++
  drivers/iommu/arm/arm-smmu/arm-smmu.h      |  2 ++
  include/linux/adreno-smmu-priv.h           | 10 +++++-
  3 files changed, 48 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 6e0a2a43e45a..38ac9cab763b 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -25,6 +25,7 @@

  #define CPRE            (1 << 1)
  #define CMTLB            (1 << 0)
+#define GFX_ACTLR_PRR        (1 << 5)

  static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device *smmu)
  {
@@ -109,6 +110,40 @@ static void qcom_adreno_smmu_resume_translation(const void *cookie, bool termina
      arm_smmu_cb_write(smmu, cfg->cbndx, ARM_SMMU_CB_RESUME, reg);
  }

+static void qcom_adreno_smmu_set_prr_bit(const void *cookie, bool set)
+{
+    struct arm_smmu_domain *smmu_domain = (void *)cookie;
+    struct arm_smmu_device *smmu = smmu_domain->smmu;
+    const struct device_node *np = smmu->dev->of_node;
+    struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+    u32 reg = 0;
+
+    if (of_device_is_compatible(np, "qcom,smmu-500") &&
+            of_device_is_compatible(np, "qcom,adreno-smmu")) {

These conditions aren't going to change between calls - wouldn't it make more sense to conditionally assign the callbacks in the first place? Not the biggest deal if this is a one-off context-setup type thing, just that it looks a little funky.


Let me know if you want to pursue this still.
 From the current PRR implementation in the graphics
vendor layer, this seems to be just setup kind-of thing.
Also if we keep this conditional check before assigning callbacks,
and vendor layer caller won't be having any such check,
wouldn't it be an issue in unsupported platforms (!qcom,smmu-500 or !qcom,adreno-smmu)
as the callbacks won't be assigned?
So as per my understanding I think it would be safe to keep the condition check here?

Like I say, it makes more sense to me personally if SMMUs which don't have a PRR don't offer a callback for setting the PRR which they don't have, and for it to be the caller's responsibility not to call a NULL callback where they wouldn't need to call one anyway. But the adreno_priv interface is kind of Rob's thing, so I'll leave it to his preference.

Thanks,
Robin.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux