All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bibek Kumar Patro <quic_bibekkum@quicinc.com>
To: Robin Murphy <robin.murphy@arm.com>, <robdclark@gmail.com>,
	<will@kernel.org>, <joro@8bytes.org>, <jgg@ziepe.ca>,
	<jsnitsel@redhat.com>, <robh@kernel.org>,
	<krzysztof.kozlowski@linaro.org>, <quic_c_gdjako@quicinc.com>,
	<dmitry.baryshkov@linaro.org>
Cc: <iommu@lists.linux.dev>, <linux-arm-msm@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v16 3/5] iommu/arm-smmu: add support for PRR bit setup
Date: Wed, 30 Oct 2024 18:44:01 +0530	[thread overview]
Message-ID: <531d0144-e027-4589-b4ef-79f02583df8b@quicinc.com> (raw)
In-Reply-To: <2d651f1b-4f51-4984-903f-7f5a14151f84@arm.com>



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@gmail.com>
>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum@quicinc.com>
>> ---
>>   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?

Thanks & regards,
Bibek


> Thanks,
> Robin.
> 
>> +        reg =  arm_smmu_cb_read(smmu, cfg->cbndx, ARM_SMMU_CB_ACTLR);
>> +        reg &= ~GFX_ACTLR_PRR;
>> +        if (set)
>> +            reg |= FIELD_PREP(GFX_ACTLR_PRR, 1);
>> +        arm_smmu_cb_write(smmu, cfg->cbndx, ARM_SMMU_CB_ACTLR, reg);
>> +    }
>> +}
>> +
>> +static void qcom_adreno_smmu_set_prr_addr(const void *cookie, 
>> phys_addr_t page_addr)
>> +{
>> +    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;
>> +
>> +    if (of_device_is_compatible(np, "qcom,smmu-500") &&
>> +            of_device_is_compatible(np, "qcom,adreno-smmu")) {
>> +        writel_relaxed(lower_32_bits(page_addr),
>> +                    smmu->base + ARM_SMMU_GFX_PRR_CFG_LADDR);
>> +
>> +        writel_relaxed(upper_32_bits(page_addr),
>> +                    smmu->base + ARM_SMMU_GFX_PRR_CFG_UADDR);
>> +    }
>> +}
>> +
>>   #define QCOM_ADRENO_SMMU_GPU_SID 0
>>
>>   static bool qcom_adreno_smmu_is_gpu_device(struct device *dev)
>> @@ -249,6 +284,8 @@ static int qcom_adreno_smmu_init_context(struct 
>> arm_smmu_domain *smmu_domain,
>>       priv->get_fault_info = qcom_adreno_smmu_get_fault_info;
>>       priv->set_stall = qcom_adreno_smmu_set_stall;
>>       priv->resume_translation = qcom_adreno_smmu_resume_translation;
>> +    priv->set_prr_bit = qcom_adreno_smmu_set_prr_bit;
>> +    priv->set_prr_addr = qcom_adreno_smmu_set_prr_addr;
>>
>>       return 0;
>>   }
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/ 
>> arm/arm-smmu/arm-smmu.h
>> index e2aeb511ae90..2dbf3243b5ad 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
>> @@ -154,6 +154,8 @@ enum arm_smmu_cbar_type {
>>   #define ARM_SMMU_SCTLR_M        BIT(0)
>>
>>   #define ARM_SMMU_CB_ACTLR        0x4
>> +#define ARM_SMMU_GFX_PRR_CFG_LADDR    0x6008
>> +#define ARM_SMMU_GFX_PRR_CFG_UADDR    0x600C
>>
>>   #define ARM_SMMU_CB_RESUME        0x8
>>   #define ARM_SMMU_RESUME_TERMINATE    BIT(0)
>> diff --git a/include/linux/adreno-smmu-priv.h b/include/linux/adreno- 
>> smmu-priv.h
>> index c637e0997f6d..03466eb16933 100644
>> --- a/include/linux/adreno-smmu-priv.h
>> +++ b/include/linux/adreno-smmu-priv.h
>> @@ -49,7 +49,13 @@ struct adreno_smmu_fault_info {
>>    *                 before set_ttbr0_cfg().  If stalling on fault is 
>> enabled,
>>    *                 the GPU driver must call resume_translation()
>>    * @resume_translation: Resume translation after a fault
>> - *
>> + * @set_prr_bit:   Extendible interface to be used by GPU to modify the
>> + *           ACTLR register bits, currently used to configure
>> + *           Partially-Resident-Region (PRR) bit for feature's
>> + *           setup and reset sequence as requested.
>> + * @set_prr_addr:  Configure the PRR_CFG_*ADDR register with the
>> + *           physical address of PRR page passed from
>> + *           GPU driver.
>>    *
>>    * The GPU driver (drm/msm) and adreno-smmu work together for 
>> controlling
>>    * the GPU's SMMU instance.  This is by necessity, as the GPU is 
>> directly
>> @@ -67,6 +73,8 @@ struct adreno_smmu_priv {
>>       void (*get_fault_info)(const void *cookie, struct 
>> adreno_smmu_fault_info *info);
>>       void (*set_stall)(const void *cookie, bool enabled);
>>       void (*resume_translation)(const void *cookie, bool terminate);
>> +    void (*set_prr_bit)(const void *cookie, bool set);
>> +    void (*set_prr_addr)(const void *cookie, phys_addr_t page_addr);
>>   };
>>
>>   #endif /* __ADRENO_SMMU_PRIV_H */
>> -- 
>> 2.34.1
>>



  reply	other threads:[~2024-10-30 13:31 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-08 12:54 [PATCH v16 0/5] iommu/arm-smmu: introduction of ACTLR implementation for Qualcomm SoCs Bibek Kumar Patro
2024-10-08 12:54 ` [PATCH v16 1/5] iommu/arm-smmu: re-enable context caching in smmu reset operation Bibek Kumar Patro
2024-10-24 12:52   ` Will Deacon
2024-10-25 14:21     ` Bibek Kumar Patro
2024-10-29 12:47       ` Will Deacon
2024-10-29 13:25         ` Robin Murphy
2024-10-30 11:30         ` Bibek Kumar Patro
2024-11-01 12:10           ` Will Deacon
2024-11-04  6:31             ` Bibek Kumar Patro
2024-11-04 11:10         ` Dmitry Baryshkov
2024-11-05 11:37           ` Will Deacon
2024-11-06  7:40             ` Dmitry Baryshkov
2024-10-28 21:12   ` Rob Clark
2024-10-08 12:54 ` [PATCH v16 2/5] iommu/arm-smmu: refactor qcom_smmu structure to include single pointer Bibek Kumar Patro
2024-10-28 21:13   ` Rob Clark
2024-10-08 12:54 ` [PATCH v16 3/5] iommu/arm-smmu: add support for PRR bit setup Bibek Kumar Patro
2024-10-28 21:13   ` Rob Clark
2024-10-29 13:29   ` Robin Murphy
2024-10-30 13:14     ` Bibek Kumar Patro [this message]
2024-10-30 15:23       ` Robin Murphy
2024-10-30 16:58         ` Rob Clark
2024-10-30 20:27           ` Bibek Kumar Patro
2024-10-08 12:54 ` [PATCH v16 4/5] iommu/arm-smmu: introduction of ACTLR for custom prefetcher settings Bibek Kumar Patro
2024-10-09 19:02   ` Dmitry Baryshkov
2024-10-28 21:14   ` Rob Clark
2024-10-08 12:54 ` [PATCH v16 5/5] iommu/arm-smmu: add ACTLR data and support for qcom_smmu_500 Bibek Kumar Patro
2024-10-28 21:16   ` Rob Clark
2024-10-29 12:40     ` Bibek Kumar Patro
2024-10-29 13:36   ` Robin Murphy
2024-10-23 19:07 ` [PATCH v16 0/5] iommu/arm-smmu: introduction of ACTLR implementation for Qualcomm SoCs Bibek Kumar Patro

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=531d0144-e027-4589-b4ef-79f02583df8b@quicinc.com \
    --to=quic_bibekkum@quicinc.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=jsnitsel@redhat.com \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_c_gdjako@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.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: 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.