[RFC PATCH 04/30] iommu/arm-smmu-v3: Add support for PCI ATS

Sunil Kovvuri sunil.kovvuri at gmail.com
Mon Apr 3 04:42:46 PDT 2017


On Mon, Apr 3, 2017 at 3:44 PM, Jean-Philippe Brucker
<jean-philippe.brucker at arm.com> wrote:
> On 03/04/17 09:34, Sunil Kovvuri wrote:
>>> +static size_t arm_smmu_atc_invalidate_domain(struct arm_smmu_domain *smmu_domain,
>>> +                                            unsigned long iova, size_t size)
>>> +{
>>> +       unsigned long flags;
>>> +       struct arm_smmu_cmdq_ent cmd = {0};
>>> +       struct arm_smmu_group *smmu_group;
>>> +       struct arm_smmu_master_data *master;
>>> +       struct arm_smmu_device *smmu = smmu_domain->smmu;
>>> +       struct arm_smmu_cmdq_ent sync_cmd = {
>>> +               .opcode = CMDQ_OP_CMD_SYNC,
>>> +       };
>>> +
>>> +       spin_lock_irqsave(&smmu_domain->groups_lock, flags);
>>> +
>>> +       list_for_each_entry(smmu_group, &smmu_domain->groups, domain_head) {
>>> +               if (!smmu_group->ats_enabled)
>>> +                       continue;
>>
>> If ATS is not supported, this seems to increase no of cycles spent in
>> pgtbl_lock.
>> Can we return from this API by checking 'ARM_SMMU_FEAT_ATS' in smmu->features ?
>
> Sure, I can add a check before taking the lock. Have you been able to
> observe a significant difference in cycles between checking FEAT_ATS,
> checking group->ats_enabled after taking the lock, and removing this
> function call altogether?
>
> Thanks,
> Jean-Philippe

No, I haven't verified, was just making an observation.

Thanks,
Sunil.



More information about the linux-arm-kernel mailing list