[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65132b36-49f6-4b08-8e7d-6d6cb8da5960@arm.com>
Date: Wed, 30 Oct 2024 15:23:28 +0000
From: Robin Murphy <robin.murphy@....com>
To: Bibek Kumar Patro <quic_bibekkum@...cinc.com>, robdclark@...il.com,
will@...nel.org, joro@...tes.org, jgg@...pe.ca, jsnitsel@...hat.com,
robh@...nel.org, krzysztof.kozlowski@...aro.org, quic_c_gdjako@...cinc.com,
dmitry.baryshkov@...aro.org
Cc: iommu@...ts.linux.dev, linux-arm-msm@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v16 3/5] iommu/arm-smmu: add support for PRR bit setup
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@...il.com>
>>> Signed-off-by: Bibek Kumar Patro <quic_bibekkum@...cinc.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?
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.
Powered by blists - more mailing lists