Hi,
On Tue, Dec 15, 2020 at 01:09:29AM +0000, Krishna Reddy wrote:
> Hi Jean,
>
> > +bool arm_smmu_master_sva_supported(struct arm_smmu_master *master) {
> > + if (!(master->smmu->features & ARM_SMMU_FEAT_SVA))
> > + return false;
> +
> > + /* SSID and IOPF support are mandatory for the moment */
> > + return master->ssid_bits && arm_smmu_iopf_supported(master); }
> > +
>
> Tegra Next Gen SOC has arm-smmu-v3 and It doesn't have support for PRI interface.
> However, PCIe client device has capability to handle the page faults on its own when the ATS translation fails.
> The PCIe device needs SVA feature enable without PRI interface supported at arm-smmu-v3.
> At present, the SVA feature enable is allowed only if the smmu/client device has PRI support.
> There seem to be no functional reason to make pri_supported as a pre-requisite for SVA enable.
The pri_supported check allows drivers to query whether the SMMU is
compatible with their capability. It's pointless, for example, to enable
SVA for a PRI-capable device if the SMMU doesn't support PRI.
I agree that we should let a device driver enable SVA if it supports some
form of IOPF. Perhaps we could extract the IOPF capability from
IOMMU_DEV_FEAT_SVA, into a new IOMMU_DEV_FEAT_IOPF feature. Device drivers
that rely on PRI or stall can first check FEAT_IOPF, then FEAT_SVA, and
enable both separately. Enabling FEAT_SVA would require FEAT_IOPF enabled
if supported. Let me try to write this up.
Thanks,
Jean
> Can SVA enable be supported for pri_supported not set case as well?
> Also, It is noticed that SVA enable on Intel doesn't need pri_supported set.
>
> -KR
