[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